無服務器架構(Faas/Serverless)

摘要
無服務器架構(Faas/Serverless)，是軟件架構領域的熱門話題。 AWS，Google Cloud和Azure - 在無服務器上投入了大量資金，已經在看到了大量專門針對Faas/Serverless的文章、書籍，開源項目，會議。 但什麼是無服務器，爲何（或不是）值得考慮？ 文章參考文末連接不少，網上也能找到文章粗糙的翻譯（也許由於文章實在太長了吧）原文中有些內容也不是很新，結合一些我的理解，但願可以對這些問題進行一些啓發討論。

1. What is Serverless?
無服務器架構是一種包含第三方「後端即服務」（BaaS）服務的應用程序設計方式，和/或包括（FaaS）平臺上的託管臨時容器中運行的自定義代碼。 此類體系結構消除了對傳統的始終在線服務器的大部分需求。 這能夠顯着下降的運維成本，複雜性以及減小項目的上線準備時間，代價是增長了對供應商依賴性和相對不成熟支持服務的依賴。

首先，沒有人清楚地知道無服務器是什麼。它包含兩個不一樣可是有關聯的領域：

無服務器能夠描述一個」富客戶端 + 第三方雲託管應用程序和服務的」的應用程序。這些「富客戶端」應用程序通常是移動應用程序，使用龐大的雲端數據庫或SSO服務（Auth0，AWS Cognito等）。這些類型的服務之前被描述爲「後端即服務」。

無服務器也能夠指服務器端邏輯仍然由應用程序開發人員編寫，可是與傳統體系結構不一樣，它運行在無狀態計算容器中，這些容器是事件觸發的短暫的（可能只持續一次調用，或Deployment會保留，根據運行負載自動調節運行實例數量），而且徹底由第三方管理（也許就是」FaaS」此名稱的來源 ）AWS Lambda是目前Faas平臺最受歡迎的實現之一，比國內的雲服務商便宜不少，看好亞馬遜市值最早破萬億（Apple may 打臉）。

在本文中，顯然咱們將重點關注後者，FaaS/Serverless。

2. 幾個引伸的例子
讓咱們考慮一個帶有服務器端邏輯的傳統的三層面向客戶端的系統。一個很好的例子是一個典型的電子商務應用程序 - 在線寵物商店。
架構像這樣：

 

在這個架構裏，客戶端能夠相對不用那麼智能，絕大多數的邏輯在服務端完成，受權，頁面導航，查詢，交易等等。
在無服務架構裏，看起來會是這個樣子：

 

兩者對比中，咱們能夠看到一系列明顯的變化：

咱們去掉了原始應用程序中的身份驗證邏輯，並將其替換爲第三方BaaS服務（例如，Auth0）

咱們容許客戶端直接訪問咱們的數據庫（用於產品列表），該數據庫自己徹底由第三方（例如Google Firebase）託管。咱們可能採用和服務器資源訪問數據庫不一樣的安全配置文件讓客戶端去訪問數據庫。

前兩點意味着很是重要的第三點：寵物商店服務器中的一些邏輯如今位於客戶端內 - 例如，跟蹤用戶會話，理解應用程序的UX結構，從數據庫讀取並將其轉換爲一個可用的視圖等客戶端正在成爲單頁應用程序。

咱們可能但願在服務器中保留一些與UX相關的功能，例如，若是它是計算密集型或須要訪問大量數據。在咱們的寵物商店中，一個例子是「搜索」。而不是像原始體系結構中那樣擁有一個始終運行的服務器，咱們能夠實現一個FaaS功能，經過API網關響應HTTP請求。客戶端和服務器「搜索」功能都從同一數據庫中讀取產品數據。

最後，咱們能夠把購買的實現替換成另外一個獨立的Faas函數，安全的緣由吧，這也是由API網關給引入的。在使用FAAS時，把不一樣的邏輯要求，拆分紅獨立的部署組件是一種很常見的方法。

3. 「Faas」的面紗
如今是時候深刻了解FAAS的真正含義。爲此，咱們來看看亞馬遜FaaS產品的開頭描述：Lambda。

AWS Lambda容許您在不配置或管理服務器的狀況下運行代碼。 （1）使用Lambda，您能夠運行幾乎任何類型的應用程序或後端服務的代碼（2）全部這些都是零管理。只需上傳代碼，Lambda就會負責運行所需的一切（3）以高可用性擴展實例。（4）能夠設置代碼以自動從其餘AWS服務觸發（5）或直接從任何Web或移動應用程序調用它。

