Serverless，后端小程序的未来
自從2014年AWS推出Lambda服務(wù)后，Serverless一詞越來越熱，已經(jīng)成為一種新型的軟件設(shè)計架構(gòu)，即Serverless Architecture。作為一種原生于公共云的架構(gòu)，Serverless有什么優(yōu)缺點？是否能應(yīng)用于傳統(tǒng)企業(yè)程序？是否適合私有云場景？是否像很多文章宣稱的一樣，會成為未來改變云計算的中堅力量？作為一名云計算行業(yè)的老兵，作者想在此文中分享一些自己的觀點。
什么是Serverless
Serverless并不神秘，用一個簡單的例子就可講明。我們設(shè)計了一個AI應(yīng)用，可以識別出圖片中人物的人種，我們把它作為一種SaaS服務(wù)架設(shè)在公共云上提供給客戶使用，其典型的后端架構(gòu)設(shè)計如下：
在該架構(gòu)中，我們購買的云主機上運行了Tomcat Web Server，用于承載Java編寫的AI應(yīng)用。用戶通過API上傳圖片。受限于云主機的本地存儲空間，為了滿足大量客戶同時上傳圖片，AI應(yīng)用實現(xiàn)了一個存儲網(wǎng)關(guān)將圖片導(dǎo)入公共云的對象存儲。圖片導(dǎo)入完成后，AI應(yīng)用從對象存儲讀入圖片進行識別，并將結(jié)果存入公共云的數(shù)據(jù)庫中（例如RDS），用戶使用API查詢結(jié)果。
AI應(yīng)用上線一段時間后受到了用戶的歡迎，越來越多的公司開始使用該服務(wù)。根據(jù)統(tǒng)計數(shù)據(jù)，大多數(shù)公司在上午9點~11點、下午2點~5點集中上傳圖片，為了滿足該時間段的突發(fā)訪問量，我們設(shè)置了公共云的Auto-Scaling策略，在訪問增加時動態(tài)創(chuàng)建更多的云主機來響應(yīng)客戶。AI應(yīng)用的架構(gòu)演化成：
在這個架構(gòu)中，我們需要做如下事情：
要完成這些工作，我們既要開發(fā)AI應(yīng)用，又要營運支撐業(yè)務(wù)（例如管理云主機生命周期、管理操作系統(tǒng)）。這是當前架構(gòu)的現(xiàn)實：為20%的核心業(yè)務(wù)營運80%的支撐業(yè)務(wù)。
下面用Serverless架構(gòu)改寫AI應(yīng)用：
使用公共云提供的Serverless框架（例如AWS的Lambda）改寫應(yīng)用后，我們不再需要云主機和Tomcat了。用戶也可以直接將圖片上傳到對象存儲，AI應(yīng)用注冊了對象存儲的一組事件，當圖片上傳完成后，代碼會被觸發(fā)運行在一個全新的進程內(nèi)，對圖像識別并將結(jié)果存入數(shù)據(jù)庫。圖片識別完后，AI應(yīng)用退出，運行代碼的進程也隨之銷毀。當有多個用戶上傳圖片時，其架構(gòu)變?yōu)?#xff1a;?
多個運行AI應(yīng)用代碼的進程被啟動，并發(fā)處理用戶上傳的圖片。
在Serverless架構(gòu)的AI應(yīng)用中，我們只需要做兩件事情：
與之前的架構(gòu)相比，我們不再營運云主機、操作系統(tǒng)、Tomcat，同時也不需要配置Auto-Scaling Group，公共云的Serverless框架會在每個圖片上傳完成后啟動一個進程運行AI應(yīng)用，自動實現(xiàn)水平擴展。我們終于只需要關(guān)心核心業(yè)務(wù)了，用Serverless框架支持的語言（例如AWS Lambda就支持Javascript, Python和JVM系語言）編寫AI應(yīng)用，一切非核心業(yè)務(wù)都外包給了公共云營運商。
我們的Serverless AI應(yīng)用用到了兩種技術(shù)。首先使用了公共云提供的對象存儲和數(shù)據(jù)庫服務(wù)，統(tǒng)稱為BaaS（Backend as a Service，后端即服務(wù)）。其次用了Lambda框架，稱為FaaS(Functions as a Service，函數(shù)即服務(wù))。
使用BaaS和FaaS是Serverless應(yīng)用的基本特征，符合這兩個基本特征的應(yīng)用可稱為Serverless應(yīng)用。
是BaaS，不是PaaS
AI應(yīng)用用到了對象存儲和數(shù)據(jù)庫，將來或許還會用到消息隊列。直觀感覺是在使用PaaS，為什么還要造一個新詞BaaS？技術(shù)圈有太多令人混淆的術(shù)語了。
BaaS并非PaaS，它們的區(qū)別在于：PaaS需要參與應(yīng)用的生命周期管理，BaaS則僅僅提供應(yīng)用依賴的第三方服務(wù)。典型的PaaS平臺需要提供手段讓開發(fā)者部署和配置應(yīng)用，例如自動將應(yīng)用部署到Tomcat容器中，并管理應(yīng)用的生命周期。BaaS不包含這些內(nèi)容，BaaS只以API的方式提供應(yīng)用依賴的后端服務(wù)，例如數(shù)據(jù)庫和對象存儲。BaaS可以是公共云服務(wù)商提供的，也可以是第三方廠商提供的，例如Facebook收購的Parse就是著名的MBaaS提供商（Mobile Backend as a Service）。從功能上講，BaaS可以看作PaaS的一個子集，即提供第三方依賴組件的部分。
FaaS是Serverless的核心
AI應(yīng)用最初是一個典型Java程序，它可能使用Spring這樣的技術(shù)，因為我們需要一個框架確保程序的各個組件能夠被正確加載，需要MVC來保證REST API被正確的Controller處理。AI應(yīng)用部署在Tomcat容器中，運行在云主機上，7 x 24小時運行，我們提供不間斷的服務(wù)。在夜里12點到早晨8點，幾乎沒有用戶使用，但我們還得讓它待在那里，防止深夜偶爾使用的用戶得到一個503錯誤而誤會AI服務(wù)不穩(wěn)定。我們?yōu)橘徺I的云主機付錢，盡管一半的時間它的CPU使用率幾乎為0，但沒有公共云是按CPU使用率計費的，不工作的時間也得付錢。我們必須關(guān)心Auto-Scaling Group的配置，如何準確的配置Auto-Scaling策略是一個技術(shù)活，需要長期的經(jīng)驗積累，在早期我們不得不多部署一些空閑的云主機以保證服務(wù)不會因Auto-Scaling的配置不當而擁塞。
用Serverless架構(gòu)改寫了AI應(yīng)用后，這些痛苦就通通消失了。Spring框架和Tomcat去掉了，用Lambda的Java SDK，只需要實現(xiàn)一個Function Handler處理圖片上傳完成這個事件，這跟寫一個Callback一樣簡單。在Function Handler中調(diào)用圖片識別的相關(guān)邏輯，然后調(diào)用數(shù)據(jù)庫的REST API存儲結(jié)果。也不用構(gòu)建MVC，不用配置Tomcat的XML文件，我們將存儲網(wǎng)關(guān)這個功能完全去除掉了，因為用戶可以直接上傳圖片到對象存儲。
AI應(yīng)用不用7 x 24小時運行了，沒有用戶上傳圖片時它只是一份編譯好的代碼。當用戶圖片上傳完成時，FaaS會為AI應(yīng)用啟動一個新的進程執(zhí)行代碼。該進程在代碼執(zhí)行完成后自動銷毀。我們只需為代碼執(zhí)行的這幾十秒鐘付錢，節(jié)省了很多開支。
最后我們無需操心Auto-Scaling的問題，FaaS會在需要的時候自動擴展。
這些就是FaaS的核心，從上面的例子里面可以歸納出它的特點：
FaaS運行的是后端代碼而不是整個后端程序。例如AI應(yīng)用僅僅包含處理圖片上傳完成這個事件的邏輯，并不是一個完整的后端程序，而是一段后端代碼。
代碼通過事件觸發(fā)。由于不再有一個長期運行的進程等待或輪詢用戶請求，代碼只能通過特殊的事件觸發(fā)。這些事件由FaaS框架定義，例如上傳文件到對象存儲、消息隊列收到一條新的消息、API Gateway收到一個新的API請求等。
代碼的生命周期很短。例如我們的AI應(yīng)用，從收到事件后Function Handler被調(diào)用開始，到調(diào)用返回結(jié)束，不會有常駐內(nèi)存的進程運行。此外公共云提供商還會限制代碼執(zhí)行的時間，超出時間后執(zhí)行代碼的進程會被強行銷毀。例如AWS的Lambda可執(zhí)行的最長時間為5分鐘。
代碼必須做到徹底無狀態(tài)，兩次調(diào)用間不能共享內(nèi)存狀態(tài)。我們的AI應(yīng)用最早使用了一個全局變量統(tǒng)計處理的圖片數(shù)，每處理完一張圖片該計數(shù)器就加一。使用FaaS后我們不能再用任何全局變量或內(nèi)存數(shù)據(jù)結(jié)構(gòu)（例如Hashmap）在調(diào)用間共享數(shù)據(jù)，因為代碼運行在獨立的進程中，無法訪問對方的內(nèi)存地址空間。于是我們對代碼進行了改造，將全局計數(shù)器放到了公共云的Redis服務(wù)中，這為代碼增加了額外的復(fù)雜性。
水平擴展不再是需要擔心的問題，FaaS會為每個事件和請求運行一份新的代碼。
應(yīng)用的部署方式從上傳、配置整個程序變成上傳一份打包代碼的文件（例如Jar文件或一個Zip文件）。
Serverless為我們帶來了什么
對比傳統(tǒng)架構(gòu)，用Serverless架構(gòu)改寫的AI應(yīng)用具有顯著的優(yōu)勢。我們不再運維任何云主機和操作系統(tǒng)，甚至不再運維Tomcat這樣的Web容器，只需要專注于代碼本身，所有配置、應(yīng)用生命周期管理的工作都由FaaS框架負責。公共云的出現(xiàn)讓我們從物理硬件管理中解放出來，Serverless架構(gòu)讓我們進一步從操作系統(tǒng)管理中解放出來，第一次真正專注于核心業(yè)務(wù)。
業(yè)務(wù)也變得更加敏捷了。我們只需要編寫核心業(yè)務(wù)相關(guān)的代碼，例如AI應(yīng)用中圖像識別的部分。無需編寫任何加載、部署、配置應(yīng)用的代碼，例如不再需要配置systemd在系統(tǒng)啟動時加載應(yīng)用。
水平擴展也不是問題。正如前面反復(fù)提及的，FaaS框架會為每一個事件、每一個API請求都啟動一份新的進程執(zhí)行代碼。這跟傳統(tǒng)應(yīng)用的線程池方式類似，每個請求都在一個單獨的線程中執(zhí)行，區(qū)別在于線程之間共享同一內(nèi)存地址空間，FaaS的進程間不共享任何內(nèi)存。與線程池有最大線程數(shù)限制類似，FaaS框架通常也限制了最大進程數(shù)，例如AWS Lambda在一個Region默認能執(zhí)行的最大并發(fā)調(diào)用是600，也就是說我們的AI應(yīng)用最多能在600個進程中同時執(zhí)行。
最后，也是最重要的，Serverless架構(gòu)為我們節(jié)省了大量開支。我們只需為AI應(yīng)用運行的時間付錢，無需為應(yīng)用等待請求的時間付錢。水平擴展的粒度從原來的云主機細化到進程，節(jié)省了額外的開支，不用再購買閑置的云主機來抵消Auto-Scaling的配置不精確帶來的影響。業(yè)務(wù)的敏捷性提高也降低了營運成本，我們不再需要精通操作系統(tǒng)配置和管理的營運人員，不僅節(jié)省了人力成本，也節(jié)省了應(yīng)用從開發(fā)到上線的時間。
Serverless不是銀子彈，是后端小程序的未來
Serverless架構(gòu)在某些應(yīng)用場景的優(yōu)勢如此明顯，有些支持者已經(jīng)開始炒作它會成為顛覆性的云計算新架構(gòu)了。技術(shù)圈向來如此，一些人總在孜孜不倦的尋找包治百病的靈藥，和解決一切問題的銀子彈。“All design is about tradeoff”，Serverless也不是銀子彈，它有獨特的優(yōu)勢，而這些優(yōu)勢也帶來了不可避免的局限。
為每個事件/請求啟動一個全新的進程運行代碼是FaaS的核心，進程的啟動延時是Serverless面臨的第一個問題。取決于編寫應(yīng)用的語言，啟動延時可以是10毫秒（如簡單的Python應(yīng)用），也可以是1分鐘（復(fù)雜的Java應(yīng)用）。這樣的延時對于realtime的程序是難以接受的。目前Serverless應(yīng)用通常運行在公共云的多租戶環(huán)境中，啟動延時還受系統(tǒng)負載影響，很難保證應(yīng)用在規(guī)定時間內(nèi)被運行。公共云提供商目前沒有對Serverless提供相應(yīng)的SLA保證，筆者寫這篇文章的時候，AWS Lambda還沒有相關(guān)的SLA條款。
Serverless無法用于高并發(fā)應(yīng)用，為每個請求啟動一個進程開銷太高。例如雙十一支付寶高峰期每秒處理的交易數(shù)為8.59萬筆，如果使用Serverless架構(gòu)，意味著我們的系統(tǒng)內(nèi)每秒有8.59萬個進程被創(chuàng)建又被銷毀，這是難以負擔的開銷。
Serverless應(yīng)用無法常駐內(nèi)存，運行的時間是受限的。如果你的應(yīng)用無法在數(shù)分鐘內(nèi)完成的工作，那Serverless不是你的選擇，例如AWS Lambda給予進程的最長運行時間是5分鐘，超時后進程將被強制終止。這對程序設(shè)計提出了挑戰(zhàn)，例如我們的AI應(yīng)用必須優(yōu)化到在5分鐘內(nèi)完成復(fù)雜圖像的識別。我們也不能編寫執(zhí)行長時間IO操作的應(yīng)用，例如對對象存儲中1T的數(shù)據(jù)進行復(fù)雜編碼。
Serverless調(diào)用之間不能共享狀態(tài)讓編寫復(fù)雜程序變得極度困難。無狀態(tài)是互連網(wǎng)應(yīng)用追求的目標，例如滿足“12要素”的應(yīng)用。但Serverless將無狀態(tài)進行的更加徹底，在不同的調(diào)用之間無法共享內(nèi)存狀態(tài)，例如使用hashmap。我們的AI應(yīng)用中統(tǒng)計已處理圖片總數(shù)的全局計數(shù)器在傳統(tǒng)架構(gòu)中只是一個全局變量，但在Serverless架構(gòu)中它變成存儲在內(nèi)存數(shù)據(jù)庫（Redis）中的一條記錄，更新成本、保證原子性等因素讓我們的編碼變得數(shù)倍復(fù)雜。對于大多云原生的互聯(lián)網(wǎng)應(yīng)用來說，這種徹底的無狀態(tài)架構(gòu)是一個巨大的挑戰(zhàn)，而對于動輒有幾十萬、上百萬行代碼的、充滿了狀態(tài)的企業(yè)應(yīng)用來說，Serverless的無狀態(tài)改造幾乎是一個無法完成的任務(wù)。
熟練的微服務(wù)的架構(gòu)師，對將業(yè)務(wù)拆分成一個個單獨的服務(wù)非常熟悉，也有不少的經(jīng)典書籍（例如《Building Microservices: Designing Fine-Grained Systems》）指導(dǎo)我們?nèi)绾巫觥５词故撬麄?#xff0c;在面對Serverless架構(gòu)時也會感到頭痛，如何將業(yè)務(wù)拆分成成百上千個運行在獨立進程、運行時間受限的函數(shù)是巨大的挑戰(zhàn)。而是否需要如此細粒度的拆分是需要回答的第一個問題。有些問題或許變成無解難題又或成本極高，例如分布式數(shù)據(jù)庫事務(wù)。
上面都是Serverless架構(gòu)的一些固有局限，它們源于Serverless架構(gòu)的特點，很難隨著時間的推移、技術(shù)的完善而解決。除此之外，作為一個新的技術(shù)，Serverless還面臨著集成測試困難、Vendor Lock-in、調(diào)試監(jiān)控困難、版本控制等諸多不足，每一項都會成為采用Serverless架構(gòu)的阻礙。
由于這些局限性，Serverless架構(gòu)不會成為復(fù)雜應(yīng)用的架構(gòu)首選，相反，它應(yīng)該是后端小程序的未來。
云端的應(yīng)用有大量的小程序場景，例如識別一張圖片、對一段音頻/視頻進行編解碼、對IOT設(shè)備的請求返回一小段數(shù)據(jù)、將客戶提交的工單通過郵件通知客服人員等等。這些基于事件觸發(fā)的小程序在傳統(tǒng)架構(gòu)中實現(xiàn)起來是相對復(fù)雜的，你往往需要為20%的核心業(yè)務(wù)運營80%的支撐業(yè)務(wù)。Serverless完美的解決了這些問題，它可以成為復(fù)雜應(yīng)用的一種補充架構(gòu)。我們可以將無狀態(tài)的、事件觸發(fā)的業(yè)務(wù)拆分成Serverless應(yīng)用，讓整個架構(gòu)變得更加的簡潔和高效。
Serverless也在不斷演變，例如AWS最近引入的Step Functions就嘗試解決調(diào)用間共享狀態(tài)的問題，其效果有待觀察。
Serverless不是傳統(tǒng)的PaaS
Serverless跟PaaS之間的界線比較模糊，很多人認為Serverless是PaaS的一種，筆者也傾向于認為Serverless是特殊的PaaS形態(tài)。
Serverless由BaaS和FaaS兩部分構(gòu)成，BaaS負責提供業(yè)務(wù)的依賴服務(wù)，FaaS負責業(yè)務(wù)的部署和生命周期管理，從這個意義上來看，Serverless的角色跟PaaS一樣。與傳統(tǒng)PaaS的區(qū)別在于，傳統(tǒng)PaaS是以程序為粒度管理應(yīng)用的生命周期，而Serverless是以函數(shù)粒度管理應(yīng)用生命周期。傳統(tǒng)PaaS中的應(yīng)用為常駐內(nèi)存的進程，而Serverless應(yīng)用運行完即銷毀。此外，使用傳統(tǒng)PaaS，用戶仍需要關(guān)心水平擴展，例如如何配置Auto-Scaling Group，但Serverless沒有這個問題，水平擴展是架構(gòu)天然自帶的功能。
Serverless和微服務(wù)
Serverless和微服務(wù)沒有直接關(guān)系，但兩者有相似之處，例如都需要做業(yè)務(wù)拆分、強調(diào)無狀態(tài)、具有敏捷特性等。Serverless在很多方面比微服務(wù)粒度更細，要求也更嚴格。例如微服務(wù)以服務(wù)為邊界拆分業(yè)務(wù)，Serverless以函數(shù)為邊界拆分業(yè)務(wù)；微服務(wù)可以有跨調(diào)用的內(nèi)存狀態(tài)共享，Serverless要求調(diào)用徹底無狀態(tài)。此外，Serverless依賴BaaS提供第三方依賴，而微服務(wù)可以自由選擇第三方依賴來源，例如使用本地搭建的傳統(tǒng)中間件棧（如本地MySql和消息總線）。
Serverless和容器
Serverless和容器是蘋果和桔子的比較，不在一個平面上。Serverless是一種軟件設(shè)計架構(gòu)，容器是軟件架構(gòu)的承載者。雖然沒有公開資料，但我們可以推測類似于AWS Lambda這樣的Serverless框架使用了某種程度的容器技術(shù)，否者難以實現(xiàn)語言無關(guān)和毫秒級的啟動。盡管已經(jīng)有一些開源項目使用Docker實現(xiàn)Serverless中的FaaS部分，筆者不認為AWS Lambda這樣的公共Serverless框架直接使用了Docker，一定是一種更為輕量級、體積更小的容器技術(shù)，我們或許可以將它稱為Nano-Container。
Serverless對私有云有意義嗎？
對于私有云來說，現(xiàn)在將業(yè)務(wù)遷往Serverless架構(gòu)還為時過早。首先Serverless是從公共云中演化出來的新型架構(gòu)，適用于運行在公共云上的小程序。而私有云更多承載的是老而笨重的傳統(tǒng)業(yè)務(wù)，難以用Serverless架構(gòu)改造。其次Serverless依賴BaaS，在私有云中搭建和運維BaaS成本都不低，使用公共BaaS服務(wù)又受限于網(wǎng)絡(luò)帶寬和延時，容易導(dǎo)致系統(tǒng)不穩(wěn)定。
隨著企業(yè)應(yīng)用的進一步云化、開源Serverless框架的成熟，私有云的Devops場景也可以采用Serverless作CI/CD，例如目前Jenkins承擔的大部分工作都可以用Serverless替代，如用FaaS框架對應(yīng)Jenkins本身，上傳的代碼對應(yīng)Jenkins Job中的Bash腳本，將原來的Jenkins API觸發(fā)Job改為觸發(fā)FaaS中的代碼。
總結(jié)
Serverless作為一種全新的架構(gòu)，是云計算發(fā)展演化的必然結(jié)果。追求更細粒度的計費單元，更加專注于核心業(yè)務(wù)、將支撐業(yè)務(wù)外包給基礎(chǔ)設(shè)施提供商是云計算的趨勢。Serverless架構(gòu)的特點，讓編寫事件觸發(fā)的后端小程序變得更加容易。同時它也有自身內(nèi)在的局限性，并不適合復(fù)雜的應(yīng)用架構(gòu)。從目前的情況看，部分采用Serverless的混合架構(gòu)對公共云應(yīng)用是個不錯的選擇，私有應(yīng)用采用Serverless還為時過早。云計算技術(shù)正在飛速發(fā)展，未來還有無限可能。
作者簡介：張鑫，ZStack創(chuàng)始人，于2006年加入Intel開源軟件技術(shù)中心，從事Xen虛擬機開發(fā)，是世界上最早一批虛擬化開發(fā)者。《系統(tǒng)虛擬化》一書的主要作者。2010年,張鑫赴硅谷加入IaaS初創(chuàng)公司Cloud.com，是CloudStack核心開發(fā)人員，負責Oracle VM，Barematel，Baremetal VPC等核心功能。之后隨Cloud.com并購加入了軟件巨頭Citrix，繼續(xù)從事CloudStack的核心技術(shù)研發(fā)。2015年回國推出了全新的下一代開源IaaS：ZStack，2016年獲阿里云數(shù)千萬A輪戰(zhàn)略投資，與阿里云在混合云方面深度戰(zhàn)略合作。
總結(jié)
以上是生活随笔為你收集整理的Serverless，后端小程序的未来的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Kubernetes1.6安装指南 (二
- 下一篇： Flannel安装