今天談下EventMesh事件驅動網格，實際在我前面談云原生技術類的文章中對于ServiceMesh服務網關，EDA事件驅動架構都做過詳細介紹。在去年騰訊微眾銀行開源了自己的EventMesh事件驅動網格和金融消息中間件。

因此今天就EventMesh相關架構資料談下自己對EventMesh的理解。

EventMesh概述

EventMesh 是以事件驅動為核心的基礎服務，EventMesh 之于微服務與Service Mesh 具有同等的定位。EventMesh 作為動態的插件式云原生基礎服務層，將應用程序和中間件層分離，并提供了靈活，可靠和快速的事件分發能力，同時可以對事件進行管理，可以作為應用進程的連接層，提供企業實現其數字化轉型目標所需的全套應用進程間通信模式。

參考網上另外一個解釋如下：

事件網格對于事件驅動的應用程序，就好比是服務網格對于 RESTful 應用程序：一個架構層，無論在哪里部署這些應用程序(非云，公有云或者私有云)，都可以動態路由某個應用程序的事件并使其被其他應用程序所接收。事件網格由內部連通的 Event broker(事件代理)網絡來創建和啟用。

可能看了這個還是不好理解EventMesh。

在這里我想強調幾點。

其一EventMesh的底層仍然是事件驅動架構，仍然是消息中間件，其核心是基于消息的異步機制，消息發布訂閱機制。而傳統的Rest API接口更多的是一種同步調用模式。通過消息事件機制的引入，可以更好地實現解耦。

其二就是這類強調了Mesh網格化的概念，即引入EventMesh不應該是再增加一個中心化的節點，而應該是一種類似ServiceMesh中的Sidecar代理模式的方式引入。要做到這點，參考Mesh架構的標準思路，其控制平面和數據平面應該是分離的，這個是Mesh架構的基礎。因此對于EventMesh實現也需要遵循這個原則。

為什么需要使用EventMesh?

這個仍然需要從兩個方面來回答，第一個內容實際本身是為何需要采用EDA事件驅動架構或者CQRS模式要回答的問題。這個問題本身核心還是通過消息機制對于業務的徹底解耦，其次是類似消息1對多發布訂閱，大并發下的削峰處理等。

當事件驅動架構變為云原生下的EventMesh后，帶來哪些變化?

實際上這里需要談兩點。

其一是EventMesh是融入到整個云原生整體技術架構體系框架的，即底層和Kurbernetes和Docker容器云的基礎，上層和當前主流的微服務融合集成。而對于我們傳統談到的消息中間件，變成了一個EventStore。

其二我個人認為引入EventMesh實際是在傳統的容器云底層，消息中間件上層引入了一層抽象和統一適配，讓微服務下對事件機制的使用，包括事件的發布，事件的訂閱更加簡單，同時也統一標準化。其次是在適配層引入對事件本身的治理能力，類似安全，路由等各種事件管控治理能力。

微眾開源EventMesh架構

EventMesh 目前整體的架構如上圖所示，通過以事件驅動為核心的體系結構,實現了應用程序與中間件層的解耦分離。對于這個架構簡單做了理解。

首先整體EventMesh是可以運行在云原生的容器云平臺上的，底層直接和容器云平臺對接。

其次是Connector連接器部分。當前EventMesh通過連接器的方式對接和適配了多個消息中間件，類似Kafka，RocketMQ，微眾自己的金融消息中間件，還有Redis分布式緩存等，這些都作為EventMesh的EventStore。

在原來我們使用消息中間件的時候都知道，對于不同的消息中間件，其發送消息事件，對消息事件訂閱和監聽，具體的API接口和實現方式本身都有差異，而通過EventMesh，我們可以在代理層來屏蔽這些差異，實現底層消息中間件能力的透明化。

對于EventMesh最核心的還是Runtime運行時。

客戶端所發出的事件交予 Runtime 調度的 Connector，將事件存儲到對應的地方。Event Store 進而再由訂閱對應事件的 EventMesh 將事件接收并轉發給所代理的下游客戶端。也就是說在核心引擎部分，可以實現協議轉換，事件路由，消息中間適配，負載均衡，事件鏈路監控，安全等各種治理能力。

而這些能力并不需要消息事件的消費端和訂閱端去提供，而是通過Mesh架構在代理中通過各種插件來實現，這個思路實際和ServiceMesh邊車模式思路一致。

所以EventMesh實現機制中核心并不是將已有的消息中間件能力重新實現一遍，而是在當前主流消息中間件上增加了一個適配層，并在該層完成消息事件的統一管控治理，如果再朝上抽象，還可以進一步做消息事件的組裝編排等。

事件能力對外發布

eventmesh-sdk-java：當前支持 HTTP 和 TCP 協議，未來會支持 gRPC 等。對于這點，再展開說明下。

