服务网格（如 Istio）与微服务的偶数驱动架构

Question

嗨，微服务大师，

我有一个关于微服务的服务到服务通信架构的问题。Istio 或任何服务网格都可以使微服务通信的路由、发现和弹性易于管理。然而，它没有涵盖跨越一个以上微服务（分布式事务的种类）的事务的重要方面，微服务的基于事件的架构中很好地包含了这一点。然而，显然，事件驱动架构错过了服务网格很好地涵盖的方面。所以，想知道哪种方法更好，或者可以有一种方法将服务网格与事件驱动架构混合使用，以利用这两种模式的优势。但是，如果这种混合是可能的，那么事件驱动的总线（如 Kafka）是否不会干扰 Istio 使用的侧车代理/控制平面的内部工作模式。

Answer 1

服务网格和 Apache Kafka 等事件驱动架构是互补且正交的：

• Apache Kafka 解耦服务，包括事件流和请求响应
• Kubernetes 为 Kafka 生态系统提供云原生基础设施
• 服务网格有助于生态系统/组织规模的安全性和可观察性
• Envoy 和 Istio 等服务网格框架位于 Kafka 之上，与 Kafka 所解决的目标正交

查看我编写的以下材料（博客文章、幻灯片、视频录制），其中更详细地介绍了这些概念及其组合：

博客文章：使用 Apache Kafka、Kubernetes 和 Envoy、Istio、Linkerd 的服务网格和云原生微服务

幻灯片：Kafka、Kubernetes、Envoy 和 Istio

视频录制：服务网格和事件驱动架构，例如 Apache Kafka

Answer 2

你正在混淆几件事。

• Istio、linkerd 等解决了云原生、容器化微服务带来的一些基本设计/架构问题。例如服务发现、断路器等。这些问题过去常常使用嵌入在应用程序中的库来解决，如 Spring cloud、hystrix、ribbon 等。服务网格在容器世界的范式中解决了这个问题。

但是服务网格并没有解决任何其他服务间数据交换问题，这些问题可以使用 Kafka 或任何其他消息代理解决。你的微服务甚至可以被驱动——服务网格不会干扰它。