摘要：導讀近期靈雀云技術(shù)專家邵明岐翻譯了所著的一書的部分內(nèi)容，可以說是對科普與觀察的上佳素材。移動應用程序可以無縫訪問同一個數(shù)據(jù)庫，以檢索過去的結(jié)果和排行榜數(shù)據(jù)。這些是統(tǒng)計信息，例如執(zhí)行持續(xù)時間和面向客戶的指標，而不是可用磁盤空間或使用率。

導讀：近期靈雀云技術(shù)專家邵明岐翻譯了Mike Roberts & John Chapin所著的《What is Serverless》一書的部分內(nèi)容，可以說是對Serverless科普與觀察的上佳素材。
在了解了何為Serverless，各種服務組件之后，如何將服務組件組合成完整的應用程序？ 基于Serverless開發(fā)的應用架構(gòu)什么樣子？與傳統(tǒng)非Serverless應用程序架構(gòu)相比，Serverless有哪些優(yōu)勢？本文將回答這些問題。
原著：
《What is serverless : understand the latest advances in cloud and service-based architecture》
作者：Mike Roberts & John Chapin
譯文來源：深入淺出談架構(gòu)（ID：deep-easy-arch）
譯者：靈雀云邵明岐
假設有這么一個應用程序，它是一個支持多用戶的手機游戲，具有以下高級要求：
友好的移動端交互界面
具備用戶管理和身份驗證
有一些基本的業(yè)務邏輯，比如游戲排行榜，歷史記錄等
我們暫時忽略游戲中可能會遇到的其他功能，畢竟我們的目的不是實際開發(fā)一個游戲，而是將Serverless程序架構(gòu)與傳統(tǒng)的非serverless架構(gòu)進行比較。

傳統(tǒng)非Serverless架構(gòu)

根據(jù)上面的要求，傳統(tǒng)非Serverless架構(gòu)看起來應該是這樣的：

Native Mobile App 是iOS或者安卓客戶端。
Java Application Server是Java代碼編寫的應用邏輯，運行在Tomcat或者JBoss這類應用服務器里面。
數(shù)據(jù)存儲在關系型數(shù)據(jù)庫，比如Mysql里面。
在這個架構(gòu)中，移動應用程序負責呈現(xiàn)游戲界面并處理來自用戶的輸入，但它將大多數(shù)實際邏輯刪除到后端，從代碼的角度來看，移動應用程序簡單輕便，它使用HTTP調(diào)用后端Java應用程序提供的不同API。
用戶管理、身份驗證和各種游戲操作都使用Java應用程序代碼進行封裝， 后端應用程序還與單個關系數(shù)據(jù)庫交互，以便維護正在進行的游戲的狀態(tài)，并存儲已完成游戲的結(jié)果。

為什么要改變架構(gòu)？

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

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

有了上面這些，我們?nèi)匀恢皇翘峁┳罨镜淖層螒蚩捎玫沫h(huán)境還沒有涉及安全性、可擴展性或高可用性，這些都是現(xiàn)代生產(chǎn)系統(tǒng)的關鍵方面。 最重要的是，即使在簡單的體系結(jié)構(gòu)中，也存在許多固有的復雜性，用來滿足現(xiàn)實世界各種各樣的需求。 構(gòu)建系統(tǒng)并不難，但是當我們修復錯誤，添加功能或嘗試快速構(gòu)建新的創(chuàng)新想法時，所有這些復雜性將會變成強大的阻力。

如何改變？

現(xiàn)在已經(jīng)發(fā)現(xiàn)了傳統(tǒng)架構(gòu)的一些挑戰(zhàn)，如何改變它？ 讓我們看看如何能夠滿足高級需求，并使用Serverless架構(gòu)模式和組件來解決傳統(tǒng)方法的一些挑戰(zhàn)。
在之前的文章已經(jīng)說過了，Serverless組件可以分為兩類，BaaS和FaaS。 考慮到游戲的要求，其中一些可以通過BaaS組件解決，一些可以通過FaaS組件解決。

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

