隨著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應用，敬請期待。