各大Serverless架構(gòu)提供商的六項服務(wù)較量
譯文【51CTO.com快譯】根據(jù)RightScale云服務(wù)狀況報告2018版(請詳見：https://www.rightscale.com/lp/state-of-the-cloud)顯示，無服務(wù)器(Serverless)架構(gòu)的市場滲透率已增至75%。而且，這個市場里的玩家，已不再局限于AWS Lambda或Azure Functions等主流提供商。不過，在面對眾多云服務(wù)提供商，并需要將現(xiàn)有服務(wù)遷移到某個無服務(wù)器架構(gòu)之前，您是否真正了解他們的不同之處?下面讓我們一起來深入探究一番。
無服務(wù)器架構(gòu)的發(fā)展歷史
近十多年來，隨著云技術(shù)在商業(yè)中的廣泛采用，整個市場也得到了迅速發(fā)展。我們可以看到，每年都有新的應(yīng)用開發(fā)方法的出現(xiàn)。從邏輯層面來看：那些使用IaaS(基礎(chǔ)設(shè)施即服務(wù))的企業(yè)，主要是通過租用服務(wù)器資源，來將其基礎(chǔ)設(shè)施遷移到云端。但是他們的IT團隊仍然需要去動手設(shè)置各種服務(wù)器。而隨著PaaS(平臺即服務(wù))的出現(xiàn)，IT團隊逐漸擺脫了對服務(wù)器的手動操作。PaaS提供商能夠提供更為完整的應(yīng)用程序棧，包括：由提供商所管理的、運行在云中的操作系統(tǒng)和數(shù)據(jù)庫等。
如上圖所示，IaaS也屬于另一種后端即服務(wù)(Backend-as-a-Service，BaaS)的云服務(wù)部署與開發(fā)模式。
2014年，一種新的應(yīng)用程序開發(fā)方法：無服務(wù)器架構(gòu)，或稱FaaS(功能即服務(wù)，F(xiàn)unction-as-a-Service)出現(xiàn)了。簡而言之，F(xiàn)aaS是一種無服務(wù)器的計算形式，它使用的是完全由提供商托管的基礎(chǔ)架構(gòu)，供用戶上傳和運行他們的功能函數(shù)，并按請求付費(pay-per-request)。
與其他云計算方法不同的是，無服務(wù)器架構(gòu)讓開發(fā)人員完全從服務(wù)器中抽象出來，使得他們能夠?qū)Ｗ⒂跇I(yè)務(wù)的邏輯。如果您想更深入地了解FaaS的相關(guān)概念，以及無服務(wù)器架構(gòu)的優(yōu)缺點，請閱讀：https://www.altexsoft.com/blog/cloud/pros-and-cons-of-serverless-architecture/?utm_source=DZone&utm_medium=referral。
無服務(wù)器架構(gòu)的好處
話說回來，盡管無服務(wù)器架構(gòu)已廣受歡迎，但是它不一定對每一家公司、每一類產(chǎn)品都合適。在此，我們首先來看看無服務(wù)器架構(gòu)的整體優(yōu)勢。當然，由于服務(wù)提供商的不同(如開源或是公有云)，各家的優(yōu)勢也可能略有不同。
u 降低成本和具有可擴展性。如前所述，與傳統(tǒng)方法相比，無服務(wù)器架構(gòu)降低了服務(wù)器運營和維護的成本。而與其他類型的云計算服務(wù)相比，大多數(shù)FaaS提供商都能夠貫徹按請求付費的定價機制。這就意味著您只需要為調(diào)用功能函數(shù)的時間和次數(shù)買單。此外，您還可以靈活地為功能函數(shù)分配一定數(shù)量的內(nèi)存和CPU，并按需擴縮容。
- 更快的開發(fā)和部署。區(qū)別于整體(monolith)結(jié)構(gòu)的構(gòu)建方式，F(xiàn)aaS提供了更靈活的替代方案。開發(fā)人員可以編寫一組，由不同功能函數(shù)所組成的代碼，而不是將整體應(yīng)用的代碼上傳到服務(wù)器上。因此，這使得整個結(jié)構(gòu)更易于調(diào)試、更新和添加新的功能。
- 減少人力資源的支出。企業(yè)不必雇用DevOps工程師來進行運維，當然也不必購買特定的硬件。
- 高可用性和自動擴展。只有在客戶端發(fā)出請求時，功能函數(shù)才會被激活并運行，而在不需要的時候，它們處于關(guān)閉狀態(tài)。同時，隨著流量的增長，F(xiàn)aaS能夠自動擴展，它們通過為特定功能函數(shù)分配更多的資源，以實現(xiàn)高可用性，和在高負載下的平穩(wěn)性能。
- 專注于業(yè)務(wù)需求。通過讓開發(fā)人員從服務(wù)器端(server-side)的工作抽象出來，您的團隊會更專注于應(yīng)用的業(yè)務(wù)邏輯。
無服務(wù)器架構(gòu)提供商概述
這兩年，隨著新玩家持續(xù)的入局，無服務(wù)器架構(gòu)提供商的名錄在2018年也擴充了不少。我們將這些提供商分為主流和備選兩大類。主流類一般是在共有云上提供無服務(wù)器架構(gòu)。下面，我們將對各大主流與備選提供商進行介紹與比較。
Amazon Web Services于2014年推出了此類FaaS產(chǎn)品。自發(fā)布以來，Lambda已經(jīng)成為了無服務(wù)器架構(gòu)的代名詞。憑借著最廣泛的服務(wù)類別，Lambda一直保持著市場的領(lǐng)先地位。其***的案例，莫過于Netflix的無服務(wù)器公有云應(yīng)用。
作為AWS Lambda競爭對手，該服務(wù)于2016年被推出。Azure Functions提供了一組與Amazon類似的服務(wù)，它更關(guān)注于Microsoft體系產(chǎn)品的語言和工具。Azure Functions的一個案例是Have I Been Pwned。如果您對Azure上的應(yīng)用程序結(jié)構(gòu)、及其執(zhí)行方式感興趣的話，您可以通過https://www.troyhunt.com/how-did-have-i-been-pwned-perform-on/，來查看有關(guān)該案例的分析和費用詳情。
作為四巨頭之一，Google直到2017年才發(fā)布了其解決方案。雖然GCF的起步晚于Azure和Lambda，但是Google在2018年奮起直追，它解決了各種早期錯誤，并在其官網(wǎng)上進行了公示。
作為無服務(wù)器領(lǐng)域的新手，IBM憑借著一系列具有競爭力的服務(wù)打入到了該市場。IBM Cloud Functions是Apache OpenWhisk在其云服務(wù)中唯一使用到的托管式架構(gòu)方案。當然，如果您更偏好開源方案的話，那么Apache OpenWhisk可能更合適于您。
總的說來，上面提到的各大提供商都能夠提供相似的服務(wù)，也都能夠在托管式架構(gòu)上運行各種應(yīng)用。雖然表現(xiàn)形式各有不同，但是它們都能給用戶帶來FaaS的各種優(yōu)勢。為了幫助您找出最適合于自己提供商，我們將從如下六個方面深入比較它們的服務(wù)：
- 定價模型和計費因素
- 支持的編程語言
- 功能函數(shù)觸發(fā)類型
- 每個請求和并發(fā)的執(zhí)行持續(xù)時間
- 部署方法
- 監(jiān)控和記錄
主流FaaS提供商的比較
定價模型和計費因素
如前所述，大多數(shù)FaaS提供商使用的是非常劃算的按請求付費的定價模型。為了能夠計算出某個應(yīng)用的成本，他們通過各種服務(wù)來精準地預(yù)測出該應(yīng)用的潛在費用。例如：Serverlesscalc就是一款能夠?qū)ｉT用來計算，目標應(yīng)用在四大無服務(wù)器架構(gòu)提供平臺上成本開銷的工具，不過它目前仍處于測試階段。當然，上述各大提供商也有著自己的計算工具：
如上圖所示，大多數(shù)提供商的價格體系基本相同，但由于Google對內(nèi)存與CPU的使用單獨計費，因此它是其中最貴的。具體說來：
AWS Lambda提供一種免費套餐，它包括：每月100萬個請求和每秒400,000 GB的計算時間(computing time)。而對于超出免費套餐限額的所有請求，均按照0.00001667美元每GB每秒收費，這是市場上的***價格。在實際操作中，免費套餐完全足夠您在開始被計費之前完成自己應(yīng)用的調(diào)試。那些分配給用戶的資源(內(nèi)存和CPU)將被視為一個整體單元進行計費，畢竟它們都是等比例增長的。如果您在自己的Lambda功能函數(shù)中使用到了其他的AWS服務(wù)，那么就可能會產(chǎn)生額外的費用。
Azure的計費方式與Lambda相同，也提供免費的套餐。不過對于超出部分，它按照0.000016美元每GB每秒收費?？梢?，Azure平臺的重負載成本略低于Lambda，而平均負載則與Lambda相同。不過，Microsoft更希望對內(nèi)存的使用量進行計費，而不是簡單地一次性分配給用戶。另外，對于用戶可能用到Windows和SQL，Azure也提供了較低的價格。
可見，對于上述兩個平臺的選擇，實際上取決于您所使用的環(huán)境，而非您所承擔的成本。
GCF的免費套餐為：每月200萬個請求和每秒400,000 GB的計算時間。而對于超出免費套餐限額的所有請求，均按照0.0000004美元每GB每秒收費，包括網(wǎng)絡(luò)流量。因此，對于那些運行耗時的功能函數(shù)或請求量大的應(yīng)用來說，Google Cloud Functions的費用明顯更高。上面也提到過，GCF會對分配給用戶的內(nèi)存和CPU進行分別計費。
IBM擁有與Lambda及Azure相同的免費套餐，而對于超出免費套餐限額的所有請求，均按照0.000017美元每GB每秒收費。在計費方面，IBM OpenWhisk會記錄功能函數(shù)處于活動狀態(tài)時所消費的資源。
總而言之，AWS Lambda的定價適中;Azure的費用取決于所使用的CPU和內(nèi)存;而對于Windows環(huán)境來說，Azure提供了***的價位。
支持的編程語言
為了讓用戶可以在托管的環(huán)境中運行自己的應(yīng)用，F(xiàn)aaS提供商往往會在它們所提供的共有云環(huán)境里支持多種語言。
Lambda涵蓋了廣泛的編程語言，其中包括：Node.js runtime、Python、Java和其他編譯語言、以及.net語言(C#、Visual Basic和F#)。
Azure Functions顯然將重點放在了Microsoft的語言系列上，包括：Node.js runtime、C#、F#、Python、PHP、Bash、Batch和PowerShell、以及編譯JavaScript語言。
Google Cloud Functions過去只支持JavaScript，如今它已宣布正在測試支持許多其他的語言。不過就目前而言，GCF看起來并不是一個非常可靠的選擇。
IBM目前支持Node.js runtime、Swift、Java、PHP和Python。同時，它可以與任何帶有Docker容器的編程語言相集成。
上圖便是四大提供商所支持的語言列表。目前，GCF的支持類型最為有限。
功能函數(shù)觸發(fā)類型
主流提供商都能夠提供用于調(diào)用功能函數(shù)的，可配置的動態(tài)觸發(fā)器類型。它們支持按需調(diào)用分別調(diào)度函數(shù)，并與其他云服務(wù)相集成。您可以在不同提供商的用戶文檔中找到相關(guān)的詳細信息。
Lambda和Azure通過API提供已配置的觸發(fā)器類型。其中，AWS使用API網(wǎng)關(guān)作為API觸發(fā)器，通過Amazon S3作為基于文件的觸發(fā)器，以及通過DynamoDB來執(zhí)行動態(tài)觸發(fā)。而Azure則建議使用其他的Microsoft服務(wù)、Azure事件中心和Azure存儲，來實現(xiàn)Web API觸發(fā)和計劃性調(diào)用。
GCF服務(wù)在其文檔中提供了各種能夠支持的觸發(fā)器列表。GCF觸發(fā)器類型的主要功能是：讓用戶的應(yīng)用能與任何Google服務(wù)相集成，進而支持cloud Pub/Sub與各種HTTP回調(diào)。
IBM雖然并沒有在觸發(fā)方面與太多的第三方服務(wù)相集成，但是它仍然能夠支持許多常見的觸發(fā)器類型，包括：基于瀏覽器的HTTP工具調(diào)用、以及計劃性的觸發(fā)。
因此，若是要根據(jù)觸發(fā)方法來選擇提供商的話，Azure與Lambda應(yīng)該是***選擇，而如果您需要通過Google服務(wù)來觸發(fā)某些功能函數(shù)的話，也可以選擇GCF。
執(zhí)行時間(Execution Time)和并發(fā)數(shù)
與功能函數(shù)調(diào)用相關(guān)的另一個重要方面是：執(zhí)行時間和并發(fā)數(shù)。此處并發(fā)數(shù)表示在一段時間內(nèi)并行執(zhí)行不同功能函數(shù)的數(shù)量。
如上圖所示，Google具有***并發(fā)數(shù)，而AWS Lambda卻有著最長執(zhí)行時間。
Lambda的并發(fā)數(shù)為1,000個，其最長執(zhí)行時間為15分鐘。用戶既可以為整個帳戶，也能夠為單個功能函數(shù)配置并發(fā)數(shù)。
Azure為單個應(yīng)用提供了***的并發(fā)率，但是單個功能函數(shù)的最長執(zhí)行時間被限制為5分鐘。如果用戶需要長達10分鐘則需要進行升級。
GCF只允許對HTTP觸發(fā)器類型進行***次的調(diào)用。而對于其他觸發(fā)方法，其并發(fā)數(shù)與Lambda相同，也是一次只能執(zhí)行1,000個。它將單個功能函數(shù)的執(zhí)行時間限制為60秒，在升級后可達9分鐘。值得一提的是：AWS Lambda計算的是單個帳戶的并發(fā)數(shù)，而GCF統(tǒng)計的是項目中的并發(fā)數(shù)。這意味著：在AWS上，您只能運行一個具有1,000個并發(fā)量的調(diào)用函數(shù)，而在GCF上，您可以使用同一個并發(fā)來運行多個功能函數(shù)。
IBM對于單個功能函數(shù)的調(diào)用并不限制時間，但它的并發(fā)率并不清楚，當然也不作保證。
因此，如果您希望功能函數(shù)的性能平穩(wěn)，則選擇Lambda、GCF和Azure皆可。如果您注重長時間的調(diào)用，那么Lambda和IBM將是更好的選擇。
部署方法
各大提供商的部署方法似乎沒有什么區(qū)別。在無服務(wù)器框架的部署中，開發(fā)人員通常會使用serverless.yml來配置功能函數(shù)，然后將函數(shù)的代碼打包到Zip文件中，進而推送到服務(wù)器上。
Lambda能夠更新用戶應(yīng)用中的每一個單獨的功能函數(shù);而Azure、GCF和IBM服務(wù)則傾向于通過插件來解析serverless.yml，當然它們上傳各種資源的順序也略有不同。
監(jiān)控和記錄
由于所有的架構(gòu)都是由提供商進行管理的，因此為了獲悉應(yīng)用程序的狀態(tài)和參數(shù)指標，它們需要為每一項服務(wù)提供監(jiān)控和日志記錄的工具。籍此，用戶也能夠概覽到資源的使用與分配、出現(xiàn)的錯誤、以及相應(yīng)的監(jiān)視日志等方面。
Amazon自家的Lambda服務(wù)工具 – CloudWatch，能夠觀察功能函數(shù)的調(diào)用與日志。但是，由于CloudWatch是一項付費的服務(wù)，因此也受到了一些批評。其他主流提供商的類似服務(wù)包括：Microsoft Monitor、Google Stackdriver、以及IBM logging and monitoring。
Amazon的另一項服務(wù)X-Ray，是一種監(jiān)控多種AWS服務(wù)的分布式跟蹤系統(tǒng)。不過，它的主要用途是監(jiān)控微服務(wù)類型的應(yīng)用，而不是功能函數(shù)。下面是一些針對無服務(wù)器應(yīng)用監(jiān)視的第三方工具：
- Dashbird是一項免費的AWS監(jiān)控服務(wù)，提供CloudWatch之外的功能，并有著更加友好的用戶界面。
- OpenTracing是一種獨立于提供商的監(jiān)控服務(wù)，而并非工具。OpenTracing支持9種語言，包括：Go、JavaScript、Java、Python、Ruby、PHP、Objective-C、C++和C#。
- Thundra聚焦于JavaScript，能夠與AWS X-Ray相集成，并在其基礎(chǔ)上呈現(xiàn)監(jiān)控和日志記錄。
其他備選考慮
如上所述，四大主流無服務(wù)器架構(gòu)提供商都能提供“勢均力敵”的基礎(chǔ)服務(wù)。只是AWS Lambda和Azure Functions更為完整和多元化一些。因此您在選擇時，更多地取決于所用到的環(huán)境、對于編程語言和社區(qū)的支持要求。
如果您不想被上述主流共有云提供商的框架所“綁架”，需要對自己的產(chǎn)品具有更多控制的話，可以考慮如下開源的無服務(wù)器框架：
- IronFunctions是一款開源的無服務(wù)器計算平臺，它同時支持私有、共有和混合云。其背后的理念是：為開發(fā)人員提供可在任何地方運行的無服務(wù)器平臺。IronFunctions使用的是Go語言，這在其他無服務(wù)器選項中并不常見。
- Oracle Fn Project也是一款開源的無服務(wù)器平臺，它原生于容器化(containerization)、且獨立于語言和云環(huán)境。與IronFunctions類似，F(xiàn)n Project也可被用于私有、共有和混合云。
- Kubeless是由Kubernetes提供的容器驅(qū)動的原生無服務(wù)器架構(gòu)。它能被用于自動化容器化應(yīng)用的部署、管理和擴展。
- Firebase是移動應(yīng)用開發(fā)的后端平臺，由Google提供托管架構(gòu)。它能夠與Google的其他云服務(wù)順利集成，當然也最適合于Google的產(chǎn)品。
- Webtask是一款完全免費的FaaS平臺。它最適合于不需要繁重后端的移動應(yīng)用，并能支持各種集成方案。
原文標題：Comparing Serverless Architecture Providers: AWS, Azure, Google, IBM, and Other FaaS Vendors，作者：Ihor Lobastov
【51CTO譯稿，合作站點轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】
