1.4.3　事件總線

本節將介紹AWS的EventBridge及開源的事件規范CloudEvent。

1.4.3.1　云服務事件總線EventBridge

ESB（企業服務總線）是SOA時代用于解決不同應用系統對接的事件總線服務，提供應用系統的服務接入、協議轉換、可靠的消息傳輸、編碼格式轉換、請求路由等功能。ESB作為消息中間件，可以實現業務系統的松耦合，提供異步消息處理機制。

進入Serverless時代后，遇到了與SOA時代同樣的問題。

? 事件源多：云服務商需要接入自身平臺、第三方平臺的SaaS服務或其他事件源。

? 事件目的地多：這些事件源可能需要對接不同的Serverless服務，比如對于用戶訂購商品成功的事件，需要將其發送到短信通知的Serverless 服務（如AWS SNS），以及分析的服務（如AWS Kinesis）。

? 需要對事件進行過濾或轉換：不愿意接收消息推送的用戶，不應該接收到消息。

如果沒有類似ESB的總線服務，無論是云服務商還是用戶，都需要編寫大量的膠水轉換代碼，同時還要完成部署并保證這些代碼在運行時中的可靠性，這增加了開發者的成本。

為此，云服務商推出了事件總線服務EventBridge。例如，AWS的由EventBridge全托管的事件總線，通過Schema定義EventBridge可對接異構事件源及目標，支持扇入/扇出（Fan-in/Fan-out），也支持事件過濾和路由。所有事件源只需要統一對接到EventBridge即可。

如圖1-25所示，開發者將Schema以配置文件的形式發送到EventBridge中，定義好過濾規則、事件的目的地。事件源（AWS服務或其他SaaS服務）可以使用Webhook或集成EventBridge的客戶端向EventBridge發送消息。EventBridge接收到請求后，可以針對事件進行過濾、路由，再去觸發AWS的自有Serverless服務或第三方服務（自定義或第三方的事件總線）。

EventBridge可以解決單個云服務商的事件源和目的服務解耦的問題，如果開發者需要跨多個云，在沒有統一的事件規范前提下，開發者同樣要使用膠水代碼進行事件格式或協議轉換。此外，事件數據往往可能涉及多跳環節，使用多個協議并跨多個云的系統才能完成處理。如圖1-26所示，對IoT設備的告警，可將正常業務事件及遙測事件通過網關發送給不同的處理者，由它們經過不同的流程完成處理。對于運行過程中不同的云服務，用戶需要使用專門的膠水代碼來進行消息轉換。因此，開發者需要通用的方式去描述事件，這是CloudEvents規范產生的動因。

1.4.3.2　事件規范CloudEvents

CloudEvents是CNCF在2017年推出的一個輕量級的事件規范，目前有超過30家公司參與制定。CloudEvents規范集成了一組大多數事件已經定義的基礎公共元數據屬性，如唯一ID、事件從哪里來、生成事件的事件類型和內容等。

如圖1-27所示，CloudEvents沒有重復“造輪子”，而是集成和兼容現有的協議。它集成現有消息和事件的技術棧（如Kafka、NATS等），并在現有的編碼（序列化）基礎上，使不同格式的編碼（如Protobuf、JSON等）更容易對接。CloudEvents允許在編碼過程中更換編碼格式和協議，以滿足事件可能經過多跳路由的場景。

CloudEvents定義了四種不同的元素，包括核心屬性（基礎的上下文、事件屬性鍵值對）、擴展屬性（自定義屬性鍵值對）、事件格式（如JSON）及綁定的協議（HTTP、Kafka等）。

CloudEvents事件的編碼支持兩種模式。

? 二進制模式可以適應任何形式的事件數據，可以高效傳輸，無須轉碼。

? 結構化模式將事件的元數據和數據都放在請求內容中，方便跨多個協議轉發。

下面CloudEvents文檔中的樣例代碼基于HTTP協議，分別使用二進制及結構化方式發送CloudEvents事件。

當前，已經有多個云平臺，如Azure的Event Grid、阿里云的Event Bridge、GCP的Eventarc，支持CloudEvents，CloudEvents自身也提供了對主流事件編碼的兼容及對多語言客戶端的支持。