簡介

不知道什麼時候，出現了一個叫做 Serverless 架構的模式，看這個英語單詞 Serverless，也就是沒有服務的意思。沒有服務怎麼搭建應用程序呢？

後來仔細研究了一下，發現 Serverless 並不是說不需要服務，而是將服務搭建在 BaaS 或者 FaaS 平臺上的。通常適用於單頁應用程序或者業務邏輯並不負責的程序。

很明顯這個 serverless 架構是雲廠商想出來的，目的就是要讓你用他們的服務。這個跟最近比較流行的 cloud native 有異曲同工之妙。

此類架構雖然消除了對傳統架構中搭建服務的需求，可能會受益於顯着降低的運營成本、複雜性和工程交付時間，但代價是增加對供應商的依賴和相對不成熟的支持服務。

本文將會詳細討論一下 serverless 和它背後的故事。

什麼是 serverless

serverless 的概念毫無疑問是雲廠商提出來的，諸如微軟，谷歌，亞馬遜都是 serverless 的推崇者，並且在他們提供的服務中進行深度綁定和推薦。

那麼什麼是 serverless 呢？

serverless 其實可以描述兩種狀態。第一種狀態就是那些富客戶端，對於富客戶端來說業務邏輯都可以在客戶端完成，在雲端只需要用到數據庫服務或者身份驗證服務即可，這些類型的服務被稱爲 BaaS。

還有一種就是服務器端邏輯仍由應用程序開發人員編寫，但與傳統架構不同，它運行在無狀態計算容器中，這些容器是事件觸發的、短暫的（可能只持續一次調用），並完全由第三方來調用。這種服務被稱爲功能即服務或 FaaS。最有名的就是現在比較火的雲上的 Lambda 服務了。

serverless 的例子

簡單的三層服務

接下來我們來舉幾個具體可以使用到 serverless 的例子，方便大家的理解。

考慮一個最最常見的 web 項目，提供了增刪改查的功能。很明顯，我們需要一個客戶端，一個服務器端和一個數據庫，如下圖所示：

上圖是一個最簡單的服務的例子，我們有一個客戶端用來展示對應的 UI 界面，一般來說這個客戶端就是瀏覽器。還有一個服務端用來接收所有的客戶端請求和業務邏輯處理。最後有一個數據庫用來存儲對應的數據。

如果將上面的服務轉換成爲 serverless 架構，該如何修改呢？

在 serverless 架構中，服務端沒有了，轉而被各種 FaaS 所替代。然後客戶端的功能會被增強，變成富客戶端，大部分的業務邏輯都會在客戶端進行，甚至在某些情況下可以直接從客戶端讀取數據庫。

必須使用到 FaaS 服務的業務邏輯需要被拆分，如下圖所示：

上圖中，我們使用了第三方的雲認證服務來進行安全認證。同時對於不重要的數據可以直接授權客戶端進行數據庫的查詢。

對於更新服務，還是需要藉助於 FaaS 提供的更新 API 來對數據庫進行更新。

可以看到，Serverless 的架構已經和原來的架構完全不同了。帶來的好處就是系統變得更加靈活，並且對功能重新做了劃分，減少了服務端的業務邏輯，有點分佈式的效果，對應的服務器成本更低。

缺點就是原來的一個服務被拆分成爲了多個服務，需要對多個服務進行監控，然後基本上所有的數據都存放在雲端，那麼對服務提供商的安全能力提出了更高的要求。最後，這種靈活性和成本的減少會帶來系統的複雜性，增加了維護的難度。

消息驅動

一個常見的消息驅動的例子就是前端的點擊流上報。當用戶在客戶端點擊某個按鈕之後，會去調用服務端的某個接口。這個接口會將點擊消息發送到消息隊列中，然後再啓用異步的後端服務從消息隊列中拿取消息，最後更新數據庫。

那麼上面的例子如果用 Serverless 該怎麼實現呢？

我們需要將服務端替換成 FaaS，並且將異步服務也替換成對應的 FaaS：

這裏的好處是可以藉助 FaaS 的快速拓展功能，在消息數量比較多的情況下，可以動態擴展消息處理函數，從而提升系統的處理速度。

