無服務(wù)器架構(gòu)(Faas/Serverless)，是軟件架構(gòu)領(lǐng)域的熱門話題。 AWS，Google Cloud和Azure - 在無服務(wù)器上投入了大量資金，已經(jīng)在看到了大量專門針對Faas/Serverless的文章、書籍，開源項目，會議。 但什么是無服務(wù)器，為什么(或不是)值得考慮?

1. What is Serverless?

無服務(wù)器架構(gòu)是一種包含第三方“后端即服務(wù)”(BaaS)服務(wù)的應(yīng)用程序設(shè)計方式，和/或包括(FaaS)平臺上的托管臨時容器中運(yùn)行的自定義代碼。 此類體系結(jié)構(gòu)消除了對傳統(tǒng)的始終在線服務(wù)器的大部分需求。 這可以顯著降低的運(yùn)維成本，復(fù)雜性以及減少項目的上線準(zhǔn)備時間，代價是增加了對供應(yīng)商依賴性和相對不成熟支持服務(wù)的依賴。

首先，沒有人清楚地知道無服務(wù)器是什么。它包含兩個不同但是有關(guān)聯(lián)的領(lǐng)域：

無服務(wù)器可以描述一個”富客戶端 + 第三方云托管應(yīng)用程序和服務(wù)的”的應(yīng)用程序。這些“富客戶端”應(yīng)用程序一般是移動應(yīng)用程序，使用龐大的云端數(shù)據(jù)庫或SSO服務(wù)(Auth0，AWS Cognito等)。這些類型的服務(wù)以前被描述為“后端即服務(wù)”。

無服務(wù)器也可以指服務(wù)器端邏輯仍然由應(yīng)用程序開發(fā)人員編寫，但是與傳統(tǒng)體系結(jié)構(gòu)不同，它運(yùn)行在無狀態(tài)計算容器中，這些容器是事件觸發(fā)的短暫的(可能只持續(xù)一次調(diào)用，或Deployment會保留，根據(jù)運(yùn)行負(fù)載自動調(diào)節(jié)運(yùn)行實例數(shù)量)，并且完全由第三方管理(也許就是”FaaS”此名稱的來源 )AWS Lambda是目前Faas平臺***的實現(xiàn)之一，比國內(nèi)的云服務(wù)商便宜很多，看好亞馬遜市值***破萬億(Apple may 打臉)。

在本文中，顯然我們將重點關(guān)注后者，F(xiàn)aaS/Serverless。

2. 幾個引申的例子

讓我們考慮一個帶有服務(wù)器端邏輯的傳統(tǒng)的三層面向客戶端的系統(tǒng)。一個很好的例子是一個典型的電子商務(wù)應(yīng)用程序 - 在線寵物商店。

架構(gòu)像這樣：

在這個架構(gòu)里，客戶端可以相對不用那么智能，絕大多數(shù)的邏輯在服務(wù)端完成，授權(quán)，頁面導(dǎo)航，查詢，交易等等。

在無服務(wù)架構(gòu)里，看起來會是這個樣子：

二者對比中，我們可以看到一系列明顯的變化：

我們?nèi)サ袅嗽紤?yīng)用程序中的身份驗證邏輯，并將其替換為第三方BaaS服務(wù)(例如，Auth0)

我們允許客戶端直接訪問我們的數(shù)據(jù)庫(用于產(chǎn)品列表)，該數(shù)據(jù)庫本身完全由第三方(例如Google Firebase)托管。我們可能采用和服務(wù)器資源訪問數(shù)據(jù)庫不同的安全配置文件讓客戶端去訪問數(shù)據(jù)庫。

前兩點意味著非常重要的第三點：寵物商店服務(wù)器中的一些邏輯現(xiàn)在位于客戶端內(nèi) - 例如，跟蹤用戶會話，理解應(yīng)用程序的UX結(jié)構(gòu)，從數(shù)據(jù)庫讀取并將其轉(zhuǎn)換為一個可用的視圖等客戶端正在成為單頁應(yīng)用程序。

