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

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

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

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

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

談談Serverless服務,顛覆你對雲的理解_騰訊視頻 https://v.qq.com/x/page/t0395qk7qew.html

以下是雷鋒網(公眾號:雷鋒網)整理的公開課主要內容,更完整內容可觀看上面雷鋒網公開課的視頻:

我們從2014年開始使用AWS。2014年,亞馬遜發布了Serverless服務,當時它還是一個顛覆性的想法,少有人使用。我們也是在去年初才把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長什麼樣?

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

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

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

一是Lambda

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

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

Lambda使用中要注意的是:

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

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

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

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

DynamoDB

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

Aurora

它是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過來的數據。

Serverless的優勢與劣勢

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

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

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

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

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

Serverless的意義

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

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

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

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

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

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

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

雷鋒網原創文章,未經授權禁止轉載。詳情見轉載須知。

推薦閱讀:

架構設計的0層邏輯
微服務的架構模式中,資料庫如何規劃?如果採用獨享資料庫,如何解決事務處理和聯合查詢?
既然 Chrome 的設計這麼優秀,為什麼其他瀏覽器不借鑒?

TAG:云计算 | 软件架构 | 云服务 |