詳細說來：

從FaaS是運行後端代碼而無需管理本身的服務器系統或應用程序。與容器和PaaS等其餘現代架構趨勢相比，是否存在長期存在的服務器和應用程序是一個關鍵的區別。
FaaS產品不須要對特定框架或庫進行編碼。 FaaS功能是語言和環境的常規應用程序。例如，AWS Lambda函數能夠把Javascript，Python，Go，任何JVM語言（Java，Clojure，Scala等）或任何.NET語言視爲「一等公民」。不過Lambda函數還能夠與其部署包一塊兒執行在另外一個進程，所以實際上可使用任何能夠編譯爲Unix進程的語言。FaaS函數具備重要的體系結構限制，特別是在涉及狀態和執行持續時間時。
部署與傳統系統有很大不一樣，由於咱們沒有本身運行的服務器應用程序。在FaaS環境中，咱們將功能的代碼上傳到FaaS提供商，提供商執行配置資源，實例VM（Container），管理流程等所需的一切。
水平縮放徹底是自動的，彈性的，並由Faas管理。若是系統須要並行處理100個請求，則Faas將處理該請求而無需你進行任何額外配置。執行函數的容器是臨時的，FaaS建立和銷燬它們，徹底由運行時決定。最重要的是使用FaaS，雲廠商能夠處理全部底層資源配置和分配，而用戶根本不須要集羣或VM管理。
FaaS中的函數一般由提供程序定義的事件類型觸發。使用AWS，此類事件包括S3（文件/對象）更新，時間（定時任務）以及消息總線的消息。
大多數Faas運營商還容許HTTP請求觸發函數，在AWS中，一般經過使用API​​網關來實現這一點。咱們在寵物商店示例中使用API​​網關進行「搜索」和「購買」功能。函數也能夠經過平臺提供的API直接調用，不管是在外部仍是在同一個雲環境中，但這是一種相對不常見的用法。
4. Faas須要關注的特色
有無狀態

FaaS函數在本地（VM/容器實例）狀態（即存儲在內存中的變量中的數據或寫入本地磁盤的數據）中具備很大的限制。通常狀況下你確實能夠這樣存儲，可是不能保證這種狀態在多個調用中保持不變，更重要的是，你原本就不該該假設一次調用函數的狀態可用於同一函數的另外一次調用。所以，FaaS函數一般被描述爲無狀態，或者更準確地說，須要持久化的FaaS函數的任何狀態都須要在FaaS函數實例以外進行。
對於天然無狀態的FaaS函數 - 即那些提供輸入到輸出的純功能轉換的函數 - 這是可有可無的。但對於有狀態的而言，這可能會比較麻煩，之前分佈式的那些限制如今徹底相同。這種面向狀態的函數一般將使用數據庫，緩存（如Redis）或網絡文件/對象存儲（如S3）來跨請求存儲狀態。

執行時長

FaaS函數一般受限於容許每次調用運行多長時間。目前，AWS Lambda函數響應事件的「超時」最多爲五分鐘，而後纔會終止。 Microsoft Azure和Google Cloud Functions具備相似的限制。這意味着某些類別的長期任務不適合FaaS - 除非你從新設計架構，須要建立幾個不一樣的協調FaaS函數，而在傳統環境中，您可能有一個長期任務執行協調和執行。

啓動延遲和「冷啓動」

FaaS平臺在每一個事件以前初始化函數實例須要一些時間。不一樣的函數，他的啓動延遲也可能顯着變化，從幾毫秒到幾秒的都有可能，取決於許多因素，具體一點以AWS Lambda爲例。

Lambda函數的初始化便可以是「熱啓動」（使用Lambda函數的以前之前產生的容器），也能夠是「冷啓動」（建立新容器實例），冷啓動帶來的延遲應該引發了咱們的關注。

冷啓動的延遲取決於許多因素：開發語言，使用的庫，代碼量，Lambda函數環境自己的配置，是否須要鏈接到VPC資源等等。這些方面受開發人員的控制，經過這些地方的優化能夠減小冷啓動的一部分啓動延遲。

