Service Mesh（如Istio）vs甚至驱动的微服务架构

Question

嗨微服务大师，

我对微服务的服务通信架构提出了质疑。 Istio或任何服务网格可以使微服务通信的路由，发现和弹性易于管理。但是，它不包括跨越多个微服务（一种分布式事务）的事务的重要方面，这些微服务很好地包含在微服务的基于事件的体系结构中。然而，显然，事件驱动架构错过了服务网格覆盖的方面。所以，想知道，这是更好的方法，或者可以有一种方法将服务网格与事件驱动架构相结合，以利用两种模式的优势。但如果这种混合是可能的，那么事件驱动的总线（如Kafka）不会干扰Istio使用的侧面车辆代理/控制平面的内部工作模式。

Answer 1

你混淆了几件事。

• Istio，linkerd等解决了云原生集装箱微服务带来的一些基本设计/架构问题。例如服务发现，断路器等。这些问题曾经使用嵌入应用程序中的库来解决，如Spring云，hystrix，功能区等。服务网格在容器世界的范例内解决了这个问题。

但Service Meshes不能解决使用Kafka或任何其他消息代理解决的任何其他服务间数据交换问题。您的微服务甚至可以被驱动 - 服务网格不会干扰它。

Answer 2

您的问题是服务网格不包括跨越多个微服务（一种分布式事务）的事务的重要方面，这些微服务很好地包含在微服务的基于事件的体系结构中，这是不正确的。 Service Mesh在分布式微服务通信方面处理得很好但是服务网络很好地支持同步RESTful和一般请求 - 回复交互，它不支持异步，事件驱动的交互，也不适合连接云原生微服务遗留应用程序对于事件驱动的体系结构，您必须使用Event Mesh而不是Service Mesh来查看系统。看看链接......

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