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