0
| 本文作者： 張馳 | 2017-04-24 20:23 | 專題：雷峰網(wǎng)公開課 |
Serverless無服務(wù)器架構(gòu)是一個新的事物，從出現(xiàn)到現(xiàn)在也不過兩年，目前也沒有一個公認的權(quán)威定義。從2014年亞馬遜正式發(fā)布Serverless服務(wù)Lambda，經(jīng)過近兩年的發(fā)酵，Google、微軟與阿里也在2016年相繼推出了自己的相關(guān)服務(wù)。
業(yè)界認為，Serverless代表了新的軟件設(shè)計范式，可能也顛覆了我們一般對云的理解。本次硬創(chuàng)公開課，雷鋒網(wǎng)就邀請到了Strikingly創(chuàng)始團隊成員及首席架構(gòu)師龔凌暉，來講講Serverless服務(wù)到底是什么，它的發(fā)展狀況又是怎么樣的。
Strikingly是自助式建站平臺，提供模版、設(shè)計資源、編輯器等，可以在短時間內(nèi)容搭建自己的網(wǎng)站，提供托管服務(wù)。它是第一家從YC孵化的國內(nèi)初創(chuàng)公司，主要幫助不懂技術(shù)但又有建站需求的用戶服務(wù)。
龔凌暉，Strikingly 創(chuàng)始團隊成員，第一個工程師。畢業(yè)于復(fù)旦大學計算機學院，在加入 Strikingly 之前，曾在 Morgan Stanley 的 Enterprise Infrastructure 部門任職。2013年加入 Strikingly 之后，做過產(chǎn)品，搞過運維自動化，研究過 Web Analytics 和 SEO，玩過數(shù)據(jù)分析，目前在團隊中負責后端開發(fā)，系統(tǒng)運維以及數(shù)據(jù)分析等部門的項目研發(fā)和團隊管理。
以下是雷鋒網(wǎng)整理的公開課主要內(nèi)容，更完整內(nèi)容可觀看上面雷鋒網(wǎng)公開課的視頻：
我們從2014年開始使用AWS。2014年，亞馬遜發(fā)布了Serverless服務(wù)，當時它還是一個顛覆性的想法，少有人使用。我們也是在去年初才把Serverless引入到系統(tǒng)中。
早期的互聯(lián)網(wǎng)應(yīng)用依賴傳統(tǒng)IDC做系統(tǒng)架構(gòu)，要有專業(yè)的運維人員管理計算資源，還要對系統(tǒng)負載做嚴格的評估和預(yù)測，這樣才有時間購買新服務(wù)器。后來虛擬化技術(shù)提高了靈活性，計算資源擁有者可以把資源打包，按使用時間計費，這也就誕生了IaaS服務(wù)。
IaaS對系統(tǒng)的可拓展性和成本控制都有很大作用，但對剛起步的公司來講，虛擬化仍不夠，所以云平臺在虛擬化的基礎(chǔ)上作了進一步抽象，讓開發(fā)者只關(guān)注應(yīng)用邏輯，而不用管服務(wù)器配置和應(yīng)用部署，這也就是PaaS。
不過雖然簡化了系統(tǒng)的復(fù)雜性和開發(fā)應(yīng)用的迭代速度，PaaS依然要調(diào)整計算資源的數(shù)量來適應(yīng)系統(tǒng)變化，那如果計算資源可隨系統(tǒng)的變化自動伸縮呢？這也就是Serverless誕生的原因。
Serverless不是沒有服務(wù)器，它與傳統(tǒng)去計算服務(wù)形態(tài)的區(qū)別主要包括：
更細粒度的計算資源分配；
基本無需預(yù)先計劃計算資源；
高度彈性可擴展；
按需使用，按使用量付費。
不過這些可能也是云計算的特別，而真正的區(qū)別就像上圖中的比喻，從自行打井水到筒裝水再到按需隨時使用的自來水，Serverless就像是水龍頭，它把服務(wù)的靈活性做到了極致，本質(zhì)是最細粒度的云平臺服務(wù)形態(tài)。
最前沿的Serverless廠商無疑是亞馬遜AWS，它從2006年開始提供云計算服務(wù)，這種領(lǐng)先也一直延續(xù)。微軟Azure與阿里云也相繼推出Serverless服務(wù)。
為什么AWS要開發(fā)Serverless？其實用戶對云的方便與靈活有越來越高的要求，所以Serverless是一個必定出現(xiàn)的趨勢，即使不是AWS，其它廠商也會提出來。下圖是AWS Serverless服務(wù)發(fā)布的時間表。
可能其中最出名的是Lambda，但Serverless包括了方方面面，比如S3就是一個很典型的Serverless服務(wù)，按照存儲的數(shù)據(jù)量和訪問量收費。
有一個值得關(guān)注的點是，2014年AWS發(fā)布了Lambda，但Serverless是在近兩年后才逐漸引起關(guān)注。這是因為2014年容器技術(shù)才剛成為關(guān)注點，而Serverless太過于前衛(wèi)，所有的云廠商都沒想明白怎么樣去發(fā)展它，而且生態(tài)也不成熟，在落實到工程中仍有很多問題。
AWS用了一年多時間推動Serverless，同時相關(guān)的工具也得到了發(fā)展，讓部分用戶嘗到了甜頭，這也引起了其它廠商的跟進，紛紛在2016年推出服務(wù)。其它廠商追趕的時候，AWS也把Lambda拓展到了其它服務(wù)，比如物聯(lián)網(wǎng)和海量數(shù)據(jù)運輸。
Google云平臺在2008年發(fā)布App Engine就進入云服務(wù)，目前它的Serverless服務(wù)Cloud Functions還處于試用階段。微軟Azure云與阿里云也在2016年發(fā)布了Azure Functions和Function Compute，都是試用。
接下來介紹幾個典型的Serverless服務(wù)，以及如何構(gòu)建實用的解決方案。
下圖把AWS的服務(wù)分成三類。一是基于EC2直接構(gòu)建服務(wù)。第二類是托管服務(wù)，不需要對底層的虛擬機進行管理，只需配置資源大小，它會自動分配資源。托管服務(wù)在各云廠商之間的差異較大，也是競爭所在。第三類是Serverless服務(wù)，完全由AWS托管，甚至不用預(yù)先分配計算資源，也不用考慮實現(xiàn)彈性伸縮，只需要用就可以了。
有代表性的Serverless服務(wù)有下列一些。
這是基于事件驅(qū)動的Serverless服務(wù)。它一不需要管理服務(wù)器和抽象的計算資源；二由事件驅(qū)動，可自動擴展計算能力；三是實現(xiàn)成本控制，按使用量收，計時可精確到4秒。
如何用Lambda呢？一是把現(xiàn)有的代碼包裝成Lambda函數(shù)；二是選擇計算單元的大小，AWS提供了單一唯獨的指標，只需要選擇運行時所需要的內(nèi)存大小，就可自動適配GPU，I/O等；三是代碼打包上傳到AWS；四是指定事件觸發(fā)方式，如來自API的請求和SNS的消息，它有與其它服務(wù)交互的能力。
Lambda使用中要注意的是：
它是一個無狀態(tài)的計算模型，因此要避免運行過程中安裝代碼依賴；
二是它的實現(xiàn)機制有一個流量預(yù)測算法，但它無法在沒有流量的情況下進行預(yù)測，因此在一段時間沒有執(zhí)行后，再啟動時會有延時，因此要視情況避免冷啟動；
三是內(nèi)置了版本和別名機制，需要合理利用；
四是正確編譯平臺相關(guān)代碼。
它是AWS內(nèi)部分布式NoSQL數(shù)據(jù)庫服務(wù)。它的主要特性如下：由AWS完全托管，不需要任何設(shè)置就可以獲得快速穩(wěn)定的讀寫性，存儲空間也會隨著數(shù)據(jù)量增長而增長。它也支持Lambda，這樣同時支持精細到每一項數(shù)據(jù)的訪問控制。
它是AWS兼容第三方接口的關(guān)系型數(shù)據(jù)庫服務(wù)，目前還在預(yù)覽階段。它的出現(xiàn)是因為，傳統(tǒng)數(shù)據(jù)庫解決方案不是為云平臺設(shè)計的，需要用云的思維重新定義。
AWS引入了SOA理念，重新打造數(shù)據(jù)庫引擎，把傳統(tǒng)數(shù)據(jù)組件分解成一個個的獨立模塊，再通過自己云平臺中已經(jīng)有的服務(wù)來實現(xiàn)這些服務(wù)模塊。這使得用戶不用擔心數(shù)據(jù)庫升級，容量擴展這些令人頭疼的問題。
如上圖，整個數(shù)據(jù)庫服務(wù)被分成數(shù)據(jù)層和控制層，控制層由DynamoDB來存儲元數(shù)據(jù)，Route 53提供服務(wù)發(fā)現(xiàn)，SWF負責SOA中的工作協(xié)調(diào)。數(shù)據(jù)層則使用了可靠性強的S3來實現(xiàn)數(shù)據(jù)的高可用存儲。
AWS通過共享存儲也實現(xiàn)了讀寫分離和高可用性，可以滿足大部分用戶對數(shù)據(jù)庫的要求。Aurora的價格幾乎接近開源數(shù)據(jù)庫的價格，只是約高端商業(yè)數(shù)據(jù)庫價格的十分之一。
下圖是Aurora（藍色）與MySQL（綠與紅）數(shù)據(jù)庫在讀寫上的性能對比。
總體來說，從經(jīng)濟成本，管理成本和實際效用上，都超越了傳統(tǒng)數(shù)據(jù)庫。
典型的web應(yīng)用通常分為動態(tài)與靜態(tài)資源。在設(shè)計中，可以用S3作為靜態(tài)資源的存儲，同時用CloudFront的CDN加速服務(wù)。動態(tài)這一塊DynamoDB作為網(wǎng)站數(shù)據(jù)存儲，通過API Gateway和Lambda實現(xiàn)前端的靜態(tài)頁面調(diào)度。整個架構(gòu)中都用的是Serverless服務(wù)。
還可以設(shè)計更復(fù)雜的架構(gòu)，如下圖：
靜態(tài)部分還是S3與CloudFront，但加入了高級功能。動態(tài)部分加入IAM支持，同時在API Gateway這一層加入流量控制，認證等。 還可以加入防火墻服務(wù)WAF。
不過Serverless架構(gòu)中的組件過多，如果API有數(shù)十甚至上百個節(jié)點，Lambda函數(shù)也會這么多，手動管理會十分不方便。因此亞馬遜也推出了相應(yīng)的方案SAM。如下圖：
AWS CloudFormation是亞馬遜專門用來配置和管理計算資源的服務(wù)，SAM是它的一個子集，可以用它打包整個架構(gòu)設(shè)計，自動把所有東西同時打包配置好，做到自動化。
很多數(shù)據(jù)批處理的邏輯都可以分解成Map-Reduce的合理操作。但亞馬遜Lambda提供的思路是，把原始數(shù)據(jù)存在云端，然后定義filter（把輸入的數(shù)據(jù)分配到多個maper上），maper（執(zhí)行映射邏輯，并把映射結(jié)果存在DynamoDB），reducer（處理映射邏輯，把最終結(jié)果存在S3上）三個lambda函數(shù)。由于S3和DynamoDB的事件都能觸發(fā)Lambda函數(shù)執(zhí)行，整個過程可以完全自動完成并自動伸縮。另由于起點和終點都是S3，所以可以把多個Map-Reduce邏輯串聯(lián)，構(gòu)成更復(fù)雜的處理模型。
Kinesis是亞馬遜處理流數(shù)據(jù)的品牌。下圖是簡化版且S3和Lambda數(shù)據(jù)流兩步歸集的處理系統(tǒng)。
第一步要用Lambda實現(xiàn)初步處理器Stream Processor，它處理流數(shù)據(jù)后會把結(jié)果保存在S3上。第二是用CloudWatch定時器功能周期性觸發(fā)Lambda函數(shù)，把中間結(jié)果進一步處理，把最終結(jié)果存在S3上。為了提高效率，第二步中的Lambda是一個任務(wù)分配器，可以同時觸發(fā)多個具體處理數(shù)據(jù)的Lambda函數(shù)，同時對多個S3中的中間結(jié)果對象做處理。
這里有一個隱患，它來自Lambda和Kinesis集成方案的技術(shù)性區(qū)別。兩者對接時，前者的并行能力會受到后者并行能力的限制。同時運行的Stream Processor的數(shù)量不能超過Kinesis的數(shù)據(jù)流分配的數(shù)據(jù)，這會導致數(shù)據(jù)流的推積。
解決方法是，如果瓶頸在于對接Kinesis的Lambda函數(shù)， 那可以縮短函數(shù)的執(zhí)行時間。具體而言，Lambda函數(shù)不負責具體的數(shù)據(jù)處理，而是應(yīng)該把它給更多Lambda并行處理。由于從Lambda函數(shù)觸發(fā)其它Lambda函數(shù)沒有并行限制，那可以做到即時處理Kinesis過來的數(shù)據(jù)。
前文已經(jīng)提及它的優(yōu)勢，現(xiàn)在再來談?wù)勊膯栴}與挑戰(zhàn)。總的來說，一些傳統(tǒng)開發(fā)的技術(shù)和經(jīng)驗不適用。
首先是服務(wù)細粒度增加了開發(fā)大型應(yīng)用的難度。傳統(tǒng)web應(yīng)用可以管理成百上千的API，但在Serverless中需要開發(fā)者有足夠的管理能力進來應(yīng)對。
其次是Serverless只能選用云廠商支持的特定的技術(shù)棧，對代碼的行為有一定限制。
建立本地開發(fā)環(huán)境較為困難，調(diào)試不便?，F(xiàn)在有人在本地用Docker模擬運行環(huán)境，這值得一試，但無法完全接近生產(chǎn)環(huán)境。
應(yīng)用安全模型不夠成熟，如何實現(xiàn)加密、認證、權(quán)限管理都需要時間來檢驗。
對開發(fā)工程師來說，Serverless是一個新的職業(yè)發(fā)展機遇。它不會完全替代現(xiàn)有的傳統(tǒng)開發(fā)與部署模式，但一定會在某些領(lǐng)域大放異彩。它也降低了開發(fā)高并發(fā)應(yīng)用的門檻，能為應(yīng)用實現(xiàn)高可擴展與高可用性。
對運維工程師來說，可以更清楚認識到在云計算時代系統(tǒng)運維這個職業(yè)的危機。云計算的一個發(fā)展趨勢是，云廠商把自己在架構(gòu)和運維實踐上的經(jīng)驗產(chǎn)品化，提供給用戶，而它們的共有特征是對運維的依賴越來越小，開發(fā)工程師可以獨立完成系統(tǒng)部署。
不過這個職業(yè)的發(fā)展方向是兼顧開發(fā)，做運維自動化。Serverless也給希望向自動化運維方向轉(zhuǎn)型的工程師提供了職業(yè)發(fā)展機遇，可以利用Serverless新的運維邏輯，完成運維自動化。
對CTO和架構(gòu)師來說，Serverless可以幫助理解全新的架構(gòu)設(shè)計思路， 把系統(tǒng)架構(gòu)中一部分用Serverless實現(xiàn)，提供開發(fā)和運維效率，用低成本實現(xiàn)可擴展性和可用性。
對CEO與產(chǎn)品經(jīng)理來說，理解Serverless有助于判斷某個產(chǎn)品特性是否適合這一服務(wù)進行快速實現(xiàn)。
對于學生來說，學習更新的知識總沒錯，學習Serverless可以幫助理解新的軟件設(shè)計范式，為自己的職業(yè)發(fā)展做準備
可以說，Serverless代表了全新的軟件設(shè)計范式，需要用新的思路來看待云計算，它已經(jīng)顛覆了對云的理解。
雷峰網(wǎng)原創(chuàng)文章，未經(jīng)授權(quán)禁止轉(zhuǎn)載。詳情見轉(zhuǎn)載須知。
專題
