8大Serverless 平臺該選誰？
在云端以24/7全天候方式全容量運行服務器十分浪費資源，所以只要可能，企業(yè)當然希望能在不需要時關停大部分容量。如果以合乎邏輯的思路來推斷，那么更好的方案應該是在必要時按需啟動服務器，而且只根據(jù)負載需求提供對應的容量資源。
這就是Serverless，即無服務器計算的施展空間了。無服務器計算是一種云執(zhí)行模型，云服務商會在模型當中根據(jù)執(zhí)行特定代碼段所需要的計算資源與存儲進行動態(tài)資源分配和計費。
換句話說，無服務器計算是一種按需且即用即付的后端計算形式。當請求進入無服務器端點時，后端要么重用已經(jīng)包含正確代碼的既有端點、要么從資源池中分配并自定義資源，或者實例化并自定義新端點�；A設施通常會根據(jù)需求運行盡可能多個實例以處理傳入請求，并在一段時間的冷卻期后釋放掉全部閑置實例。
其實，Serverless也要使用服務器，只是用戶無需承擔服務器管理工作。運行無服務器代碼的容器或其他資源通常運行在云端，但也可以運行在指定的邊緣點位置。函數(shù)即服務（FaaS）是對各類無服務器架構的基本總結。在FaaS中，用戶為一條函數(shù)編寫代碼，基礎設施則負責提供必要的運行時環(huán)境、加載與運行代碼并控制運行時生命周期。FaaS模塊能夠與Webhook、HTTP請求、流、存儲桶、數(shù)據(jù)庫以及其他構建單元順暢集成，共同建立起無服務器應用程序。
下面我們來看幾種流行的無服務器計算平臺，希望能對企業(yè)的平臺選型提供一定幫助。
平臺一 AWS Lambda與其他相關服務
AWS Lambda是一種常見的FaaS解決方案。除AWS Lambda之外，亞馬遜云科技目前提供十余種無服務器產(chǎn)品。誕生于2014年的AWS Lambda并非全球首例FaaS服務，在它之前還有2006年的Zimki、2008年的Google App Engine以及2010年的PiCloud。
AWS Lambda支持以Python、Node.js、Ruby、Java、C#、PowerShell以及Go等語言編寫的無狀態(tài)函數(shù)代碼。Lambda函數(shù)在運行之后即可響應事件，例如對象被上傳至Amazon S3、Amazon SNS通知或者API操作等。Lambda函數(shù)會自動接收一個500 MB的臨時暫存目錄，而且可以使用Amazon S3、Amazon DynamoDB或其他線上存儲服務實現(xiàn)持久狀態(tài)。Lambda函數(shù)還可以使用Amazon Linux支持的一切語言啟動進程，并靈活調(diào)用庫。此外，Lambda目前已經(jīng)在全體AWS區(qū)域內(nèi)上線。
其他幾款AWS無服務器產(chǎn)品同樣值得關注。Lambda@Edge允許在200多個AWS邊緣站點運行Lambda函數(shù)，靈活響應Amazon CloudFront內(nèi)容交付網(wǎng)絡上的各類事件。Amazon DynamoDB則是一項快速且敏捷的鍵值與文檔數(shù)據(jù)庫服務，能夠提供穩(wěn)定的個位數(shù)毫秒級延遲。Amazon Kinesis則是一套用于在AWS上實現(xiàn)流式數(shù)據(jù)傳輸?shù)钠脚_。此外，可以使用AWS Greengrass在本地聯(lián)網(wǎng)設備（例如物聯(lián)網(wǎng)控制器）上運行Lambda函數(shù)。
開源AWS Serverless Application Model（AWS SAM）用于建模并部署無服務器應用程序及服務。除了SAM之外，AWS Lambda還支持八種開源及第三方框架。
AWS Serverless Application Repository則幫助為各種用例查找并重用無服務器應用程序與相關組件。企業(yè)可以使用Amazon CloudWatch監(jiān)控無服務器應用程序，并使用AWS X-Ray實現(xiàn)分析與調(diào)試。最后，AWS Lambda最近還發(fā)布了Lambda Extensions的預覽版——這是一套用于將Lambda同監(jiān)控、可觀察性、安全性及治理工具輕松集成起來的全新解決方案。
平臺二 微軟Azure Functions
微軟Azure Functions是一套事件驅(qū)動型無服務器計算平臺，能夠解決種種復雜的編排問題。無需額外設置，大家就能在本地構建并調(diào)試Azure Functions，將成果大規(guī)模部署并運行在云端，而后使用相應的觸發(fā)器與綁定機制集成更多其他服務。
開發(fā)者可以使用C#、F#、Java、JavaScript（Node.js）、PowerShell或者Python語言編寫Azure Functions代碼。但在單一Azure Functions應用程序中，我們只能選擇使用一種編程語言�？梢栽赩isual Studio、Visual Studio Code、IntelliJ、Eclipse以及Azure Functions Core Tools當中完成Azure Functions的本地開發(fā)。或者，也可以直接通過Azure門戶編輯各種小型Azure函數(shù)。
Durable Functions是Azure Functions的一種擴展，以供在無服務器計算環(huán)境中編寫有狀態(tài)函數(shù)。該擴展允許使用Azure Functions編程模型編寫實體函數(shù)，由此開發(fā)出包含有編排器函數(shù)及有狀態(tài)實體的有狀態(tài)工作流。
觸發(fā)器是引導函數(shù)運行的關鍵，也定義著函數(shù)的具體調(diào)用方式。一條函數(shù)必須只能對應一個觸發(fā)器。觸發(fā)器中還包含關聯(lián)數(shù)據(jù)，這些數(shù)據(jù)通常作為函數(shù)的有效負載存在。綁定至函數(shù)，則是一種將資源接入函數(shù)的聲明方式；綁定具體分為輸入綁定、輸出綁定或者二者皆有。來自綁定的數(shù)據(jù)會以參數(shù)的形式被交付至函數(shù)當中。
平臺三 Google Cloud Functions
Google Cloud Functions是一套可擴展的即用即付FaaS平臺。它提供集成化的監(jiān)控、日志記錄與調(diào)試功能，在各角色及函數(shù)層級提供內(nèi)置安全機制，同時具備適配混合云及多云場景所必需的關鍵網(wǎng)絡功能。在它的幫助下，開發(fā)者可以通過觸發(fā)器輕松接入Google Cloud或第三方云服務，大大簡化以往難度頗高的編排問題。
Google Cloud Functions支持Go、Java、Node.js以及Python等語言編寫的代碼。Cloud Functions則支持各類常見的HTTP請求方法（包括GET、PUT、POST、DELETE以及OPTIONS），也能支持負責處理來自云基礎設施的各類事件的后臺函數(shù)。大家可以使用Cloud Build或其他CI/CD（持續(xù)集成/持續(xù)部署）平臺實現(xiàn)Cloud Functions的自動測試與部署，并靈活匹配GitHub、Bitbucket或者Cloud Source Repositories等源代碼存儲庫。最后，開發(fā)者也可以在本地計算機上開發(fā)并部署Cloud Functions。
平臺四 IBM Cloud Functions
IBM Cloud Functions以Apache OpenWhisk為基礎，屬于一套多語言的函數(shù)即服務編程平臺，可用于開發(fā)按需執(zhí)行并擴展的輕量級代碼。開發(fā)者可以使用Node.js、Python、Swift及PHP語言開發(fā)IBM Cloud Functions。IBM一直在努力引導客戶在“事件-觸發(fā)-操作”這一典型工作流中將Cloud Functions與Watson API集成使用，借此將應用程序數(shù)據(jù)的認知分析融入無服務器工作流當中。
平臺五 Apache OpenWhisk
OpenWhisk是一套用于構建云應用程序的開源無服務器函數(shù)平臺。OpenWhisk提供豐富的編程模型，能夠使用函數(shù)構建無服務器API、將函數(shù)組合添加至無服務器工作流內(nèi)，并使用規(guī)則與觸發(fā)器將事件與函數(shù)相對接。
企業(yè)可以在本地運行OpenWhisk堆棧，或?qū)⑵洳渴鹬罧ubernetes集群（可以是企業(yè)自己的集群，也可以是由公有云服務商托管的Kubernetes集群），或者使用完全支持OpenWhisk的其他云服務商（例如IBM Cloud）。OpenWhisk目前可支持使用Ballerina、Go、Java、JavaScript、PHP、Python、Ruby、Rust、Swift以及.NET Core編寫的代碼；也可以使用自己的Docker容器。
OpenWhisk項目中包含多種開發(fā)者工具，例如用于輕松創(chuàng)建、運行并管理OpenWhisk實體對象的wsk命令行界面；使用應用程序清單通過單項命令部署并管理所有OpenWhisk包、操作、觸發(fā)器、規(guī)則與API的wskdeploy；OpenWhisk REST API；以及JavaScript及Go版本的OpenWHisk API客戶端等。
平臺六 Knative
Knative項目由谷歌發(fā)起，先后獲得50多家企業(yè)的貢獻，用于在Kubernetes上構建并運行無服務器應用程序。Knative的各組件專注于解決常見但又令人頭痛的任務，例如容器部署、使用藍/綠部署進行流量路由與管理、根據(jù)需求自動擴展并調(diào)整工作負載，以及將運行的服務綁定至事件生態(tài)系統(tǒng)等。值得一提的是，Google Cloud Run就是基于Knative構建而成。
平臺七 Kubeless
Kubeless是一套開源Kubernetes原生無服務器框架，強調(diào)以Kubernetes集群為部署環(huán)境。Kubeless重現(xiàn)了AWS Lambda、微軟Azure Functions以及Google Cloud Functions上的大部分功能。開發(fā)者可以使用Python、Node.js、Ruby、PHP、Golang、.NET以及Ballerina等語言編寫Kubeless函數(shù)。Kubeless事件觸發(fā)器使用的則是Kafka消息系統(tǒng)與HTTP事件。
Kubeless還使用Kubernetes定制資源定義（Kubernetes Custom Resource Definition）創(chuàng)建作為自定義Kubernetes資源的函數(shù)。在此之后，它會運行集群內(nèi)控制器以監(jiān)控各自定義資源，并按需啟動運行時�？刂破鲿⻊討B(tài)將函數(shù)代碼注入運行時，并通過HTTP或發(fā)布/訂閱機制進行實際使用。
平臺八 OpenFaaS
OpenFaaS是一套面向Kubernetes的開源無服務器框架，項目口號是“讓無服務器函數(shù)更簡單”。OpenFaaS屬于云原生技術堆棧“PLONK”中的一部分，即Prometheus（監(jiān)控系統(tǒng)與時間序列數(shù)據(jù)庫）、Linkerd（服務網(wǎng)格）、OpenFaaS、NATS（安全消息傳遞與流媒體）以及Kubernetes。您可以使用OpenFaaS中的模板存儲或Dockerfile，將相應的事件驅(qū)動函數(shù)及微服務部署到Kubernetes。
Serverless 平臺選型原則
講解了這么多選項，我們到底該如何選擇？與一切軟件架構選擇難題一樣，問題的答案還是跟具體的需求密切相關。
首先，企業(yè)需要評估現(xiàn)有軟件資產(chǎn)及發(fā)展目標。在大型機上運行著海量Cobol遺留程序的組織，其發(fā)展路徑當然不可能跟已經(jīng)擁有規(guī)�；栖浖Y產(chǎn)的組織相同。
如果企業(yè)中已經(jīng)擁有不少云資產(chǎn)，請明確列出現(xiàn)有部署方案、具體使用哪些云服務商以及對應的可用區(qū)。此外，總結客戶及用戶的位置與服務使用模式也非常重要。
例如，需要24/7全天候保持統(tǒng)一負載級別的應用程序就不太適合無服務器部署——相反，合適的服務器、虛擬機或容器集群也許成本更低也更易于管理。另一方面，具有明確偶發(fā)運行特征、負載規(guī)模靈活多變且往往由特定操作（例如源代碼簽入）觸發(fā)的應用程序則是無服務器架構的完美匹配對象。
另外，分布在全球各地而且對延遲要求嚴苛的服務，則特別適合部署在多可用區(qū)或邊緣端點之上。因為原本在華盛頓特區(qū)使用的服務，可以被完美遷移至弗吉尼亞州的目標可用區(qū)內(nèi)。
如果您的企業(yè)已經(jīng)擁有豐富的Kubernetes使用經(jīng)驗，不妨考慮選擇Kubernetes的各類開源無服務器平臺。但如果沒什么Kubernetes經(jīng)驗，最好還是選擇原生云FaaS基礎設施，這時候開源（例如無服務器框架）還是專有（包括AWS Lambda、Google Cloud Functions或者Azure Functions）就不那么重要了。
如果企業(yè)所構建的無服務器應用程序依賴于云數(shù)據(jù)庫或流媒體服務，則應考慮將它們部署在同一云環(huán)境內(nèi)，最大程度降低應用程序之內(nèi)各組件間的延遲。請放心，這不會對無服務器框架選擇造成太大影響。例如，使用Google Cloud Bigtable數(shù)據(jù)存儲的應用程序完全可以選擇Google Cloud Functions、Google Cloud Run、Serverless Framework、OpenWhisk、Kubeless、OpenFaaS、Fission或者Knative等多種方案，且繼續(xù)保持穩(wěn)定的最低延遲水平。
在大多數(shù)情況下，您的應用程序可能與常見用例頗為相似、甚至完全相同。這時候，大家就應認真評測目標無服務器平臺的示例和庫資源，看看有沒有能夠拿來就用的參考架構。事實上，大部分函數(shù)即服務系統(tǒng)并不需要編寫大量代碼：FaaS擁有豐富的可重用代碼資源，而且架構本身也經(jīng)過良好測試及驗證。無需大量調(diào)試，企業(yè)就可以將其化為己用、大大提升工作效率。
