共计 3664 个字符，预计需要花费 10 分钟才能阅读完成。
关键点
- 当前流行的 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 上跟踪进展。
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 数据平面上，因此可以为所有事件驱动的消息传递系统部署指标、跟踪和开箱即用的日志记录。
关于作者
Kasun Indrasiri 是 WSO2 的集成架构总监，是微服务架构和企业集成架构的作者 / 传播者。他撰写了“微服务企业（Apress）和开始 WSO2 ESB（Apress）”一书。他是 Apache 提交者，曾担任 WSO2 Enterprise Integrator 的产品经理和架构师。他曾参加过 O ’Reilly 软件架构大会，GOTO 芝加哥 2019 大会以及大多数 WSO2 会议。他参加了旧金山湾区的大部分微服务会议。他创建了硅谷微服务，API 和集成会议，这是湾区的供应商中立的微服务会议。
本文由博云研究院原创翻译发表，转载请注明出处。·
