摘要
無服務器架構(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。