翻譯 | 宋鬆
原文 | 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抽象用於事件驅動的消息傳遞。
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和集成會議，這是灣區的供應商中立的微服務會議。
本文由博雲研究院原創翻譯發表，轉載請註明出處。
相關推薦
加入技術交流羣，添加管理員微信ID : ruffylining ，備註姓名-公司-職位，即可入羣
