Serverless五大優點，成本和規模不是最重要的，這點纔是

導讀：近期靈雀雲技術專家邵明岐翻譯了Mike Roberts & John Chapin所著的《What is Serverless》一書的部份內容，能夠說是對Serverless科普與觀察的上佳素材。
在瞭解了何爲Serverless，各類服務組件以後，如何將服務組件組合成完整的應用程序？ 基於Serverless開發的應用架構什麼樣子？與傳統非Serverless應用程序架構相比，Serverless有哪些優點？本文將回答這些問題。
原著：
《What is serverless : understand the latest advances in cloud and service-based architecture》
做者：Mike Roberts & John Chapin
譯文來源：深刻淺出談架構（ID：deep-easy-arch）
譯者：靈雀雲邵明岐
假設有這麼一個應用程序，它是一個支持多用戶的手機遊戲，具備如下高級要求：
友好的移動端交互界面
具有用戶管理和身份驗證
有一些基本的業務邏輯，好比遊戲排行榜，歷史記錄等
咱們暫時忽略遊戲中可能會遇到的其餘功能，畢竟咱們的目的不是實際開發一個遊戲，而是將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驅動的數據存儲和服務粘合在一塊兒。 已完成的應用程序已具備高可用性和可擴展性，高利用率，低成本和快速部署。
-Adrian Cockcroft

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

因爲Serverless消除了在生產中大規模構建，部署和運行應用程序的大量附帶複雜性，所以它爲咱們提供了巨大的槓桿做用，以致於軟件交付方式能夠顛倒過來。經過正確的組織支持，創新和「精益創業」風格，實驗能夠成爲全部企業的默認工做方式，而不只僅是爲初創公司或「黑客日」保留的東西。
這不只僅是一種理論。 除了Adrian的的觀點以外，咱們看到相對缺少經驗的工程師完成項目一般須要幾個月的時間，並須要更多資深工程師的幫助。 相反，使用Serverless，他們可以在幾天內基本上無需幫助地實施項目。

這就是爲何對Serverless感到很是興奮：除了節省全部成本以外，還能夠釋放他們的能力，讓他們專一於讓產品不同凡響的地方。