可調的還有冷啓動的啓動頻率。例如若是一個函數每秒處理10個事件，每一個事件須要50毫秒來處理，那麼每隔100,000-200,000個事件，您可能會看到一個實例的冷啓動。另外一方面，若是每小時處理一次事件，你可能會看到每一個事件來時的冷啓動，由於Amazon會在幾分鐘後退出非活動的Lambda實例。知道這一點有助於瞭解冷啓動是否會影響集成效果，以及是否可能但願對函數實例執行「保持活動」以免它們被回收。

冷啓動須要太關注嗎？這取決於應用程序的負載或流量的狀況。若是你須要的是低延遲交易應用程序，那麼最好忘掉FaaS系統吧，不管你使用哪種編程語言。

不管你是否定爲你的應用是否存在此類問題，你最好用相似生產的負載來測試性能。若是此時此刻比較爛，不要着急，FaaS供應商正在持續改進，說不定年末就知足你的要求了。

API網關

API網關是一個HTTP服務器，其中路由和負載點定義在配置中，而且每一個路由與處理該路由的函數關聯。當API網關收到請求後，它會找到與請求匹配的路由配置，來調用相關的FaaS函數。API網關容許從HTTP請求參數映射到FaaS函數的更簡潔的輸入，或者讓HTTP請求原封不動得經過，FaaS函數將執行其邏輯並將結果返回給API網關，而API網關又將此結果轉換爲HTTP響應，並將其傳遞迴原始調用方。

 

工具
關於工具成熟度的評論也適用於FaaS。 到今年（2018年），咱們已經看到了明顯的改善，咱們但願工具可以更好地發展。

FaaS世界中一些「開發者用戶體驗」好的例子值得一提。 首先是Auth0 Webtask，它很是重視開發人員用戶體驗。 其次是Microsoft，其Azure功能產品。 Microsoft一直將Visual Studio及其反饋循環置於其開發人員產品的最前沿，而Azure Functions也不例外。 在雲觸發事件的輸入下，它提供的在本地調試功能的能力很是特殊。

開源勢力

無服務器中開源的最多見用途是FaaS工具和框架，它提供了一些跨雲提供商的工具抽象，相似工具的例子包括Claudia和Zappa。另外一個例子是Apex，它容許你使用亞馬遜直接支持的語言以外的語言開發Lambda函數。不過AWS本身的部署工具SAM（無服務器應用程序模型）也是開源的。

專有FaaS的主要好處之一是沒必要關心底層計算基礎架構（機器，虛擬機，容器）。可是若是你想關注這些事情呢？也許你有一些雲供應商沒法知足的安全需求，或者你有一些你已經購買但不想丟棄的服務器機架。在這些場景中能夠開源幫助，容許運行本身的「Serverful」FaaS平臺，這個領域有不少活動。開源FaaS的最初領導者之一是IBM（使用OpenWhisk，如今是一個Apache項目）。Microsoft，它開源了不少Azure功能平臺。許多其餘自託管FaaS實現使用底層容器平臺，一般是Kubernetes，在這個領域，值得探索Galactic Fog，Fission和OpenFaaS等項目。在將來的博客中，我會重點關注OpenFaas項目，該項目目前有超過10k+的Star。

5. Serverless 不是什麼
由於概念太多，容易混淆，如今不少Readme都有這個環節：

和Paas平臺相比

看下大神(VP Cloud Architecture Strategy at AWS)是怎麼說的：

 

換句話說，大多數PaaS應用程序並非爲了響應事件而使整個應用程序啓動或消失，而FaaS平臺是。

FaaS和PaaS之間的關鍵運營差別是擴展。一般使用PaaS，你須要考慮如何擴展服務實例，使用FaaS應用程序，則是徹底透明的。即便您將PaaS應用程序設置爲自動擴展，你幾乎不可能將此操做設置爲單個請求的級別的擴展，舉個例子，你一個服務實例，通常不會對不一樣的請求設置不一樣的實例數量，若是大量查詢操做，和少許更新操做，你可能會考慮優化查詢，增長緩存等，而不是在1分鐘內，將你的實例擴大到100倍，所以FaaS應用程序在成本方面更加高效。

鑑於此優點，您爲何還要使用PaaS？也許最大的緣由是工具成熟度，基於Paas有不少行之有效的實踐，Faas給了咱們系統擴展一些更多的思路。

