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

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

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

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

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

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

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

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

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

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

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

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

從架構變遷聚焦Serverless內(nèi)涵

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

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

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

依靠一臺服務器外加一個數(shù)據(jù)庫，就能讓服務可用性達到峰值狀態(tài)。

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

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

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

例如那些年的緩存服務 Redis、狀態(tài)協(xié)調(diào)服務ZooKeeper、消息服務 Kafka等。

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

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

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

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

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

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

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

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

Serverless架構類同F(xiàn)aaS，又做何解？

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

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

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

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

一般是API調(diào)用后端或別人已經(jīng)實現(xiàn)好的程序邏輯，通常用來管理數(shù)據(jù)。

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

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

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

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

大致上是開發(fā)者先將函數(shù)定義封裝在容器中，通過調(diào)用函數(shù)來實現(xiàn)調(diào)用后端存儲等服務。

本質(zhì)上，F(xiàn)aaS是一種事件驅(qū)動的由消息觸發(fā)的服務。

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

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

更重要的一點，F(xiàn)aaS產(chǎn)品不需要對特定框架或庫進行編碼。

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

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

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

目前，函數(shù)即服務（Function as a Service，F(xiàn)aaS）是當下Serverless實現(xiàn)的技術基礎。

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

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

使用Serverless，也是一把雙刃劍

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

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

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

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

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

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

例如里程碑式的AWS Lambda。

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

AWS Lambda的優(yōu)勢可以簡單總結(jié)為：

成熟度高：第一個在主流公有云平臺上的Serverless FaaS平臺，已經(jīng)有數(shù)年的發(fā)展和沉淀

用戶基數(shù)大：AWS Lambda有較大的用戶基數(shù)，參考案例很多

活躍的社區(qū)：目前開源社區(qū)有很多圍繞AWS Lambda展開的開源項目

AWS的整合：AWS Lambda天然和AWS平臺上的服務有良好集成

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

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

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

產(chǎn)品功能也是可圈可點：

完整性：Azure Functions是一個功能比較完備的Serverless FaaS平臺

整合：Azure Functions天然與Azure云平臺上各類服務有良好的集成

平臺：對于使用微軟體系產(chǎn)品和工具構建IT能力的企業(yè)而言，Azure Functions是Serverless轉(zhuǎn)型的首選平臺

私有化：提供帶有商業(yè)支持的私有化部署版本，可滿足不同層面的用戶的需求

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

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

細數(shù)以后，可能在于Google Cloud Functions目前僅支持JavaScript作為函數(shù)開發(fā)語言，運行環(huán)境為Node.js。

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

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

如果從事件觸發(fā)、支持語言以及用戶體驗等方面考量，該產(chǎn)品也有很多數(shù)據(jù)值得關注：

事件觸發(fā)：阿里云函數(shù)計算可以被阿里云上的服務事件觸發(fā)，例如阿里云對象存儲（OSS）

支持語言：阿里云函數(shù)計算目前支持的開發(fā)語言為Node.js，并計劃后續(xù)將支持Java及Python

整個函數(shù)代碼的部署包大小不能超過50MB，部署包解壓后的代碼不能超過250MB

用戶體驗：阿里云函數(shù)計算提供了基于Web的控制臺和SDK；用戶可以通過Web控制臺管理函數(shù)應用，也可以通過交互式的命令行來操作

服務規(guī)格：一個服務下最多包含50個函數(shù)和10個觸發(fā)器。在運行時，函數(shù)最長的運行時間為300s，即5min，一個函數(shù)的最大并發(fā)數(shù)為100

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

總結(jié)下騰訊云Serverless平臺的特點：

函數(shù)運行時：騰訊云SCF目前支持Python、Java及Node.js作為函數(shù)的開發(fā)語言

用戶可以以壓縮包的形式從本地上傳代碼，也可以引用騰訊云對象存儲中的代碼文件

事件觸發(fā)：目前騰訊云SCF支持的事件觸發(fā)源有騰訊云對象存儲COS、定時器、騰訊云消息服務CMQ，以及用戶手動通過API及控制臺觸發(fā)

服務規(guī)格：每個函數(shù)將在一個基于CentOS Linux的環(huán)境中被執(zhí)行。函數(shù)執(zhí)行的內(nèi)存范圍為128MB至1536MB，單個區(qū)域支持的最大函數(shù)定義數(shù)量為20個，函數(shù)執(zhí)行的最大時長為300秒，最大的并發(fā)數(shù)為5

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

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

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

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

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

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

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

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