在 2021 年 11 月 12 日落地的 ArchSummit 全球架構(gòu)師峰會(huì)（深圳站）上，我們邀請(qǐng)了微眾銀行的資深技術(shù)專家陳廣勝為大家?guī)?lái)了《分布式應(yīng)用提效框架 Apache EventMesh》的分享，他從 EventMesh 的特征入手，為大家深入介紹了 EventMesh 在微眾銀行的探索與實(shí)踐。本文為演講整理文章~
今天分享 Apache EventMesh 事件驅(qū)動(dòng)的分布式應(yīng)用運(yùn)行時(shí)，這是一個(gè)比較新的概念，希望可以通過(guò)本次的分享，給大家?guī)?lái)一些啟發(fā)。
我們都了解兩個(gè)概念——消息和事件，消息指的是具體事件的更新，這種更新是從一個(gè)點(diǎn)發(fā)送到另外一個(gè)點(diǎn)之后，消息就會(huì)被刪除，消息是臨時(shí)存在的狀態(tài)；而事件是指在特定時(shí)間發(fā)生的，它并沒(méi)有綁定到具體的接收者或客戶端，它往往是可以被回放、回溯和再加工。
根據(jù) Gartner 的一份報(bào)告顯示，隨著時(shí)間的推移，數(shù)據(jù)的價(jià)值將逐漸減少。在很多實(shí)時(shí)場(chǎng)景下，如果能夠?qū)κ录M(jìn)行實(shí)時(shí)的分析和數(shù)據(jù)挖掘，那將會(huì)帶來(lái)很大的價(jià)值，像現(xiàn)在非常火的流式計(jì)算 Flink、Spark 以及 ClickHouse 等，他們都非常關(guān)注數(shù)據(jù)的實(shí)時(shí)性，EventMesh 可以及時(shí)地傳遞數(shù)據(jù)。
EventMesh
我們先來(lái)了解 EventMesh 架構(gòu)圖，EventMesh 的定位是事件驅(qū)動(dòng)分布式應(yīng)用運(yùn)行時(shí)。EventMesh 可以提供非常輕量級(jí)、多語(yǔ)言的客戶端以及各種各樣的協(xié)議，例如 MQTT、Cloudevents、Web Socket 和 MQP，與此同時(shí)，它可以提供 gRPC、TCP 和 HTTP 等傳輸?shù)膮f(xié)議。
EventMesh Runtime 是一個(gè)插件化的架構(gòu)，可以對(duì)接到后端的中間件或者服務(wù)，比如事件的存儲(chǔ) RocketMQ、Kafaka 以 及 Apache Pulsar 等；如果需要有一些狀態(tài)更新維護(hù)的時(shí)候，可以對(duì)接到后端的 redis、MySQL 以及 Mongo DB 等；如果需要有一些冷數(shù)據(jù)更新的時(shí)候，也是可以通過(guò)插件化的形式連接到 S3，ES 等存儲(chǔ)。
在控制層面，如果需要對(duì)事件的調(diào)用鏈進(jìn)行跟蹤、元數(shù)據(jù)進(jìn)行管理以及分布式協(xié)調(diào)性的時(shí)候，EventMesh Runtime 也可以對(duì)接到 ETCD、NACOS、 Prometheus、Zipkin、Skywalking
、OpenTelemetry 等。我們內(nèi)部最常用的是 RocketMQ 以及 Redis 兩個(gè)插件，不過(guò) EventMesh 也可以很方便地與 Kubernetes 進(jìn)行集成，這是因?yàn)?EventMesh Runtime 可以作為 Sidecar 部署，也可以作為 Gateway 部署。
我們?cè)倏匆幌庐?dāng)前在微服務(wù)領(lǐng)域的 REST Drive 和 Event Drive，他們各自的優(yōu)缺點(diǎn)非常明顯。就 Spring Cloud、HTTP2、gRPC 通信而言，當(dāng) REST 調(diào)用服務(wù)的時(shí)候，由于工業(yè)界非常完善的工具文檔以及開發(fā)工具客戶端，開發(fā)起來(lái)非常方便，但是 REST Drive 的所有調(diào)用都是同步的，同步則意味著阻塞。如果在一個(gè)鏈中，任何節(jié)點(diǎn)的服務(wù)出現(xiàn)緩慢調(diào)用或故障，那么便會(huì)影響到最前端的服務(wù)調(diào)用，那么當(dāng) Spring Cloud 與 Dubbo 服務(wù)建立通信的時(shí)候，需要付出更多的成本。
然而在事件驅(qū)動(dòng)領(lǐng)域，當(dāng)接入網(wǎng)關(guān)或進(jìn)行業(yè)務(wù)層面的框架層適配的時(shí)候，它的調(diào)用是異步的，所有的狀態(tài)是最終一致的，并且可以與很多的服務(wù)以及中間層解耦。另外像 Queue 訂閱發(fā)布方式，擴(kuò)容非常方便。但是它需要依賴一層中間件，中間件的復(fù)雜度需要人工處理，不過(guò)這層復(fù)雜度可以使用 EventMesh 屏蔽掉，所以對(duì)應(yīng)用的開發(fā)本身而言，輕量又便捷。
SeviceMesh vs EventMesh
接下來(lái)分享一下 SeviceMesh vs EventMesh 的區(qū)別。
SeviceMesh 需要 Sidecar，所有數(shù)據(jù)層面的通信是在 Sidecar 之間的轉(zhuǎn)發(fā)，不過(guò)在 EventMesh 中，我們看到單個(gè)或多個(gè)服務(wù)可以掛在 EventMesh 的單個(gè)節(jié)點(diǎn)，EventMesh 具備較強(qiáng)的微服務(wù)編排能力，但是 EventMesh 并不能解決所有的問(wèn)題，它的優(yōu)勢(shì)在于事件驅(qū)動(dòng)，它也可以做到 Request、Reply。
服務(wù)有同步和異步之分，同步調(diào)用可以采用 SeviceMesh，異步調(diào)用可以采用 EventMesh 。當(dāng)然 EventMesh 也可以做同步調(diào)用，SeviceMes 也可以做異步調(diào)用，但是兩者本身的定位以及處理的場(chǎng)景不一樣，所以 SeviceMesh 與 EventMesh 可以結(jié)合使用。
例如，前端 Web App 通過(guò) API 網(wǎng)關(guān)進(jìn)來(lái)的調(diào)用，轉(zhuǎn)發(fā)到前置或某個(gè)業(yè)務(wù)領(lǐng)域的服務(wù)，它會(huì)進(jìn)行內(nèi)部服務(wù)之間的調(diào)用，這個(gè)過(guò)程便會(huì)產(chǎn)生數(shù)據(jù)，數(shù)據(jù)會(huì)進(jìn)入到關(guān)系型數(shù)據(jù)庫(kù)或者 NoSQL 數(shù)據(jù)庫(kù)。但是入數(shù)據(jù)庫(kù)的這一動(dòng)作，可能需要讓其他的服務(wù)訂閱或關(guān)注到，這個(gè)時(shí)候，我們可以將事件或者服務(wù)轉(zhuǎn)發(fā)給 EventMesh，讓 EventMesh 驅(qū)動(dòng)關(guān)心這些事件的服務(wù)進(jìn)行后續(xù)工作。
接著，我們一起看看 EventMesh 的作用。
在 DMZ 區(qū)或 ECN 區(qū)域，部署網(wǎng)關(guān)或者前置服務(wù)的作用是為了進(jìn)行協(xié)議的轉(zhuǎn)換——從外部的 HTTP 或 HTTPS 接口協(xié)議的服務(wù)，轉(zhuǎn)換到內(nèi)部不同的服務(wù)框架（例如 Dubbo、Spring Cloud）的協(xié)議。當(dāng)外部、公網(wǎng)或者合作方流量進(jìn)入此區(qū)域的時(shí)候，內(nèi)部區(qū)域?qū)?huì)形成非常復(fù)雜網(wǎng)狀的結(jié)構(gòu)，邊界區(qū)流量治理非常不方便。
現(xiàn)在的通用做法是在邊界布置網(wǎng)關(guān)，但是當(dāng)有了 EventMesh 之后，我們只需要在外聯(lián)區(qū)和內(nèi)部區(qū)域布置兩個(gè) EventMesh（可以是集群，也可以是節(jié)點(diǎn)），這樣邊界區(qū)的服務(wù)只需要在 EventMesh 之間進(jìn)行通訊，而且當(dāng)請(qǐng)求到了內(nèi)部服務(wù)的時(shí)候，通過(guò)內(nèi)部區(qū)域的 EventMesh 可以形成很多網(wǎng)格，每一個(gè) EventMesh 網(wǎng)格代理了向其注冊(cè)的服務(wù)。不同的 EventMesh 以及其代理的服務(wù)連接起來(lái)，形成較大的事件網(wǎng)格，很多復(fù)雜調(diào)用場(chǎng)景的治理將會(huì)變得極其簡(jiǎn)單。
EventMesh Feature
這一部分我將會(huì)介紹幾個(gè)重要的 EventMesh Feature。
Pub/Sub+
現(xiàn)在有非常多各種云以及私有部署環(huán)境下的服務(wù)，服務(wù)與服務(wù)之間的連接可以通過(guò) EventMesh 來(lái)完成。不同的區(qū)域的服務(wù)，使用的協(xié)議和語(yǔ)言不一樣，但是通過(guò) Pub/Sub+的形式增加的任何協(xié)議、節(jié)點(diǎn)、服務(wù)，都可以統(tǒng)一匯聚到 EventMesh 形成的網(wǎng)格中。
舉個(gè)例子，當(dāng)大家在亞馬遜云上發(fā)布事件之后，私有化部署 Kubernetes 的某服務(wù)節(jié)點(diǎn)訂閱了這個(gè)消息，消息可以跨越很多節(jié)點(diǎn)路由到 Kubernetes 服務(wù)。同時(shí)，當(dāng)多個(gè)區(qū)域的服務(wù)訂閱了相同的主題，只要將消息發(fā)送到對(duì)應(yīng)的主題，對(duì)應(yīng)的服務(wù)會(huì)自動(dòng)將消息接收下來(lái)。EventMesh 可以解決連接協(xié)議的多樣性、語(yǔ)言的多樣性，并且可以解決邊界區(qū)的連接問(wèn)題。
事件總線
事件驅(qū)動(dòng)架構(gòu)（EDA）是一種以事件為紐帶，將不同系統(tǒng)進(jìn)行解耦的異步架構(gòu)設(shè)計(jì)模型。在 EDA 中，事件驅(qū)動(dòng)的運(yùn)行流程天然地劃分了各個(gè)系統(tǒng)的業(yè)務(wù)語(yǔ)義，用戶可以根據(jù)需求對(duì)事件與針對(duì)此事件做出的響應(yīng)靈活定制，這使得基于 EDA 架構(gòu)可以方便地構(gòu)建出高伸縮性的應(yīng)用。
HTTP Source 事件源是 EventMesh 支持的事件源的一種，它以 Webhook 形式暴露了發(fā)布事件的 HTTP 請(qǐng)求地址，用戶可以在有 URL 回調(diào)的場(chǎng)景配置 HTTP Source 事件源，或者直接使用最簡(jiǎn)單的 HTTP 客戶端來(lái)完成事件的發(fā)布。HTTP Source 事件源提供了支持 HTTP 與 HTTPS，公有云 VPC 等不同請(qǐng)求方式、不同網(wǎng)絡(luò)環(huán)境的 Webhook URL，便于用戶將其集成到各類應(yīng)用中。接入時(shí)無(wú)需使用客戶端，僅需保證應(yīng)用可以訪問(wèn)到對(duì)應(yīng) Webhook URL 即可，這使得接入過(guò)程變得簡(jiǎn)單而高效。
在將 HTTP 請(qǐng)求轉(zhuǎn)換為 CloudEvent 的時(shí)候，EventMesh 會(huì)將請(qǐng)求的頭部和消息體部分置于 CloudEvents 字段中，其余字段會(huì)依據(jù)用戶 EventMesh 資源屬性以及系統(tǒng)默認(rèn)規(guī)則進(jìn)行填充。用戶可以在事件規(guī)則中，對(duì)所需的內(nèi)容進(jìn)行過(guò)濾、提取，最終按照模板拼裝成所需的消息內(nèi)容投遞給事件目標(biāo)。
Streaming
在當(dāng)前的微服務(wù)下，當(dāng)我們進(jìn)行流量調(diào)度的時(shí)候，肯定需要解碼消息頭，根據(jù)消息頭的特定字段，路由到對(duì)應(yīng)的服務(wù)上以便增加策略。
實(shí)際上在事件驅(qū)動(dòng)中，首先我們不需要解碼報(bào)文，我們?cè)谒南⒅黝}設(shè)計(jì)上，可以解決類似的問(wèn)題。比如可以設(shè)計(jì)非常多 Topic 層級(jí)，層級(jí)與層級(jí)之間有遞進(jìn)關(guān)系，以此來(lái)實(shí)現(xiàn)動(dòng)態(tài)的過(guò)濾。其次，當(dāng)消息到達(dá)之后，可以很方便地針對(duì)消息進(jìn)行報(bào)文解析，在產(chǎn)生的事件上面，我們可以增加非常多的 Match 處理函數(shù)，產(chǎn)生的消息可以實(shí)時(shí)地經(jīng)過(guò) filter chain 的處理。事件的處理都可以由 EventMesh 來(lái)完成。
編排與協(xié)調(diào)
在上圖的左邊區(qū)域，當(dāng)寫入復(fù)雜的 Case、If else 條件或引入工作流之后，它的編排有很多串行的分支，但是如果采用 EventMesh 編排，看起來(lái)將會(huì)非常簡(jiǎn)潔。
我們只需要訂閱感興趣的事件，發(fā)送對(duì)應(yīng)的事件到對(duì)方主題上就可以，我們并不需要關(guān)注對(duì)方 IP 的所在地，也不需要關(guān)注服務(wù)部署在虛擬機(jī)還是在容器上，以及對(duì)方服務(wù)實(shí)例數(shù)量，當(dāng)然更不需要關(guān)注對(duì)方實(shí)例掛了之后，我們是否需要進(jìn)行熔斷等等。下游的 EventMesh 可以完成所有的事情，例如，當(dāng)它下游的服務(wù)發(fā)生故障，消息將會(huì)自動(dòng)分發(fā)到當(dāng)前在線的服務(wù)實(shí)例。從上面這張圖，大家可以看出，采用 EventMesh 可以使得編排與協(xié)調(diào)過(guò)程更加清晰。
動(dòng)態(tài)擴(kuò)縮容
接下來(lái)是擴(kuò)縮容場(chǎng)景，當(dāng)現(xiàn)有的 Kubernetes 在進(jìn)行擴(kuò)縮容的時(shí)候，有兩個(gè)常見(jiàn)的場(chǎng)景。
首先是擴(kuò)容場(chǎng)景，例如，在當(dāng)前的 CPU 占用很高的時(shí)候，正常情況會(huì)觸發(fā)擴(kuò)容事件，但我們?cè)谙㈥?duì)列中，并沒(méi)有看到特別多的消息堆積，也就是說(shuō)，這個(gè)時(shí)候并不需要擴(kuò)容，實(shí)際上這個(gè)擴(kuò)容是浪費(fèi)的；其次是縮容場(chǎng)景，例如在消息隊(duì)列里，當(dāng)前沒(méi)有消息堆積，理論上實(shí)例是可以縮容，甚至可以縮容到零，但是因?yàn)?CPU 的使用導(dǎo)致無(wú)法順利縮容。
但是這兩種場(chǎng)景，如果在事件驅(qū)動(dòng)的服務(wù)下，我們采用 Queue 隊(duì)列堆積的監(jiān)控方式可以實(shí)現(xiàn)以下效果。首先是在資源占用很高，但隊(duì)列的任務(wù)沒(méi)有堆積的情況下，可以不進(jìn)行擴(kuò)容；其次，在占用當(dāng)前的 CPU 的資源，但沒(méi)有任務(wù)處理的情況下，可以進(jìn)行縮容。在我看來(lái)，伸縮監(jiān)控的指標(biāo)應(yīng)該根據(jù)當(dāng)前處理的任務(wù)堆積情況來(lái)判斷。
Bridge（Federated Governance）
沒(méi)有治理前，就如下圖一樣，各個(gè)不同區(qū)域之間形成了數(shù)據(jù)的孤島。
但當(dāng)治理之后，就變成了下圖一樣的這樣網(wǎng)格狀態(tài)，清晰且簡(jiǎn)潔。
在過(guò)去十年的大部分時(shí)間里，企業(yè)都在與數(shù)據(jù)孤島作斗爭(zhēng)，數(shù)據(jù)孤島是孤立的持久性存儲(chǔ)，擁有無(wú)數(shù)但無(wú)法訪問(wèn)的知識(shí)，他們的主要武器是數(shù)據(jù)湖：一個(gè)巨大的集中式數(shù)據(jù)存儲(chǔ)，將 TB 級(jí)的特定于域的數(shù)據(jù)保存在一個(gè)邏輯位置。沒(méi)有領(lǐng)域知識(shí)的數(shù)據(jù)專?家試圖從不同的數(shù)據(jù)集中挖掘數(shù)據(jù)價(jià)值是很困難的，而且?guī)缀鯖](méi)有動(dòng)力向數(shù)據(jù)湖貢獻(xiàn)高質(zhì)量數(shù)據(jù)的數(shù)據(jù)生產(chǎn)者。
EventMesh 具備實(shí)時(shí)分析、大規(guī)模數(shù)據(jù)收集、平臺(tái)無(wú)關(guān)的連接以及對(duì)開放標(biāo)準(zhǔn)的支持等能力，理想情況下，對(duì)客戶數(shù)據(jù)的任何更改都應(yīng)通過(guò)事件網(wǎng)格之類的東西實(shí)時(shí)推送給依賴的消費(fèi)者，但如果數(shù)據(jù)不太重要或不及時(shí)，數(shù)據(jù)消費(fèi)者可以在需要時(shí)提取（或查詢）數(shù)據(jù)。
我們正在從數(shù)據(jù)無(wú)政府狀態(tài)過(guò)渡到聯(lián)合治理和成熟的企業(yè)數(shù)據(jù)策略——理想情況下，可以將策略有效地表示為代碼的最終狀態(tài)。聯(lián)合治理需要特定于任務(wù)的工具、事件目錄和 AsyncAPI 等標(biāo)準(zhǔn)。企業(yè)級(jí)數(shù)據(jù)策略還包括訪問(wèn)控制、法規(guī)（即 GDPR）、機(jī)密性（如 PII 和 PHI）、編輯和加密等特性/功能。功能的示例可能包括強(qiáng)制性標(biāo)頭元數(shù)據(jù)（將數(shù)據(jù)上下文化）、可觀察性要求、主題結(jié)構(gòu)（用于路由）以及通過(guò)模式驗(yàn)證和其他工具實(shí)現(xiàn)的數(shù)據(jù)質(zhì)量。
EventMesh in WeBank Message Bus（DeFiBus）
在微眾銀行，已經(jīng)開源的消息總線 DeFiBus 如上圖所示，這里以三個(gè) EventMesh 的節(jié)點(diǎn)為例，每一個(gè) EventMesh 節(jié)點(diǎn)，可以在其上面訂閱服務(wù)。當(dāng)發(fā)送方發(fā)布一個(gè)事件之后，其他的 EventMesh 上的任何服務(wù)，只要訂閱了 Topic，這個(gè)事件便可以發(fā)送到對(duì)應(yīng)的服務(wù)上，它能夠自動(dòng)地學(xué)習(xí)和更新路由表。
EventMesh 在微眾銀行內(nèi)部解決了以下問(wèn)題，首先是多語(yǔ)言治理問(wèn)題，例如 AI 計(jì)算使用 Python、很多銀行的系統(tǒng)使用 C 語(yǔ)言，EventMesh 能夠簡(jiǎn)化接入消息總線的復(fù)雜度，同時(shí)我們知道，推動(dòng)業(yè)務(wù)的 SDK 的升級(jí)非常麻煩，當(dāng) SDK 輕量簡(jiǎn)化之后，我們只需要負(fù)責(zé)中間件層的發(fā)布，就可以節(jié)省掉應(yīng)用推動(dòng)升級(jí)的成本。除了應(yīng)用在業(yè)務(wù)系統(tǒng)外，EventMesh 還應(yīng)用在流量復(fù)制回放平臺(tái)，消息旁路過(guò)濾，消息多活路由，AI 聯(lián)邦學(xué)習(xí)，區(qū)塊鏈等場(chǎng)景，更多的場(chǎng)景在持續(xù)探索實(shí)踐過(guò)程中，未來(lái)有機(jī)會(huì)再分享給大家。
Summary
今天的 IT 系統(tǒng)正在生成、收集和處理比以往更多的數(shù)據(jù)。而且，他們正在處理高度復(fù)雜的流程（正在自動(dòng)化）以及跨越典型組織邊界的系統(tǒng)和設(shè)備之間的集成。同時(shí)，預(yù)計(jì) IT 系統(tǒng)的開發(fā)速度更快、成本更低，同時(shí)還具有高可用性、可擴(kuò)展性和彈性。為了實(shí)現(xiàn)這些目標(biāo)，開發(fā)人員正在采用架構(gòu)風(fēng)格和編程范式，例如微服務(wù)、事件驅(qū)動(dòng)架構(gòu)、DevOps 等。正在構(gòu)建新的工具和框架來(lái)幫助開發(fā)人員實(shí)現(xiàn)這些期望。開發(fā)人員正在結(jié)合事件驅(qū)動(dòng)架構(gòu) (EDA) 和微服務(wù)架構(gòu)風(fēng)格來(lái)構(gòu)建具有極強(qiáng)可擴(kuò)展性、可用、容錯(cuò)、并發(fā)且易于開發(fā)和維護(hù)的系統(tǒng)。
EventMesh 作為事件基礎(chǔ)設(shè)施，主要負(fù)責(zé)事件的傳輸、路由和序列化。它可以提供用于處理事件流的 API。事件基礎(chǔ)設(shè)施提供對(duì)多種序列化格式的支持，并對(duì)架構(gòu)質(zhì)量（例如容錯(cuò)、彈性可伸縮性、吞吐量等）產(chǎn)生重大影響，也可以存儲(chǔ)事件以創(chuàng)建事件存儲(chǔ)，事件存儲(chǔ)是恢復(fù)和彈性的關(guān)鍵架構(gòu)模式。
了解更多軟件開發(fā)與相關(guān)領(lǐng)域知識(shí)，點(diǎn)擊訪問(wèn) InfoQ 官網(wǎng)：https://www.infoq.cn/，獲取更多精彩內(nèi)容！