雖然用戶界面仍是移動應用程序的一部分，需要自己通過代碼來實現(xiàn)，但用戶身份驗證和管理可由AWS Cognito等BaaS服務處理，這些服務可以直接從移動應用程序調(diào)用，以處理注冊和身份驗證等面向用戶的功能，其他后端組件可以使用相同的BaaS來檢索用戶信息。
現(xiàn)在由BaaS處理用戶管理和身份驗證，后端Java應用程序的邏輯被簡化了， 可以使用另一個組件AWS API Gateway，以安全、可擴展的方式來處理移動應用程序和后端游戲邏輯之間的HTTP請求。 然后可以將每個不同功能的操作封裝在FaaS函數(shù)中。

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

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

Serverless架構(gòu)優(yōu)勢

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

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

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

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

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

降低人工成本

我們在之前說過，Serverless本質(zhì)上不再需要關心自己的服務器和進程 ，只需要關心應用程序的業(yè)務邏輯和狀態(tài)，所有其他不必要的工作都交給平臺來處理。這里的第一個明顯好處是運維工作量減少， 您不再管理操作系統(tǒng)，補丁級別，數(shù)據(jù)庫版本升級等。如果您正在使用BaaS數(shù)據(jù)庫，消息總線或?qū)ο蟠鎯Γ敲醋ＹR你，這些基礎架構(gòu)也都不要你來運維。

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

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

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

降低風險

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

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

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

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

降低資源投入成本

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

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

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

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

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

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

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

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

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

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

減少交付周期
通過采用Serverless技術(shù)，可以帶來顯著的成本節(jié)省。
康卡斯特有線電視公司首席技術(shù)官Sree Kotay在2016年8月AWS峰會上說：他不是在談論Serverless，他在談論康卡斯特如何從各種其他基礎設施外包中獲益匪淺，從“本地”轉(zhuǎn)向云計算：

經(jīng)歷了云和敏捷的這一旅程，過去五年我們已經(jīng)實現(xiàn)了收益，而且這些收益都是圍繞成本和規(guī)模進行的，它們是關鍵且重要的，但有趣的是它們并不是最引人注目的，最關鍵部分是這真的改變了你的創(chuàng)新周期，它從根本上改變了你對產(chǎn)品開發(fā)的看法。
Sot Kotay
復制代碼我們要提出的一點是，一家大公司的首席技術(shù)官說，成本和規(guī)模對他來說并不是最重要的，最重要的是創(chuàng)新。 那么Serverless如何在這方面提供幫助呢？
Adrian Cockcroft（AWS云架構(gòu)戰(zhàn)略副總裁，Netflix前云架構(gòu)師）談到：

我們開始看到開發(fā)應用程序的時間越來越短，小型開發(fā)團隊在短短幾天內(nèi)從頭開始構(gòu)建生產(chǎn)就緒的應用程序。 他們使用簡短的功能和事件將強大的API驅(qū)動的數(shù)據(jù)存儲和服務粘合在一起。 已完成的應用程序已具有高可用性和可擴展性，高利用率，低成本和快速部署。
-Adrian Cockcroft

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

由于Serverless消除了在生產(chǎn)中大規(guī)模構(gòu)建，部署和運行應用程序的大量附帶復雜性，因此它為我們提供了巨大的杠桿作用，以至于軟件交付方式可以顛倒過來。通過正確的組織支持，創(chuàng)新和“精益創(chuàng)業(yè)”風格，實驗可以成為所有企業(yè)的默認工作方式，而不僅僅是為初創(chuàng)公司或“黑客日”保留的東西。
這不僅僅是一種理論。 除了Adrian的的觀點之外，我們看到相對缺乏經(jīng)驗的工程師完成項目通常需要幾個月的時間，并需要更多資深工程師的幫助。 相反，使用Serverless，他們能夠在幾天內(nèi)基本上無需幫助地實施項目。

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