基于事件驱动机制，在Service Mesh中进行消息传递的探讨

翻译 | 宋松

原文 | https://www.infoq.com/articles/service-mesh-event-driven-messaging

 

关键点

 

• 当前流行的Service Mesh实现（Istio，Linkerd，Consul Connect等）仅知足微服务之间的请求 - 响应式同步通讯。

• 为了推动和采用Service Mesh，咱们认为支持事件驱动或基于消息的通讯是相当重要的。

• 在Service Mesh中实现消息传递支持有两种主要的体系结构模式；协议代理sidecar，它是来自消费者和生产者的全部入站和出站事件的代理；以及HTTP bridge sidecar，它将事件驱动的通讯协议转换为HTTP或相似的协议。

• 无论使用哪一种bridge模式，sidecar均可以促进跨功能特性的实现(和纠正抽象)，好比可观察性、节流、跟踪等。

 

 

Service Mesh做为基础技术和基于微服务、云原生架构的架构模式愈来愈受欢迎。 Service Mesh主要是一个网络基础结构组件，容许您从基于微服务的应用程序卸载网络通讯逻辑，以便您能够彻底专一于服务的业务逻辑。

 

Service Mesh是围绕代理的概念构建的，代理与服务做为sidecar进行协做。虽然Service Mesh经常被宣传为任何云原生应用程序的平台，但目前流行的Service Mesh实现（Istio/Envoy、Linkerd等）只知足微服务之间同步通讯的request/response风格。可是，在大多数实用的微服务用例中，服务间通讯经过各类模式进行，例如request/response（HTTP，gRPC，GraphQL）和事件驱动的消息传递（NATS，Kafka，AMQP）。 因为Service Mesh实现不支持事件驱动的通讯，Service Mesh提供的大多数商品功能仅可用于同步request/response服务 - 事件驱动的微服务必须支持这些功能做为服务代码自己的一部分，这与Service Mesh架构的目标相矛盾。

 

Service Mesh支持事件驱动的通讯相当重要。本文着眼于支持Service Mesh中事件驱动架构的关键方面，以及现有Service Mesh技术如未尝试解决这些问题。

 

 

实现事件驱动的消息传递

 

在典型的request/response同步消息传递方案中，您将找到一个服务（服务器）和一个调用该服务的使用者（客户端）。 Service Mesh数据平面充当客户端和服务之间的中介。 在事件驱动的通讯中，通讯模式是大相径庭的。 事件生成器异步地将事件发送到事件代理，生成器和使用者之间没有直接的通讯通道。 通讯风格能够是pub-sub（多个使用者）或基于队列的（单个使用者），而且根据样式，生产者能够分别向主题或队列发送消息。

 

消费者决定订阅驻留在事件代理中的主题或队列，该事件代理与生产者彻底分离。 当有可用于该主题或队列的新消息时，代理会将这些消息推送给使用者。

 

有几种方法能够将Service Mesh抽象用于事件驱动的消息传递。

 

 

01 Protocol-proxy sidecar

 

协议代理模式围绕全部事件驱动的通讯信道应该经过Service Mesh数据平面（即，边车代理）的概念构建。 为了支持事件驱动的消息传递协议（如NATS，Kafka或AMQP），您须要构建特定于通讯协议的协议处理程序/过滤器，并将其添加到sidecar代理。 图1显示了使用service mesh进行事件驱动的消息传递的典型通讯模式。

 

 

                                       图1：使用service mesh的事件驱动的消息传递

 

因为大多数事件驱动的通讯协议都是在TCP之上实现的，因此sidecar代理能够在TCP之上构建协议处理程序/过滤器，以专门处理支持各类消息传递协议所需的抽象。

 

生产者微服务（微服务A）必须经过底层消息传递协议（Kafka，NATS，AMQP等）向side car发送消息，使生产者客户端使用最简单的代码，而side car去处理与协议相关的大部分的复杂性。Envoy团队目前正在基于上述模式实现对Envoy代理的Kafka支持。它仍在进行中，但你能够在GitHub上跟踪进展。

 

02 HTTP-bridge sidecar

 

