【轉】Serverless架構

這是來自martinfowler.com的Serverless架構一文的大意翻譯。

什麼是Serverless?
    Serverless首先是用於描述咱們的應用程序是明顯或充分地依賴第三方應用或服務來管理服務器端邏輯和狀態，這些應用是典型的富客戶端應用，好比單頁Web應用或移動應用，它們使用基於雲可訪問的數據庫好比Parse或Firebase，還有受權服務好比Auth0AWS Cognito等，這些服務類型以前曾經被描述爲後端服務，下面使用Baas這一簡稱表明後端服務(Backend as a Service)。

    其次，Serverless也意味着應用會有一些服務器端邏輯，可是不像傳統架構是運行在無態容器中，經過事件觸發，它是瞬間的，可能只使用一次，徹底由第三方管理，一種思想認爲這是「Functions as service函數服務」簡稱Faas，AWS Lambda就是一種流行的Faas實現，固然還有其餘。

    當開發Baas shaped應用，特別當開發一個富Web應用，而不是移動應用時，你會須要一些服務器端定製功能，Faas功能也許對於這種狀況是一種好的解決方案，特別是若是他們和你使用的BaaS服務集成到必定程度時，這樣功能案例包括數據校驗和計算敏感的處理，好比圖片和視頻的製做。

下面是一些案例應用：
    UI驅動應用：讓咱們看看帶有服務器端邏輯的傳統三層面向客戶端系統，好比電子商務應用，傳統的架構是看上去像下面：

    客戶端(瀏覽器) ---> 寵物店服務器 ---->數據庫
    這種架構的客戶端相對不會太智能，系統中有太多邏輯：受權，分頁，搜索和事務等都是由服務器應用實現。

而使用Serverless架構則會以下面：

下面是二者區別：
    1.刪除了原來在應用中的受權邏輯，使用地反覆BaaS服務來替代
    2.容許客戶端直接訪問數據庫，好比產品列表等，數據庫是第三方主機上好比AWS Dynamo，這樣，咱們訪問數據庫的安全策略就和訪問服務器資源不一樣。
    3.前面兩點意味着很是重要的第三點，原來在寵物店的邏輯如今遷移到客戶端了，好比跟蹤用戶會話，理解應用的UX用戶體驗結構好比分頁，從數據庫中讀取和轉爲可用的視圖等等，客戶端其實這時已經變成了一個單頁應用。
    4.一些UX相關功能可能會要保留在服務器端，好比計算敏感或須要訪問大量數據，好比搜索功能，對於這種功能咱們不老是讓其運行在服務器端，而是實現一個FaaS函數方式來響應http請求，客戶端經過API網關來訪問這個FaaS函數。
    5.咱們也許使用FaaS函數來替代購買功能，讓其仍是放在服務器端是由於安全緣由，不須要在客戶端再實現一遍，這也是經過API網關調用。

消息驅動應用
    一個不一樣的案例是後端數據處理服務，假設你正在編寫一個用戶中心的應用，須要快速響應 UI請求，可是其次你須要截獲全部發生活動類型，讓咱們看看一個在線系統：當用戶點擊一個廣告你要快速導向點擊到廣告目標網址，可是同時你須要收集剛剛發生的點擊事件與信息，這樣纔是對廣告主負責的作法。

    傳統架構以下，廣告服務器同步響應用戶，同時會發送一個消息給一個能夠異步處理的通道，稱爲「點擊處理器」，應用而後更新數據庫等等作其餘動做。

    而在Serverless架構下，會有多個「點擊處理器」做爲點擊事件的消費者，這些消費應用也是做爲FaaS功能運行在第三方提供的事件驅動上下文場景下的。注意，第三方提供消息系統Broker和FaaS環境，這兩個系統會彼此緊密聯繫在一塊兒。

    FaaS環境能夠並行處理幾個點擊事件，只要將函數代碼實例化多個便可。

解密「函數做爲服務」
爲了解密FaaS，咱們看看Amazon的Lambda產品：

    AWS Lambda讓你無需任何配置或管理服務器的代價下運行你的代碼： (1) Lambda能夠運行你的幾乎全部類型的應用或後端服務的代碼 (2) 由於零管理，只要上傳你的代碼和lambda會照顧運行等一切 (3) 並以高可用性擴展 (4) 你代碼的運行性能. 你能設置你的代碼自動從AWS服務觸發 (5) 或者直接從任何web或移動應用直接調用你的代碼 (6) (此處略去關於上述6點AWS詳細說明…………)

狀態
    在本地狀態方面FaaS功能有顯著的約束，你能假設任何函數的調用創造的狀態，不管是同一個進程或同一個主機內的狀態，都不適用於下次調用了，RAM中狀態須要寫到本地磁盤，也就是說，FaaS是無態的。

這對應用程序體系結構產生了巨大的影響。這意味着FaaS是天然地無態，提供純輸入的函數轉換，若是須要存儲狀態，使用數據庫或跨應用的緩存或網絡文件存儲等等，實現跨請求的狀態存儲，爲下一個請求訪問上個請求的狀態。

執行時間
    FaaS是典型限制每次長調用，AWS Lambda函數不容許調用超過5分鐘，超過就會中斷。

    這意味着長任務運行不適合PaaS，所以你可能須要從新架構：好比建立幾個不一樣的協調的FaaS函數，而在傳統環境中，你只須要一個這樣的任務，既作協調又作執行。

