所謂 Serverless，你理解對了嗎？
作者 Emac
杏仁醫生架構師兼平台組負責人，關注為服務、DevOps領域。
隨著 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，這也是目前各類 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)
全文完
杏仁技術站
TAG:杏仁技術 |