一文看懂當紅Serverless：為何AWS、阿里云和騰訊云都在發力「無服務器架構」

冠望 發自 凹非寺
量子位 報道 | 公眾號 QbitAI

要說目前軟件架構中熱度十二分的話題，當屬Serverless。

通常我們會將其翻譯為“無服務器架構”。

盡管成天被稱為“無服務器”，但該架構與傳統架構不同，顯然并不是真的不需要服務器。

而是選擇將服務器等基礎設施的管理“隱藏”起來，計算資源作為服務而不是作為服務器的概念出現。

兼具事件觸發、短暫以及完全被第三方管理等多重屬性，其中開發者只需關注業務邏輯即可。

那一年，也就是2012，TA首次出現在技術人的視野之中。

就在嶄露頭角之后的短短兩年，號稱云計算“3A巨頭”之一的AWS，就于當年年底正式推出了Lambda 產品，標志著Serverless的商業化進程隆重被開啟。

當時的Lambda曾被大家如此描述：這是一種計算服務，可以根據時間來運行用戶的代碼，無需關心底層的計算資源。

從2012年到2014年，Lambda著實不算早到。

但就像云計算PaaS初出茅廬時的說法一樣：用戶只管業務就好，底層IaaS就交給我們吧！

Serverless與PaaS帶給人們的理念是如此驚人的相似。

隨后的兩年時間內，Google Cloud Function 和微軟 Azure Function 在技術圈子的成功，也就順理成章將 Serverless推進了熱化階段。

從架構變遷聚焦Serverless內涵

對于眾多開發者而言，顯然僅僅知道“Serverless被定義為無服務器架構”的概念完全不夠，如何將Serverless的理解更具象化一些？

恐怕還是要從軟件應用架構演進的角度說起。

或許你可能了解，在十幾年前，單體應用作為最主流的應用架構形式被廣泛認可。

依靠一臺服務器外加一個數據庫，就能讓服務可用性達到峰值狀態。

但隨著服務器老化性能下降甚至自身損壞的情況，再加上企業業務量的逐漸擴大，單體架構再也不是“一招鮮吃遍天”。

哪怕在流量入口加入負載均衡器，讓單體應用可以部署在多臺服務器上來增加彈性，也不能完全解決由代碼無物理邊界所帶來的大量沖突。

至此，單體應用架構第一次有機會進化成微服務架構，而此時的架構師們也就不得不直面分布式帶來的新挑戰。

例如那些年的緩存服務 Redis、狀態協調服務ZooKeeper、消息服務 Kafka等。

我們可以簡單理解為，將一個大系統劃分為多個業務模塊，其中的業務模塊又需要分別部署在不同的服務器上，各個業務模塊之間通過接口進行數據交互，這件事兒似乎沒那么簡單。

當然除了分布式環境的特殊性以外，微服務架構也給運維帶來了不小改變。

具體實踐中，由于微服務可以部署在不同的服務器上，也可以部署在相同的服務器卻不同的容器上，包括應用分發標準、生命周期標準以及自動化彈性等能力在內的重要性也就一一凸顯出來。

轉眼到了眾所周知的云原生時代，業務直接上云不說，還能提供標準化的應用托管服務，包括版本管理、發布、上線后的觀測、自愈等，價值紅利得到進一步彰顯。

而此時Serverless也正迎著這波技術紅利闖入了大眾的視線，得到關注。

可以看出，在架構的演進中，無論是研發還是運維人員都逐漸將著眼點從機器向平臺系統轉移，而不是單純用人去管理，這或許是對于Serverless原理最樸素的闡釋。

總結一下，Serverless的出現其實是將主機管理、操作系統管理、資源分配等，甚至是應用邏輯全部組件都集成為服務。

如果將其放在當下的云計算場景中，就不能單純狹義理解為“不用關心服務器”那么簡單，畢竟上云的資源除了服務器之外，還涉及基礎計算、存儲資源、網絡資源等諸多，也包括數據庫、緩存以及消息隊列等更上層的范疇。

Serverless架構類同FaaS，又做何解？

提及 Serverless，很多人的第一反應都是 FaaS+BaaS。

的確，這是 Serverless的一種實現形式，也是一種比較主流的理解。

所謂“FaaS+BaaS ”，其實就是函數即服務與后端即服務的結合體。

具體來說，BaaS（Backend as a Service）可以被解釋為“后端即服務”。

一般是API調用后端或別人已經實現好的程序邏輯，通常用來管理數據。

例如，亞馬遜RDS可以替代自己部署的MySQL，當然其中還有各種其它數據庫、中間件的作用。

FaaS（Functions as a Service）則是函數即服務，作為無服務器計算的一種形式，當前使用最廣泛的當屬AWS的Lambada。

