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

因此今天就EventMesh相關(guān)架構(gòu)資料談下自己對EventMesh的理解。

EventMesh概述

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

參考網(wǎng)上另外一個解釋如下：

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

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

在這里我想強調(diào)幾點。

其一EventMesh的底層仍然是事件驅(qū)動架構(gòu)，仍然是消息中間件，其核心是基于消息的異步機制，消息發(fā)布訂閱機制。而傳統(tǒng)的Rest API接口更多的是一種同步調(diào)用模式。通過消息事件機制的引入，可以更好地實現(xiàn)解耦。

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

為什么需要使用EventMesh?

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

當事件驅(qū)動架構(gòu)變?yōu)樵圃碌腅ventMesh后，帶來哪些變化?

實際上這里需要談兩點。

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

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

微眾開源EventMesh架構(gòu)

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

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

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

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

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

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

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

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

事件能力對外發(fā)布

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

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

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

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

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

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

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

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

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

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

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

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

關(guān)鍵組件和分層架構(gòu)

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

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

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

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

對EventMesh的簡單總結(jié)

最后再簡單做下總結(jié)。

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

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

事件驅(qū)動架構(gòu)下，對于多語言，多環(huán)境，私有云和公有云的混合云管理和協(xié)同，物聯(lián)網(wǎng)硬件設備的接口協(xié)同等提供了更好的支持和適配能力。這個本身是事件驅(qū)動架構(gòu)的優(yōu)勢。

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