您的位置:首頁 > 服務器硬件技術

                                            深入理解無服務器架構(Faas\u002FServerless)

                                            發布時間:2022-04-11 15:15:23  來源:IT資訊網    采編:author  背景:

                                            無服務器架構(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的好處有哪些?

                                            降低運營成本

                                            無服務器是最簡單的外包解決方案。你可以向云服務商付費以管理服務器,數據庫甚至應用程序?;谝幠=洕耗銥橥泄軘祿熘Ц兜馁M用較少,因為一個供應商運行著數千個非常相似的數據庫。

                                            降低的成本來源于兩方面,首先是純粹來自與其他人共享基礎設施(例如,硬件,網絡)的基礎設施成本。第二個是人工運維成本。

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

                                            BaaS:降低開發成本

                                            IaaS和PaaS基于服務器或容器的商品化。而無服務器 BaaS是應用程序組件的商品化。例如:身份驗證是一個很好的例子,許多應用程序編寫自己的身份驗證功能,這些功能通常包括注冊,登錄,密碼管理以及與其他身份驗證提供程序集成等功能??偟膩碚f,這個邏輯在大多數應用程序中非常相似,并且已經創建了像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供應商為我們的實時需求提供足夠的計算容量。然后,供應商可以在其客戶中匯總制定自己的容量決策,就像集中供暖,而不是你自己在北方的家里燒鍋爐。

                                              聲明:本文僅為傳遞更多網絡信息,不代表IT資訊網觀點和意見,僅供參考了解,更不能作為投資使用依據。


                                            返回網站首頁 本文來源:IT資訊網

                                            本文評論
                                            一文讀懂CPU和顯卡究竟先升級誰
                                            如果問一個游戲玩家CPU和顯卡先升級誰,得到的答案多半
                                            日期:02-12
                                            Netcraft 8 月 Web 服務器調查報告發布
                                            Netcraft 2021 年 8 月份的全球 Web 服務器調查報告已
                                            日期:02-10
                                            Second Order:一款功能強大的子域名接管漏洞安全掃描工具
                                            漏洞安全掃描工具Second Order基于Go語言開發,因此廣大
                                            日期:02-24
                                            分布式軟總線讓阿里巴巴商家玩轉多設備直播
                                            本文將從技術角度出發,分享 1688直播供給側是如何基于H
                                            日期:03-10
                                            17英寸機皇 22納米四核Alienware M17x
                                            Alienware M17x(ALW17D-2828)筆記本采用22納米工藝的
                                            日期:02-27
                                            物聯網將如何為遠程工作和疫情危機后的常態提供動力
                                            即使冠狀病毒大流行已經消退到足以使工作場所開放的程
                                            日期:04-07
                                            理解EMM:是更好地管理移動性的關鍵所在
                                            由于移動性已經成為各種類型及規模組織IT部門的關注點
                                            日期:03-05
                                            讓計算更智慧  聯想布局AI推動智慧化變革
                                            聯想在人工智能領域的戰略布局,得益于在人工智能三大要
                                            日期:03-20
                                            服務器市場再燃戰火!AMD Naples破局在即
                                            Naples單顆處理器擁有32個核心,64線程,雙路則可以支持到
                                            日期:01-21
                                            小伙伴問我性能指標監控怎么做,這次我安排上了??!
                                            作者個人研發的在高并發場景下,提供的簡單、穩定、可擴
                                            日期:02-22
                                            G Suite vs. Office 365:適合企業的辦公套件是什么?
                                            選擇辦公套件在以往是一件很簡單的事情,但是谷歌公司推
                                            日期:02-13
                                            初學者必看 5分鐘速成投影機使用寶典
                                            盡管投影機目前已經非常普遍,但是不少用戶對它的使用方
                                            日期:02-23
                                             

                                            精品无码久久午夜福利