▎基礎服務架構
本篇內容主要討論的是 Serverless 架構與其事件規範的基礎原則。
首先，我們先來了解下在 HTTP/Web 場景下我們的典型的 WEB 場景是怎樣的：
這裡，我們不難看出典型的 Web 場景其實是由三大塊內容，客戶端，服務器，數據庫組成。客戶端在服務器側通過類型 apache，nginx 等代理服務器來請求數據，代理服務器又通過數據庫來寫入或拉取數據資料。這個很簡單，也是我們最常用的 Web 場景。
這裡面服務器中可能涉及路由規則，鑑權邏輯以及其他各類複雜的業務代碼，同時，開發團隊要付出很大的精力在這個服務器的運維上面，包括客戶量突然增多時是否需要擴容服務器？服務器上的腳本，業務代碼等是否還在健康運行？是否有黑客在不斷地對服務器發起攻擊？
▎Serverless 服務架構
那麼接下來，我們來看下 Serverless 服務是如何請求數據的吧：
Serverless 場景下，客戶端需要通過 API 網關 Baas 來訪問函數 FaaS 服務，然後在通過函數計算做數據庫鏈接實現數據庫的寫入和拉取。
當客戶端和數據庫未發生變的前提下，服務器變化巨大，之前需要開發團隊維護的路由模塊以及鑑權模塊都將接入服務商提供的API網關係統以及鑑權系統，開發團隊無須再維護這兩部分的業務代碼，只需要持續維護相關規則即可。同時業務代碼也被拆分成了函數粒度，不同函數表示不同的功能。
從上面的例子中，我們不難發現，其實一個完整的 Serverless 請求其實是有兩大塊的，即我們的 Faas 服務和我們的 BaaS 服務。那麼，簡單敘述下 Serverless，其實由兩部分組成的，即我們的 Faas+Baas。
▎Serverless 架構核心
瞭解完整體 Serverless 的情況，我們來看下傳統 Faas 的基礎架構，其實傳統 Faas 最關鍵的核心概念是我們的調用，我們可以通過 Event Sources 事件源調用另一個函數的 Function 來實現單個函數的擴展，整體的原理圖如下所示：
- Event Sources（事件源）：將Event觸發或流式傳輸到一個或多個函數實例中；
- Function Instance（函數實例）：可以根據需要，將單個函數/微服務進行擴展；
- FaaS Controller（Faas 控制器）：部署，控制和監視函數實例及其來源
- 平臺服務：FaaS 解決方案使用的一般集群或雲服務（有時稱為後端即服務，或者 BaaS 等）
▎Serverless 架構中的事件
這樣，我們引出出來另一個概念，就是事件，什麼是事件？事件是怎麼定義的？
我們可以引出來 CloudEvents ，它是⼀種規範，⽤於以通⽤格式描述事件數據，以提供跨服務、平臺和系統的交互能⼒。 事件格式指定了如何使⽤某些編碼格式來序列化 CloudEvent。⽀持這些編碼的兼容 CloudEvents 實現必須遵循在相應的事件格式中指定的編碼規則。所有實現都必須⽀持 JSON 格式。
事件 (Event) ⽆處不在,然⽽每個事件源產⽣的事件各不相同。由於缺乏事件的統⼀描述,對於事件的開發者來說,需要不斷地重複學習如何消費不同類型的事件。 例如同⼀個⼚商的 CMQ 產⽣的事件和 API ⽹關觸發器產⽣的事件是不同的，不同⼚商的 API ⽹關觸發器產⽣的事件也可能是不同的。
必須的事件屬性（REQUIRED attributes）
• ID - 識別事件
• Source - 識別發⽣事件的上下⽂
• Specversion - 事件使⽤該版本的 cloudEvents 規範
• Type - 發⽣相關事件的類型值
• Data - Data的數據內容格式
• Subject -事件開發者有關的事件上下⽂主題
• Tiem - 事件發⽣的事件
▎Serverless 架構中的調用
聊完我們的事件，我們來談談另外一個核心調用，其實在 Serverless 架構中，調用簡單分為四種：
可以根據不同的用例從不同的事件源調用函數，例如：
- 同步請求（Req / Rep），例如 HTTP 請求，gRPC 調用
- 客戶發出請求並等待立即響應
- 異步消息隊列請求（發佈/訂閱），例如 RabbitMQ，AWS SNS，MQTT，電子郵件，對象（S3）更改，計劃事件（如 CRON 作業）
- 消息發佈到交換機並分發給訂閱者；
- 沒有嚴格的消息排序，以單次處理為粒度。
- 消息/記錄流：例如 Kafka，AWS Kinesis，AWS DynamoDB Streams，數據庫 CDC
- 一組有序的消息/記錄（必須按順序處理）；
- 通常，每個分片使用單個工作程序（分片消費者）將流分片為多個分區/分片；
- 可以從消息，數據庫更新（日誌）或文件（例如 CSV，Json，Parquet）生成流；
- 事件可以推送到函數運行時或由函數運行時拉動。
8. 批量作業，例如ETL作業，分佈式機器學習，HPC 模擬
9. 作業被調度或提交到隊列，並在運行時使用並行的多個函數實例進行處理，每個函數實例處理工作集的一個或多個部分（任務）
不同類型的事件源包括：
- 事件和消息服務，例如：RabbitMQ，MQTT，SNS
- 存儲服務，例如：COS，CDB，PGSQL，Cognito，Google 雲存儲，
- 端點服務，例如：物聯網，HTTP 網關，移動設備，Alexa，
- 配置存儲庫，例如：Git，CodeCommit
- 使用特定於語言 SDK 的用戶應用程序
- 計劃事件，定期啟用函數調用。
雖然每個事件提供的數據可能在不同的事件源之間有所不同，但事件結構應該是通用的，能夠封裝關於事件源的特定信息。
▎總結
如上就是關於 Serverless 架構與事件規範的一點思考，希望可以給到大家一些幫助。
閱讀更多 Serverless 的文章
