詳解Serverless服務，它會顛覆你對雲的理解 | 硬創公開課

Serverless無伺服器架構是一個新的事物，從出現到現在也不過兩年，目前也沒有一個公認的權威定義。從2014年亞馬遜正式發布Serverless服務Lambda，經過近兩年的發酵，Google、微軟與阿里也在2016年相繼推出了自己的相關服務。

業界認為，Serverless代表了新的軟體設計範式，可能也顛覆了我們一般對雲的理解。本次硬創公開課，雷鋒網就邀請到了Strikingly創始團隊成員及首席架構師龔凌暉，來講講Serverless服務到底是什麼，它的發展狀況又是怎麼樣的。

Strikingly是自助式建站平台，提供模版、設計資源、編輯器等，可以在短時間內容搭建自己的網站，提供託管服務。它是第一家從YC孵化的國內初創公司，主要幫助不懂技術但又有建站需求的用戶服務。

龔凌暉，Strikingly 創始團隊成員，第一個工程師。畢業於復旦大學計算機學院，在加入 Strikingly 之前，曾在 Morgan Stanley 的 Enterprise Infrastructure 部門任職。2013年加入 Strikingly 之後，做過產品，搞過運維自動化，研究過 Web Analytics 和 SEO，玩過數據分析，目前在團隊中負責後端開發，系統運維以及數據分析等部門的項目研發和團隊管理。

以下是雷鋒網整理的公開課主要內容，更完整內容可觀看上面雷鋒網公開課的視頻：

我們從2014年開始使用AWS。2014年，亞馬遜發布了Serverless服務，當時它還是一個顛覆性的想法，少有人使用。我們也是在去年初才把Serverless引入到系統中。

早期的互聯網應用依賴傳統IDC做系統架構，要有專業的運維人員管理計算資源，還要對系統負載做嚴格的評估和預測，這樣才有時間購買新伺服器。後來虛擬化技術提高了靈活性，計算資源擁有者可以把資源打包，按使用時間計費，這也就誕生了IaaS服務。

IaaS對系統的可拓展性和成本控制都有很大作用，但對剛起步的公司來講，虛擬化仍不夠，所以雲平台在虛擬化的基礎上作了進一步抽象，讓開發者只關注應用邏輯，而不用管伺服器配置和應用部署，這也就是PaaS。

不過雖然簡化了系統的複雜性和開發應用的迭代速度，PaaS依然要調整計算資源的數量來適應系統變化，那如果計算資源可隨系統的變化自動伸縮呢？這也就是Serverless誕生的原因。

Serverless不是沒有伺服器，它與傳統去計算服務形態的區別主要包括：

更細粒度的計算資源分配；

基本無需預先計劃計算資源；

高度彈性可擴展；

按需使用，按使用量付費。

不過這些可能也是雲計算的特別，而真正的區別就像上圖中的比喻，從自行打井水到筒裝水再到按需隨時使用的自來水，Serverless就像是水龍頭，它把服務的靈活性做到了極致，本質是最細粒度的雲平台服務形態。

最前沿的Serverless廠商無疑是亞馬遜AWS，它從2006年開始提供雲計算服務，這種領先也一直延續。微軟Azure與阿里雲也相繼推出Serverless服務。

為什麼AWS要開發Serverless？其實用戶對雲的方便與靈活有越來越高的要求，所以Serverless是一個必定出現的趨勢，即使不是AWS，其它廠商也會提出來。下圖是AWS Serverless服務發布的時間表。

可能其中最出名的是Lambda，但Serverless包括了方方面面，比如S3就是一個很典型的Serverless服務，按照存儲的數據量和訪問量收費。

有一個值得關注的點是，2014年AWS發布了Lambda，但Serverless是在近兩年後才逐漸引起關注。這是因為2014年容器技術才剛成為關注點，而Serverless太過於前衛，所有的雲廠商都沒想明白怎麼樣去發展它，而且生態也不成熟，在落實到工程中仍有很多問題。

