基於事件驅動機制，在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和整合會議，這是灣區的供應商中立的微服務會議。
本文由博雲研究院原創翻譯發表，轉載請註明出處。·