軟件體系架構閱讀筆記二

當咱們還在容器的浪潮中前行時，已經有一些革命先驅悄然佈局另一個雲計算戰場：Serverless架構。

2014年11月14日，亞馬遜AWS發佈了新產品Lambda。當時Lambda被描述爲：一種計算服務，根據時間運行用戶的代碼，無需關心底層的計算資源。從某種意義上來講，Lambda姍姍來遲，它像雲計算的PaaS理念：客戶只管業務，無需擔憂存儲和計算資源。在此前不久，2014年10月22日，谷歌收購了實時後端數據庫創業公司Firebase。Firebase聲稱開發者只需引用一個API庫文件就可使用標準REST API的各類接口對數據進行讀寫操做，只需編寫HTML＋CSS＋JavaScrip前端代碼，不須要服務器端代碼（如需整合，也極其簡單）。

相對於上二者，Facebook 在2014年二月收購的 Parse，則側重於提供一個通用的後臺服務。這些服務被稱爲Serverless或no sever。想到PaaS（平臺即服務）了是嗎？很像，用戶不須要關心基礎設施，只須要關心業務，這是遲到的PaaS，也是更實用的PaaS。這頗有可能將會變革整個開發過程和傳統的應用生命週期，一旦開發者們習慣了這種全自動的雲上資源的建立和分配，或許就再也回不到那些須要微應用配置資源的時代裏去了。

Serverless架構可以讓開發者在構建應用的過程當中無需關注計算資源的獲取和運維，由平臺來按需分配計算資源並保證應用執行的SLA（服務等級協議），按照調用次數進行計費，有效的節省應用成本。ServerLess的架構如上圖所示。其優勢以下所示：

低運營成本：在業務突發性極高的場景下，系統爲了應對業務高峯，必須構建可以應對峯值需求的系統，這個系統在大部分時間是空閒的，這就致使了嚴重的資源浪費和成本上升。在微服務架構中，服務須要一直運行，實際上在高負載狀況下每一個服務都不止一個實例，這樣才能完成高可用性；在Serverless架構下，服務將根據用戶的調用次數進行計費，按照雲計算pay-as-you-go原則，若是沒有東西運行，你就沒必要付款，節省了使用成本。同時，用戶可以經過共享網絡、硬盤、CPU等計算資源，在業務高峯期經過彈性擴容方式有效的應對業務峯值，在業務波谷期將資源分享給其餘用戶，有效的節約了成本。

簡化設備運維：在原有的IT體系中，開發團隊即須要維護應用程序，同時還要維護硬件基礎設施；Serverless架構中，開發人員面對的將是第三方開發或自定義的API 和URL，底層硬件對於開發人員透明化了，技術團隊無需再關注運維工做，可以更加專一於應用系統開發。

提高可維護性：Serverless架構中，應用程序將調用多種第三方功能服務，組成最終的應用邏輯。目前，例如登錄鑑權服務，雲數據庫服務等第三方服務在安全性、可用性、性能方面都進行了大量優化，開發團隊直接集成第三方的服務，可以有效的下降開發成本，同時使得應用的運維過程變得更加清晰，有效的提高了應用的可維護性。

更快的開發速度：這一點在如今互聯網創業公司獲得很好的體現，創業公司每每開始因爲人員和資金等問題，不可能每一個產品線都同時進行，這時候就能夠考慮第三方的Baas平臺，好比使用微信的用戶認證、阿里雲提供的RDS，極光的消息推送，第三方支付及地理位置等等，可以很快進行產品開發的速度，把工做重點放在業務實現上，把產品更快的推向市場。

但ServerLess架構也有其缺點：

廠商平臺綁定：平臺會提供Serverless架構給大玩家，好比AWS Lambda，運行它須要使用AWS指定的服務，好比API網關，DynamoDB，S3等等，一旦你在這些服務上開發一個複雜系統，你會粘牢AWS，之後只好任由他們漲價訂價或者下架等操做，個性化需求很難知足，不能進行隨意的遷移或者遷移的成本比較大，同時不可避免帶來一些損失。Baas行業內一個比較典型的事件，2016年1月19日Facebook關閉曾經花鉅額資金收購的Parse，形成用戶不得不遷移在這個平臺中產生一年多的數據，無疑須要花費比較大的人力和時間成本。

成功案例比較少，沒有行業標準：目前的狀況也只適合簡單的應用開發，缺少大型成功案例的推進。對於Serverless缺少統一的認知以及相應的標準，沒法適應全部的雲平臺。