深入理解無伺服器架構(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。