說明：文章内容來自網絡文章的整理和翻譯以及ATA文章知識的彙總，知識點及資料具體出處見參考部分
背景
雲計算的發展在經曆了IaaS（Infrastructure as a Service－基礎設施即服務），PaaS（Platform as a Service－平台即服務），SaaS（Software as a Service－軟體即服務）幾個階段後，Serverless（無伺服器化）趨勢越發明顯，時至今日，無伺服器計算（Serverless Computing）作為雲原生計算模型的應用也日臻完善，相關産品也是各雲廠商競相角逐的戰場。
Serverless落地情況（Serverless Landscape）
從
CNCF Serverless Landscape中看出，Serverless落地産品形态一般分為如下三類：
- 公有雲Severless平台，代表性的有：
- 私有雲Severless架構，代表性的有：
- Fission （Kubernetes）
- Funktion （Kubernetes）
- Kubeless （Kubernetes）
- Gestalt （DC/OS）
- IBM OpenWhisk （Docker）
- Iron Functions （Docker，Swarm， Kubernetes）
- Serverless平台的包裝架構，代表性的有：
- Serverless（Node，大多數平台）
- Apex（Go，AWS）
- Zappa（Python，AWS）
- Chalice（Python，AWS）
- Claudia.js（Node，AWS）
- Gordon （Python，AWS）
Serverless發展趨勢
截至2018年12月Google Trends 的結果所示，
“Serverless”的搜尋量在過去三年中增加了近 20 倍。
中指出Serverless是增長最快的擴充雲服務，不僅在基本計算、存儲和網絡服務領域，即使在最流行的擴充服務、關系資料庫、推送通知和緩存中仍保持在前三位
相比于2017年Serverless的年增長率達到了75%，已經超過了Container-as-aservice（容器即服務），位列第一
中的付費調研也指出，78％的參與者表示他們将在未來幾個月内使用或計劃使用 Serverless 技術。
Serverless Computing概念
雲原生計算基金會
CNCF（Cloud Native Computing Foundation, CNCF）Serverless Whitepaper v1.0對無伺服器計算作了如下定義：
Serverless computing refers to the concept of building and running applications that do not require server management. It describes a finer-grained deployment model where applications, bundled as one or more functions, are uploaded to a platform and then executed, scaled, and billed in response to the exact demand needed at the moment.
無伺服器計算（Serverless Computing）是指在建構和運作應用時無需管理伺服器等基礎設施。它描述了一個更細粒度的部署模型，在該模型中，應用被拆解為一個或多個細粒度的函數被上傳到一個平台，然後根據目前所需執行、擴充和計費。
無伺服器計算并不意味着我們不再使用伺服器來承載和運作代碼，也不意味着不再需要運維工程師。而是指無伺服器計算的消費者不再需要花費時間和資源在伺服器配置、維護、更新、擴充和容量規劃上。所有這些任務和功能都由無伺服器平台處理，并且完全從開發人員和IT/操作團隊中抽象出來。是以，開發人員專注于編寫應用程式的業務邏輯。營運工程師能夠将他們的重點提升到更關鍵的業務任務上。
FaaS & BaaS
無伺服器計算平台可以提供以下一種或兩種服務：
- FaaS(Functions-as-a-Service-函數即服務），通常提供事件驅動(event-driving)的計算。開發人員使用由事件(event)或HTTP請求觸發的函數運作和管理應用程式代碼。開發人員将小的代碼單元部署到FaaS，FaaS按需執行和擴充，開發人員無需管理伺服器或任何其他底層基礎設施。
- Baas(Backend-as-a-Service後端即服務），是第三方基于API的服務，用于替換應用程式中的核心功能子集。因為這些API是作為一個自動擴縮容和透明操作的服務提供的，是以開發人員認為這是無伺服器的 ，如：OSS
Pros & Cons
無伺服器計算（Serverless Computing）應用利弊大緻如下：
Pros：
- 0伺服器操作。無伺服器通過消除維護伺服器資源所涉及的開銷，極大地改變了運作軟體應用程式的成本模型。
- 沒有配置、更新和管理伺服器基礎結構。
- 彈性伸縮：無伺服器FaaS或BaaS産品可以立即精确地伸縮以處理每個單獨的傳入請求。對于開發人員來說，無伺服器平台沒有“預先計劃的容量”的概念，也不需要配置“自動伸縮”觸發器或規則。在沒有開發人員幹預的情況下，自動進行縮放。在完成請求處理後，無伺服器FaaS會自動縮小計算資源的規模，以確定永遠沒有空閑的容量。
- 低成本。無伺服器計算服務對空閑的虛拟機或容器不收費；也就是說當代碼沒有運作或沒有進行有意義的工作時，不收費。
Cons：
- 作為一種新興的計算模型、缺乏标準化和生态系統成熟度。
- 由于運作時更具動态性，與iaas和paas相比，調試可能更具挑戰性。
- 由于按需結構，如果運作時在空閑時删除函數的所有執行個體，則某些無伺服器運作時的“冷啟動”方面可能是性能問題。
- 在更複雜的情況下（例如，觸發其他功能的功能），對于相同數量的邏輯，可以有更多的操作表面積。
Serverless處理模型（Serverless Processing Model）
CNCF白皮書對于無伺服器架構中的函數用法，函數限制、生命周期、調用類型和所需的抽象等定義了規範，以便同一個函數可以一次性編碼，并在不同的無伺服器架構中使用。
FaaS解決方案概括為具有以下圖中所示的幾個關鍵元素：
- 事件源（Event sources）-觸發器或流事件到一個或多個函數執行個體中
- 函數執行個體（Function instances）-單個函數/微服務，可根據需求進行擴充
- FaaS控制器（FaaS Controller）-部署、控制和監視函數執行個體及其源
- 平台服務（Platform services ）-FaaS解決方案使用的通用叢集或雲服務（有時稱為後端即服務－BaaS）
CNCF函數相關規範
函數定義（Function Definition）
無伺服器函數定義可以包含以下規範和中繼資料，函數定義是特定于版本的：
- 唯一ID
- 名字
- 描述
- 标簽
- 版本ID（和/或版本别名）
- 版本建立時間
- 上次修改時間（函數定義的）
- 函數處理程式
- 運作時語言
- 代碼+依賴項或代碼路徑和憑據
- 環境變量
- 執行角色和密鑰
- 資源（所需的CPU、記憶體）
- 執行逾時時間
- 日志失敗（死信隊列）
- 網絡政策/vpc
- 資料綁定（Metadata Binding）
中繼資料詳細資訊（Metadata details）
- 版本（Version）-每個函數版本都應該有一個唯一的辨別符，此外，可以使用一個或多個别名（例如“最新”、“生産”、“測試版”）标記版本。API網關和事件源将流量/事件路由到特定的函數版本。
- 環境變量（Environment Variables）-使用者可以指定将在運作時提供給函數的環境變量。環境變量也可以從機密和加密内容派生，或者從平台變量派生（例如，kubernetes envvar定義）。環境變量使開發人員能夠控制函數行為和參數，而無需修改代碼和/或重建函數，進而獲得更好的開發人員體驗和函數重用。
- 執行角色（Execution Role）-該函數應在特定的使用者或角色辨別下運作，該辨別授予并稽核其對平台資源的通路權限。
- 資源（Resources）-定義功能所需的或最大的硬體資源，如記憶體和CPU。
- 逾時（Timeout）-指定函數調用在被平台終止之前可以運作的最長時間。
- 失敗日志（死信隊列）（Failure Log (Dead Letter Queue)）-隊列或流的路徑，用于存儲失敗的函數執行清單，并提供适當的詳細資訊。
- 網絡政策（Network Policy）-配置設定給功能的網絡域和政策（用于與外部服務/資源通信的功能）。
- 執行語義（Execution Semantics）-指定應如何執行函數（例如，每個事件至少執行一次、至多執行一次、完全執行一次）。
資料綁定（Data Bindings）
一些無伺服器架構允許使用者指定函數使用的輸入/輸出資料資源，這使開發人員能夠簡化、提高性能（在執行之間保留資料連接配接，可以預取資料等）和更好的安全性（資料資源憑據是上下文的一部分，而不是代碼）。
綁定資料可以是檔案、對象、記錄、消息等形式，函數規範可以包括一組資料綁定定義，每個定義指定資料資源、其憑證和使用參數。資料綁定可以引用事件資料（例如，db鍵是從事件“使用者名”字段派生的），示例：https://docs.microsoft.com/azure/azure-functions/functions-triggers-bindings
函數限制(Function Requirements)
函數和無伺服器運作時應該滿足的通用需求：
- 函數必須與不同僚件類的基礎實作分離
- 可以從多個事件源調用函數
- 每個調用方法不需要不同的函數
- 事件源可以調用多個函數
- 函數可能需要與底層平台服務進行持久綁定的機制，這可能是跨函數調用。函數可能是短暫的，但如果需要在每次調用（例如在日志記錄、連接配接和裝載外部資料源的情況下）上都進行引導，則引導可能會很昂貴。
- 每個函數可以用不同于同一應用程式中使用的其他函數的代碼語言編寫。
- 函數運作時應盡可能減少事件序列化和反序列化開銷（例如，使用本機語言結構或有效的編碼方案）
函數調用類型（Function Invocation Types）
根據不同的用例，可以從不同的事件源調用函數，例如：
- 同步請求（Synchronous Request (Req/Rep)），例如http請求、grpc調用
- 客戶機送出請求并等待立即響應。這是一個阻塞呼叫。
- 異步消息隊列請求（pub/sub）（Asynchronous Message Queue Request），例如RabbitMQ, AWS SNS, MQTT, Email, Object (S3) change、計劃事件（如cron作業）
- 消息釋出到交換并分發到訂閱伺服器
- 沒有嚴格的消息順序， 可一次處理
- 消息/記錄流（Message/Record Streams）：Kafka, AWS Kinesis, AWS DynamoDB Streams, Database CDC
- 一組有序的消息/記錄（必須按順序處理）
- 通常，一個流被分割到多個分區/碎片（partitions/shards ），每個碎片有一個worker（碎片使用者）
- 流可以從消息、資料庫更新（日志）或檔案（例如csv、json、parquet）生成。
- 事件可以推送到函數運作時，也可以由函數運作時拉取。
- 批處理作業（Batch Jobs），例如ETL作業、分布式深度學習、HPC模拟
- 作業（Jobs）被排程或送出到隊列，并在運作時使用多個并行函數執行個體進行處理，每個執行個體處理工作集（任務）的一個或多個部分。
- 當所有并行從業人員成功完成所有計算任務時，作業完成。
函數生命周期（Function LifeCycle）
函數部署管道（Function Deployment Pipeline）
函數生命周期：
- 編寫代碼、提供規範和中繼資料
- 擷取代碼和規範，編譯并将其轉化為一個工件（二進制代碼、包或容器鏡像）
- 工件部署到一個叢集上，控制器實體負責根據事件流量和/或執行個體上的負載調整函數執行個體的數量。
函數操作（Function Operations）
無伺服器架構可能允許以下操作和方法定義和控制功能生命周期：
- 建立（Create）-建立一個新函數，包括其規範和代碼
- 釋出（Publish）-建立可部署在群集上的函數的新版本
- 更新别名/标簽（Update Alias/Label [of a version]）-更新版本别名
- 執行/調用(Execute/Invoke)-不通過事件源調用特定版本
- 事件源關聯(Event Source association )-将函數的特定版本連接配接到事件源
- 擷取（Get）-傳回函數中繼資料和規範
- 更新（Update）-修改函數的最新版本
- 删除（Delete）-删除一個函數，可以删除一個特定的版本或函數的所有版本
- 清單（List）-顯示函數及其中繼資料的清單
- 狀态擷取（get stats）-傳回有關函數運作時使用情況的統計資訊
- 日志擷取（get logs）-傳回函數生成的日志
關鍵步驟說明：
- Create：在建立函數時，提供其中繼資料（稍後在函數規範中描述）作為函數建立的一部分，将對其進行編譯并可能釋出。稍後可以啟動、禁用和啟用功能。功能部署需要能夠支援以下用例：
- 事件流（Event streaming），在這種情況下，隊列中可能總是有事件，但是可能需要通過顯式請求暫停/恢複處理。
- 熱啟動(Warm startup)-在任何時候具有最少執行個體數的函數，例如，接收到的“第一個”事件具有熱啟動，因為該函數已經部署并準備好服務于該事件（而不是在“傳入”事件第一次調用時部署該函數的冷啟動）。
- Publish：使用者可以釋出一個函數，這将建立一個新版本（最新版本的副本），釋出的版本可能會被标記/标記或有别名，請參閱下面的詳細資訊。
- 使用者可能希望為調試和開發過程直接執行/調用函數（繞過事件源或API網關）。使用者可以指定調用參數，如所需版本、同步/異步操作、詳細級别等。
- 使用者可能希望獲得函數統計資訊（例如調用次數、平均運作時間、平均延遲、失敗、重試次數等），統計資訊可以是目前路徑成本或一系列值（例如存儲在Prometheus或雲提供程式設施（如AWS Cloud Watch））。
- 使用者可能希望檢索函數日志資料。這可以根據嚴重性級别和/或時間範圍和/或内容進行篩選。日志資料是每個函數的，它包括諸如函數建立和删除、顯式錯誤、警告或調試消息等事件，還可以選擇函數的stdout或stderr。每次調用最好有一個日志條目，或者一種将日志條目與特定調用關聯的方法（以便更簡單地跟蹤函數執行流）。
事件源(Event Source)
不同類型的事件源包括：
- 事件和消息服務，例如： RabbitMQ, MQTT, SES, SNS, Google Pub/Sub
- 存儲服務，例如：S3, DynamoDB, Kinesis, Cognito, Google Cloud Storage, Azure Blob, iguazio V3IO (object/stream/DB)
- 端點服務，例如：物聯網（IoT）、HTTP網關（HTTP Gateway）、移動裝置、Alexa、Google Cloud Endpoints
- 配置存儲庫，例如：Git, CodeCommit
- 使用特定于語言的sdk的使用者應用程式
- 定時事件-允許定期調用函數。
事件源到函數的關聯（Event Source to Function Association）
函數是由事件源觸發的事件調用的。函數和事件源之間有一個n:m映射。每個事件源可以用來調用多個函數，一個函數可以由多個事件源觸發。事件源可以映射到函數的特定版本或函數的别名，後者提供了更改函數的方法，并部署了一個新版本，而不需要更改事件關聯。事件源也可以定義為使用同一函數的不同版本，定義應為每個函數配置設定多少流量。
在建立了一個函數之後，或者在以後的某個時間點，需要将事件源關聯起來，該事件源應該作為該事件的結果觸發函數調用。這需要一組操作和方法，例如：
- 建立事件源關聯
- 更新事件源關聯
- 列出事件源關聯
函數輸入（Function Input）
函數輸入包括事件資料(event data)和中繼資料(metadata)，并且可以包括一個上下文對象（context object）。
事件資料和中繼資料（Event data and metadata）
事件詳細資訊應傳遞給函數處理程式，不同的事件可能具有不同的中繼資料，是以函數需要能夠确定事件的類型并輕松解析通用和特定于事件的中繼資料。
将事件類與實作分離是可取的，例如：處理消息流的函數将工作相同，而不管流存儲是Kafka還是Kinesis。在這兩種情況下，它都将接收消息體和事件中繼資料，消息可以在不同的架構之間路由。
事件可以包括單個記錄（例如，在請求/響應模型中），或者接受多個記錄或微批（例如，在流模式中）。
FaaS解決方案使用的常見事件資料和中繼資料示例：
- 事件類别
- 版本
- 事件ID
- 事件來源/來源
- 源識别
- 内容類型
- 消息體
- 時間戳
事件/記錄特定中繼資料的示例：
- HTTP: 路徑、方法、頭、查詢參數
- Message Queue：消息隊列：主題，标題
- 記錄流（Record Stream）：表、鍵、op、修改時間、舊字段、新字段
事件源結構示例：
- AWS Lambda： http://docs.aws.amazon.com/lambda/latest/dg/eventsources.html
- Microsoft Azure Functions： https://docs.microsoft.com/azure/azure-functions/functions-triggers-bindings
- Google Cloud Functions： https://cloud.google.com/functions/docs/concepts/events-triggers
有些實作将JSON作為向函數傳遞事件資訊的機制來關注。這可能會增加高速函數（例如流處理）或低能耗裝置（IOT）的大量序列化/反序列化開銷。在這些情況下，将本機語言結構或其他序列化機制視為選項可能是值得的。
函數上下文(Function Context)
當調用函數時，架構可能希望提供對跨多個函數調用的平台資源或正常屬性的通路，而不是将所有靜态資料放在事件中，或強制函數在每次調用時初始化平台服務。
上下文作為一組輸入屬性、環境變量或全局變量傳遞。有些實作使用這三種方法的組合。
上下文示例：
- 函數名、版本、ARN
- 存儲限制（Memory Limit）
- 請求ID（Request ID）
- 雲區（Cloud Region）
- 環境變量（Environment Variables）
- 安全密鑰/令牌（Security keys/tokens）
- 運作時/bin路徑（Runtime/Bin paths）
- 日志（Log ）
- 資料綁定（Data binding）
一些實作使用日志對象初始化日志對象（例如，作為AWS中的全局變量或Azure中的部分上下文），使用者可以使用內建平台工具跟蹤函數執行。除了傳統的日志記錄之外，未來的實作可能會将計數器/監視和跟蹤活動抽象為平台上下文的一部分，以進一步提高功能的可用性。
資料綁定作為函數上下文的一部分，平台根據使用者配置啟動到外部資料資源的連接配接，這些連接配接可以在多個函數調用中重用。
函數輸出（Function Output）
當函數退出時，它可以：
- 向調用者傳回一個值（例如，在HTTP請求/響應示例中）
- 将結果傳遞到工作流中的下一個執行階段
- 将輸出寫入日志
應該有一種确定的方法來知道函數是否通過傳回的錯誤值或退出代碼成功或失敗。
函數輸出可以是結構化的（如HTTP響應對象）或非結構化的（如某些輸出字元串）。
無伺服器函數工作流（Serverless Function Workflow）
- 在無伺服器域中，用例（Use Case）屬于以下類别之一：
- 一個事件觸發一個函數
- 事件的和/或組合觸發一個函數
- 一個事件觸發順序或并行執行的多個函數
- 函數的結果可能是另一個函數的觸發器
- n個事件（i n和/或）觸發m個函數，即事件函數交錯的工作流，如事件1觸發函數1，完成函數1和事件2以及事件3觸發函數2，然後函數2的不同結果觸發分支到函數3或函數4。
使用者需要一種方法來指定他們的無伺服器用例或工作流。例如，一個用例可以是“在照片上傳到雲存儲時在照片上進行人臉識别（發生照片存儲事件）。”另一個物聯網用例可以是“在接收到運動檢測事件時進行運動分析”，然後根據分析功能的結果，或者“觸發房屋警報并調用e警察部門“或隻是”将運動圖像發送給房主。“有關詳細資訊，請參閱用例部分。
AWS提供“步驟函數”（
step function），供使用者指定其工作流，但步驟函數不允許指定觸發工作流中哪些函數的事件/事件。
下圖是涉及事件和函數的使用者工作流的示例。使用這種函數圖，使用者可以輕松地指定事件和函數之間的互動，以及如何在工作流中的函數之間傳遞資訊。
功能圖狀态包括：
- Event State（事件狀态）：此狀态允許等待來自事件源的事件，然後觸發函數運作或多個函數按順序、并行或在分支中運作。
- Operation/Task State（操作/任務狀态）：此狀态允許按順序或并行運作一個或多個函數，而不等待任何事件。
- Switch/Choice State（切換/選擇狀态）：此狀态允許轉換到多個其他狀态（例如，前一個函數結果觸發分支/轉換到不同的下一個狀态）。
- End/Stop State（結束/停止狀态）：此狀态以失敗/成功終止工作流。
- Pass State（通過狀态）：此狀态在兩個狀态之間插入事件資料。
- Delay/Wait State（延遲/等待狀态）：此狀态導緻工作流執行延遲指定的持續時間或直到指定的時間/日期。
狀态和相關資訊需要儲存在一些持久存儲中，以便進行故障恢複。在某些用例中，使用者可能希望将來自一個狀态的資訊傳遞到下一個狀态。這些資訊可以是函數執行結果的一部分，也可以是與事件觸發器關聯的輸入資料的一部分。需要在每個狀态定義一個資訊過濾器，以過濾出需要在狀态之間傳遞的資訊。