經過長期實踐我們認為，Serverless架構可以提供一種更加“代碼碎片化”的軟件架構范式，而所謂的“函數”（Function），則是提供相比微服務更加細小的程序單元。

進一步來說，究竟該如何理解“函數即服務”的概念？

大致上是開發者先將函數定義封裝在容器中，通過調用函數來實現調用后端存儲等服務。

本質上，FaaS是一種事件驅動的由消息觸發的服務。

與傳統的服務器端軟件的不同，經應用程序部署到擁有操作系統的虛擬機或者容器中，一般需要長時間駐留在操作系統中運行。

而FaaS則可以直接將程序部署上到平臺上，當有事件到來時觸發執行，執行完了就可以消滅。

更重要的一點，FaaS產品不需要對特定框架或庫進行編碼。

還是以AWS Lambda函數為例，函數可以在Javascript、Python、Go等，也就是任何JVM語言（Java，Clojure，Scala等）或.NET語言中實現；但與此同時，Lambda函數還可執行與其部署工件捆綁在一起的另一個進程。

在FaaS環境中，用戶將函數功能代碼上傳到FaaS提供商，其中對的水平擴展是完全自動彈性的。

而“函數”還可以代表客戶所要執行的每個操作，即每個函數完成一個相對簡單的業務邏輯，一個完整的應用由若干個函數組成，主要包括創建、讀取、更新以及刪除等。

目前，函數即服務（Function as a Service，FaaS）是當下Serverless實現的技術基礎。

因為FaaS和Serverless之間關系密切，所以FaaS的特點也可以被認為是Serverless平臺的特點，但如果單純認為Serverless就是FaaS，就比較狹義了。

BaaS 時代僅僅以 API 的方式提供應用依賴的后端服務；而在 FaaS 時期，用戶與開發者不再關注底層，這么說Serverless繁榮也是合理有據的事兒。

使用Serverless，也是一把雙刃劍

據實際觀察，一直以來企業使用 Serverless 通常會涉及幾方面因素，其中“減少運營成本”被認為是最直觀有效的原因之一。

的確，應用Serverless后，企業就無需再為潛在的流量高峰買進大部分時間都可能空閑的服務器機架，而是根據流量進行自動伸縮，采用按請求量來付費的靈活方式。

此外“自動按需擴展”可以發揮到極致：隨時擴展到當前的使用量，消除了意外或者季節性流量高峰的困擾。

更重要的是，Serverless 不需要關心內存泄露，還具備將云數據庫、云消息隊列等服務囊括在內的完善配套設施，極大減少工作量。

哪怕企業中大部分的開發人員都出身軟件，對修復保護以及管理并不擅長，一樣可以做到專注軟件開發，Serverless絕對沒問題。

基于此，一直以來國內外都有很多企業致力于提供基于Serverless 框架的能力服務，接受程度更是水漲船高，簡單盤點下，尤其是幾家大型的公有云廠商。

例如里程碑式的AWS Lambda。

作為AWS針對Serverless架構推出的FaaS云服務，AWS Lambda自2014年上線以后就受到廣泛關注，除了滿足大家對Serverless的期望之外，更重要的是AWS平臺的成功。

AWS Lambda的優勢可以簡單總結為：

• 成熟度高：第一個在主流公有云平臺上的Serverless FaaS平臺，已經有數年的發展和沉淀
• 用戶基數大：AWS Lambda有較大的用戶基數，參考案例很多
• 活躍的社區：目前開源社區有很多圍繞AWS Lambda展開的開源項目
• AWS的整合：AWS Lambda天然和AWS平臺上的服務有良好集成

緊隨其后，Microsoft Azure也在2016年推出了事件驅動的函數式云計算服務Azure Functions。

其支持用戶以多種語言進行函數開發，包括Java、Node.js、PHP、C#、F#、Bash及Microsoft Windows的PowerShell腳本等。

此外，Azure Functions除了提供公有云的版本之外，還提供私有化（On-premises）部署的版本Azure Functions Runtime。

產品功能也是可圈可點：

• 完整性：Azure Functions是一個功能比較完備的Serverless FaaS平臺
• 整合：Azure Functions天然與Azure云平臺上各類服務有良好的集成
• 平臺：對于使用微軟體系產品和工具構建IT能力的企業而言，Azure Functions是Serverless轉型的首選平臺
• 私有化：提供帶有商業支持的私有化部署版本，可滿足不同層面的用戶的需求

同樣是在2016年，Google Cloud Platform推出了Google Cloud Functions平臺，也同時加入Serverless領域的競爭序列。

同為FaaS平臺，Google Cloud Functions與AWS Lambda和Microsoft Azure在功能上最大的區別有啥？

細數以后，可能在于Google Cloud Functions目前僅支持JavaScript作為函數開發語言，運行環境為Node.js。

