本文介紹當前serverless框架的函數概念，Serverless框架還允許用戶監視代碼存儲庫中的更改（例如代碼觸發器等），并在每次提交時自動構建函數鏡像。函數代碼、依賴項和/或二進制文件可以駐留在外部存儲庫（例如S3對象存儲桶或Git存儲庫）中，或由用戶直接提供。如果代碼在外部存儲庫中，則用戶需要指定路徑和接入憑證。函數可能依賴于外部庫或二進制文件，這些需要由用戶提供，包括描述其構建過程的方式（例如，使用 Dockerfile、Zip等）。另外，可以通過一些二進制打包（例如OCI鏡像）將函數提供給框架。

接下來讓我們介紹一下serverless函數概念。

一、函數定義

函數代碼、依賴項或二進制文件可以駐留在外部存儲庫（例如S3對象存儲桶或Git存儲庫）中，或由用戶直接提供。如果代碼在外部存儲庫中，則用戶需要指定路徑和憑據。Serverless 框架還允許用戶 watch 代碼存儲庫中的更改（例如，使 Webhook），并在每次提交時自動構建函數鏡像/二進制文件。函數可能依賴于外部庫或二進制文件，這些需要由用戶提供，包括描述其構建過程的方式（例如，使用 Dockerfile、Zip）。另外，可以通過一些二進制打包（例如OCI鏡像）將函數提供給框架。

函數定義

Serverless 函數定義可能包含以下規范和元數據，該函數定義：

• 唯一ID
• 名稱
• 說明
• Label（或tag）
• 版本ID/或版本別名
• 版本創建時間
• 上次修改時間（函數定義）
• 函數處理程序
• 運行時語言
• 代碼 + 依賴關系或代碼路徑和憑據
• 環境變量
• 執行角色和密鑰
• 資源（所需的 CPU、內存）
• 執行超時處理
• 日志記錄失敗（Dead Letter Queue，）
• 網絡策略/VPC
• 數據綁定
• 網關接入等

Dead Letter Queue中文譯作“死信隊列”，在消息隊列中，死信隊列是一種服務實現，用于存儲滿足以下一個或多個條件的消息： 發送到不存在的隊列的消息。 超出隊列長度限制。 超出了郵件長度限制。 消息被另一個隊列交換拒絕。 消息達到閾值讀取計數器編號，因為它沒有被消耗。有時這被稱為“退出隊列”。 存儲這些消息的死信隊列允許開發人員查找常見模式和潛在的軟件問題。

二、元數據

函數框架可能包括以下函數元數據：

• 版本：每個函數版本應具有唯一的標識符，此外，可以使用一個或多個別名（例如“latest”、“production”、“beta”）來標記版本。API 網關和事件源會將流
  量/事件路由到特定的函數版本。
• 環境變量：用戶可以指定在運行時將提供給函數的環境變量。環境變量也可以從機密和加密的內容派生，也可以從平臺變量派生（例如，像Kubernetes EnvVar定
  義）。環境變量使開發人員能夠控制函數行為和參數，而無需修改代碼和/或重建函數，從而獲得更好的開發人員體驗和函數重用。
• 執行角色：該函數應在特定的用戶或角色身份下運行，以授予和審核其對平臺資源的訪問權限。
• 資源：定義所需或最大的硬件資源，例如函數使用的內存和CPU。
• 超時：指定函數調用在平臺終止之前可以運行的最長時間。
• 故障日志（死信隊列）：隊列或流的路徑，它將存儲具有適當詳細信息的失敗函數執行列表。
• 網絡策略：分配給函數的網絡域和策略（函數與外部服務/資源進行通信）。
• 執行語義：指定應如何執行函數（例如，每個事件至少執行一次，最多執行一次，恰好一次）。

三、數據綁定

某些 Serverless 框架允許用戶指定函數使用的輸入/輸出數據資源，這使開發變得更簡單，性能更高（在執行期間保留數據連接，可以預取數據等）以及更好的安全
性（數據資源憑據是上下文的一部分，而不是代碼）。

綁定數據可以采用文件、對象、記錄、消息等形式，函數說明可以包括一組數據綁定定義，每個定義都指定數據資源、其憑證和使用參數。數據綁定可以引用事件數據
（例如，DB 鍵是從事件 “username” 字段派生的）

四、函數輸入

函數輸入包括事件數據和元數據，并且可以包括上下文對象。

事件數據和元數據

事件詳細信息應傳遞給函數處理程序，不同的事件可能具有不同的元數據，因此希望函數能夠確定事件的類型并輕松解析公共和特定于事件的元數據。

可能需要將事件類與實現分離，例如：不管流存儲是 Kafka 還是 Kinesis，處理消息流的函數都可以運行。在這兩種情況下，它將接收消息正文和事件元數據，消

息可能在不同框架之間路由。

事件可以包括單個記錄（例如，在請求/響應模型中），也可以接受多個記錄或微批處理（例如，在流模式中）。

FaaS 解決方案使用的常見事件數據和元數據的示例：

• Event Class/Kind
• 版本
• 事件 ID
• Event Source/Origin
• 來源身份
• 內容類型
• 郵件正文
• 時間戳記

事件/記錄特定元數據的示例

• HTTP：Path、Method、Header、查詢參數
• 消息隊列：Topic、Header
• 記錄流（Record Stream）：表、鍵、操作、修改時間、舊字段、新字段

事件源結構的示例：

• http://docs.aws.amazon.com/lambda/latest/dg/eventsources.html
• https://docs.microsoft.com/zh-cn/azure/azure-functions/functions-triggers-bindings
• https://cloud.google.com/functions/docs/concepts/events-triggers

一些實現將 JSON 視為將事件信息傳遞給函數的機制。對于高速函數（例如，流處理）或低能耗設備（IoT），這可能會增加大量的序列化/反序列化開銷。在這些情況

下，可能值得考慮使用本地語言結構或其他序列化機制。

五、函數上下文

調用函數時，框架可能希望提供對跨多個函數調用的平臺資源或常規屬性的訪問，而不是將所有靜態數據放入事件中或強制該函數在每次調用時初始化平臺服務。上下文（Context）可以是一組輸入屬性、環境變量或全局變量。有的實現將這三者結合使用。

上下文示例：

• 函數名稱、版本、ARN
• 內存限制
• 請求 ID
• Cloud Region
• 環境變量
• 安全密鑰/令牌
• 運行時/綁定路徑
• 日志
• 數據綁定

有的實現初始化日志對象（例如， AWS 中的全局變量或 Azure 中的部分上下文），用戶可以使用平臺集成的工具查看日志來跟蹤函數執行。除了傳統的日志記錄，未來的實現可能會將計數器/監控和跟蹤活動抽象為平臺上下文的一部分，以進一步提高函數的可用性。數據綁定是函數上下文的一部分，平臺根據用戶配置啟動與外部數據資源的連接，并且這些連接可以在多個函數調用之間重用。

五、函數輸出

當函數退出時，它可能：

• 將值返回給調用方（例如，在 HTTP 請求/響應示例中）
• 將結果傳遞到工作流程中的下一個執行階段
• 將輸出寫入日志

應該有確定的方式通過返回的錯誤值或退出代碼來知道函數是成功還是失敗。

函數輸出可以是結構化的（例如 HTTP 響應對象）或非結構化的（例如某些輸出字符串）。

參考資料
1. function

2. Serverless函數小解

End

樂于輸出干貨的CloudNative相關技術公眾號：DCOS。

總結

以上是生活随笔為你收集整理的二进制函数_SERVERLESS函数小解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。