AWS用了一年多時間推動Serverless，同時相關的工具也得到了發展，讓部分用戶嘗到了甜頭，這也引起了其它廠商的跟進，紛紛在2016年推出服務。其它廠商追趕的時候，AWS也把Lambda拓展到了其它服務，比如物聯網和海量數據運輸。

Google雲平台在2008年發布App Engine就進入雲服務，目前它的Serverless服務Cloud Functions還處於試用階段。微軟Azure雲與阿里雲也在2016年發布了Azure Functions和Function Compute，都是試用。

接下來介紹幾個典型的Serverless服務，以及如何構建實用的解決方案。

下圖把AWS的服務分成三類。一是基於EC2直接構建服務。第二類是託管服務，不需要對底層的虛擬機進行管理，只需配置資源大小，它會自動分配資源。託管服務在各雲廠商之間的差異較大，也是競爭所在。第三類是Serverless服務，完全由AWS託管，甚至不用預先分配計算資源，也不用考慮實現彈性伸縮，只需要用就可以了。

有代表性的Serverless服務有下列一些。

這是基於事件驅動的Serverless服務。它一不需要管理伺服器和抽象的計算資源；二由事件驅動，可自動擴展計算能力；三是實現成本控制，按使用量收，計時可精確到4秒。

如何用Lambda呢？一是把現有的代碼包裝成Lambda函數；二是選擇計算單元的大小，AWS提供了單一唯獨的指標，只需要選擇運行時所需要的內存大小，就可自動適配GPU，I/O等；三是代碼打包上傳到AWS；四是指定事件觸發方式，如來自API的請求和SNS的消息，它有與其它服務交互的能力。

Lambda使用中要注意的是：

它是一個無狀態的計算模型，因此要避免運行過程中安裝代碼依賴；

二是它的實現機制有一個流量預測演算法，但它無法在沒有流量的情況下進行預測，因此在一段時間沒有執行後，再啟動時會有延時，因此要視情況避免冷啟動；

三是內置了版本和別名機制，需要合理利用；

四是正確編譯平台相關代碼。

DynamoDB

它是AWS內部分布式NoSQL資料庫服務。它的主要特性如下：由AWS完全託管，不需要任何設置就可以獲得快速穩定的讀寫性，存儲空間也會隨著數據量增長而增長。它也支持Lambda，這樣同時支持精細到每一項數據的訪問控制。

它是AWS兼容第三方介面的關係型資料庫服務，目前還在預覽階段。它的出現是因為，傳統資料庫解決方案不是為雲平台設計的，需要用雲的思維重新定義。

AWS引入了SOA理念，重新打造資料庫引擎，把傳統數據組件分解成一個個的獨立模塊，再通過自己雲平台中已經有的服務來實現這些服務模塊。這使得用戶不用擔心資料庫升級，容量擴展這些令人頭疼的問題。

如上圖，整個資料庫服務被分成數據層和控制層，控制層由DynamoDB來存儲元數據，Route 53提供服務發現，SWF負責SOA中的工作協調。數據層則使用了可靠性強的S3來實現數據的高可用存儲。

AWS通過共享存儲也實現了讀寫分離和高可用性，可以滿足大部分用戶對資料庫的要求。Aurora的價格幾乎接近開源資料庫的價格，只是約高端商業資料庫價格的十分之一。

下圖是Aurora（藍色）與MySQL（綠與紅）資料庫在讀寫上的性能對比。

總體來說，從經濟成本，管理成本和實際效用上，都超越了傳統資料庫。

Serverless設計模式經典3層web應用

典型的web應用通常分為動態與靜態資源。在設計中，可以用S3作為靜態資源的存儲，同時用CloudFront的CDN加速服務。動態這一塊DynamoDB作為網站數據存儲，通過API Gateway和Lambda實現前端的靜態頁面調度。整個架構中都用的是Serverless服務。

還可以設計更複雜的架構，如下圖：

靜態部分還是S3與CloudFront，但加入了高級功能。動態部分加入IAM支持，同時在API Gateway這一層加入流量控制，認證等。 還可以加入防火牆服務WAF。

