近期靈雀云技術專家邵明岐翻譯了 Mike Roberts & John Chapin 所著的《What is Serverless》一書的部分內容，可以說是對 Serverless 科普與觀察的上佳素材。

在了解了何為 Serverless，各種服務組件之后，如何將服務組件組合成完整的應用程序？基于 Serverless 開發的應用架構什么樣子？與傳統非 Serverless 應用程序架構相比，Serverless 有哪些優勢？本文將回答這些問題。

假設有這么一個應用程序，它是一個支持多用戶的手機游戲，具有以下高級要求：

友好的移動端交互界面；

具備用戶管理和身份驗證；

有一些基本的業務邏輯，比如游戲排行榜，歷史記錄等。

我們暫時忽略游戲中可能會遇到的其他功能，畢竟我們的目的不是實際開發一個游戲，而是將 Serverless 程序架構與傳統的非 serverless 架構進行比較。

傳統非 Serverless 架構

根據上面的要求，傳統非 Serverless 架構看起來應該是這樣的：

Native Mobile App 是 iOS 或者安卓客戶端。

Java Application Server 是 Java 代碼編寫的應用邏輯，運行在 Tomcat 或者 JBoss 這類應用服務器里面。

數據存儲在關系型數據庫，比如 MySQL 里面。

在這個架構中，移動應用程序負責呈現游戲界面并處理來自用戶的輸入，但它將大多數實際邏輯刪除到后端，從代碼的角度來看，移動應用程序簡單輕便，它使用 HTTP 調用后端 Java 應用程序提供的不同 API。

用戶管理、身份驗證和各種游戲操作都使用 Java 應用程序代碼進行封裝， 后端應用程序還與單個關系數據庫交互，以便維護正在進行的游戲的狀態，并存儲已完成游戲的結果。

為什么要改變架構？

這個簡單的架構似乎符合我們的要求，那么為什么對它做改進呢？關鍵在于未來開發和運維方面帶來的一系列潛在的挑戰和陷阱。

在構建游戲時，需要具備 iOS 和 Java 開發方面的專業知識，以及配置，部署和操作 Java 應用程序服務器的專業知識，還需要配置和操作關系數據庫服務器。除了應用服務器和數據庫，也需要配置和運行各自的主機，無論這些系統是基于容器還是直接在虛擬或物理硬件上運行。我們還需要通過配置路由策略，訪問控制列表等，來確保系統組件之間以及用戶端和服務端之間的網絡連通性。

有了上面這些，我們仍然只是提供最基本的讓游戲可用的環境還沒有涉及安全性、可擴展性或高可用性，這些都是現代生產系統的關鍵方面。最重要的是，即使在簡單的體系結構中，也存在許多固有的復雜性，用來滿足現實世界各種各樣的需求。構建系統并不難，但是當我們修復錯誤，添加功能或嘗試快速構建新的創新想法時，所有這些復雜性將會變成強大的阻力。

如何改變？

現在已經發現了傳統架構的一些挑戰，如何改變它？讓我們看看如何能夠滿足高級需求，并使用 Serverless 架構模式和組件來解決傳統方法的一些挑戰。

在之前的文章已經說過了，Serverless 組件可以分為兩類，BaaS 和 FaaS。考慮到游戲的要求，其中一些可以通過 BaaS 組件解決，一些可以通過 FaaS 組件解決。

Serverless 架構

基于 Serverless 構建的游戲，架構看起來應該是下圖這個樣子的：

雖然用戶界面仍是移動應用程序的一部分，需要自己通過代碼來實現，但用戶身份驗證和管理可由 AWS Cognito 等 BaaS 服務處理，這些服務可以直接從移動應用程序調用，以處理注冊和身份驗證等面向用戶的功能，其他后端組件可以使用相同的 BaaS 來檢索用戶信息。

