翻譯 | 宋松
原文 | https://www.infoq.com/articles/service-mesh-event-driven-messaging
關(guān)鍵點
·當(dāng)前流行的Service Mesh實現(xiàn)（Istio，Linkerd，Consul Connect等）僅滿足微服務(wù)之間的請求 - 響應(yīng)式同步通信。
·為了推進和采用Service Mesh，我們認為支持事件驅(qū)動或基于消息的通信是至關(guān)重要的。
·在Service Mesh中實現(xiàn)消息傳遞支持有兩種主要的體系結(jié)構(gòu)模式；協(xié)議代理sidecar，它是來自消費者和生產(chǎn)者的所有入站和出站事件的代理；以及HTTP bridge sidecar，它將事件驅(qū)動的通信協(xié)議轉(zhuǎn)換為HTTP或類似的協(xié)議。
·不管使用哪種bridge模式，sidecar都可以促進跨功能特性的實現(xiàn)(和糾正抽象)，比如可觀察性、節(jié)流、跟蹤等。
Service Mesh作為基礎(chǔ)技術(shù)和基于微服務(wù)、云原生架構(gòu)的架構(gòu)模式越來越受歡迎。 Service Mesh主要是一個網(wǎng)絡(luò)基礎(chǔ)結(jié)構(gòu)組件，允許您從基于微服務(wù)的應(yīng)用程序卸載網(wǎng)絡(luò)通信邏輯，以便您可以完全專注于服務(wù)的業(yè)務(wù)邏輯。
Service Mesh是圍繞代理的概念構(gòu)建的，代理與服務(wù)作為sidecar進行協(xié)作。雖然Service Mesh常常被宣傳為任何云原生應(yīng)用程序的平臺，但目前流行的Service Mesh實現(xiàn)（Istio/Envoy、Linkerd等）只滿足微服務(wù)之間同步通信的request/response風(fēng)格。但是，在大多數(shù)實用的微服務(wù)用例中，服務(wù)間通信通過各種模式進行，例如request/response（HTTP，gRPC，GraphQL）和事件驅(qū)動的消息傳遞（NATS，Kafka，AMQP）。 由于Service Mesh實現(xiàn)不支持事件驅(qū)動的通信，Service Mesh提供的大多數(shù)商品功能僅可用于同步request/response服務(wù) - 事件驅(qū)動的微服務(wù)必須支持這些功能作為服務(wù)代碼本身的一部分，這與Service Mesh架構(gòu)的目標(biāo)相矛盾。
Service Mesh支持事件驅(qū)動的通信至關(guān)重要。本文著眼于支持Service Mesh中事件驅(qū)動架構(gòu)的關(guān)鍵方面，以及現(xiàn)有Service Mesh技術(shù)如何嘗試解決這些問題。
實現(xiàn)事件驅(qū)動的消息傳遞
在典型的request/response同步消息傳遞方案中，您將找到一個服務(wù)（服務(wù)器）和一個調(diào)用該服務(wù)的使用者（客戶端）。 Service Mesh數(shù)據(jù)平面充當(dāng)客戶端和服務(wù)之間的中介。 在事件驅(qū)動的通信中，通信模式是截然不同的。 事件生成器異步地將事件發(fā)送到事件代理，生成器和使用者之間沒有直接的通信通道。 通信風(fēng)格可以是pub-sub（多個使用者）或基于隊列的（單個使用者），并且根據(jù)樣式，生產(chǎn)者可以分別向主題或隊列發(fā)送消息。
消費者決定訂閱駐留在事件代理中的主題或隊列，該事件代理與生產(chǎn)者完全分離。 當(dāng)有可用于該主題或隊列的新消息時，代理會將這些消息推送給使用者。
有幾種方法可以將Service Mesh抽象用于事件驅(qū)動的消息傳遞。
01 Protocol-proxy sidecar
協(xié)議代理模式圍繞所有事件驅(qū)動的通信信道應(yīng)該通過Service Mesh數(shù)據(jù)平面（即，邊車代理）的概念構(gòu)建。 為了支持事件驅(qū)動的消息傳遞協(xié)議（如NATS，Kafka或AMQP），您需要構(gòu)建特定于通信協(xié)議的協(xié)議處理程序/過濾器，并將其添加到sidecar代理。 圖1顯示了使用service mesh進行事件驅(qū)動的消息傳遞的典型通信模式。
重慶分公司
重慶分公司
圖1：使用service mesh的事件驅(qū)動的消息傳遞由于大多數(shù)事件驅(qū)動的通信協(xié)議都是在TCP之上實現(xiàn)的，所以sidecar代理可以在TCP之上構(gòu)建協(xié)議處理程序/過濾器，以專門處理支持各種消息傳遞協(xié)議所需的抽象。
生產(chǎn)者微服務(wù)（微服務(wù)A）必須通過底層消息傳遞協(xié)議（Kafka，NATS，AMQP等）向side car發(fā)送消息，使生產(chǎn)者客戶端使用最簡單的代碼，而side car去處理與協(xié)議相關(guān)的大部分的復(fù)雜性。Envoy團隊目前正在基于上述模式實現(xiàn)對Envoy代理的Kafka支持。它仍在進行中，但你可以在GitHub上跟蹤進展。
02
HTTP-bridge sidecar
不需要為事件驅(qū)動的消息傳遞協(xié)議使用代理，我們可以構(gòu)建一個HTTP bridge來轉(zhuǎn)換需要消息協(xié)議的消息（to/from）。構(gòu)建此橋接模式的關(guān)鍵動機之一是大多數(shù)事件代理提供REST API（例如，Kafka REST API）來使用和生成消息。如圖2所示，通過控制連接兩個協(xié)議的sidecar，現(xiàn)有的微服務(wù)可以透明地使用底層事件代理的消息傳遞系統(tǒng)。sidecar代理主要負責(zé)接收HTTP請求并將其轉(zhuǎn)換為Kafka/NATS/AMQP/等。消息，反之亦然。
圖2：HTTP bridge允許服務(wù)通過HTTP與事件代理通信同樣，您可以使用HTTP橋接器允許基于Kafka / NATS / AMQP的微服務(wù)直接與HTTP（或其他request/response消息傳遞協(xié)議）微服務(wù)進行通信，如圖3所示。在這種情況下，sidecar接收Kafka / NATS / AMQP 請求，將它們轉(zhuǎn)發(fā)為HTTP，并將HTTP響應(yīng)轉(zhuǎn)換回Kafka / NATS / AMQP。目前正在努力在Envoy和NATS上添加對此模式的支持（例如，AMQP / HTTP Bridge和NATS / HTTP Bridge，都在Envoy做此種模式的支持）。
圖3：HTTP Bridge允許基于事件驅(qū)動的消息傳遞協(xié)議的服務(wù)使用HTTP服務(wù)
盡管HTTP-bridge模式適用于某些用例，但它還不夠強大，不能作為service mesh體系結(jié)構(gòu)中處理事件驅(qū)動消息傳遞的標(biāo)準(zhǔn)。因為對于基于request/response的事件驅(qū)動消息協(xié)議來說總是存在一些限制。它或多或少是一種適用于某些用例的方法。
事件驅(qū)動service mesh的關(guān)鍵功能
基于request/response樣式消息傳遞的傳統(tǒng)service mesh的功能與支持消息傳遞范例的service mesh的功能有些不同。以下是一個支持事件驅(qū)動消息傳遞的service mesh將提供的一些獨特功能：
· 消費者和生產(chǎn)者抽象：對于大多數(shù)消息傳遞系統(tǒng)，比如Kafka，代理本身是相當(dāng)抽象和簡單的(微服務(wù)上下文中的啞管道)，而您的服務(wù)是智能端點(大多數(shù)智能都存在于生產(chǎn)者或消費者代碼中)。這意味著生產(chǎn)者或消費者必須在業(yè)務(wù)邏輯旁邊有大量的消息協(xié)議代碼。通過引入service mesh，您可以將與消息傳遞協(xié)議相關(guān)的特性(例如Kafka中的分區(qū)再平衡)轉(zhuǎn)移到sidecar，并完全專注于微服務(wù)代碼中的業(yè)務(wù)邏輯。
· 消息傳遞語義：有很多消息傳遞語義，比如“至多一次”、“至少一次”、“恰好一次”等等。根據(jù)底層消息傳遞系統(tǒng)所支持的內(nèi)容，可以將這些任務(wù)轉(zhuǎn)移到Service Mesh(這類似于在request/response范例中支持斷路器、超時等)。
· 訂閱語義：還可以使用service-mesh層來處理訂閱語義，例如消費者端邏輯的持久訂閱。
· 限流：可以根據(jù)各種參數(shù)（如消息數(shù)量，消息大小等）控制和管理消息限制（速率限制）。
·服務(wù)發(fā)現(xiàn)(代理、主題和隊列發(fā)現(xiàn))：Service -mesh sidecar允許你在消息生產(chǎn)和使用期間發(fā)現(xiàn)代理位置、主題或隊列名稱。這涉及到處理不同的主題層次結(jié)構(gòu)和通配符。
· 消息驗證：驗證用于事件驅(qū)動消息傳遞的消息變得越來越重要，因為大多數(shù)消息傳遞協(xié)議(如Kafka、NATS等)都協(xié)議無關(guān)的。因此，消息驗證是使用者或生產(chǎn)者實現(xiàn)的一部分。Service Mesh可以提供這種抽象，以便使用者或生產(chǎn)者可以轉(zhuǎn)移消息驗證。例如，如果您將Kafka和Avro一起用于模式驗證，那么您可以使用sidecar進行驗證(即，從外部scheme注冊表(如Confluent)獲取模式，并根據(jù)該模式驗證消息)。您還可以使用它來檢查消息中的惡意內(nèi)容。
· 消息壓縮：某些基于事件的消息傳遞協(xié)議，如Kafka，允許數(shù)據(jù)被生產(chǎn)者壓縮，以壓縮格式寫入服務(wù)器，并被消費者解壓。您可以很容易地在sidecar-proxy級別實現(xiàn)這些功能，并在service-mesh控制平面上控制它們。
· 安全性：您可以通過在service-mesh sidecar級別啟用TLS來保護代理和消費者/生產(chǎn)者之間的通信，這樣您的生產(chǎn)者和消費者實現(xiàn)就不需要擔(dān)心安全通信，而可以用純文本與sidecar通信。
· 可觀察性：由于所有通信都發(fā)生在service-mesh數(shù)據(jù)平面上，因此可以為所有事件驅(qū)動的消息傳遞系統(tǒng)部署指標(biāo)、跟蹤和開箱即用的日志記錄。
關(guān)于作者
Kasun Indrasiri是WSO2的集成架構(gòu)總監(jiān)，是微服務(wù)架構(gòu)和企業(yè)集成架構(gòu)的作者/傳播者。 他撰寫了“微服務(wù)企業(yè)（Apress）和開始WSO2 ESB（Apress）”一書。 他是Apache提交者，曾擔(dān)任WSO2 Enterprise Integrator的產(chǎn)品經(jīng)理和架構(gòu)師。 他曾參加過O'Reilly軟件架構(gòu)大會，GOTO芝加哥2019大會以及大多數(shù)WSO2會議。 他參加了舊金山灣區(qū)的大部分微服務(wù)會議。 他創(chuàng)建了硅谷微服務(wù)，API和集成會議，這是灣區(qū)的供應(yīng)商中立的微服務(wù)會議。
本文由博云研究院原創(chuàng)翻譯發(fā)表，轉(zhuǎn)載請注明出處。
另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機、免備案服務(wù)器”等云主機租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。
