作者 | Emac

杏仁醫生架構師兼平臺組負責人，關注為服務、DevOps領域。

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

1 Serverless != No Server

首先，必須澄清的是 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 Architectures (https://martinfowler.com/articles/serverless.html)

• What makes serverless architectures so attractive? (https://developer.ibm.com/opentech/2016/09/06/what-makes-serverless-attractive/)

• InfoQ虛擬研討會：無伺服器計算的實踐方法 (http://www.infoq.com/cn/articles/practical-serverless-computing?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=架構%20&%20設計-articles)

• 姍姍來遲的Serverless如何助力微服務和DevOps (http://www.infoq.com/cn/news/2017/06/tengxun-cloud-serverless?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=DevOps)

 全文完

以下文章您可能也會感興趣：

我們正在招聘 Java 工程師，歡迎有興趣的同學投遞簡歷到 [email protected] 。

杏仁技術站

長按左側二維碼關注我們，這裡有一群熱血青年期待著與您相會。