FaaS

上面我們提到了很多次 FaaS，那麼 FaaS 到底是什麼呢？

按照它的英文原意，FaaS 就是函數作爲服務。或者你可以看做是亞馬遜的 AWS Lambda 服務。

AWS Lambda 可以不需要任何服務器就可以運行，只需要上傳你的業務代碼，就可以自動生成一個 Lambda 服務。然後這個服務就可以供外部調用。

當然，這裏的不需要服務器是指客戶不需要自己購買服務器和在上面搭建服務，事實上 lambda 也是需要在服務器上運行的。

FaaS 基本上可以兼容 Javascript、Python、Go 和任何 jvm 語言編寫的代碼，只需要做少許更改即可重新生成爲 FaaS 服務。

FaaS 的另外一個優點就是可以水平擴展，並且這個水平擴展是完全自動的。這個水平擴展自動管理是由運營商來控制的，用戶不需要考慮到實現的底層細節。這種水平擴展能力對於服務在某個時刻的峯值應用是非常有效的。

我們只需要設計好 FaaS 函數，剩下的一切都交給雲廠商去做即可。

FaaS 的缺點

FaaS 是無狀態的，也就是說你不能夠使用本地內存變量或者本地磁盤的數據，因爲 FaaS 不能保證這些數據的有效性和持久性。

所以需要對要存儲的數據進行外部持久化。

另外，由於雲服務器的限制，每次 FaaS 的調用都有一個最長超時時間，所以 FaaS 只適合那些能夠快速響應的程序。

另外，FaaS 在啓動的時候可能需要初始化，這種函數的實例化可能會帶來請求的延遲。所以需要考慮雲提供商的啓動策略，並作出相應的調整。

當我們決定使用任何外包策略時，您都將部分系統的控制權交給第三方供應商。這種缺乏控制可能表現爲系統停機、意外限制、成本變化、功能丟失、強制 API 升級等。

• 多租戶問題

多租戶是指多個不同客戶（或租戶）的多個軟件實例在同一臺機器上運行的情況，並且可能在同一託管應用程序中運行。這是一種雲服務商實現規模經濟效益的策略。服務供應商盡最大努力讓客戶覺得他們每個人都是唯一使用他們系統的人，但是，沒有一個完美的方案能夠同時解決多租戶的安全性（一個客戶能夠看到另一個客戶的數據）、健壯性（一個客戶的軟件中的錯誤導致另一個客戶的軟件出現故障）和性能（一個高負載的客戶）等方面的問題。

• 供應商綁定

如果你在一個服務商使用了 serverless, 那麼將其切換到另外一個供應商的成本是巨大的。可能需要更新對應的運營工具，還可能需要更新代碼。

FaaS 的優點

我們可以把 Serverless 看做是最簡單的外包解決方案，你不需要自己管理服務器和數據庫，這些都可以託管給雲廠商。

一方面，基礎設施服務的投入變少了，另外一方面，可以節約維護這些基礎設施的人力成本。

另外，您對代碼進行的任何性能優化不僅會提高應用程序的速度，而且它們將與降低運營成本有直接或者間接的聯繫，具體取決於服務供應商的收費方案。例如，假設一個應用程序最初需要一秒鐘來處理一個事件。如果通過代碼優化將這一時間減少到 200 毫秒，將立即看到計算成本節省 80%，而無需進行任何基礎架構更改。

與部署整個服務器相比，打包和部署 FaaS 功能很簡單。您所做的就是將所有代碼打包成一個 zip 文件，然後上傳。

總結

serverless 架構是目前比較熱門的一種架構方式，我們可以去嘗試使用這種新的架構方式，來看看能否給我們的業務帶來不同的變化。但是也需要看到並不是所有的服務都可以使用 serverless 架構。我們需要對其進行權衡。

本文已收錄於 http://www.flydean.com/11-serverless-architecture/

最通俗的解讀，最深刻的乾貨，最簡潔的教程，衆多你不知道的小技巧等你來發現！

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/pTGZCu8yp71nTh3PvvhHoQ