架構之:serverless架構

簡介

不知道什麼時候，出現了一個叫做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/ 最通俗的解讀，最深刻的幹貨，最簡潔的教程，衆多你不知道的小技巧等你來發現！