現在由 BaaS 處理用戶管理和身份驗證，后端 Java 應用程序的邏輯被簡化了， 可以使用另一個組件 AWS API Gateway，以安全、可擴展的方式來處理移動應用程序和后端游戲邏輯之間的 HTTP 請求。然后可以將每個不同功能的操作封裝在 FaaS 函數中。

這些后端 FaaS 功能可以與像 DynamoDB 這樣的 NoSQL 數據庫進行交互，以存儲游戲的狀態。實際上，一個重大變化是不再在服務器端應用程序代碼中存儲任何會話狀態，而是將所有會話狀態保存到 NoSQL 存儲中。雖然這可能看起來很麻煩，但它有助于擴展。

移動應用程序可以無縫訪問同一個數據庫，以檢索過去的結果和排行榜數據。這允許我們將一些業務邏輯移動到客戶端實現，而不是將其放到到后端實現。

Serverless 架構優勢

這種新的 Serverless 架構看起來很復雜，而且它比傳統架構需要更多的組件，但是，由于我們使用完全托管的 Serverless 組件，已經消滅了很多因為管理應用程序基礎設施和底層系統而帶來的挑戰。

我們編寫的代碼現在幾乎完全集中在游戲獨特的業務邏輯上，更重要的是，組件已經解耦和分離，因此，可以非常快速地將它們切換出來或添加新邏輯，而不會出現非無服務器架構中固有的阻力。

擴展，高可用性和安全性也有所提升，這意味著隨著我們的游戲越來越流行，不需要擔心購買功能更強大的服務器，也不需要擔心數據庫是否會崩潰，或者排查防火墻配置故障。

簡而言之，我們降低了制作游戲的人工成本，以及運行游戲的風險和計算成本，它的所有組成部分都將靈活擴展。當我們有一些新的想法，交付期會大大縮短，可以開始獲得反饋并更快迭代。

云計算的基礎設施外包帶來五大好處：降低人工成本、降低風險、降低基礎設施成本、擴展性、交付時間 。Serverless 同樣也有這五大優點， 前四個都或多或少是關于成本節約的，這就是 Serverless 更為人所知的：如何以更低的成本做以前做過的同樣的事情。但是，對我們來說，節省成本并不是無服務器最令人興奮的部分，較大的好處是，它減少了從新的想法到實施上線的時間，換句話說，它能夠讓你更快地創新。

降低人工成本

我們在之前說過，Serverless 本質上不再需要關心自己的服務器和進程 ，只需要關心應用程序的業務邏輯和狀態，所有其他不必要的工作都交給平臺來處理。這里的第一個明顯好處是運維工作量減少， 您不再管理操作系統，補丁級別，數據庫版本升級等。如果您正在使用 BaaS 數據庫，消息總線或對象存儲，那么祝賀你，這些基礎架構也都不要你來運維。

通過其他 BaaS 服務，對于節省人工成本是比較直觀的，自己開發的邏輯更少了。我們已經多次討論過身份驗證的 BaaS 服務，其中較大的好處是可以使用較少的代碼來定義開發、測試、部署和運營，所有這些都減少了工程師時間成本，另一個例子是像 Mailgun 這樣的第三方郵件 BaaS 服務，它消除了處理電子郵件發送和接收的大部分復雜工作。

與傳統方法相比，FaaS 還具有顯著的勞動力成本優勢。使用 FaaS 進行軟件開發得以簡化，因為大部分基礎架構代碼已移至平臺。這里的一個例子是 HTTP API 服務的開發，這里所有的 HTTP 級請求和響應處理都是由 API 網關完成的。

使用 FaaS 進行部署更容易，因為我們只是上傳打包成 Zip 格式 (如果是 JS 或者 Python 腳本語言) 的基本代碼，或者如果是 Java 的話，則上傳普通的 JAR 文件，沒有要管理的 Puppet，Chef，Ansible 或 Docker 配置。其他類型的操作活動也變得更加簡單，例如，由于不再關注“永遠在線”服務器進程，因此可以將監控限制為更多面向應用程序的指標。這些是統計信息，例如執行持續時間和面向客戶的指標，而不是可用磁盤空間或 CPU 使用率。

