基于事件驅動機制，在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數據平面上，因此可以為所有事件驅動的消息傳遞系統部署指標、跟蹤和開箱即用的日志記錄。

關于作者

Kasun Indrasiri是WSO2的集成架構總監，是微服務架構和企業集成架構的作者/傳播者。 他撰寫了“微服務企業（Apress）和開始WSO2 ESB（Apress）”一書。 他是Apache提交者，曾擔任WSO2 Enterprise Integrator的產品經理和架構師。 他曾參加過O'Reilly軟件架構大會，GOTO芝加哥2019大會以及大多數WSO2會議。 他參加了舊金山灣區的大部分微服務會議。 他創建了硅谷微服務，API和集成會議，這是灣區的供應商中立的微服務會議。

本文由博云研究院原創翻譯發表，轉載請注明出處。