瞭解Serverless架構

1 概述

Serverless中文譯爲「無服務」是一種新興起的架構模式，公司ESB產品引入Rest微服務服務機制過程，筆者恰好參與其中，其中Serverless做爲一個新起的概念，跟微服務架構相關，爲此筆者查閱了許多資料，有一些初步瞭解，所以把本身的學習筆記分享給你們，但願能對相關學習者有所幫助。本文主要是從自身的疑問出發，來闡述什麼是Serverless架構，Serverless架構有哪些優缺點以及有哪些應用案例等。

2 名詞解釋

什麼是Serverless？它是一種基於互聯網的技術架構理念。Serverless不是真的不須要服務器了，而是不用過多的關注服務器。它是指明顯或充分地依賴第三方應用或服務來管理服務器端邏輯和狀態，可讓你在服務部署級別而不是服務器部署級別來管理你的應用部署，甚至可讓你管理某個具體功能或端口的部署，這就能讓開發者快速迭代，更快速地開發軟件。

Serverless架構分爲兩種類型，分別爲「Backend as a Service」 和 「Functions as a Service」。

「Backend as a Service」即BaaS，是一種新型的雲服務，指在爲移動和Web應用提供後端雲服務，實現對邏輯和狀態進行管理，包括雲端數據/文件存儲、消息推送（例如極光推送、個推）、應用數據分析等等。 能夠說BaaS是誕生於移動互聯網，爲了加速移動應用開發和下降成本而造成的開發架構。

「Functions as a Service」即FaaS，指這樣的應用，一部分服務邏輯由應用實現，可是跟傳統架構不一樣在於，他們運行於無狀態的容器中，能夠由事件觸發，短暫的，徹底被第三方管理，功能上FaaS就是不須要關心後臺服務器或者應用服務，只需關心本身的代碼便可。其中AWS Lambda是目前最佳的FaaS實現之一。

Lambda是一種計算服務，它在AWS基礎設施上執行用JavaScript（node.js）、Python或Java編寫的代碼。源代碼部署到孤立的容器上，該容器有單獨分配的內存、磁盤空間和處理器。代碼、配置和依賴項這一組合一般被稱爲Lambda函數。

3 架構特色

3.1 節約成本

咱們在阿里雲或者騰訊雲上購買的雲服務器的配置是固定的，好比2G內存，雙核CPU，這樣作的弊端是若是系統在特定的某一天須要支持很高的併發量，好比：雙十一那天，可是服務器的內存並不夠，難道要爲了那一天又特定去多買一些內存麼？在Serverless架構下，用戶可以經過網絡、硬盤、CPU等計算資源，在不須要額外服務器基礎設施的狀況下，能夠作到隨時擴縮容，對數據庫的存儲也沒有限制。它是按照調用次數進行計費的，若是平時沒有訪問量就不計費，因此不會有浪費的狀況，有效的節約成本。

3.2 簡化運維

傳統服務器須要維護程序和硬件設施；而Serverless架構中，開發人員面對的將是第三方開發或自定義的API 和URL，底層硬件對於開發人員是透明化的，技術團隊無需再關注運維工做，可以更加專一於應用系統開發。同時，應用程序的組成邏輯會使用大量的第三方功能服務。目前，例如登錄鑑權的服務，雲數據庫服務等第三方服務在安全性、可用性、性能方面都進行了大量優化，開發團隊直接集成第三方的服務，就可以有效的下降開發成本，同時使得應用的運維過程變得更加清晰，有效的提高了應用的可維護性。

4 應用模式

4.1 UI-驅動型應用

讓咱們從服務端邏輯上來探討下，一個3層的客戶端導向系統。常見的電子商務應用是一個好的例子（這裏我拿一個網上寵物店來當例子）

傳統上，架構將看起來像這樣，而且假設它在服務器端的Java中實現，使用HTML / Javascript組件做爲客戶端：

 

客戶端(瀏覽器) ---> 寵物店服務器 ---->數據庫

使用這種架構，客戶端可能相對不智能，系統中的許多邏輯 - 認證，頁面導航，搜索，事務 - 由服務器應用程序實現。

