組合式應用新利器？SaaS新時代事件網格如何解決集成標準化問題

在SaaS新時代下，業務適應性需求引導企業轉向支持快速、安全和高效應用變化的技術架構。組合式應用作為加速數字化的關鍵技術，是Gartner提出的在2022年重要戰略技術之一，它由以業務為中心的模塊化組件構建而成，使技術和業務團隊可以更敏捷、更有效地重用代碼。組合式應用需要面臨的一個難題是如何解決各個應用之間的集成標準問題，比如應用可能僅支持HTTP、TCP等協議中的一種，而缺乏統一的通訊標準就給業務落地該架構帶來了困難。下面介紹事件網格（EventGrid）是如何解決這一問題。

事件網格是華為云中間件在云原生時代推出的新一代無服務器事件總線，承載和管理來自傳統應用、云服務應用和SaaS合作伙伴應用的各類事件，幫助應用開發者輕松搭建高可用、松耦合、分布式的事件驅動架構。作為Serverless 架構下事件驅動架構的關鍵一環，它提供彈性、異步、去中心化的事件治理服務，對事件提供匯聚、模型校驗、過濾、路由、轉換和推送等核心功能，還包括容錯重試、死信儲存、事件查詢跟蹤、事件工作流等增強特性。

從以上EventGrid總體架構圖可以看出，EventGrid 對接了一系列云服務作為事件源。這些云服務包括分布式消息服務（如RocketMQ、Kafka和 Pulsar）、對象存儲服務 (OBS) 和分布式緩存服務(Redis) 。事件源會產生管理類、數據類和自定義事件，然后通過EventGrid SDK推送到EventGrid的事件總線 (Bus Runtime) 的 事件通道中。事件總線為EventGrid用戶以租戶為單位配置事件通道，一個租戶下允許有多個事件通道，承載來自不同事件源的事件。比如默認事件通道存儲華為云產生的事件，而自定義事件通道存儲應用和微服務的事件。EventGrid用戶通過訂閱的方式消費事件，通過在訂閱的配置項里定義事件源、事件目標、事件過濾和轉換規則，EventGrid就能從事件總線里提取相關事件，然后實時推送到所定義的事件目標中。推送方式可以是同步和異步：同步推送一般是以HTTP協議，適合應用和微服務；異步推送一般是推動到SaaS伙伴應用的消息隊列中。

所以，華為云EventGrid通過事件驅動的方式聯動周邊的云服務、云原生應用和SaaS伙伴應用，實現服務和應用之間解耦，專注發揮自己服務的優勢，通過各種事件模型連接，為華為云創造更多的應用場景，豐富華為云的開發者生態。

以EventMesh 為引擎

華為云EventGrid引入了開源明星項目Apache EventMesh，作為其運行時引擎。Apache EventMesh 作為云原生的事件驅動架構中間件，用于分離應用程序和后端事件存儲(Event Store)，支持廣泛的應用場景，包括混合云和傳統數據中心，以及不同技術棧的分布式架構。