啓動延遲
    FaaS函數響應一個請求會有延遲，其延遲有多長取決於不少狀況，也許會從10ms到2分鐘，讓咱們使用AWS lambda做爲一個案例：

若是你的函數是使用Javascript或Python或少於一千行代碼，應該不會運行超過10-100ms，更大的函數也許偶爾會發生長時間運行的狀況。

若是你的Lambda函數使用JVM實現，偶爾會看到超過10秒的響應時間，只會在下面狀況發生：
    1.你的函數處理事件不頻繁，兩次調用之間長於10分鐘
    2.你在流量上有忽然峯涌，原來每秒處理10個請求忽然在10秒內上升到每秒100個請求。

    這些狀況能夠經過這個醜陋方式避免：每隔5分鐘ping一下函數的方式確認它是活着。

    也就是說， 延遲時間會依賴你的應用風格和流量狀況，曾經有一個團隊使用異步消息處理Lambda的Java應用實現天天處理幾百萬的消息，根本不關心啓動延遲，若是你編寫一個低延遲交易應用，可能就沒法使用FaaS系統，無論你使用什麼語言實現。

API網關(Gateway)
    它是一個HTTP服務器，經過配置實現路由和REST端點服務，每一個路由URI都和相應的FaaS函數對應，當API網關接收到一個請求，會經過路由配置匹配到哦相應的FaaS函數。也就是說，API網關是將FaaS函數調用結果轉化爲Http響應而後返回調用者。

    除了純粹的路由請求之外，API網關也能夠執行身份驗證，輸入驗證，響應代碼的映射等功能。

    咱們有一個API網關 + FaaS案例是以Serverless方式建立一個http前端的微服務，從而得到了FaaS函數的擴展性、可管理性和其餘好處。

開源
    由於Serverless的FaaS應用可以提供生產運行環節的質量要求，而開源項目好比Docker等容器則不屬於這個範疇，

Apex開源項目能提供易於構建 部署和管理AWS Lambda函數，能讓你用語言方式開發Lamda函數，而不是直接使用Amazon支持的Lambda。

與PaaS比較
    若是PaaS可以在20ms內啓動實例運行半秒，那麼能夠稱它爲serverless。

    PaaS並非將整個應用只爲每一個請求啓動使用的，而FaaS平臺剛好是這麼作的。

NoOps
    Serverless不意味着無運營"No Ops"，只是意味着沒有內部系統管理。

存儲過程做爲服務
    一些FaaS函數除了訪問數據庫的語句之外只有不多的代碼，所以這樣的FaaS函數也被稱爲存儲過程的服務。但也有些問題，好比會須要使用具體廠商的語言，難以測試和進行版本控制等時比較棘手。Mike Roberts對這些問題都進行了認真討論。

後記：

什麼是Serverless無服務器架構？

    Serverless不表明不再須要服務器了，而是說：開發者不再用過多考慮服務器的問題，計算資源做爲服務而不是服務器的概念出現。Serverless是一種構建和管理基於微服務架構的完整流程，容許你在服務部署級別而不是服務器部署級別來管理你的應用部署，你甚至能夠管理某個具體功能或端口的部署，這就能讓開發者快速迭代，更快速地開發軟件。

    以AWS Lambda爲案例，Lambda能讓不用思考任何服務器，也就是說，不用你處理服務器上的部署、服務器容量和服務器的擴展和失敗容錯，還有服務器上選擇什麼OS操做系統，語言的更新，日誌等等問題。你的應用程序只須要和多個第三方的API或服務打交道，也能夠自我建立一個無服務器的API。

Serverless有如下幾個特色：

    Serverless意味無維護，Serverless不表明徹底去除服務器，而是表明去除有關對服務器運行狀態的關心和擔憂，它們是否在工做，應用是否跑起來正常運行等等。Serverless表明的是你不要關心運營維護問題。有了Serverless，能夠幾乎無需Devops了。

    Serverless不表明某個具體技術，有些人會給他們的語言框架取名爲Serverless，Serverless其實去除維護的擔憂，若是你瞭解某個具體服務器技術固然有幫助，但不是必須的。

    Serverless中的服務或功能表明的只是微功能或微服務，Serverless是思惟方式的轉變，從過去：「構建一個框架運行在一臺服務器上，對多個事件進行響應。」變爲：「構建或使用一個微服務或微功能來響應一個事件。」，你可使用 django or node.js 和express等實現，可是serverless自己超越這些框架概念。框架變得也不那麼重要了。

    Serverless規模擴展性方面因爲充分利用雲計算的特色，所以其擴展是平滑的，同時因爲Serverless是基於微服務的，而一些微功能微服務的雲計算是零收費，這樣有助於下降總體運營費用。

++補充：

++Serverless表明着將來雲服務正在走向愈來愈分離關注點的趨勢，業務系統不直接與硬件、操做系統和通常容器打交道而是經過一個更高級的容器運行業務系統，業務系統會向容器的管理中心申請各類資源。部署和運維業務再也不過多關心具體硬件與其餘細節，而是關心自身業務與須要的各類資源調配的設置與應用。之後幾乎全部的部署與運維都是針對業務自己，因此之後感受不到服務器的這個具體的硬件實施的存在。這就是亞馬遜定義的「無服務器」架構。

Serverless的架構圖