基礎服務架構
本篇內容主要討論的是 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）生成流；
- 事件可以推送到函式運行時或由函式運行時拉動，
- 批量作業，例如ETL作業，分布式機器學習，HPC 模擬
- 作業被調度或提交到佇列，并在運行時使用并行的多個函式實體進行處理，每個函式實體處理作業集的一個或多個部分（任務）
不同型別的事件源包括：
- 事件和訊息服務，例如：RabbitMQ，MQTT，SNS
- 存盤服務，例如：COS，CDB，PGSQL，Cognito，Google 云存盤，
- 端點服務，例如：物聯網，HTTP 網關，移動設備，Alexa，
- 配置存盤庫，例如：Git，CodeCommit
- 使用特定于語言 SDK 的用戶應用程式
- 計劃事件，定期啟用函式呼叫，
雖然每個事件提供的資料可能在不同的事件源之間有所不同，但事件結構應該是通用的，能夠封裝關于事件源的特定資訊，
總結
如上就是關于 Serverless 架構與事件規范的一點思考，希望可以給到大家一些幫助，
傳送門：
- GitHub: github.com/serverless
- 官網：serverless.com
歡迎訪問：Serverless 中文網，您可以在 最佳實踐 里體驗更多關于 Serverless 應用的開發！
推薦閱讀：《Serverless 架構：從原理、設計到專案實戰》
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/38931.html
標籤：其他