當我們在采用某種消息中間件的時候，比如RocketMQ消息中間件，你會看到該中間件本身有自己的Java API接口，來實現事件的發布，消息的監聽和訂閱等。如果是在一個微服務架構體系下，那么在業務系統或微服務端，實際是需要安裝和部署一個代理包來實現本地代理。那么當代理包本身有升級的時候，所有的消費端和訂閱端都必須做出配套的修改。

在我們早期實施SOA的業務場景中，就存在使用JMS消息中間件來實現消息一對多分發的場景。在整個實現過程中，我們對JMS消息進行了一層代理和適配。

將JMS消息發布能力封裝為一個標準的Rest API接口服務，這樣消費端就不再需要安裝任何代理組件，直接調用Rest API接口來實現消息發布。

但是對于訂閱端，很難做這種適配，仍然是需要安裝一個代理Jar包，通過傳統的方式來實現消息事件的監聽和訂閱。在這種場景下可以看到，如果需要替換消息中間件，或消息中間件本身代理包版本升級的時候會很麻煩，基本所有的訂閱端都需要配套升級。

在引入EventMesh+微服務+容器云后可以更好地解決這個問題。

對于EventMesh運行引擎組件，我們可以在進行鏡像制作的時候動態下發到鏡像里面，并完成動態部署。這個不再需要人工去操作了。

其次我們在Mesh中做一層適配，形成一套標準的API接口和訂閱機制，這樣在消息中間件本身出現變更或替換的時候，對業務系統影響最小。

同時對于消息發布的能力，我們在消息層上面封裝為Http Rest API接口發布。這樣可以更加方便上層微服務應用的訪問和調用，實現微服務和底層消息事件架構的融合。

如上圖，實際Order訂單微服務仍然是在消費調用Rest API接口，但是這個數據EventMesh在獲取后通過代理適配和路由轉發將其寫入消息中間件，然后CustomerService通過訂閱端標準的能力實現對消息的獲取。

簡單來說消費端仍然調用Rest API Service服務，但是底層已經是異步的消息中間件和事件引擎，并且通過這個引擎實現微服務間的徹底解耦。

注：如果要實現徹底和消息中間件的解耦，那么在訂閱端也不是通過消息中間件的API進行消息監聽和訂閱，而是訂閱端本身提供一個Http Rest API接口來實現消息事件的導入。這個時候Mesh組件可以在獲取消息后，去調用這個API接口能力將數據推送到目標端。當采用這種模式時候，消息中間件徹底演變為一個EventStore作用。

關鍵組件和分層架構

通過上圖可以看出 EventMesh 橫向分為 Control Panel、Data Panel、Store Panel 三層。

整體來說實際的業務系統和Data PanelApp這層進行交互，來失效消息事件的發布，訂閱等，這個時候無須關注底層適配的消息中間件和底層事件存儲邏輯。

在數據層實際是需要實現一個簡單的代理，還是通過邊車的模式將代理包下發到業務系統或微服務層，也就是說最終消息事件的發布，訂閱，整個數據流不應該走到控制層，而是在業務系統和EventStore間之間交互完成，以避免引入一個新的中心點。

但是整個Mesh架構在去中心化的同時需要引入對于消息事件的管控治理能力，其中包括了注冊，路由，安全，監控，度量分析等，這些能力在當前的Control Panel層來實現。Control PanelControl Panel 分為治理模塊、注冊模塊、安全模塊、指標模塊、追蹤定位模塊， 這些模塊都將采用業界通用、優秀的解決方案與 EventMesh 進行對接，進而豐富內容。EventMesh 的生態環境。例如：注冊模塊可對接 Nacos、指標模塊可對接 Prometheus、追蹤定位模塊可對接 SkyWalking 等。

對EventMesh的簡單總結

最后再簡單做下總結。

當采用ServiceMesh的時候，我在談可以通過ServiceMesh來實現一種去中心化的服務治理能力。同樣道理，當采用EventMesh的時候，我們更加希望的是通過這個事件架構來實現去中心化的事件管控治理能力。

對于ServiceMesh的時候，如果一個大應用本身不對外，那么完全可以取消使用API網關，而對于EventMesh可以看到本身無法完全取代消息中間件，更多的是對消息中間件進行適配，將消息中間件能力變成一個EventStore的能力。基于這個思路你可以看到，你也可以完全不用當前消息中間件，而是基于Redis+自研來實現一個去中心化的消息事件管理架構。在這種情況下消息事件管理能力，本身也下移到了各個業務系統代理端來完成，而不是在中心化的消息中間件中完成。

事件驅動架構下，對于多語言，多環境，私有云和公有云的混合云管理和協同，物聯網硬件設備的接口協同等提供了更好的支持和適配能力。這個本身是事件驅動架構的優勢。

最后，EventMesh引擎本身是依托在云原生架構下的，其底層直接托管或部署到容器云上面，其上層又和微服務管理，微服務治理中心進行集成。如果做得好的話，EventMesh引擎本身也是一個對用戶透明的底層引擎能力。