我們可能希望在服務(wù)器中保留一些與UX相關(guān)的功能，例如，如果它是計算密集型或需要訪問大量數(shù)據(jù)。在我們的寵物商店中，一個例子是“搜索”。而不是像原始體系結(jié)構(gòu)中那樣擁有一個始終運(yùn)行的服務(wù)器，我們可以實現(xiàn)一個FaaS功能，通過API網(wǎng)關(guān)響應(yīng)HTTP請求。客戶端和服務(wù)器“搜索”功能都從同一數(shù)據(jù)庫中讀取產(chǎn)品數(shù)據(jù)。

***，我們可以把購買的實現(xiàn)替換成另一個獨立的Faas函數(shù)，安全的原因吧，這也是由API網(wǎng)關(guān)給引入的。在使用FAAS時，把不同的邏輯要求，拆分成獨立的部署組件是一種很常見的方法。

3. “Faas”的面紗

現(xiàn)在是時候深入了解FAAS的真正含義。為此，我們來看看亞馬遜FaaS產(chǎn)品的開頭描述：Lambda。

AWS Lambda允許您在不配置或管理服務(wù)器的情況下運(yùn)行代碼。 (1)使用Lambda，您可以運(yùn)行幾乎任何類型的應(yīng)用程序或后端服務(wù)的代碼(2)所有這些都是零管理。只需上傳代碼，Lambda就會負(fù)責(zé)運(yùn)行所需的一切(3)以高可用性擴(kuò)展實例。(4)可以設(shè)置代碼以自動從其他AWS服務(wù)觸發(fā)(5)或直接從任何Web或移動應(yīng)用程序調(diào)用它。

詳細(xì)說來：

從FaaS是運(yùn)行后端代碼而無需管理自己的服務(wù)器系統(tǒng)或應(yīng)用程序。與容器和PaaS等其他現(xiàn)代架構(gòu)趨勢相比，是否存在長期存在的服務(wù)器和應(yīng)用程序是一個關(guān)鍵的區(qū)別。

FaaS產(chǎn)品不需要對特定框架或庫進(jìn)行編碼。 FaaS功能是語言和環(huán)境的常規(guī)應(yīng)用程序。例如，AWS Lambda函數(shù)可以把Javascript，Python，Go，任何JVM語言(Java，Clojure，Scala等)或任何.NET語言視為“一等公民”。不過Lambda函數(shù)還可以與其部署包一起執(zhí)行在另一個進(jìn)程，因此實際上可以使用任何可以編譯為Unix進(jìn)程的語言。FaaS函數(shù)具有重要的體系結(jié)構(gòu)限制，特別是在涉及狀態(tài)和執(zhí)行持續(xù)時間時。

部署與傳統(tǒng)系統(tǒng)有很大不同，因為我們沒有自己運(yùn)行的服務(wù)器應(yīng)用程序。在FaaS環(huán)境中，我們將功能的代碼上傳到FaaS提供商，提供商執(zhí)行配置資源，實例VM(Container)，管理流程等所需的一切。

水平縮放完全是自動的，彈性的，并由Faas管理。如果系統(tǒng)需要并行處理100個請求，則Faas將處理該請求而無需你進(jìn)行任何額外配置。執(zhí)行函數(shù)的容器是臨時的，F(xiàn)aaS創(chuàng)建和銷毀它們，完全由運(yùn)行時決定。最重要的是使用FaaS，云廠商可以處理所有底層資源配置和分配，而用戶根本不需要集群或VM管理。

FaaS中的函數(shù)通常由提供程序定義的事件類型觸發(fā)。使用AWS，此類事件包括S3(文件/對象)更新，時間(定時任務(wù))以及消息總線的消息。