和容器相比

另外一種流行的服務抽象是容器，Docker是這種技術最明顯的例子。Kubernetes之類的容器託管系統愈來愈受歡迎，它們從操做系統級部署中抽象出各個應用程序。在這條道路上，咱們看到像Amazon ECS和EKS這樣的雲託管容器平臺（這裏推薦下，靈雀雲的AKS發行版），以及Google Container Engine（Alauda Container Engine，AKE），它們像Serverless/FaaS同樣，團隊徹底無需管理本身的服務器主機。鑑於容器發展的勢頭，仍是值得考慮無服務器FaaS嗎？

運維

無服務器並不意味着沒有運維，它可能意味着沒有系統管理員，運維比服務器管理重要，它至少還意味着：監控，部署，安全性，網絡，以及一般一些生產調試和系統擴展。這些問題在無服務器應用程序中仍然存在，仍然須要一個策略來處理它們。在某些方面，Ops在無服務器世界中更難，由於不少都如此新鮮。不管哪一種方式，在某些時候抽象可能會泄漏，你最好知道在某個地方，有一我的類系統管理員正在支持你的應用程序。

和存儲過程的對比

另外一個主題是無服務器FaaS是「存儲過程即服務」。原文中也解釋過了，但由於它實際上只是FaaS功能的一個子集，還有文章中提到的代碼版本控制的問題，其餘的幾種開源方案不清楚，可是OpenFaas中有一個項目OpenFaas-Cloud，基於Github作了一個很棒的持續集成過程。

6. 使用Faas/Serverless的好處有哪些？
下降運營成本

無服務器是最簡單的外包解決方案。你能夠向雲服務商付費以管理服務器，數據庫甚至應用程序。基於規模經濟效應：你爲託管數據庫支付的費用較少，由於一個供應商運行着數千個很是類似的數據庫。
下降的成原本源於兩方面，首先是純粹來自與其餘人共享基礎設施（例如，硬件，網絡）的基礎設施成本。第二個是人工運維成本。
可是，這種好處與IaaS、PaaS並沒有太大差異，只是更省錢了。

BaaS：下降開發成本

IaaS和PaaS基於服務器或容器的商品化。而無服務器 BaaS是應用程序組件的商品化。例如：身份驗證是一個很好的例子，許多應用程序編寫本身的身份驗證功能，這些功能一般包括註冊，登陸，密碼管理以及與其餘身份驗證提供程序集成等功能。總的來講，這個邏輯在大多數應用程序中很是類似，而且已經建立了像Auth0這樣的服務，以容許咱們將現成的身份驗證功能集成到咱們的應用程序中，而無需咱們本身開發它，不得不說，真的很省錢。

關於BaaS數據庫，如Firebase的數據庫服務。一些移動應用程序團隊發現讓客戶端直接與服務器端數據庫通訊是有意義的。 BaaS數據庫消除了大部分數據庫管理開銷，而且一般提供以無服務器應用程序所指望的模式對不一樣類型的用戶執行適當受權的機制。
是否是有些擔憂安全？我想在新的雲計算時代，咱們都要慢慢接受這些變化。

擴容成本

但在基礎設施方面，最大的好處是您只需支付所需的計算費用，在AWS Lambda的狀況下，AWS 爲開發人員提供每個月 100萬的請求和 400,000 GB 的計算時間 ——無需任何費用，省去的但是真金白銀！

示例：低頻的請求

假設正在運行僅每分鐘處理一個請求的服務器應用程序，處理每一個請求須要50毫秒，而且您在一小時內的平均CPU使用率爲0.1％。若是將此應用程序部署到其本身的專用主機，那麼這很是低效。這個機器你明明能夠運行一千個相似的應用程序，共享在這臺機器。

FaaS把下降的成本交給了你。使用上面的示例應用程序，每分鐘只需支付50毫秒的計算費用。

示例：不規律的流量洪峯

讓咱們看另外一個例子。 假設你的服務收到的基準流量是每秒20個請求，可是每隔5分鐘每秒會收到200個請求（一般數量的10倍），持續10秒。你固然不但願在流量峯值階段減小響應時間。 你是如何解決這個問題的？

在傳統環境中，你可能須要將總硬件數量增長10倍，僅僅爲了處理峯值的狀況，即便峯值的總持續時間不到總機器正常運行時間的4％。 自動擴展可能不是一個好的選擇，由於新的實例啓動時，服務器須要多長時間才能啓動，峯值階段將結束。

