基礎服務架構
本篇內容主要討論的是 Serverless 架構與其事件規範的基礎原則。html
首先，咱們先來了解下在 HTTP/Web 場景下咱們的典型的WEB場景是怎樣的：nginx
這裏，咱們不難看出典型的Web場景實際上是由三大塊內容，客戶端，服務器，數據庫組成。客戶端在服務器側經過類型 apache，nginx 等代理服務器來請求數據，代理服務器又經過數據庫來寫入或拉取數據資料。這個很簡單，也是咱們最經常使用的 Web 場景。git
這裏面服務器中可能涉及路由規則，鑑權邏輯以及其餘各種複雜的業務代碼，同時，開發團隊要付出很大的精力在這個服務器的運維上面，包括客戶量忽然增多時是否須要擴容服務器？服務器上的腳本，業務代碼等是否還在健康運行？是否有黑客在不斷地對服務器發起攻擊？github
Serverless服務架構
那麼接下來，咱們來看下 Serverless 服務是如何請求數據的吧：數據庫
Serverless 場景下，客戶端須要經過 API 網關 Baas 來訪問函數 FaaS 服務，而後在經過函數計算作數據庫連接實現數據庫的寫入和拉取。apache
當客戶端和數據庫未發生變的前提下，服務器變化巨大，以前須要開發團隊維護的路由模塊以及鑑權模塊都將接入服務商提供的 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 架構中的事件
這樣，咱們引出出來另外一個概念，就是事件，什麼是事件？事件是怎麼定義的？less
咱們能夠引出來 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 應用的開發！