大多數(shù)Faas運(yùn)營商還允許HTTP請求觸發(fā)函數(shù)，在AWS中，通常通過使用API網(wǎng)關(guān)來實現(xiàn)這一點。我們在寵物商店示例中使用API網(wǎng)關(guān)進(jìn)行“搜索”和“購買”功能。函數(shù)也可以通過平臺提供的API直接調(diào)用，無論是在外部還是在同一個云環(huán)境中，但這是一種相對不常見的用法。

4. Faas需要關(guān)注的特點

有無狀態(tài)

FaaS函數(shù)在本地(VM/容器實例)狀態(tài)(即存儲在內(nèi)存中的變量中的數(shù)據(jù)或?qū)懭氡镜卮疟P的數(shù)據(jù))中具有很大的限制。一般情況下你確實可以這樣存儲，但是不能保證這種狀態(tài)在多個調(diào)用中保持不變，更重要的是，你本來就不應(yīng)該假設(shè)一次調(diào)用函數(shù)的狀態(tài)可用于同一函數(shù)的另一次調(diào)用。因此，F(xiàn)aaS函數(shù)通常被描述為無狀態(tài)，或者更準(zhǔn)確地說，需要持久化的FaaS函數(shù)的任何狀態(tài)都需要在FaaS函數(shù)實例之外進(jìn)行。

對于自然無狀態(tài)的FaaS函數(shù) - 即那些提供輸入到輸出的純功能轉(zhuǎn)換的函數(shù) - 這是無關(guān)緊要的。但對于有狀態(tài)的而言，這可能會比較麻煩，以前分布式的那些限制現(xiàn)在完全相同。這種面向狀態(tài)的函數(shù)通常將使用數(shù)據(jù)庫，緩存(如Redis)或網(wǎng)絡(luò)文件/對象存儲(如S3)來跨請求存儲狀態(tài)。

執(zhí)行時長

FaaS函數(shù)通常受限于允許每次調(diào)用運(yùn)行多長時間。目前，AWS Lambda函數(shù)響應(yīng)事件的“超時”最多為五分鐘，然后才會終止。 Microsoft Azure和Google Cloud Functions具有類似的限制。這意味著某些類別的長期任務(wù)不適合FaaS - 除非你重新設(shè)計架構(gòu)，需要創(chuàng)建幾個不同的協(xié)調(diào)FaaS函數(shù)，而在傳統(tǒng)環(huán)境中，您可能有一個長期任務(wù)執(zhí)行協(xié)調(diào)和執(zhí)行。

啟動延遲和“冷啟動”

FaaS平臺在每個事件之前初始化函數(shù)實例需要一些時間。不同的函數(shù)，他的啟動延遲也可能顯著變化，從幾毫秒到幾秒的都有可能，取決于許多因素，具體一點以AWS Lambda為例。

Lambda函數(shù)的初始化即可以是“熱啟動”(使用Lambda函數(shù)的之前以前產(chǎn)生的容器)，也可以是“冷啟動”(創(chuàng)建新容器實例)，冷啟動帶來的延遲應(yīng)該引起了我們的關(guān)注。

冷啟動的延遲取決于許多因素：開發(fā)語言，使用的庫，代碼量，Lambda函數(shù)環(huán)境本身的配置，是否需要連接到VPC資源等等。這些方面受開發(fā)人員的控制，通過這些地方的優(yōu)化可以減少冷啟動的一部分啟動延遲。

可調(diào)的還有冷啟動的啟動頻率。例如如果一個函數(shù)每秒處理10個事件，每個事件需要50毫秒來處理，那么每隔100,000-200,000個事件，您可能會看到一個實例的冷啟動。另一方面，如果每小時處理一次事件，你可能會看到每個事件來時的冷啟動，因為Amazon會在幾分鐘后退出非活動的Lambda實例。知道這一點有助于了解冷啟動是否會影響集成效果，以及是否可能希望對函數(shù)實例執(zhí)行“保持活動”以避免它們被回收。