使用無服務器架構，可能會更像是這樣：

 

認證服務--->產品數據庫--->客戶端(瀏覽器) --->API網關--->購買功能--->購買數據庫

認證服務--->產品數據庫--->客戶端(瀏覽器) --->API網關--->搜索功能--->產品數據庫

下面是二者區別：

        1. 將原來應用的認證邏輯系統刪除，替換成一個第三方的BaaS服務。

        2. 容許客戶端直接訪問數據庫，好比產品列表，數據庫在第三方主機上好比AWS Dynamo，這樣，咱們訪問數據庫的安全策略就和訪問服務器資源不一樣。

        3. 前面兩點意味着很是重要的第三點，原來在寵物店的邏輯如今遷移到客戶端了，好比跟蹤用戶會話，理解應用的UX用戶體驗結構，好比分頁，從數據庫中讀取和轉爲可用的視圖等，客戶端其實在這時已經變成了一個單頁應用。

        4. 一些UX相關功能可能會保留在服務器端，好比計算敏感或須要訪問大量數據，好比搜索功能，對於這種功能咱們不老是讓其運行在服務器端，而是實現一個FaaS函數方式來響應http請求，客戶端經過API網關來訪問這個FaaS函數。

        5. 使用FaaS函數來替代購買功能，由於安全緣由仍是讓其放在服務器，不須要在客戶端再實現一遍，這也是經過API網關調用實現的。

4.2 消息驅動應用

另外一個不一樣的例子是一個後端數據計算服務。好比你正在寫一個用戶爲中心的應用，須要快速響應UI請求，可是你又須要捕獲發生的全部不一樣類型的活動。讓咱們來思考下在線廣告系統，當一個用戶點擊一個廣告時，你須要快速的導向到廣告，可是同時你又須要將這個點擊計數，從而向廣告商收費。

傳統方式下這種系統的架構多是相似這樣的：「廣告服務器」會以同步的方式響應用戶（因爲只是例子，咱們並不須要關心具體的交互），同時須要向渠道發佈一條消息並由負責更新數據庫的「點擊處理器」應用程序以異步的方式處理，例如扣掉廣告主的部分預算。

在無服務器的世界中，這個系統應該是這樣的：

和上一個例子相比，本例中兩種架構的差別很小。咱們將須要長期運行的消費者應用程序替換爲一個在供應商提供的事件驅動的上下文中運行的FaaS函數。請注意該供應商同時提供了消息代理（Message Broker）和FaaS環境，這兩個系統很是緊密地相互結合在一塊兒。

經過實例化（Instantiating）函數代碼的多個副本，FaaS環境能夠並行處理多個點擊，這主要取決於最初流程的編寫方式，同時這也是一個須要考慮的新概念。

5 架構缺陷

5.1 廠商平臺綁定

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

5.2 沒有行業標準

目前的狀況也只適合簡單的應用開發，缺少大型成功案例的推進。對於Serverless缺少統一的認知以及相應的標準，沒法適應全部的雲平臺，目前尚不成熟，各廠家自說自話，更可能是在一種探索、觀望過程當中，真正在作的可能並無提標準，而提標準的有很多還在概念模糊階段。

6 心得總結

Serverless無服務器架構是開發人員和企業組織須要考慮、研究和採用的最新理念，它是依賴第三方應用或服務來管理服務器端邏輯和狀態的技術架構，可是其實它並不能替代服務器。Serverless是最新流行微服務的一種表現形式，是新一代雲服務和開發架構的實踐，是雲計算髮展重點方向之一。

隨着開發人員積極採用AWS Lambda等計算服務，這種架構可能會迅速發展起來。可是，這一架構目前來看還不是特別成熟，有待考證。筆者認爲咱們能夠熟悉下業內Serverless架構的經典產品，並進行學習，進而開發屬於本身的Serverless產品，數通暢聯的拳頭產品ESB企業服務總線中就提供Rest微服務服務組件、以及微服務服務管理、監控、統計功能，能知足微服務架構下的常見典型應用場景，若有需求敬請關注。