0
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使用中要注意的是：
它是一個無狀態的計算模型，因此要避免運行過程中安裝代碼依賴；
二是它的實現機制有一個流量預測算法，但它無法在沒有流量的情況下進行預測，因此在一段時間沒有執行后，再啟動時會有延時，因此要視情況避免冷啟動；
三是內置了版本和別名機制，需要合理利用；
四是正確編譯平臺相關代碼。
它是AWS內部分布式NoSQL數據庫服務。它的主要特性如下：由AWS完全托管，不需要任何設置就可以獲得快速穩定的讀寫性，存儲空間也會隨著數據量增長而增長。它也支持Lambda，這樣同時支持精細到每一項數據的訪問控制。
它是AWS兼容第三方接口的關系型數據庫服務，目前還在預覽階段。它的出現是因為，傳統數據庫解決方案不是為云平臺設計的，需要用云的思維重新定義。
AWS引入了SOA理念，重新打造數據庫引擎，把傳統數據組件分解成一個個的獨立模塊，再通過自己云平臺中已經有的服務來實現這些服務模塊。這使得用戶不用擔心數據庫升級，容量擴展這些令人頭疼的問題。
如上圖，整個數據庫服務被分成數據層和控制層，控制層由DynamoDB來存儲元數據，Route 53提供服務發現，SWF負責SOA中的工作協調。數據層則使用了可靠性強的S3來實現數據的高可用存儲。
AWS通過共享存儲也實現了讀寫分離和高可用性，可以滿足大部分用戶對數據庫的要求。Aurora的價格幾乎接近開源數據庫的價格，只是約高端商業數據庫價格的十分之一。
下圖是Aurora（藍色）與MySQL（綠與紅）數據庫在讀寫上的性能對比。
總體來說，從經濟成本，管理成本和實際效用上，都超越了傳統數據庫。
典型的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只能選用云廠商支持的特定的技術棧，對代碼的行為有一定限制。
建立本地開發環境較為困難，調試不便?，F在有人在本地用Docker模擬運行環境，這值得一試，但無法完全接近生產環境。
應用安全模型不夠成熟，如何實現加密、認證、權限管理都需要時間來檢驗。
對開發工程師來說，Serverless是一個新的職業發展機遇。它不會完全替代現有的傳統開發與部署模式，但一定會在某些領域大放異彩。它也降低了開發高并發應用的門檻，能為應用實現高可擴展與高可用性。
對運維工程師來說，可以更清楚認識到在云計算時代系統運維這個職業的危機。云計算的一個發展趨勢是，云廠商把自己在架構和運維實踐上的經驗產品化，提供給用戶，而它們的共有特征是對運維的依賴越來越小，開發工程師可以獨立完成系統部署。
不過這個職業的發展方向是兼顧開發，做運維自動化。Serverless也給希望向自動化運維方向轉型的工程師提供了職業發展機遇，可以利用Serverless新的運維邏輯，完成運維自動化。
對CTO和架構師來說，Serverless可以幫助理解全新的架構設計思路， 把系統架構中一部分用Serverless實現，提供開發和運維效率，用低成本實現可擴展性和可用性。
對CEO與產品經理來說，理解Serverless有助于判斷某個產品特性是否適合這一服務進行快速實現。
對于學生來說，學習更新的知識總沒錯，學習Serverless可以幫助理解新的軟件設計范式，為自己的職業發展做準備
可以說，Serverless代表了全新的軟件設計范式，需要用新的思路來看待云計算，它已經顛覆了對云的理解。
雷峰網原創文章，未經授權禁止轉載。詳情見轉載須知。
專題