降低風險

當考慮軟件應用風險時，我們經常考慮對故障和宕機的敏感程度，我們的團隊負責管理的不同類型的系統或組件的數量越多，發生問題的風險就越大。我們可以不是自己管理這些系統，而是像之前描述的那樣，讓“外包”系統來解決這些問題。

雖然整體而言仍然面臨應用程序發生故障的風險，但我們選擇以不同的方式管理風險 -- 我們現在依靠其他人的專業知識來解決其中的一些故障，而不是自己修復它們。這通常來說是一個好主意，因為應用的技術棧中，一些技術是平時很少發生變更的，當它們發生故障時，修復時間和難度都不確定。通過 Serverless，我們可以顯著減少直接操作的技術棧數量，那些我們仍在自己管理的技術，通常是我們非常熟悉并且頻繁變更的，因此我們更有能力在失敗時自信地處理失敗。

例如，管理分布式 NoSQL 數據庫。一旦安裝了組件，節點發生中的故障可能相對罕見，但是當它發生故障時，會發生什么？您的團隊是否具備快速有效地診斷，修復和恢復問題的專業知識？常常沒有。相反，團隊可以選擇使用 Serverless 的 NoSQL 數據庫服務，例如 Amazon DynamoDB， 雖然 DynamoDB 中的中斷偶爾會發生，但由于亞馬遜擁有致力于此特定服務的整個團隊，因此它們發生故障的次數更少，并且能夠更快的恢復。

因此，我們說當使用 Serverless 技術時，風險會降低，因為組件的預期宕機時間會減少，并且修復它們的時間會更少。

降低資源投入成本

通常，當運行應用程序時，我們必須弄清楚它們將運行的底層主機類型和數量。例如，數據庫服務器需要多少內存和 CPU？需要多少個不同的實例來支持擴展？或者如何支持高可用性（HA）？

一旦規劃了我們需要的主機或資源，就可以分配應用程序的哪些部分將在哪些資源上運行。最后，一旦我們開始準備部署應用程序，就需要實際獲得我們想要的主機，這是環境配置。

整個環境配置過程很復雜，我們很少提前知道我們的資源要求是什么，因此高估了我們的計劃，這稱為過度配置，這實際上是正確的做法：擁有備用容量并保持應用程序運行比在負載下降低更好。對于某些類型的組件（如數據庫），可能很難在以后擴展，因此可能希望通過過度配置，來承載未來預期的負載。

過度供應意味著我們總是為滿足處理峰值預期負載所需的容量付費，即使我們的應用程序沒有遇到負載也是如此。最極端的情況是，我們的應用程序處于空閑狀態時，我們正在為服務器付費，而事實上它并沒有做任何有用的事情。但即使我們的應用程序處于活動狀態，我們也不希望主機得到充分利用。相反，我們希望留下一些空間，以應對意外的負載峰值。

無服務器給這個領域帶來的巨大好處是不需要計劃，分配或配置資源，讓服務較精確地提供我們在任何時間點所需的容量，如果我們沒有任何負載，那么不需要任何計算資源，也不會支付任何費用。如果我們只有 1 GB 的數據，我們不需要容量來存儲 100 GB。我們相信當需要時，服務將按需擴展，并且這同樣適用于 FaaS 和 BaaS 服務。

除了消除資源分配帶來的問題，無服務器還使成本更加高效。對于負載不一樣的各種應用程序，我們將通過使用無服務器來節省資源成本。例如，如果我們的應用程序每小時只運行 5 分鐘，我們只需支付每小時 5 分鐘，而不是整個 60 分鐘。此外，良好的無服務器產品將具有非常較精確的使用增量 ; 例如，AWS Lambda 按 100 毫秒的使用時間收費，比 EC2 的每小時計費較精確 36,000 倍。