冷啟動需要太關(guān)注嗎?這取決于應(yīng)用程序的負(fù)載或流量的情況。如果你需要的是低延遲交易應(yīng)用程序，那么***忘掉FaaS系統(tǒng)吧，無論你使用哪一種編程語言。

無論你是否認(rèn)為你的應(yīng)用是否存在此類問題，你***用類似生產(chǎn)的負(fù)載來測試性能。如果此時此刻比較爛，不要著急，F(xiàn)aaS供應(yīng)商正在持續(xù)改進(jìn)，說不定年底就滿足你的要求了。

API網(wǎng)關(guān)

API網(wǎng)關(guān)是一個HTTP服務(wù)器，其中路由和負(fù)載點定義在配置中，并且每個路由與處理該路由的函數(shù)關(guān)聯(lián)。當(dāng)API網(wǎng)關(guān)收到請求后，它會找到與請求匹配的路由配置，來調(diào)用相關(guān)的FaaS函數(shù)。API網(wǎng)關(guān)允許從HTTP請求參數(shù)映射到FaaS函數(shù)的更簡潔的輸入，或者讓HTTP請求原封不動得通過，F(xiàn)aaS函數(shù)將執(zhí)行其邏輯并將結(jié)果返回給API網(wǎng)關(guān)，而API網(wǎng)關(guān)又將此結(jié)果轉(zhuǎn)換為HTTP響應(yīng)，并將其傳遞回原始調(diào)用方。

工具

關(guān)于工具成熟度的評論也適用于FaaS。 到今年(2018年)，我們已經(jīng)看到了明顯的改善，我們希望工具能夠更好地發(fā)展。

FaaS世界中一些“開發(fā)者用戶體驗”好的例子值得一提。 首先是Auth0 Webtask，它非常重視開發(fā)人員用戶體驗。 其次是Microsoft，其Azure功能產(chǎn)品。 Microsoft一直將Visual Studio及其反饋循環(huán)置于其開發(fā)人員產(chǎn)品的最前沿，而Azure Functions也不例外。 在云觸發(fā)事件的輸入下，它提供的在本地調(diào)試功能的能力非常特殊。

開源勢力

無服務(wù)器中開源的最常見用途是FaaS工具和框架，它提供了一些跨云提供商的工具抽象，類似工具的例子包括Claudia和Zappa。另一個例子是Apex，它允許你使用亞馬遜直接支持的語言之外的語言開發(fā)Lambda函數(shù)。不過AWS自己的部署工具SAM(無服務(wù)器應(yīng)用程序模型)也是開源的。

專有FaaS的主要好處之一是不必關(guān)心底層計算基礎(chǔ)架構(gòu)(機(jī)器，虛擬機(jī)，容器)。但是如果你想關(guān)注這些事情呢?也許你有一些云供應(yīng)商無法滿足的安全需求，或者你有一些你已經(jīng)購買但不想丟棄的服務(wù)器機(jī)架。在這些場景中可以開源幫助，允許運(yùn)行自己的“Serverful”FaaS平臺，這個領(lǐng)域有很多活動。開源FaaS的最初***之一是IBM(使用OpenWhisk，現(xiàn)在是一個Apache項目)。Microsoft，它開源了很多Azure功能平臺。許多其他自托管FaaS實現(xiàn)使用底層容器平臺，通常是Kubernetes，在這個領(lǐng)域，值得探索Galactic Fog，F(xiàn)ission和OpenFaaS等項目。在未來的博客中，我會重點關(guān)注OpenFaas項目，該項目目前有超過10k+的Star。

5. Serverless 不是什么

因為概念太多，容易混淆，現(xiàn)在很多Readme都有這個環(huán)節(jié)：

和Paas平臺相比

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

換句話說，大多數(shù)PaaS應(yīng)用程序并不是為了響應(yīng)事件而使整個應(yīng)用程序啟動或消失，而FaaS平臺是。