不過Serverless架構中的組件過多，如果API有數十甚至上百個節點，Lambda函數也會這麼多，手動管理會十分不方便。因此亞馬遜也推出了相應的方案SAM。如下圖：

AWS CloudFormation是亞馬遜專門用來配置和管理計算資源的服務，SAM是它的一個子集，可以用它打包整個架構設計，自動把所有東西同時打包配置好，做到自動化。

很多數據批處理的邏輯都可以分解成Map-Reduce的合理操作。但亞馬遜Lambda提供的思路是，把原始數據存在雲端，然後定義filter（把輸入的數據分配到多個maper上），maper（執行映射邏輯，並把映射結果存在DynamoDB），reducer（處理映射邏輯，把最終結果存在S3上）三個lambda函數。由於S3和DynamoDB的事件都能觸發Lambda函數執行，整個過程可以完全自動完成並自動伸縮。另由於起點和終點都是S3，所以可以把多個Map-Reduce邏輯串聯，構成更複雜的處理模型。

數據流式處理

Kinesis是亞馬遜處理流數據的品牌。下圖是簡化版且S3和Lambda數據流兩步歸集的處理系統。

第一步要用Lambda實現初步處理器Stream Processor，它處理流數據後會把結果保存在S3上。第二是用CloudWatch定時器功能周期性觸發Lambda函數，把中間結果進一步處理，把最終結果存在S3上。為了提高效率，第二步中的Lambda是一個任務分配器，可以同時觸發多個具體處理數據的Lambda函數，同時對多個S3中的中間結果對象做處理。

這裡有一個隱患，它來自Lambda和Kinesis集成方案的技術性區別。兩者對接時，前者的並行能力會受到後者並行能力的限制。同時運行的Stream Processor的數量不能超過Kinesis的數據流分配的數據，這會導致數據流的推積。

解決方法是，如果瓶頸在於對接Kinesis的Lambda函數， 那可以縮短函數的執行時間。具體而言，Lambda函數不負責具體的數據處理，而是應該把它給更多Lambda並行處理。由於從Lambda函數觸發其它Lambda函數沒有並行限制，那可以做到即時處理Kinesis過來的數據。

前文已經提及它的優勢，現在再來談談它的問題與挑戰。總的來說，一些傳統開發的技術和經驗不適用。

首先是服務細粒度增加了開發大型應用的難度。傳統web應用可以管理成百上千的API，但在Serverless中需要開發者有足夠的管理能力進來應對。

其次是Serverless只能選用雲廠商支持的特定的技術棧，對代碼的行為有一定限制。

建立本地開發環境較為困難，調試不便。現在有人在本地用Docker模擬運行環境，這值得一試，但無法完全接近生產環境。

應用安全模型不夠成熟，如何實現加密、認證、許可權管理都需要時間來檢驗。

Serverless的意義

對開發工程師來說，Serverless是一個新的職業發展機遇。它不會完全替代現有的傳統開發與部署模式，但一定會在某些領域大放異彩。它也降低了開發高並發應用的門檻，能為應用實現高可擴展與高可用性。

對運維工程師來說，可以更清楚認識到在雲計算時代系統運維這個職業的危機。雲計算的一個發展趨勢是，雲廠商把自己在架構和運維實踐上的經驗產品化，提供給用戶，而它們的共有特徵是對運維的依賴越來越小，開發工程師可以獨立完成系統部署。

不過這個職業的發展方向是兼顧開發，做運維自動化。Serverless也給希望向自動化運維方向轉型的工程師提供了職業發展機遇，可以利用Serverless新的運維邏輯，完成運維自動化。

對CTO和架構師來說，Serverless可以幫助理解全新的架構設計思路， 把系統架構中一部分用Serverless實現，提供開發和運維效率，用低成本實現可擴展性和可用性。

對CEO與產品經理來說，理解Serverless有助於判斷某個產品特性是否適合這一服務進行快速實現。

對於學生來說，學習更新的知識總沒錯，學習Serverless可以幫助理解新的軟體設計範式，為自己的職業發展做準備

可以說，Serverless代表了全新的軟體設計範式，需要用新的思路來看待雲計算，它已經顛覆了對雲的理解。