在現代非 Serverless 應用程序中，我們通過自動伸縮等技術獲得了一些收益，但是，這些方法通常不如無服務器產品那么較精確，并且通常無法自動擴展數據庫。

提高擴展性

所有這些資源成本優勢都來自于這樣一個事實，即 Serverless 服務可以較精確地滿足我們的需求。那么如何才能真正實現這種擴展呢？我們需要設置自動縮放組嗎？監控流程？沒有！事實上，縮放是自動完成的，不費力氣。

以 AWS Lambda 為例。當平臺收到第一個觸發函數事件時，它會啟動一個容器來運行代碼，如果在收到另一個事件時仍在處理此事件，則平臺將啟動代碼的第二個實例以處理第二個事件。這種自動、零管理、水平擴展將持續到 Lambda 有足夠的代碼實例來處理負載。

一個特別好的方面是 AWS 仍然只會根據你代碼執行的時間收取費用，無論它有多少個容器要啟動。例如，假設所有事件的總執行時間相同，在一個容器中按順序調用 Lambda 100 的成本與在 100 個不同容器中同時調用 Lambda 100 次的成本完全相同。

減少交付周期

通過采用 Serverless 技術，可以帶來顯著的成本節剩

康卡斯特有線電視公司首席技術官 Sree Kotay 在 2016 年 8 月 AWS 峰會上說：他不是在談論 Serverless，他在談論康卡斯特如何從各種其他基礎設施外包中獲益匪淺，從“本地”轉向云計算：

經歷了云和敏捷的這一旅程，過去五年我們已經實現了收益，而且這些收益都是圍繞成本和規模進行的，它們是關鍵且重要的，但有趣的是它們并不是最引人注目的，最關鍵部分是這真的改變了你的創新周期，它從根本上改變了你對產品開發的看法。

——Sot Kotay

我們要提出的一點是，一家大公司的首席技術官說，成本和規模對他來說并不是最重要的，最重要的是創新。那么 Serverless 如何在這方面提供幫助呢？

Adrian Cockcroft（AWS 云架構戰略副總裁，Netflix 前云架構師）談到：

我們開始看到開發應用程序的時間越來越短，小型開發團隊在短短幾天內從頭開始構建生產就緒的應用程序。他們使用簡短的功能和事件將強大的 API 驅動的數據存儲和服務粘合在一起。已完成的應用程序已具有高可用性和可擴展性，高利用率，低成本和快速部署。

在過去幾年中，我們看到通過持續交付和自動化測試以及 Docker 等技術改進開發的增量周期時間取得了很大進展。這些技術很棒，但只有在設置和穩定后才能實現。對于真正蓬勃發展的創新而言，縮短周期時間是不夠的，您還需要更短的交付周期 -- 從新產品或功能的概念化到以最小的可行方式部署到生產環境的時間。

由于 Serverless 消除了在生產中大規模構建，部署和運行應用程序的大量附帶復雜性，因此它為我們提供了巨大的杠桿作用，以至于軟件交付方式可以顛倒過來。通過正確的組織支持，創新和“精益創業”風格，實驗可以成為所有企業的默認工作方式，而不僅僅是為初創公司或“黑客日”保留的東西。

這不僅僅是一種理論。除了 Adrian 的的觀點之外，我們看到相對缺乏經驗的工程師完成項目通常需要幾個月的時間，并需要更多資深工程師的幫助。相反，使用 Serverless，他們能夠在幾天內基本上無需幫助地實施項目。

這就是為什么對 Serverless 感到非常興奮：除了節省所有成本之外，還可以釋放他們的能力，讓他們專注于讓產品與眾不同的地方。

總結

以上是生活随笔為你收集整理的Serverless五大优势，成本和规模不是最重要的，这点才是架构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。