FaaS和PaaS之間的關(guān)鍵運(yùn)營差異是擴(kuò)展。通常使用PaaS，你需要考慮如何擴(kuò)展服務(wù)實例，使用FaaS應(yīng)用程序，則是完全透明的。即使您將PaaS應(yīng)用程序設(shè)置為自動擴(kuò)展，你幾乎不可能將此操作設(shè)置為單個請求的級別的擴(kuò)展，舉個例子，你一個服務(wù)實例，一般不會對不同的請求設(shè)置不同的實例數(shù)量，如果大量查詢操作，和少量更新操作，你可能會考慮優(yōu)化查詢，增加緩存等，而不是在1分鐘內(nèi)，將你的實例擴(kuò)大到100倍，因此FaaS應(yīng)用程序在成本方面更加高效。

鑒于此優(yōu)勢，您為什么還要使用PaaS?也許***的原因是工具成熟度，基于Paas有很多行之有效的實踐，F(xiàn)aas給了我們系統(tǒng)擴(kuò)展一些更多的思路。

和容器相比

另一種流行的服務(wù)抽象是容器，Docker是這種技術(shù)最明顯的例子。Kubernetes之類的容器托管系統(tǒng)越來越受歡迎，它們從操作系統(tǒng)級部署中抽象出各個應(yīng)用程序。在這條道路上，我們看到像Amazon ECS和EKS這樣的云托管容器平臺(這里推薦下，靈雀云的AKS發(fā)行版)，以及Google Container Engine(Alauda Container Engine，AKE)，它們像Serverless/FaaS一樣，團(tuán)隊完全無需管理自己的服務(wù)器主機(jī)。鑒于容器發(fā)展的勢頭，還是值得考慮無服務(wù)器FaaS嗎?

運(yùn)維

無服務(wù)器并不意味著沒有運(yùn)維，它可能意味著沒有系統(tǒng)管理員，運(yùn)維比服務(wù)器管理重要，它至少還意味著：監(jiān)控，部署，安全性，網(wǎng)絡(luò)，以及通常一些生產(chǎn)調(diào)試和系統(tǒng)擴(kuò)展。這些問題在無服務(wù)器應(yīng)用程序中仍然存在，仍然需要一個策略來處理它們。在某些方面，Ops在無服務(wù)器世界中更難，因為很多都如此新鮮。無論哪種方式，在某些時候抽象可能會泄漏，你***知道在某個地方，有一個人類系統(tǒng)管理員正在支持你的應(yīng)用程序。

和存儲過程的對比

另一個主題是無服務(wù)器FaaS是“存儲過程即服務(wù)”。原文中也解釋過了，但因為它實際上只是FaaS功能的一個子集，還有文章中提到的代碼版本控制的問題，其他的幾種開源方案不清楚，但是OpenFaas中有一個項目OpenFaas-Cloud，基于Github做了一個很棒的持續(xù)集成過程。

6. 使用Faas/Serverless的好處有哪些?

降低運(yùn)營成本

無服務(wù)器是最簡單的外包解決方案。你可以向云服務(wù)商付費(fèi)以管理服務(wù)器，數(shù)據(jù)庫甚至應(yīng)用程序。基于規(guī)模經(jīng)濟(jì)效應(yīng)：你為托管數(shù)據(jù)庫支付的費(fèi)用較少，因為一個供應(yīng)商運(yùn)行著數(shù)千個非常相似的數(shù)據(jù)庫。

降低的成本來源于兩方面，首先是純粹來自與其他人共享基礎(chǔ)設(shè)施(例如，硬件，網(wǎng)絡(luò))的基礎(chǔ)設(shè)施成本。第二個是人工運(yùn)維成本。

但是，這種好處與IaaS、PaaS并無太大差別，只是更省錢了。

BaaS：降低開發(fā)成本