2018年7月，Google又順勢公布了開源項目Knative，定位為Kubernetes的Serverless插件，推出后得到了Pivotal、IBM以及Red Hat的大力支持。

國外爭先恐后，國內也是蜂擁而至。阿里云作為國內第一批推出Serverless平臺的公有云廠商，其FaaS平臺產品被稱為阿里云函數計算。

如果從事件觸發、支持語言以及用戶體驗等方面考量，該產品也有很多數據值得關注：

• 事件觸發：阿里云函數計算可以被阿里云上的服務事件觸發，例如阿里云對象存儲（OSS）
• 支持語言：阿里云函數計算目前支持的開發語言為Node.js，并計劃后續將支持Java及Python
• 整個函數代碼的部署包大小不能超過50MB，部署包解壓后的代碼不能超過250MB
• 用戶體驗：阿里云函數計算提供了基于Web的控制臺和SDK；用戶可以通過Web控制臺管理函數應用，也可以通過交互式的命令行來操作
• 服務規格：一個服務下最多包含50個函數和10個觸發器。在運行時，函數最長的運行時間為300s，即5min，一個函數的最大并發數為100

同為國內云計算競爭的翹楚，無服務器云函數（Serverless Cloud Function，SCF）是騰訊云推出的函數式計算平臺，根據官方的資料，其發布時間是2017年4月26日。

總結下騰訊云Serverless平臺的特點：

• 函數運行時：騰訊云SCF目前支持Python、Java及Node.js作為函數的開發語言
• 用戶可以以壓縮包的形式從本地上傳代碼，也可以引用騰訊云對象存儲中的代碼文件
• 事件觸發：目前騰訊云SCF支持的事件觸發源有騰訊云對象存儲COS、定時器、騰訊云消息服務CMQ，以及用戶手動通過API及控制臺觸發
• 服務規格：每個函數將在一個基于CentOS Linux的環境中被執行。函數執行的內存范圍為128MB至1536MB，單個區域支持的最大函數定義數量為20個，函數執行的最大時長為300秒，最大的并發數為5

以上我們探討的基本是大型公有云服務商針對Serverless的技術實踐。

其實與公有云相比，在私有環境中構建Serverless平臺，在技術上并沒有什么太多障礙，自然也有不少領先的技術嘗試，對于此我們會專門成文詳細探討。

可以發現，哪怕是擁有世界范圍影響力的公有云服務商針對Serverless的技術探究似乎也出現了缺乏統一認知以及相應標準，無法適應所有的云平臺的情況，例如支持的開發語言不同，事件觸發的機制有差異等。

畢竟Serverless從來都不是一款產品，也不是一個工具，而是一整套能力的合集。

甚至在實踐中還會出現業務輕量化困難、難以在秒級甚至毫秒級別擴容出業務實例；基礎設施響應能力不足導致服務發現和日志監控系統等問題。

進而帶來大量其他web服務器托管提供商可能會倒閉，很多SaaS平臺受到沖擊以及運維和實施人員的生存空間進一步縮小等行業現象。

但不容規避的一點，Serverless 架構的興起使“去服務器化”真正造福了開發者，讓基礎設施管理出現了新契機。

隨著技術上對去中心化以及輕量虛擬化的需求越發強烈，這種“全云化”的模式似乎預示著真正的云時代正在到來，不是嗎？

附：文章參考多家平臺內容并撰寫，主要資源列表如下：

Serverless國內發展的縱向觀察

https://mp.weixin.qq.com/s/1jhLRNaUag-Gp-kbYvzzGA

聊聊火熱的Serverless

https://mp.weixin.qq.com/s/VctPCJCmCCEf2OorEZPX9g

喧嘩的背后：Serverless 的概念及挑戰

https://mp.weixin.qq.com/s/vxFRetml4Kx8WkyoSTD1tQ

Serverless當打之年

https://mp.weixin.qq.com/s/t2f9WtSThbRofAcHVpN-HQ

萬字長文之 Serverless 實戰詳細指南

https://mp.weixin.qq.com/s/yL4VbZuPlm6WMPZMrMEUKg

漫談Serverless、微服務、分布式和單體四種主流軟件架構

https://mp.weixin.qq.com/s/iuP87IUNJOWQe88dLcpKCw

架構 | 暢想 Serverless 2019

https://mp.weixin.qq.com/s/MAGrSEjsxi85TdMimJnxsQ

Serverless無服務器架構是微服務架構的表現形式

https://mp.weixin.qq.com/s/1Gjxq5QskaObipIBbRaAlw

深入淺出Serverless：2 Serverless與相關技術

https://www.jianshu.com/p/af80f1819a90

深入淺出Serverless：3 Serverless的實現

https://www.jianshu.com/p/0a6c4963c8ba