后端小程序的未來(lái)——Serverless

　　自從2014年AWS推出Lambda服務(wù)后，Serverless一詞越來(lái)越熱，已經(jīng)成為一種新型的軟件設(shè)計(jì)架構(gòu)，即Serverless Architecture。作為一種原生于公共云的架構(gòu)，Serverless有什么優(yōu)缺點(diǎn)?是否能應(yīng)用于傳統(tǒng)企業(yè)程序?是否適合私有云場(chǎng)景?是否像很多文章宣稱(chēng)的一樣，會(huì)成為未來(lái)改變?cè)朴?jì)算的中堅(jiān)力量?作為一名云計(jì)算行業(yè)的老兵，作者想在此文中分享一些自己的觀點(diǎn)。

　　一、什么是Serverless

　　Serverless并不神秘，用一個(gè)簡(jiǎn)單的例子就可講明。我們?cè)O(shè)計(jì)了一個(gè)AI應(yīng)用，可以識(shí)別出圖片中人物的人種，我們把它作為一種SaaS服務(wù)架設(shè)在公共云上提供給客戶(hù)使用，其典型的后端架構(gòu)設(shè)計(jì)如下：

　　在該架構(gòu)中，我們購(gòu)買(mǎi)的云主機(jī)上運(yùn)行了Tomcat Web Server，用于承載Java編寫(xiě)的AI應(yīng)用。用戶(hù)通過(guò)API上傳圖片。受限于云主機(jī)的本地存儲(chǔ)空間，為了滿(mǎn)足大量客戶(hù)同時(shí)上傳圖片，AI應(yīng)用實(shí)現(xiàn)了一個(gè)存儲(chǔ)網(wǎng)關(guān)將圖片導(dǎo)入公共云的對(duì)象存儲(chǔ)。圖片導(dǎo)入完成后，AI應(yīng)用從對(duì)象存儲(chǔ)讀入圖片進(jìn)行識(shí)別，并將結(jié)果存入公共云的數(shù)據(jù)庫(kù)中(例如RDS） ，用戶(hù)使用API查詢(xún)結(jié)果。

　　AI應(yīng)用上線(xiàn)一段時(shí)間后受到了用戶(hù)的歡迎，越來(lái)越多的公司開(kāi)始使用該服務(wù)。根據(jù)統(tǒng)計(jì)數(shù)據(jù)，大多數(shù)公司在上午9點(diǎn)~11點(diǎn)、下午2點(diǎn)~5點(diǎn)集中上傳圖片，為了滿(mǎn)足該時(shí)間段的突發(fā)訪(fǎng)問(wèn)量，我們?cè)O(shè)置了公共云的Auto-Scaling策略，在訪(fǎng)問(wèn)增加時(shí)動(dòng)態(tài)創(chuàng)建更多的云主機(jī)來(lái)響應(yīng)客戶(hù)。AI應(yīng)用的架構(gòu)演化成：