IaaS和PaaS基于服務(wù)器或容器的商品化。而無服務(wù)器 BaaS是應(yīng)用程序組件的商品化。例如：身份驗證是一個很好的例子，許多應(yīng)用程序編寫自己的身份驗證功能，這些功能通常包括注冊，登錄，密碼管理以及與其他身份驗證提供程序集成等功能。總的來說，這個邏輯在大多數(shù)應(yīng)用程序中非常相似，并且已經(jīng)創(chuàng)建了像Auth0這樣的服務(wù)，以允許我們將現(xiàn)成的身份驗證功能集成到我們的應(yīng)用程序中，而無需我們自己開發(fā)它，不得不說，真的很省錢。

關(guān)于BaaS數(shù)據(jù)庫，如Firebase的數(shù)據(jù)庫服務(wù)。一些移動應(yīng)用程序團(tuán)隊發(fā)現(xiàn)讓客戶端直接與服務(wù)器端數(shù)據(jù)庫通信是有意義的。 BaaS數(shù)據(jù)庫消除了大部分?jǐn)?shù)據(jù)庫管理開銷，并且通常提供以無服務(wù)器應(yīng)用程序所期望的模式對不同類型的用戶執(zhí)行適當(dāng)授權(quán)的機(jī)制。

是不是有些擔(dān)心安全?我想在新的云計算時代，我們都要慢慢接受這些變化。

擴(kuò)容成本

但在基礎(chǔ)設(shè)施方面，***的好處是您只需支付所需的計算費(fèi)用，在AWS Lambda的情況下，AWS 為開發(fā)人員提供每月 100萬的請求和 400,000 GB 的計算時間 ——無需任何費(fèi)用，省去的可是真金白銀!

示例：低頻的請求

假設(shè)正在運(yùn)行僅每分鐘處理一個請求的服務(wù)器應(yīng)用程序，處理每個請求需要50毫秒，并且您在一小時內(nèi)的平均CPU使用率為0.1%。如果將此應(yīng)用程序部署到其自己的專用主機(jī)，那么這非常低效。這個機(jī)器你明明可以運(yùn)行一千個類似的應(yīng)用程序，共享在這臺機(jī)器。

FaaS把降低的成本交給了你。使用上面的示例應(yīng)用程序，每分鐘只需支付50毫秒的計算費(fèi)用。

示例：不規(guī)律的流量洪峰

讓我們看另一個例子。 假設(shè)你的服務(wù)收到的基準(zhǔn)流量是每秒20個請求，但是每隔5分鐘每秒會收到200個請求(通常數(shù)量的10倍)，持續(xù)10秒。你當(dāng)然不希望在流量峰值階段減少響應(yīng)時間。 你是如何解決這個問題的?

在傳統(tǒng)環(huán)境中，你可能需要將總硬件數(shù)量增加10倍，僅僅為了處理峰值的情況，即使峰值的總持續(xù)時間不到總機(jī)器正常運(yùn)行時間的4%。 自動擴(kuò)展可能不是一個好的選擇，因為新的實例啟動時，服務(wù)器需要多長時間才能啟動，峰值階段將結(jié)束。

就像下圖中的處理一樣：

使用FaaS這就不會成為一個問題，只需在峰值階段支付額外的計算費(fèi)用就好。顯然，這是一個Serverless/FaaS可以節(jié)省大量成本的示例，但重點是從擴(kuò)展的角度來看。

優(yōu)化是成本節(jié)約的根本

還有一個有趣的方面：對代碼進(jìn)行的任何性能優(yōu)化不僅會提高應(yīng)用程序的速度，而且還可以直接關(guān)系到運(yùn)營成本的降低。例如你的FaaS函數(shù)，之前的相應(yīng)需要100ms，進(jìn)過優(yōu)化后減少到50ms，那么恭喜，成本降低了一半，就是這么直接，不需要改任何基礎(chǔ)架構(gòu)。

運(yùn)維管理的提升

擴(kuò)容帶來的便利

這個前文提到過多次，F(xiàn)aaS的擴(kuò)展功能不僅降低了計算成本，而且還減少了操作管理，因為擴(kuò)展是自動的。

