所謂Serverless，你理解對了嗎？

隨着DevOps和微服務的理念日漸被IT業界所接受，另外一個新名詞Serverless也 開始進入人們的視野。尤爲在今年4月份國內兩大雲服務廠商阿里雲、騰訊雲前後推出各自的Serverless產品以後，Serverless一時洛陽紙貴。那到底什麼是Serverless，它跟DevOps和微服務又有什麼樣的聯繫呢？本文將嘗試揭開Serverless的神祕面紗，讓你一睹爲快。

1 Serverless != No Server

首先，必須澄清的是Serverless並不能按字面上理解爲無服務器，而是說對應用開發者而言，再也不須要操心大部分跟服務器相關的事務，好比服務器選購、應用運行環境配置、負載均衡、日誌蒐集、系統監控等，這些事情通通交給Serverless平臺便可，應用開發者惟一須要作的就是編寫應用代碼，實現業務邏輯。爲了不歧義，本文將保留使用Serverless，而不是其一般的中文翻譯無服務器。

Serverless最先由Amazon提出，第一個Serverless平臺是2014年年末推出的Amazon Lambda，應用開發者只須要上傳代碼或者應用包，便可發佈一個應用。以後全球各大雲服務廠商都紛紛推出各自的Serverless平臺，好比Google Cloud Functions，Azure Functions，IBM Cloud Functions，以及前面提到的阿里雲函數計算和騰訊雲無服務器雲函數等。在雲服務廠商以外，開源社區也涌現出不少優秀的Serverless框架，好比Apache OpenWhisk，Spring Cloud Function，Lambada Framework，webtask等。

根據Serverless Architectures一文，Serverless應用能夠細分爲BaaS和FaaS兩類，

• BaaS: Backend as a Service，這裏的Backend能夠指代任何第三方提供的應用和服務，好比提供雲數據庫服務的Firebase和Parse，提供統一用戶身份驗證服務的Auth0和Amazon Cognito等。
• FaaS: Functions as a Service，應用以函數的形式存在，並由第三方雲平臺託管運行，好比以前提到的Amazon Lambda，Google Cloud Functions等。

本文主要討論的是FaaS，這也是目前各種Serverless平臺和框架主要支持的類型。

2 函數即應用

當咱們討論函數時，咱們到底在討論什麼？

函數，往大了說能夠是一個應用的main函數，往小了說也能夠是一個簡單的加法函數，那到底該如何理解FaaS中的函數呢？先來看張圖。

左側的Monolith即咱們常說的單體應用，中間是微服務，右側就是FaaS中的函數（爲了不歧義，如不特殊指明，下文提到的函數都是指代FaaS中的函數）。如同一個單體應用能夠按業務模塊拆分紅多個微服務，一個微服務也能夠按使用場景拆分紅多個函數。好比一個廣告微服務，至少能夠拆分出實時競價、展現計數、報表查詢等多個函數。也就是說，FaaS中的函數和微服務中的API是同一粒度的。但不一樣於API，在Serverless架構下，每一個函數都是獨立部署，按需執行。那這樣的拆分有意義嗎？接着往下看。

3 搞懂Serverless的4把鑰匙

和其餘架構相比，Serverless有如下4個特色。

3.1 運行成本更低

不管是過去的IDC，仍是現在的雲主機，本質上都是一種包月計費模式，也就是說，無論有沒有用戶訪問你的應用，也無論你有沒有部署應用，你都要付相同的錢。但對於Serverless應用，你只須要根據實際使用的資源量（好比Amazon Lambda是按內存大小*計算時間計算資源量）進行付費，也即用多少，付多少，至關於移動網絡的按流量計費模式。那爲何說使用這種模式就能下降運行成本呢？

紅線如下的長方形面積表明了傳統包月計費模式下你所須要支付的成本，而藍色區域的面積則表明了按流量計費模式下的成本，顯而後者要遠低於前者。根據福布斯2015年發佈的一份研究報告，從整年來看，一個典型的數據中內心的服務器平均資源使用率只有可憐的5%到15%，也就是說若是所有使用Serverless，理論上至少能夠節省80%的運行成本。

按流量計費的另外一個隱藏的好處是任何的性能提高均可以直接的反應到運行成本上，這讓技術人員的價值也有了更充分的體現。

3.2 自動擴縮容

Serverless第二個常被說起的特色是自動擴縮容。前面說了函數即應用，一個函數只作一件事，能夠獨立的進行擴縮容，而不用擔憂影響其餘函數，而且因爲粒度更小，擴縮容速度也更快。而對於單體應用和微服務，藉助於各類容器編排技術，雖然也能實現自動擴縮容，但因爲粒度關係，相比函數，始終會存在必定的資源浪費。好比一個微服務提供兩個API，其中一個API須要進行擴容，而另外一個並不須要，那麼這時候擴容，對於不須要的API就是一種浪費。

3.3 事件驅動

函數本質上實現的是一種IPO（Input-Process-Output）模型，它是短暫的，是即用即走的。這點是函數區別於單體應用和微服務的另外一個特徵。不論是單體應用，仍是微服務，都是系統中的常駐進程，套用一句流行語，就是你來或不來，我都在這裏，不捨不棄。而函數不同，既不發佈任何服務，沒有請求時也不消耗任何資源，只有當請求來了，纔會消耗資源進行響應，服務完馬上釋放資源。正是因爲這一點，函數自然的適用於任何事件驅動的業務場景，好比廣告競價，身份驗證，定時任務，以及一些新興的IoT應用。

OpenWhisk給出的一個IoT電冰箱的案例

3.4 無狀態性

函數的IPO本質決定了函數的另外一個特徵，無狀態性。無狀態一方面有助於提升函數的可重用性和可遷移性，但另外一方面也帶來了一些性能上的損失。第一，函數不是常駐進程，這就意味着每來一個請求，函數都要經歷一次冷啓動，這對編譯型語言編寫的應用不啻爲一場噩夢（以Spring Boot爲例，即使是一個最簡單的Hello World應用，至少也須要5秒鐘才能啓動完畢）。第二，每服務完一個請求，函數所在的進程就會被殺掉，也就是說使用內存進行緩存對函數而言再也不有意義。第三，因爲每次啓動均可能被調度到新的服務器上，任何基於本地磁盤的緩存技術也就再也不適用。從第二點和第三點可知，函數只能使用外存（好比Redis，數據庫）進行緩存，而操做外存都須要經過網絡，性能跟內存、本地硬盤相比差了一到兩個數量級。

4 DevOps => NoOps

若是說Agile+IaaS促成了DevOps，那麼Agile+PaaS就孕育了Serverless。

理解了什麼是Serverless，再來看看它和DevOps的關係。DevOps雖然作了不少Dev的事，但底牌仍是Ops（比如貓熊雖然長得像貓，但實際上仍是熊）。但Serverless不一樣，從本質上說，它是把Ops外包給第三方平臺，讓Dev專一於業務邏輯的實現而不用操心Ops相關的工做，最終的結果就是絕大多數企業再也不須要Ops這個崗位。它和DevOps最大的共同點就是幫助企業縮短產品上市的時間。

5 小結

以上就是我對Serverless的一些簡單介紹，歡迎你到個人留言板分享，和你們一塊兒過過招。下一篇我會手把手教你們如何在Amazon Lambda部署一個基於Spring Cloud Function的Serverless應用，敬請期待。

6 參考

• Serverless Architectures
• What makes serverless architectures so attractive?
• InfoQ虛擬研討會：無服務器計算的實踐方法
• Serverless雲函數架構精解
• 姍姍來遲的Serverless如何助力微服務和DevOps