基於事件驅動機制，在Service Mesh中進行消息傳遞的探討

關鍵點

• 當前流行的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和集成會議，這是灣區的供應商中立的微服務會議。

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