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

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

EventMesh概述

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

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

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

可能看了這個(gè)還是不好理解EventMesh。

在這里我想強(qiáng)調(diào)幾點(diǎn)。

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

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

為什么需要使用EventMesh?

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

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

實(shí)際上這里需要談兩點(diǎn)。

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

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

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

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

首先整體EventMesh是可以運(yùn)行在云原生的容器云平臺(tái)上的，底層直接和容器云平臺(tái)對(duì)接。

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

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

對(duì)于EventMesh最核心的還是Runtime運(yùn)行時(shí)。

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

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

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

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

eventmesh-sdk-java：當(dāng)前支持 HTTP 和 TCP 協(xié)議，未來(lái)會(huì)支持 gRPC 等。對(duì)于這點(diǎn)，再展開(kāi)說(shuō)明下。

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

在我們?cè)缙趯?shí)施SOA的業(yè)務(wù)場(chǎng)景中，就存在使用JMS消息中間件來(lái)實(shí)現(xiàn)消息一對(duì)多分發(fā)的場(chǎng)景。在整個(gè)實(shí)現(xiàn)過(guò)程中，我們對(duì)JMS消息進(jìn)行了一層代理和適配。

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

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

在引入EventMesh+微服務(wù)+容器云后可以更好地解決這個(gè)問(wèn)題。

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

其次我們?cè)贛esh中做一層適配，形成一套標(biāo)準(zhǔn)的API接口和訂閱機(jī)制，這樣在消息中間件本身出現(xiàn)變更或替換的時(shí)候，對(duì)業(yè)務(wù)系統(tǒng)影響最小。

同時(shí)對(duì)于消息發(fā)布的能力，我們?cè)谙由厦娣庋b為Http Rest API接口發(fā)布。這樣可以更加方便上層微服務(wù)應(yīng)用的訪問(wèn)和調(diào)用，實(shí)現(xiàn)微服務(wù)和底層消息事件架構(gòu)的融合。

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

簡(jiǎn)單來(lái)說(shuō)消費(fèi)端仍然調(diào)用Rest API Service服務(wù)，但是底層已經(jīng)是異步的消息中間件和事件引擎，并且通過(guò)這個(gè)引擎實(shí)現(xiàn)微服務(wù)間的徹底解耦。

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

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

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

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

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

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

對(duì)EventMesh的簡(jiǎn)單總結(jié)

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

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

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

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

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