Apache EventMesh的理念和EventGrid很類似。它也是連接事件源，聚集事件，然后把事件推送到客戶端。它的亮點是其內核可以支持插件化。根據不同的事件應用場景，可以接入不同的插件來匹配。比如在事件鏈接器 (Event Connector）方面, 可以對接RocketMQ Connector或者 Kafka Connector。在HTTP授權(Http-Auth)方面, 可以引用BasicAuth或者TokenAuth。 這樣靈活的架構有助于打造生態系統，對接不同的產品和服務。

EventMesh gRPC特性

Apache EventMesh 最新發布的v1.4.0版本相比之前的版本又增加了多個重要特性和架構優化。其中一個亮點是對于gRPC的支持。gRPC是基于HTTP/2的現代高性能RPC (Remote Procedure Call) 框架。相比HTTP 協議，gRPC支持Client 和 Server雙向異步通訊，通過Protobuf 定義API接口數據模型，支持多語言SDK。 通過實現gRPC協議，Apache EventMesh 可以整合原有的TCP和HTTP協議，讓當前運行時輕量化。 同時其SDK可以擴展到多語言支持，比如Java、Go、JavaScript等等。

Protobuf 設計

EventMesh 引入gRPC首先從設計Protobuf定義(eventmesh-client.proto) 開始。我們在eventmesh-client.proto文件里定義EventMesh事件發送和訂閱服務的方法和事件模型。由于篇幅原因，以下僅介紹定義的重點部分，完整的文檔請見：

https://github.com/apache/incubator-eventmesh/blob/master/eventmesh-protocol-plugin/eventmesh-protocol-grpc/src/main/proto/eventmesh-client.proto

1. 事件發送服務提供以下接口。

service PublisherService { rpc publish(SimpleMessage) returns (Response); rpc requestReply(SimpleMessage) returns (SimpleMessage); rpc batchPublish(BatchMessage) returns (Response); }

事件是以SimpleMessage的數據模型呈現。事件發送支持同步發送、異步發送和批量發送三種模式。其中同步發送是指事件生產者發送事件到EventMesh，并等待事件成功推送到事件消費者，并收到事件消費者的返回，才算完成整個端到端的事件發送過程；異步發送是指事件生產者發送事件到EventMesh即可，無需等待事件被成功推送到事件消費者；批量發送是指異步發送一批事件到EventMesh。

2. 事件模型如下：

message RequestHeader { string env = 1; string region = 2; string idc = 3; string ip = 4; string pid = 5; string sys = 6; string username = 7; string password = 8; string language = 9; string protocolType = 10; string protocolVersion = 11; string protocolDesc = 12; } message SimpleMessage { RequestHeader header = 1; string producerGroup = 2; string topic = 3; string content = 4; string ttl = 5; string uniqueId = 6; string seqNum = 7; string tag = 8; map properties = 9; }

事件模型可以支持多種協議，包括CNCF CloudEvents、OpenMessenging和EventMesh原生事件協議，這些協議都在SimpleMessage的protocol 相關字段中體現。 另外模型中帶有 producerGroup和topic 用于事件的路由；ttl、uniqueId和seqNum則是用于事件的管理。請求頭里帶有事件生產者的基本信息: env、region、idc、ip和sys。

3. 事件訂閱服務提供以下接口：

service ConsumerService { rpc subscribe(Subscription) returns (Response); rpc subscribeStream(stream Subscription) returns (stream SimpleMessage); rpc unsubscribe(Subscription) returns (Response); }

事件訂閱支持兩種方式：集群(cluster) 和廣播(broadcast) 。集群模式中，事件消費者集群里只有一個實例能消費到事件；廣播模式讓集群里每一個實例都消費到事件。這些訂閱模式是在訂閱數據模型里定義的。另外訂閱服務提供兩種訂閱接口：subscribe API和 subscribeStream API。Subscribe API 是通過url方式 推送事件到消費者，這里url又叫 webhook。這種場景適合云原生微服務和自定義應用及函數。subscribeStream API 是通過gRPC 雙向流(Bidirectional Streaming) 推送事件到消費者 ，同時可以讓事件消費者返回確認信息 (Ack) 給事件生產者。這就滿足了生產者RequestReply同步事件發送的需求。

服務端的多線程并發

為了提高事件生產和消費的性能，EventMesh 服務端 (EventMesh Runtime) 在 gRPC的服務里定義了線程池 (ThreadPool)，而且針對事件生產和消費的對性能要求的不同，配置獨立的參數。這些參數都可以在EventMesh配置文件 (eventmesh.properties)里找到。比如以下分別是事件生產，訂閱和推送的線程數。

eventMesh.server.sendmsg.threads.num=50 eventMesh.server.clientmanage.threads.num=30 eventMesh.server.pushmsg.threads.num=50

當gRPC服務啟動后，它會監聽客戶端的請求，一旦有新請求進來，它會分發到對應服務的線程池，然后讓對應的處理器 (Processor)處理，這樣就不會阻塞下一個請求的處理，從而提高了并發量。

public void publish(SimpleMessage request, StreamObserver responseObserver){ cmdLogger.info("cmd={}|{}|client2eventMesh|from={}|to={}", "AsyncPublish", EventMeshConstants.PROTOCOL_GRPC, request.getHeader().getIp(), eventMeshGrpcServer.getEventMeshGrpcConfiguration().eventMeshIp); EventEmitter emitter = new EventEmitter<>(responseObserver); threadPoolExecutor.submit(() -> { SendAsyncMessageProcessor sendAsyncMessageProcessor = new SendAsyncMessageProcessor(eventMeshGrpcServer); try { sendAsyncMessageProcessor.process(request, emitter); } catch (Exception e) { logger.error("Error code {}, error message {}", StatusCode.EVENTMESH_SEND_ASYNC_MSG_ERR.getRetCode(), StatusCode.EVENTMESH_SEND_ASYNC_MSG_ERR.getErrMsg(), e); ServiceUtils.sendRespAndDone(StatusCode.EVENTMESH_SEND_ASYNC_MSG_ERR, e.getMessage(), emitter); } }); }

比如以上代碼是事件發送服務 (publish service) 的實現。它使用了 threadPoolExecutor把事件發送到線程池讓下游SendAsyncMessageProcessor處理。

事件消費者的負載均衡和重試

在事件消費者方面，EventMesh 支持負載均衡。用戶可以在事件訂閱里指定多個事件消費者來消費事件。每個消費者會是一個URL(Webhook) 或者 gRPC 客戶端 (stream)，這些消費者可以是集群或者是主備方式部署。那么EventMesh會通過算法計算選擇其中一個消費者去推送事件。如果當前消費者無法消費事件，那么EventMesh會選下一個消費者。EventMesh默認以輪詢方式選擇消費者推送事件，來達到消費者的負載均衡。開發者可以通過插件提供其他算法來選擇消費者。

事件推送失敗，可能是網絡原因，當前消費者繁忙或下線。EventMesh先嘗試重試，每次重試會間隔幾秒鐘，最多重試3次。如果3次重試失敗了，EventMesh才會選擇下一個消費者。重試間隔時間可以在配置文件里定義。

gRPC non-Blocking 和 Blocking Stub

為了提高客戶端性能，gRPC提供了非阻塞存根 (non-Blocking Stub)。使用non-Blocking Stub客戶端發送請求后不需要等待服務器回復，繼續進行執行下一步操作。這很適合在大量事件生產的場景。但是在事件RequestReply場景下，客戶端需要同步的等待事件成功推送到事件消費者，我們就需要gRPC的阻塞存根 (Blocking Stub)。通過給客戶端提供的兩種選擇，可以更靈活的滿足不同的事件生產和消費場景。目前EventMesh SDK 使用了Blocking Stub, 下一步是使用non-Bocking Stub 提高客戶端高并發性能。

支持多語言SDK

Apache EventMesh v1.3.0之前只提供Java SDK。這對于接入其他云原生的應用場景有局限。因為很多云服務都是用Go, Python和JavaScript (NodeJS 框架) 語言開發的 。一些云原生的開源項目，比如KNative、Dapr也是用Go作為開發語言。所以EventMesh 對支持多語言SDK有迫切需求，以繼續豐富應用開發者的生態。

gRPC的開發工具帶有多語言代碼生成工具，包括Java、Go、NodeJS、PHP、Python、C#和C++等。EventMesh實現gRPC協議后可以借助該工具，快速提供多語言的SDK。后續對于通信API的改動只需要同步修改Protobuf模型定義，重新生成代碼即可。迭代快速，維護簡單。

整合TCP和HTTP 協議

gRPC 支持4種Client和Server通信RPC機制：Unary RPC、Server Streaming RPC、Client Streaming RPC和 Bidirectional Streaming RPC. EventMesh v1.4.0版本整合了v1.3.0版本的TCP 和 HTTP 的 SDK API，利用Unary RPC和 Bidirectional Streaming RPC，提供了 Event Publish、Broadcast、Request-Reply、Webhook Subscription和 Event Stream Subscription五種SDK API。

Protocol

Supported Use Case

Supported Version

gRPC

Send Async Message

Send Sync Message

Request and Reply

Send Broadcast Message

Send Batch Messages

Webhook Subscribe

Event Stream Subscribe

Unsubscribe

Heartbeat

v1.4.0+

HTTP

Send Async Message

Send Batch Messages

Webhook Subscribe

Unsubscribe

Heartbeat

v1.0.0+

TCP

Send Sync Message

Send Async Message

Send Batch Messages

Request and Reply

Send Broadcast Message

Event Stream Subscribe

Unsubscribe

Heartbeat

v1.0.0+

通過整合TCP和 HTTP協議，EventMesh Runtime和 SDK架構更加輕量化，減少了代碼維護。同時用戶使用SDK就不需要考慮使用場景要選哪一種協議。用戶不需要學習和感知SDK層面的通訊協議，gRPC就能滿足他們事件生產和消費的所有場景。

開箱即用的gRPC樣例

為了讓EventMesh開發者更好的體驗gRPC新特性，社區提供了完善的使用文檔和多個Event Publisher, Event Subscriber代碼樣例。以下是相關文檔：

https://github.com/apache/incubator-eventmesh/blob/master/docs/en/instructions/eventmesh-runtime-quickstart.md

https://github.com/apache/incubator-eventmesh/blob/master/docs/en/instructions/eventmesh-sdk-java-quickstart.md

第一個文檔介紹如何部署和啟動EventMesh 服務器。文檔里第一部分介紹如何遠程部署EventMesh 在虛擬機里，適合測試和生產環境的部署；第二部分介紹如何在本地開發環境里部署EventMesh，適合常用的本地開發和調試場景。以下命令行是展示如何在Linux 環境里部署和啟動EventMesh Runtime

> tar -zxvf Eventmesh_1.3.0-release.tar.gz > cd bin > sh start.sh > tail -f ./logs/eventmesh.out

第二個文檔介紹如何使用EventMesh SDK開發應用生產和消費事件，包含了TCP、HTTP和gRPC 三部分。EventMesh工程項目里帶有客戶端的代碼樣例 (eventmesh-example)，包括了gRPC Event Publisher、Event Subscriber的代碼。比如，我們可以把EventMesh工程項目導入Java IDE 里 （比如Intellij IDEA）。按照以下步驟啟動 gRPC Event Publisher and Subscriber。

1. 修改eventmesh-examples/src/main/resources/application.properties指向已經部署的EventMesh Runtime。

2. 啟動Event Publisher, 運行

Eventmesh-example/src/main/java/ org.apache.eventmesh.grpc.pub.eventmeshmessage.AsyncPublishInstance

3. 啟動Event Subscriber, 運行

Eventmesh-example/src/main/java/ org.apache.eventmesh.grpc.sub.app.SpringBootDemoApplication

作為組合式應用新利器，gRPC的引入無疑是集成標準化的一大助力。當然，除了通訊標準外，還有schema、governance等集成標準需要統一，事件網格會在這些領域繼續做出自己的探索。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。