Categories
程式開發

為“無服務器”正名


無服務器(Severless)不是一個好的術語,但它卻被用來描述一個強大且經常被誤解的概念。

為“無服務器”正名 1

本文將討論“無服務器”的缺點和優點,並為其改變構建應用程序的方式帶來的好處辯護——進一步向無服務器架構發展。

現有的一些定義:

AWS——無服務器允許你構建和運行應用程序和服務,而無需考慮服務器。

Paul Johnston——無服務器的解決方案是,如果沒有人使用它,就沒有任何運行成本。

Mike Roberts——無服務器架構是在應用程序設計中包含第三方“後端即服務”(BaaS)服務和/或包含在“函數即服務”(FaaS)平台上託管的臨時容器中運行的自定義代碼。

這些定義都非常簡潔和巧妙,但它們缺乏實用性細節,而這些細節是理解無服務器方法能力的關鍵。

作為一個補充說明,在早些時候,我在一條推特主題中給出一個簡單定義。

為“無服務器”正名 2

上面使用的符號“⊂”是指左邊東西是右邊東西的子集,也就是說,FaaS是無服務器的子集。

更深入的討論

自2014年AWS Lambda發布以來,人們經常將FaaS(函數即服務)和無服務器作為同義詞使用。

FaaS是一個計算服務術語,它允許代碼的功能以一種隔離方式運行。這些函數在響應事件(如HTTP調用)時運行,一個系統抽象了服務器的底層複雜性,包括操作系統和所有的細節或配置和擴展。

FaaS是許多無服務器架構的關鍵組成部分,但你可以實現一個不使用FaaS的無服務器架構,也能實現一個使用FaaS的非無服務器架構。在很大程度上,FaaS是一種無服務器的計算方法,但是,對於許多應用程序架構來說,計算(即運行代碼)並不是其唯一的一個方面。

應用程序架構可能需要很多東西,例如:計算、存儲、監控……

為“無服務器”正名 3

AWS提供的幾個無服務器架構組件示例

如前所述,FaaS函數是由事件(events)觸發的,例如HTTP調用。上圖中的其他無服務器服務都可以由事件觸發,甚至能自己生成事件,從而觸發更多的服務。遷移到能高效利用這些服務的架構,通常就是遷移到事件驅動的架構。

最近,事件驅動架構的概念開始與無服務器架構這個術語一起出現。

隨著AWS等雲提供商針對無服務器架構發布越來越多的服務,這種術語鏈接正在進一步擴展。這並不是什麼新鮮事,無服務器從早期階段就經常被描述為“scale to zero”——這種擴展和計費的方法顯然與基於事件的服務緊密結合在一起。

事件驅動架構的一個例子是AWS發布的一個新的重要的無服務器服務——可以說是Lambda以來最大的服務之一。

EventBridge是AWS針對無服務器全託管事件總線給出的答案。它使得事件可以通過更少的代碼、更好的可觀測性和一些非常超前的附加功能(如新推出的EventBrige模式註冊表)在不同服務間流動。

模式註冊表(The Schema Registry)可自動檢測並將大型分佈式架構的所有事件聚合到一個集中式註冊表中——甚至為開發人員提供自動生成代碼綁定的SDK來從IDE訪問事件。

潛在解決方案空間在擴大

潛在解決方案空間包括上圖所示的所有服務。

以及AWS和其他雲提供商的許多其他服務。

以及未來十年將會發布的服務。

以及由富有創造力的工程師自行構建的無服務器系統,他們將這些組件塊以連雲提供商都沒預料到的方式組合在一起,構建出新的、令人興奮的東西。

畢竟,EventBridge源於AWS發現了Cloudwatch事件被用來觸發Lambdas的奇妙方式。

這種現象的另一個例子可能是簡單的無服務器事件調度系統,我們搭配使用Step Functions和Lambda構建該系統,我們的另一篇文章對此進行了詳細介紹。

那麼,為何我們沒全都採用無服務器呢?

首先,很難從一個經常被誤用的術語“無服務器” 中看到這個潛在解決方案空間。

特別是當某個框架選擇使用它作為自己的名稱時——這是一個令人驚嘆的工具,但無助於保留術語背後的複雜語義。

現在,顯然不僅僅是因為一個詞彙的問題減緩了無服務器架構的普及。這是一個範式轉變,可能比之前的“雲”更有影響力。

構建由服務器、自管理系統和永久狀態組成系統的過程中成長起來的工程師,不得不轉向事件驅動的思考方式,這種方式似乎具有無限的計算規模和存儲空間——同時還面臨著新的挑戰、約束,而且缺少工具和最佳實踐。

例如,遷移到更偏向無服務器的架構,通常涉及到採用DynamoDB(或類似的東西)來代替過去的關係型數據庫。 NoSQL現在已經不是什麼新東西了,但是將它用於所有核心業務需求的想法是——這是因為整個系統現在的規模更大,而且具備之前人們並不了解的事件驅動的特性。

這並不容易——DynamoDB很複雜,要做好就更複雜了。拋棄過去熟悉的Web應用程序框架——不是通過低成本的修改來保持函數的輕量化,而是將典型的框架責任轉移給雲提供商——這些都不是小事!

當你能清楚地看到“潛在空間”時,才能讓收益大於成本

人們不會為了遷移系統和轉變觀念而經歷這種痛苦。正如在許多其他文章中討論的那樣,無服務器架構允許開發人員專注於編寫最能體現業務價值的代碼,同時降低TCO(總擁有成本)、增加可伸縮性並同時減少碳足跡(carbon footprint)。

為“無服務器”正名 4

無以言表

有時候,無法用言語來表達。有時候,要用一個詞來描述潛在解決方案所涉及的範圍之廣、形式之多,實在是太過複雜。

但是,作為一個在許多新的無服務器服務出現前就存在的詞,它做得還不錯。事實上,這證明了這個我們正努力把它從這個空間中分離出來的詞的力量。

如果這個詞是FunctionFull ,那麼隨著這個space的擴大,我們就不可能一直使用它,如果沒有無服務器這顆北斗星引導我們走向一個無形的特性,也許我們不會以這種方式擴展這個空間。

目前,至少對我來說,無服務器設法完成了一項艱鉅工作,定義了一個非常靈活且複雜空間的邊界。

英文原文:

In Defence of “Serverless” —the term