在***的情況下，如果擴(kuò)展是手動的，那么運(yùn)維人員需要明確地向一組服務(wù)器添加和刪除實例 - 使用FaaS，忘記這一點并讓FaaS供應(yīng)商擴(kuò)展你的應(yīng)用程序。即使您已經(jīng)在非FaaS架構(gòu)中使用自動擴(kuò)展，仍然需要設(shè)置和維護(hù)。 FaaS不再需要這項工作。

降低了打包和部署的復(fù)雜性

與部署整個服務(wù)器相比，打包和部署FaaS功能非常簡單。 你所做的就是將所有代碼打包到一個zip文件中，然后上傳它，也沒有決定是否在計算機(jī)上部署一個或多個容器。 如果您剛開始使用，甚至不需要打包任何東西 - 您可以在供應(yīng)商控制臺本身編寫代碼。OpenFaaS好玩了，它允許你直接拉取Github的源碼，一個配置好CI參數(shù)后，一個Commit就會讓你的函數(shù)更新掉。

這個過程不需要花費(fèi)很長時間來描述，但對于某些團(tuán)隊而言，這種好處可能非常巨大：完全無服務(wù)器的解決方案需要零系統(tǒng)管理。

PaaS解決方案具有類似的部署優(yōu)勢，但正如我們之前看到的，在將PaaS與FaaS進(jìn)行比較時，擴(kuò)展優(yōu)勢是FaaS獨有的。

交付速度和持續(xù)的驗證

隨著團(tuán)隊和產(chǎn)品越來越多地面向敏捷，我們希望不斷嘗試新事物并快速更新現(xiàn)有系統(tǒng)。雖然在持續(xù)交付的情況下進(jìn)行簡單的重新部署可以快速迭代穩(wěn)定的項目，但是從具一個Idea到初始部署能力使我們能夠以極快和低成本嘗試新的實驗。

前文提到的，基于FaaS的持續(xù)集成，非常***的讓你持續(xù)的實驗下去

雖然成本效益是無服務(wù)器最容易表達(dá)的改進(jìn)，但是這種縮短的交付時間讓我最興奮。它可以實現(xiàn)持續(xù)實驗的產(chǎn)品開發(fā)思維，這是我們?nèi)绾卧诠局薪桓盾浖恼嬲锩?/p>

“綠色”計算?

在過去的幾十年中，世界上數(shù)據(jù)中心的數(shù)量和規(guī)模都在大幅增加。除了建立這些中心所需的物理資源外，相關(guān)的能源需求如此之大，蘋果，谷歌等都在談?wù)搶⒁恍?shù)據(jù)中心托管在可再生能源附近以減少化石燃燒。

通電后的空閑，使得服務(wù)器消耗了大量的能量。

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

這非常低效，并產(chǎn)生巨大的環(huán)境影響。

一方面，云基礎(chǔ)設(shè)施可能已經(jīng)幫助減少了這種影響，因為公司可以按需“購買”更多的服務(wù)器，只有當(dāng)他們絕對需要時，而不是提前很長時間配置所有可能必需的服務(wù)器。然而，人們還可以爭辯說，如果沒有足夠的容量管理，很多服務(wù)器都會被丟棄，那么配置服務(wù)器的容易程度可能會使情況變得更糟。

無論我們使用自托管服務(wù)器，IaaS還是PaaS基礎(chǔ)架構(gòu)解決方案，我們?nèi)匀粫謩又贫P(guān)于我們的應(yīng)用程序的容量決策，這些決策通常會持續(xù)數(shù)月或數(shù)年。通常，我們對管理容量持謹(jǐn)慎態(tài)度，因此我們過度配置，導(dǎo)致剛才描述的效率低下。使用無服務(wù)器方法，我們不再自己做出這樣的容量決策 - 我們讓FaaS供應(yīng)商為我們的實時需求提供足夠的計算容量。然后，供應(yīng)商可以在其客戶中匯總制定自己的容量決策，就像集中供暖，而不是你自己在北方的家里燒鍋爐。