　　(一） 在這個(gè)架構(gòu)中，我們需要做如下事情：

　　1. 管理云主機(jī)。我們要關(guān)心CPU數(shù)量、內(nèi)存大小、IP地址等等系統(tǒng)級(jí)的配置。同時(shí)還要關(guān)心云主機(jī)的操作系統(tǒng)，為部署AI應(yīng)用擬定策略。操作系統(tǒng)和Tomcat的安全補(bǔ)丁也不能忽視，否則競(jìng)爭(zhēng)對(duì)手可能雇傭黑客來(lái)攻擊我們的系統(tǒng)。

　　2. 配置公共云的Auto-Scaling的策略，應(yīng)對(duì)高峰期突發(fā)訪(fǎng)問(wèn)量。

　　3. 使用公共云的對(duì)象存儲(chǔ)和數(shù)據(jù)庫(kù)。

　　4. 編寫(xiě)AI應(yīng)用。

　　要完成這些工作，我們既要開(kāi)發(fā)AI應(yīng)用，又要營(yíng)運(yùn)支撐業(yè)務(wù)(例如管理云主機(jī)生命周期、管理操作系統(tǒng)） 。這是當(dāng)前架構(gòu)的現(xiàn)實(shí)：為20%的核心業(yè)務(wù)營(yíng)運(yùn)80%的支撐業(yè)務(wù)。

　　(二） 下面用Serverless架構(gòu)改寫(xiě)AI應(yīng)用：

　　使用公共云提供的Serverless框架(例如AWS的Lambda） 改寫(xiě)應(yīng)用后，我們不再需要云主機(jī)和Tomcat了。用戶(hù)也可以直接將圖片上傳到對(duì)象存儲(chǔ)，AI應(yīng)用注冊(cè)了對(duì)象存儲(chǔ)的一組事件，當(dāng)圖片上傳完成后，代碼會(huì)被觸發(fā)運(yùn)行在一個(gè)全新的進(jìn)程內(nèi)，對(duì)圖像識(shí)別并將結(jié)果存入數(shù)據(jù)庫(kù)。圖片識(shí)別完后，AI應(yīng)用退出，運(yùn)行代碼的進(jìn)程也隨之銷(xiāo)毀。當(dāng)有多個(gè)用戶(hù)上傳圖片時(shí)，其架構(gòu)變?yōu)椋?/p>

　　多個(gè)運(yùn)行AI應(yīng)用代碼的進(jìn)程被啟動(dòng)，并發(fā)處理用戶(hù)上傳的圖片。

　　在Serverless架構(gòu)的AI應(yīng)用中，我們只需要做兩件事情：

　　1. 使用公共云的對(duì)象存儲(chǔ)和數(shù)據(jù)庫(kù)。

　　2. 用公共云的Serverless框架編寫(xiě)AI應(yīng)用。

　　與之前的架構(gòu)相比，我們不再營(yíng)運(yùn)云主機(jī)、操作系統(tǒng)、Tomcat，同時(shí)也不需要配置Auto-Scaling Group，公共云的Serverless框架會(huì)在每個(gè)圖片上傳完成后啟動(dòng)一個(gè)進(jìn)程運(yùn)行AI應(yīng)用，自動(dòng)實(shí)現(xiàn)水平擴(kuò)展。我們終于只需要關(guān)心核心業(yè)務(wù)了，用Serverless框架支持的語(yǔ)言(例如AWS Lambda就支持Javascript, Python和JVM系語(yǔ)言） 編寫(xiě)AI應(yīng)用，一切非核心業(yè)務(wù)都外包給了公共云營(yíng)運(yùn)商。

　　我們的Serverless AI應(yīng)用用到了兩種技術(shù)。首先使用了公共云提供的對(duì)象存儲(chǔ)和數(shù)據(jù)庫(kù)服務(wù)，統(tǒng)稱(chēng)為BaaS(Backend as a Service，后端即服務(wù)） 。其次用了Lambda框架，稱(chēng)為FaaS(Functions as a Service，函數(shù)即服務(wù)） 。

　　使用BaaS和FaaS是Serverless應(yīng)用的基本特征，符合這兩個(gè)基本特征的應(yīng)用可稱(chēng)為Serverless應(yīng)用。

　　三、是BaaS，不是PaaS

　　AI應(yīng)用用到了對(duì)象存儲(chǔ)和數(shù)據(jù)庫(kù)，將來(lái)或許還會(huì)用到消息隊(duì)列。直觀感覺(jué)是在使用PaaS，為什么還要造一個(gè)新詞BaaS?技術(shù)圈有太多令人混淆的術(shù)語(yǔ)了。

　　BaaS并非PaaS，它們的區(qū)別在于：PaaS需要參與應(yīng)用的生命周期管理，BaaS則僅僅提供應(yīng)用依賴(lài)的第三方服務(wù)。典型的PaaS平臺(tái)需要提供手段讓開(kāi)發(fā)者部署和配置應(yīng)用，例如自動(dòng)將應(yīng)用部署到Tomcat容器中，并管理應(yīng)用的生命周期。BaaS不包含這些內(nèi)容，BaaS只以API的方式提供應(yīng)用依賴(lài)的后端服務(wù)，例如數(shù)據(jù)庫(kù)和對(duì)象存儲(chǔ)。BaaS可以是公共云服務(wù)商提供的，也可以是第三方廠(chǎng)商提供的，例如Facebook收購(gòu)的Parse就是著名的MBaaS提供商(Mobile Backend as a Service） 。從功能上講，BaaS可以看作PaaS的一個(gè)子集，即提供第三方依賴(lài)組件的部分。

　　四、FaaS是Serverless的核心

　　AI應(yīng)用最初是一個(gè)典型Java程序，它可能使用Spring這樣的技術(shù)，因?yàn)槲覀冃枰粋€(gè)框架確保程序的各個(gè)組件能夠被正確加載，需要MVC來(lái)保證REST API被正確的Controller處理。AI應(yīng)用部署在Tomcat容器中，運(yùn)行在云主機(jī)上，7 x 24小時(shí)運(yùn)行，我們提供不間斷的服務(wù)。在夜里12點(diǎn)到早晨8點(diǎn)，幾乎沒(méi)有用戶(hù)使用，但我們還得讓它待在那里，防止深夜偶爾使用的用戶(hù)得到一個(gè)503錯(cuò)誤而誤會(huì)AI服務(wù)不穩(wěn)定。我們?yōu)橘?gòu)買(mǎi)的云主機(jī)付錢(qián)，盡管一半的時(shí)間它的CPU使用率幾乎為0，但沒(méi)有公共云是按CPU使用率計(jì)費(fèi)的，不工作的時(shí)間也得付錢(qián)。我們必須關(guān)心Auto-Scaling Group的配置，如何準(zhǔn)確的配置Auto-Scaling策略是一個(gè)技術(shù)活，需要長(zhǎng)期的經(jīng)驗(yàn)積累，在早期我們不得不多部署一些空閑的云主機(jī)以保證服務(wù)不會(huì)因Auto-Scaling的配置不當(dāng)而擁塞。

　　用Serverless架構(gòu)改寫(xiě)了AI應(yīng)用后，這些痛苦就通通消失了。Spring框架和Tomcat去掉了，用Lambda的Java SDK，只需要實(shí)現(xiàn)一個(gè)Function Handler處理圖片上傳完成這個(gè)事件，這跟寫(xiě)一個(gè)Callback一樣簡(jiǎn)單。在Function Handler中調(diào)用圖片識(shí)別的相關(guān)邏輯，然后調(diào)用數(shù)據(jù)庫(kù)的REST API存儲(chǔ)結(jié)果。也不用構(gòu)建MVC，不用配置Tomcat的XML文件，我們將存儲(chǔ)網(wǎng)關(guān)這個(gè)功能完全去除掉了，因?yàn)橛脩?hù)可以直接上傳圖片到對(duì)象存儲(chǔ)。

　　AI應(yīng)用不用7 x 24小時(shí)運(yùn)行了，沒(méi)有用戶(hù)上傳圖片時(shí)它只是一份編譯好的代碼。當(dāng)用戶(hù)圖片上傳完成時(shí)，F(xiàn)aaS會(huì)為AI應(yīng)用啟動(dòng)一個(gè)新的進(jìn)程執(zhí)行代碼。該進(jìn)程在代碼執(zhí)行完成后自動(dòng)銷(xiāo)毀。我們只需為代碼執(zhí)行的這幾十秒鐘付錢(qián)，節(jié)省了很多開(kāi)支。

　　最后我們無(wú)需操心Auto-Scaling的問(wèn)題，F(xiàn)aaS會(huì)在需要的時(shí)候自動(dòng)擴(kuò)展。

　　這些就是FaaS的核心，從上面的例子里面可以歸納出它的特點(diǎn)：

　　1. FaaS運(yùn)行的是后端代碼而不是整個(gè)后端程序。例如AI應(yīng)用僅僅包含處理圖片上傳完成這個(gè)事件的邏輯，并不是一個(gè)完整的后端程序，而是一段后端代碼。

　　2. 代碼通過(guò)事件觸發(fā)。由于不再有一個(gè)長(zhǎng)期運(yùn)行的進(jìn)程等待或輪詢(xún)用戶(hù)請(qǐng)求，代碼只能通過(guò)特殊的事件觸發(fā)。這些事件由FaaS框架定義，例如上傳文件到對(duì)象存儲(chǔ)、消息隊(duì)列收到一條新的消息、API Gateway收到一個(gè)新的API請(qǐng)求等。

　　3. 代碼的生命周期很短。例如我們的AI應(yīng)用，從收到事件后Function Handler被調(diào)用開(kāi)始，到調(diào)用返回結(jié)束，不會(huì)有常駐內(nèi)存的進(jìn)程運(yùn)行。此外公共云提供商還會(huì)限制代碼執(zhí)行的時(shí)間，超出時(shí)間后執(zhí)行代碼的進(jìn)程會(huì)被強(qiáng)行銷(xiāo)毀。例如AWS的Lambda可執(zhí)行的最長(zhǎng)時(shí)間為5分鐘。

　　4. 代碼必須做到徹底無(wú)狀態(tài)，兩次調(diào)用間不能共享內(nèi)存狀態(tài)。我們的AI應(yīng)用最早使用了一個(gè)全局變量統(tǒng)計(jì)處理的圖片數(shù)，每處理完一張圖片該計(jì)數(shù)器就加一。使用FaaS后我們不能再用任何全局變量或內(nèi)存數(shù)據(jù)結(jié)構(gòu)(例如Hashmap） 在調(diào)用間共享數(shù)據(jù)，因?yàn)榇a運(yùn)行在獨(dú)立的進(jìn)程中，無(wú)法訪(fǎng)問(wèn)對(duì)方的內(nèi)存地址空間。于是我們對(duì)代碼進(jìn)行了改造，將全局計(jì)數(shù)器放到了公共云的Redis服務(wù)中，這為代碼增加了額外的復(fù)雜性。

　　5. 水平擴(kuò)展不再是需要擔(dān)心的問(wèn)題，F(xiàn)aaS會(huì)為每個(gè)事件和請(qǐng)求運(yùn)行一份新的代碼。

　　6. 應(yīng)用的部署方式從上傳、配置整個(gè)程序變成上傳一份打包代碼的文件(例如Jar文件或一個(gè)Zip文件） 。

　　五、Serverless為我們帶來(lái)了什么

　　對(duì)比傳統(tǒng)架構(gòu)，用Serverless架構(gòu)改寫(xiě)的AI應(yīng)用具有顯著的優(yōu)勢(shì)。我們不再運(yùn)維任何云主機(jī)和操作系統(tǒng)，甚至不再運(yùn)維Tomcat這樣的Web容器，只需要專(zhuān)注于代碼本身，所有配置、應(yīng)用生命周期管理的工作都由FaaS框架負(fù)責(zé)。公共云的出現(xiàn)讓我們從物理硬件管理中解放出來(lái)，Serverless架構(gòu)讓我們進(jìn)一步從操作系統(tǒng)管理中解放出來(lái)，第一次真正專(zhuān)注于核心業(yè)務(wù)。

　　業(yè)務(wù)也變得更加敏捷了。我們只需要編寫(xiě)核心業(yè)務(wù)相關(guān)的代碼，例如AI應(yīng)用中圖像識(shí)別的部分。無(wú)需編寫(xiě)任何加載、部署、配置應(yīng)用的代碼，例如不再需要配置systemd在系統(tǒng)啟動(dòng)時(shí)加載應(yīng)用。

　　水平擴(kuò)展也不是問(wèn)題。正如前面反復(fù)提及的，F(xiàn)aaS框架會(huì)為每一個(gè)事件、每一個(gè)API請(qǐng)求都啟動(dòng)一份新的進(jìn)程執(zhí)行代碼。這跟傳統(tǒng)應(yīng)用的線(xiàn)程池方式類(lèi)似，每個(gè)請(qǐng)求都在一個(gè)單獨(dú)的線(xiàn)程中執(zhí)行，區(qū)別在于線(xiàn)程之間共享同一內(nèi)存地址空間，F(xiàn)aaS的進(jìn)程間不共享任何內(nèi)存。與線(xiàn)程池有最大線(xiàn)程數(shù)限制類(lèi)似，F(xiàn)aaS框架通常也限制了最大進(jìn)程數(shù)，例如AWS Lambda在一個(gè)Region默認(rèn)能執(zhí)行的最大并發(fā)調(diào)用是600，也就是說(shuō)我們的AI應(yīng)用最多能在600個(gè)進(jìn)程中同時(shí)執(zhí)行。

　　最后，也是最重要的，Serverless架構(gòu)為我們節(jié)省了大量開(kāi)支。我們只需為AI應(yīng)用運(yùn)行的時(shí)間付錢(qián)，無(wú)需為應(yīng)用等待請(qǐng)求的時(shí)間付錢(qián)。水平擴(kuò)展的粒度從原來(lái)的云主機(jī)細(xì)化到進(jìn)程，節(jié)省了額外的開(kāi)支，不用再購(gòu)買(mǎi)閑置的云主機(jī)來(lái)抵消Auto-Scaling的配置不精確帶來(lái)的影響。業(yè)務(wù)的敏捷性提高也降低了營(yíng)運(yùn)成本，我們不再需要精通操作系統(tǒng)配置和管理的營(yíng)運(yùn)人員，不僅節(jié)省了人力成本，也節(jié)省了應(yīng)用從開(kāi)發(fā)到上線(xiàn)的時(shí)間。

　　六、Serverless不是銀子彈，是后端小程序的未來(lái)

　　Serverless架構(gòu)在某些應(yīng)用場(chǎng)景的優(yōu)勢(shì)如此明顯，有些支持者已經(jīng)開(kāi)始炒作它會(huì)成為顛覆性的云計(jì)算新架構(gòu)了。技術(shù)圈向來(lái)如此，一些人總在孜孜不倦的尋找包治百病的靈藥，和解決一切問(wèn)題的銀子彈。“All design is about tradeoff”，Serverless也不是銀子彈，它有獨(dú)特的優(yōu)勢(shì)，而這些優(yōu)勢(shì)也帶來(lái)了不可避免的局限。

　　為每個(gè)事件/請(qǐng)求啟動(dòng)一個(gè)全新的進(jìn)程運(yùn)行代碼是FaaS的核心，進(jìn)程的啟動(dòng)延時(shí)是Serverless面臨的第一個(gè)問(wèn)題。取決于編寫(xiě)應(yīng)用的語(yǔ)言，啟動(dòng)延時(shí)可以是10毫秒(如簡(jiǎn)單的Python應(yīng)用） ，也可以是1分鐘(復(fù)雜的Java應(yīng)用） 。這樣的延時(shí)對(duì)于realtime的程序是難以接受的。目前Serverless應(yīng)用通常運(yùn)行在公共云的多租戶(hù)環(huán)境中，啟動(dòng)延時(shí)還受系統(tǒng)負(fù)載影響，很難保證應(yīng)用在規(guī)定時(shí)間內(nèi)被運(yùn)行。公共云提供商目前沒(méi)有對(duì)Serverless提供相應(yīng)的SLA保證，筆者寫(xiě)這篇文章的時(shí)候，AWS Lambda還沒(méi)有相關(guān)的SLA條款。

　　Serverless無(wú)法用于高并發(fā)應(yīng)用，為每個(gè)請(qǐng)求啟動(dòng)一個(gè)進(jìn)程開(kāi)銷(xiāo)太高。例如雙十一支付寶高峰期每秒處理的交易數(shù)為8.59萬(wàn)筆，如果使用Serverless架構(gòu)，意味著我們的系統(tǒng)內(nèi)每秒有8.59萬(wàn)個(gè)進(jìn)程被創(chuàng)建又被銷(xiāo)毀，這是難以負(fù)擔(dān)的開(kāi)銷(xiāo)。

　　Serverless應(yīng)用無(wú)法常駐內(nèi)存，運(yùn)行的時(shí)間是受限的。如果你的應(yīng)用無(wú)法在數(shù)分鐘內(nèi)完成的工作，那Serverless不是你的選擇，例如AWS Lambda給予進(jìn)程的最長(zhǎng)運(yùn)行時(shí)間是5分鐘，超時(shí)后進(jìn)程將被強(qiáng)制終止。這對(duì)程序設(shè)計(jì)提出了挑戰(zhàn)，例如我們的AI應(yīng)用必須優(yōu)化到在5分鐘內(nèi)完成復(fù)雜圖像的識(shí)別。我們也不能編寫(xiě)執(zhí)行長(zhǎng)時(shí)間IO操作的應(yīng)用，例如對(duì)對(duì)象存儲(chǔ)中1T的數(shù)據(jù)進(jìn)行復(fù)雜編碼。

　　Serverless調(diào)用之間不能共享狀態(tài)讓編寫(xiě)復(fù)雜程序變得極度困難。無(wú)狀態(tài)是互連網(wǎng)應(yīng)用追求的目標(biāo)，例如滿(mǎn)足“12要素”的應(yīng)用。但Serverless將無(wú)狀態(tài)進(jìn)行的更加徹底，在不同的調(diào)用之間無(wú)法共享內(nèi)存狀態(tài)，例如使用hashmap。我們的AI應(yīng)用中統(tǒng)計(jì)已處理圖片總數(shù)的全局計(jì)數(shù)器在傳統(tǒng)架構(gòu)中只是一個(gè)全局變量，但在Serverless架構(gòu)中它變成存儲(chǔ)在內(nèi)存數(shù)據(jù)庫(kù)(Redis） 中的一條記錄，更新成本、保證原子性等因素讓我們的編碼變得數(shù)倍復(fù)雜。對(duì)于大多云原生的互聯(lián)網(wǎng)應(yīng)用來(lái)說(shuō)，這種徹底的無(wú)狀態(tài)架構(gòu)是一個(gè)巨大的挑戰(zhàn)，而對(duì)于動(dòng)輒有幾十萬(wàn)、上百萬(wàn)行代碼的、充滿(mǎn)了狀態(tài)的企業(yè)應(yīng)用來(lái)說(shuō)，Serverless的無(wú)狀態(tài)改造幾乎是一個(gè)無(wú)法完成的任務(wù)。

　　熟練的微服務(wù)的架構(gòu)師，對(duì)將業(yè)務(wù)拆分成一個(gè)個(gè)單獨(dú)的服務(wù)非常熟悉，也有不少的經(jīng)典書(shū)籍(例如《Building Microservices: Designing Fine-Grained Systems》） 指導(dǎo)我們?nèi)绾巫?。但即使是他們，在面?duì)Serverless架構(gòu)時(shí)也會(huì)感到頭痛，如何將業(yè)務(wù)拆分成成百上千個(gè)運(yùn)行在獨(dú)立進(jìn)程、運(yùn)行時(shí)間受限的函數(shù)是巨大的挑戰(zhàn)。而是否需要如此細(xì)粒度的拆分是需要回答的第一個(gè)問(wèn)題。有些問(wèn)題或許變成無(wú)解難題又或成本極高，例如分布式數(shù)據(jù)庫(kù)事務(wù)。

　　上面都是Serverless架構(gòu)的一些固有局限，它們?cè)从赟erverless架構(gòu)的特點(diǎn)，很難隨著時(shí)間的推移、技術(shù)的完善而解決。除此之外，作為一個(gè)新的技術(shù)，Serverless還面臨著集成測(cè)試?yán)щy、Vendor Lock-in、調(diào)試監(jiān)控困難、版本控制等諸多不足，每一項(xiàng)都會(huì)成為采用Serverless架構(gòu)的阻礙。

　　由于這些局限性，Serverless架構(gòu)不會(huì)成為復(fù)雜應(yīng)用的架構(gòu)首選，相反，它應(yīng)該是后端小程序的未來(lái)。

　　云端的應(yīng)用有大量的小程序場(chǎng)景，例如識(shí)別一張圖片、對(duì)一段音頻/視頻進(jìn)行編解碼、對(duì)IOT設(shè)備的請(qǐng)求返回一小段數(shù)據(jù)、將客戶(hù)提交的工單通過(guò)郵件通知客服人員等等。這些基于事件觸發(fā)的小程序在傳統(tǒng)架構(gòu)中實(shí)現(xiàn)起來(lái)是相對(duì)復(fù)雜的，你往往需要為20%的核心業(yè)務(wù)運(yùn)營(yíng)80%的支撐業(yè)務(wù)。Serverless完美的解決了這些問(wèn)題，它可以成為復(fù)雜應(yīng)用的一種補(bǔ)充架構(gòu)。我們可以將無(wú)狀態(tài)的、事件觸發(fā)的業(yè)務(wù)拆分成Serverless應(yīng)用，讓整個(gè)架構(gòu)變得更加的簡(jiǎn)潔和高效。

　　Serverless也在不斷演變，例如AWS最近引入的Step Functions就嘗試解決調(diào)用間共享狀態(tài)的問(wèn)題，其效果有待觀察。

　　七、Serverless不是傳統(tǒng)的PaaS

　　Serverless跟PaaS之間的界線(xiàn)比較模糊，很多人認(rèn)為Serverless是PaaS的一種，筆者也傾向于認(rèn)為Serverless是特殊的PaaS形態(tài)。

　　Serverless由BaaS和FaaS兩部分構(gòu)成，BaaS負(fù)責(zé)提供業(yè)務(wù)的依賴(lài)服務(wù)，F(xiàn)aaS負(fù)責(zé)業(yè)務(wù)的部署和生命周期管理，從這個(gè)意義上來(lái)看，Serverless的角色跟PaaS一樣。與傳統(tǒng)PaaS的區(qū)別在于，傳統(tǒng)PaaS是以程序?yàn)榱６裙芾響?yīng)用的生命周期，而Serverless是以函數(shù)粒度管理應(yīng)用生命周期。傳統(tǒng)PaaS中的應(yīng)用為常駐內(nèi)存的進(jìn)程，而Serverless應(yīng)用運(yùn)行完即銷(xiāo)毀。此外，使用傳統(tǒng)PaaS，用戶(hù)仍需要關(guān)心水平擴(kuò)展，例如如何配置Auto-Scaling Group，但Serverless沒(méi)有這個(gè)問(wèn)題，水平擴(kuò)展是架構(gòu)天然自帶的功能。

　　八、Serverless和微服務(wù)

　　Serverless和微服務(wù)沒(méi)有直接關(guān)系，但兩者有相似之處，例如都需要做業(yè)務(wù)拆分、強(qiáng)調(diào)無(wú)狀態(tài)、具有敏捷特性等。Serverless在很多方面比微服務(wù)粒度更細(xì)，要求也更嚴(yán)格。例如微服務(wù)以服務(wù)為邊界拆分業(yè)務(wù)，Serverless以函數(shù)為邊界拆分業(yè)務(wù);微服務(wù)可以有跨調(diào)用的內(nèi)存狀態(tài)共享，Serverless要求調(diào)用徹底無(wú)狀態(tài)。此外，Serverless依賴(lài)BaaS提供第三方依賴(lài)，而微服務(wù)可以自由選擇第三方依賴(lài)來(lái)源，例如使用本地搭建的傳統(tǒng)中間件棧(如本地MySql和消息總線(xiàn)） 。

　　九、Serverless和容器

　　Serverless和容器是蘋(píng)果和桔子的比較，不在一個(gè)平面上。Serverless是一種軟件設(shè)計(jì)架構(gòu)，容器是軟件架構(gòu)的承載者。雖然沒(méi)有公開(kāi)資料，但我們可以推測(cè)類(lèi)似于AWS Lambda這樣的Serverless框架使用了某種程度的容器技術(shù)，否者難以實(shí)現(xiàn)語(yǔ)言無(wú)關(guān)和毫秒級(jí)的啟動(dòng)。盡管已經(jīng)有一些開(kāi)源項(xiàng)目使用Docker實(shí)現(xiàn)Serverless中的FaaS部分，筆者不認(rèn)為AWS Lambda這樣的公共Serverless框架直接使用了Docker，一定是一種更為輕量級(jí)、體積更小的容器技術(shù)，我們或許可以將它稱(chēng)為Nano-Container。

　　十、Serverless對(duì)私有云有意義嗎?

　　對(duì)于私有云來(lái)說(shuō)，現(xiàn)在將業(yè)務(wù)遷往Serverless架構(gòu)還為時(shí)過(guò)早。首先Serverless是從公共云中演化出來(lái)的新型架構(gòu)，適用于運(yùn)行在公共云上的小程序。而私有云更多承載的是老而笨重的傳統(tǒng)業(yè)務(wù)，難以用Serverless架構(gòu)改造。其次Serverless依賴(lài)BaaS，在私有云中搭建和運(yùn)維BaaS成本都不低，使用公共BaaS服務(wù)又受限于網(wǎng)絡(luò)帶寬和延時(shí)，容易導(dǎo)致系統(tǒng)不穩(wěn)定。

　　隨著企業(yè)應(yīng)用的進(jìn)一步云化、開(kāi)源Serverless框架的成熟，私有云的Devops場(chǎng)景也可以采用Serverless作CI/CD，例如目前Jenkins承擔(dān)的大部分工作都可以用Serverless替代，如用FaaS框架對(duì)應(yīng)Jenkins本身，上傳的代碼對(duì)應(yīng)Jenkins Job中的Bash腳本，將原來(lái)的Jenkins API觸發(fā)Job改為觸發(fā)FaaS中的代碼。

　　十一、Serverless總結(jié)

　　Serverless作為一種全新的架構(gòu)，是云計(jì)算發(fā)展演化的必然結(jié)果。追求更細(xì)粒度的計(jì)費(fèi)單元，更加專(zhuān)注于核心業(yè)務(wù)、將支撐業(yè)務(wù)外包給基礎(chǔ)設(shè)施提供商是云計(jì)算的趨勢(shì)。Serverless架構(gòu)的特點(diǎn)，讓編寫(xiě)事件觸發(fā)的后端小程序變得更加容易。同時(shí)它也有自身內(nèi)在的局限性，并不適合復(fù)雜的應(yīng)用架構(gòu)。從目前的情況看，部分采用Serverless的混合架構(gòu)對(duì)公共云應(yīng)用是個(gè)不錯(cuò)的選擇，私有應(yīng)用采用Serverless還為時(shí)過(guò)早。云計(jì)算技術(shù)正在飛速發(fā)展，未來(lái)還有無(wú)限可能。