服务网格（如Istio）与微服务的均匀驱动架构

Question

Hi Microservices Gurus，

我对微服务的服务到服务通信体系结构有疑问。 Istio或任何服务网格都可以使微服务通信的路由，发现和弹性易于管理。但是，它没有涵盖跨越一个以上微服务（分布式事务的一种）的事务的重要方面，该事务很好地包含在基于事件的微服务体系结构中。但是，显然，事件驱动的体系结构缺少服务网格覆盖的方面。因此，我想知道，这是更好的方法，还是可以将服务网格与事件驱动的体系结构混合使用，以利用两种模式的优势。但是，如果这种混合是可能的，那么事件驱动的总线（例如Kafka）将不会干扰Istio使用的侧车代理/控制平面的内部工作模式。

Answer 1

您正在混淆几件事。

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

但是服务网格无法解决使用Kafka或任何其他消息代理解决的任何其他服务间数据交换问题。您的微服务甚至可以被驱动-服务网格将不会对此产生干扰。

Answer 2

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

• Apache Kafka解耦服务，包括事件流和请求-响应
• Kubernetes为Kafka生态系统提供云原生基础架构
• Service Mesh在生态系统/组织范围内帮助提高安全性和可观察性
• 诸如Envoy和Istio之类的Service Mesh框架位于Kafka之上的层中，并且与Kafka的目标正交。

请查看我写的以下材料（博客文章，幻灯片，视频记录），其中涵盖了这些概念以及它们的更详细结合：

博客文章：Service Mesh and Cloud-Native Microservices with Apache Kafka, Kubernetes and Envoy, Istio, Linkerd

幻灯片组：Kafka, Kubernetes, Envoy and Istio

视频录制：Service Mesh and Event Driven Architectures like Apache Kafka

Answer 3

您的问题是服务网格不能涵盖跨越一个以上微服务（分布式事务的一种）的事务的重要方面，这在基于事件的微服务体系结构中很好地包含了，那是不正确的。服务网格在分布式微服务通信方面处理得很好，但服务网格可以很好地支持同步RESTful和常规的请求-响应交互，它不支持异步的，事件驱动的交互，也不适合将云原生的微服务与旧版应用程序。对于事件驱动的体系结构，您必须看起来像事件网格而不是服务网格。查看链接...

https://solace.com/use-cases/event-mesh/