就像下圖中的處理同樣：

 

使用FaaS這就不會成爲一個問題，只需在峯值階段支付額外的計算費用就好。顯然，這是一個Serverless/FaaS能夠節省大量成本的示例，但重點是從擴展的角度來看。

優化是成本節約的根本

還有一個有趣的方面：對代碼進行的任何性能優化不只會提升應用程序的速度，並且還能夠直接關係到運營成本的下降。例如你的FaaS函數，以前的相應須要100ms，進過優化後減小到50ms，那麼恭喜，成本下降了一半，就是這麼直接，不須要改任何基礎架構。

運維管理的提高

擴容帶來的便利
這個前文提到過屢次，FaaS的擴展功能不只下降了計算成本，並且還減小了操做管理，由於擴展是自動的。

在最好的狀況下，若是擴展是手動的，那麼運維人員須要明確地向一組服務器添加和刪除實例 - 使用FaaS，忘記這一點並讓FaaS供應商擴展你的應用程序。即便您已經在非FaaS架構中使用自動擴展，仍然須要設置和維護。 FaaS再也不須要這項工做。

下降了打包和部署的複雜性
與部署整個服務器相比，打包和部署FaaS功能很是簡單。 你所作的就是將全部代碼打包到一個zip文件中，而後上傳它，也沒有決定是否在計算機上部署一個或多個容器。 若是您剛開始使用，甚至不須要打包任何東西 - 您能夠在供應商控制檯自己編寫代碼。OpenFaaS好玩了，它容許你直接拉取Github的源碼，一個配置好CI參數後，一個Commit就會讓你的函數更新掉。

這個過程不須要花費很長時間來描述，但對於某些團隊而言，這種好處可能很是巨大：徹底無服務器的解決方案須要零系統管理。

PaaS解決方案具備相似的部署優點，但正如咱們以前看到的，在將PaaS與FaaS進行比較時，擴展優點是FaaS獨有的。

交付速度和持續的驗證

隨着團隊和產品愈來愈多地面向敏捷，咱們但願不斷嘗試新事物並快速更新現有系統。雖然在持續交付的狀況下進行簡單的從新部署能夠快速迭代穩定的項目，可是從具一個Idea到初始部署能力使咱們可以以極快和低成本嘗試新的實驗。

前文提到的，基於FaaS的持續集成，很是完美的讓你持續的實驗下去

雖然成本效益是無服務器最容易表達的改進，可是這種縮短的交付時間讓我最興奮。它能夠實現持續實驗的產品開發思惟，這是咱們如何在公司中交付軟件的真正革命。

「綠色」計算？

在過去的幾十年中，世界上數據中心的數量和規模都在大幅增長。除了創建這些中心所需的物理資源外，相關的能源需求如此之大，蘋果，谷歌等都在談論將一些數據中心託管在可再生能源附近以減小化石燃燒。

通電後的空閒，使得服務器消耗了大量的能量。

Typical servers in business and enterprise data centers deliver between 5 and 15 percent of their maximum computing output on average over the course of the year. – Forbes

這很是低效，併產生巨大的環境影響。

一方面，雲基礎設施可能已經幫助減小了這種影響，由於公司能夠按需「購買」更多的服務器，只有當他們絕對須要時，而不是提早很長時間配置全部可能必需的服務器。然而，人們還能夠爭辯說，若是沒有足夠的容量管理，不少服務器都會被丟棄，那麼配置服務器的容易程度可能會使狀況變得更糟。

不管咱們使用自託管服務器，IaaS仍是PaaS基礎架構解決方案，咱們仍然會手動制定關於咱們的應用程序的容量決策，這些決策一般會持續數月或數年。一般，咱們對管理容量持謹慎態度，所以咱們過分配置，致使剛纔描述的效率低下。使用無服務器方法，咱們再也不本身作出這樣的容量決策 - 咱們讓FaaS供應商爲咱們的實時需求提供足夠的計算容量。而後，供應商能夠在其客戶中彙總制定本身的容量決策，就像集中供暖，而不是你本身在北方的家裏燒鍋爐。

FaaS的不足之處和用武之地，To Be Continued。

Serverless Architectures

It’s all about functional stateless microservices