冠望 發自 凹非寺｜量子位 報道 | 公眾號 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 架構的興起使「去伺服器化」真正造福了開發者，讓基礎設施管理出現了新契機。
隨著技術上對去中心化以及輕量虛擬化的需求越發強烈，這種「全雲化」的模式似乎預示著真正的雲時代正在到來，不是嗎？