不须要为事件驱动的消息传递协议使用代理，咱们能够构建一个HTTP bridge来转换须要消息协议的消息（to/from）。构建此桥接模式的关键动机之一是大多数事件代理提供REST API（例如，Kafka REST API）来使用和生成消息。如图2所示，经过控制链接两个协议的sidecar，现有的微服务能够透明地使用底层事件代理的消息传递系统。sidecar代理主要负责接收HTTP请求并将其转换为Kafka/NATS/AMQP/等。消息，反之亦然。

 

                           图2：HTTP bridge容许服务经过HTTP与事件代理通讯

 

一样，您可使用HTTP桥接器容许基于Kafka / NATS / AMQP的微服务直接与HTTP（或其余request/response消息传递协议）微服务进行通讯，如图3所示。在这种状况下，sidecar接收Kafka / NATS / AMQP 请求，将它们转发为HTTP，并将HTTP响应转换回Kafka / NATS / AMQP。目前正在努力在Envoy和NATS上添加对此模式的支持（例如，AMQP / HTTP Bridge和NATS / HTTP Bridge，都在Envoy作此种模式的支持）。

 

 

               图3：HTTP Bridge容许基于事件驱动的消息传递协议的服务使用HTTP服务

 

尽管HTTP-bridge模式适用于某些用例，但它还不够强大，不能做为service mesh体系结构中处理事件驱动消息传递的标准。由于对于基于request/response的事件驱动消息协议来讲老是存在一些限制。它或多或少是一种适用于某些用例的方法。

 

 

事件驱动service mesh的关键功能

 

基于request/response样式消息传递的传统service mesh的功能与支持消息传递范例的service mesh的功能有些不一样。如下是一个支持事件驱动消息传递的service mesh将提供的一些独特功能：

 

• 消费者和生产者抽象：对于大多数消息传递系统，好比Kafka，代理自己是至关抽象和简单的(微服务上下文中的哑管道)，而您的服务是智能端点(大多数智能都存在于生产者或消费者代码中)。这意味着生产者或消费者必须在业务逻辑旁边有大量的消息协议代码。经过引入service mesh，您能够将与消息传递协议相关的特性(例如Kafka中的分区再平衡)转移到sidecar，并彻底专一于微服务代码中的业务逻辑。

 

• 消息传递语义：有不少消息传递语义，好比“至多一次”、“至少一次”、“刚好一次”等等。根据底层消息传递系统所支持的内容，能够将这些任务转移到Service Mesh(这相似于在request/response范例中支持断路器、超时等)。

 

• 订阅语义：还可使用service-mesh层来处理订阅语义，例如消费者端逻辑的持久订阅。

 

• 限流：能够根据各类参数（如消息数量，消息大小等）控制和管理消息限制（速率限制）。

 

• 服务发现(代理、主题和队列发现)：Service -mesh sidecar容许你在消息生产和使用期间发现代理位置、主题或队列名称。这涉及处处理不一样的主题层次结构和通配符。

 

• 消息验证：验证用于事件驱动消息传递的消息变得愈来愈重要，由于大多数消息传递协议(如Kafka、NATS等)都协议无关的。所以，消息验证是使用者或生产者实现的一部分。Service Mesh能够提供这种抽象，以便使用者或生产者能够转移消息验证。例如，若是您将Kafka和Avro一块儿用于模式验证，那么您可使用sidecar进行验证(即，从外部scheme注册表(如Confluent)获取模式，并根据该模式验证消息)。您还可使用它来检查消息中的恶意内容。

 

• 消息压缩：某些基于事件的消息传递协议，如Kafka，容许数据被生产者压缩，以压缩格式写入服务器，并被消费者解压。您能够很容易地在sidecar-proxy级别实现这些功能，并在service-mesh控制平面上控制它们。

 

• 安全性：您能够经过在service-mesh sidecar级别启用TLS来保护代理和消费者/生产者之间的通讯，这样您的生产者和消费者实现就不须要担忧安全通讯，而能够用纯文本与sidecar通讯。

 

• 可观察性：因为全部通讯都发生在service-mesh数据平面上，所以能够为全部事件驱动的消息传递系统部署指标、跟踪和开箱即用的日志记录。

 

 

 

本文由博云研究院原创翻译发表，转载请注明出处。