要說目前軟件架構(gòu)中熱度十二分的話題，當(dāng)屬Serverless。

通常我們會將其翻譯為“無服務(wù)器架構(gòu)”。

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

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

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

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

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

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

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

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

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

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

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

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

恐怕還是要從軟件應(yīng)用架構(gòu)演進的角度說起。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

提及 Serverless，很多人的第一反應(yīng)都是 FaaS+BaaS。

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

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

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

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

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

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

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

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

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

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

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

而FaaS則可以直接將程序部署上到平臺上，當(dāng)有事件到來時觸發(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è)務(wù)邏輯，一個完整的應(yīng)用由若干個函數(shù)組成，主要包括創(chuàng)建、讀取、更新以及刪除等。

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

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

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

使用Serverless，也是一把雙刃劍

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

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

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

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

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

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

例如里程碑式的AWS Lambda。

作為AWS針對Serverless架構(gòu)推出的FaaS云服務(wù)，AWS Lambda自2014年上線以后就受到廣泛關(guān)注，除了滿足大家對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平臺上的服務(wù)有良好集成

緊隨其后，Microsoft Azure也在2016年推出了事件驅(qū)動的函數(shù)式云計算服務(wù)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云平臺上各類服務(wù)有良好的集成

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

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

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

同為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ù)值得關(guān)注：

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

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

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

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

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

同為國內(nèi)云計算競爭的翹楚，無服務(wù)器云函數(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、定時器、騰訊云消息服務(wù)CMQ，以及用戶手動通過API及控制臺觸發(fā)

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

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

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

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

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

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

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

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

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