[译] 使用服务网格进行事件驱动消息的潜力

原文转载自 「敖小剑的博客」 ( https://skyao.io/post/201905-service-mesh-event-driven-messaging/ ) By 敖小剑

预计阅读时间 0 分钟(共 0 个字, 0 张图片, 0 个链接)

备注:英文原文来自InfoQ网站文章 The Potential for Using a Service Mesh for Event-Driven Messaging

关键点

正文

作为基础技术和基于微服务和云原生架构的架构模式,服务网格越来越受欢迎。服务网格主要是一个网络基础设施组件,允许从基于微服务的应用程序下放网络通信逻辑,以便完全专注于服务的业务逻辑。

服务网格围绕代理的概念构建,代理以Sidecar的方式与服务协作。虽然服务网格通常被宣传为可用于任何云原生应用的平台,但是服务网格的流行实现(Istio / Envoy,Linkerd等)目前仅满足微服务之间同步通信的请求/响应风格。但是,在大多数实用的微服务用例中,服务间通信通过各种模式进行,例如请求/响应(HTTP,gRPC,GraphQL)和事件驱动的消息传递(NATS,Kafka,AMQP)。由于服务网格实现不支持事件驱动的通信,服务网格提供的大多数功能仅可用于同步请求/响应服务 - 事件驱动的微服务必须以服务代码本身的一部分的方式来支持这些功能,这与服务网格架构的目标相矛盾。

服务网格支持事件驱动的通信至关重要。本文着眼于支持服务网格中事件驱动架构的关键问题,以及现有服务网格技术如何尝试解决这些问题。

实现事件驱动的消息机制

在典型的请求/响应同步消息场景中,您将找到一个服务(服务器端)和一个调用该服务的使用者(客户端)。服务网格数据平面充当客户端和服务器端之间的中介。在事件驱动的通信中,通信模式是截然不同的。事件生产者异步地将事件发送到事件代理,生产者和消费者之间没有直接的通信通道。通信风格可以是pub-sub(多个消费者)或基于队列的(单个消费者),并且根据样式,生产者可以分别向主题或队列发送消息。

消费者决定订阅驻留在事件代理中的主题或队列,与生产者完全解耦。当有可用于该主题或队列的新消息时,代理会将这些消息推送给消费者。

有几种方法可以将服务网格抽象用于事件驱动的消息机制。

协议代理Sidecar

协议代理模式构建的基本概念是:所有事件驱动的通信信道(channel)应该通过服务网格数据平面(即,Sidecar代理)。要支持事件驱动的消息协议(如NATS,Kafka或AMQP),您需要构建特定于通信协议的协议处理程序/过滤器,并将其添加到sidecar代理。图1显示了使用服务网格进行事件驱动的消息机制的典型通信模式。

图1: 使用服务网格的事件驱动消息机制

由于大多数事件驱动的通信协议是在TCP之上实现的,因此sidecar代理可以具有构建在TCP之上的协议处理程序/过滤器,以专门处理支持各种消息协议所需的抽象。

生产者微服务(微服务A)必须通过底层消息传递协议(Kafka,NATS,AMQP等)向 Sidecar 发送消息,使用最简单的生产者客户端代码,而 Sidecar 处理与之相关的大多数复杂性。类似地,消费者服务(微服务B)的逻辑也非常简单,而复杂性存在于Sidecar。服务网格提供的抽象可以转换协议。

Envoy 团队目前正致力于根据上述模式实施Envoy代理的Kafka支持。它仍在进行中,但您可以 在GitHub上 跟踪进度。

HTTP桥接Sidecar

我们构建一个HTTP桥接,实现消息和要求的消息传递协议的转换,而不是使用代理来实现事件驱动的消息协议。构建此桥接模式的关键动机之一是大多数事件代理提供 REST API(例如,Kafka REST API)来使用和生成消息。如图2所示,现有的微服务可以简单地通过控制桥接两个协议的 sidecar 来透明地使用底层事件代理的消息系统。sidecar代理主要负责接收 HTTP 请求并将其转换为 Kafka/NATS/AMQP /等。消息,反之亦然。

图2:HTTP桥接允许服务通过HTTP与事件代理通信

同样,您可以使用HTTP桥接器允许基于Kafka/NATS/AMQP的微服务直接与HTTP(或其他请求/响应消息协议)微服务进行通信,如图3所示。在这种情况下,sidecar接收Kafka/NATS/AMQP请求,将它们转发为HTTP,并将HTTP响应转换回Kafka/NATS/AMQP。目前正在努力在Envoy和NATS上添加对此模式的支持(例如,用于Envoy的 AMQP/HTTP BridgeNATS/HTTP Bridge)。

图3:HTTP Bridge允许基于事件驱动消息协议的服务使用HTTP服务

尽管HTTP桥接模式适用于某些用例,但它不足以作为标准方法,在服务网格架构中处理事件驱动的消息传递,因为桥接事件驱动的消息传递协议始终具有请求/响应消息传递协议有限制。它或多或少只是一种可能适用于某些用例的解决方法。

事件驱动的服务网格的关键功能

基于请求/响应式消息传递的传统服务网格的功能,与支持消息范例的服务网格的功能有些不同。以下是支持事件驱动的消息传递的服务网格将提供的一些独特功能:

more_vert