盤點 Serverless 架構的六個特質

作者 | Wisen Tanasa

編譯 | 劉雅夢

策劃 | 辛曉亮

本文介紹了 Serverless（無服務器）架構的六個特質（Traits）：入門門檻低（Low barrier-to-entry）、無主機（Hostless）、無狀態（Stateless）、彈性（Elasticity）、分佈式（Distributed）和事件驅動（Event-driven）。其目的是倡導大家儘可能廣泛地採用 Serverless 架構。Serverless 架構帶來了一個有趣的範式轉變，這使得軟件開發的許多方面都變得更好了。但它也帶來了技術人員必須要適應的新挑戰。對於如何應對每種特質所帶來的挑戰，我也給出一些簡短的建議，希望這些挑戰不會阻止大家採用 Serverless 架構。

每當新技術出現時，技術專家的首要任務就是要理解採用新技術的意義。Serverless（無服務器）架構就是一個很好的例子。

不幸的是，目前關於 Serverless 架構的文獻大多都只關注於它的優點。許多文章（以及使用示例）都是由雲供應商推出的，因此，會毫不意外地談論其積極方面。本文的意圖是讓大家更好地理解 Serverless 架構的特質。

我特意選了特質（Trait）這個詞，而不是特性（Characteristic），因爲這些是 Serverless 架構的元素，我們無法更改它們。Characteristic 特性是可塑的，而 Trait 特質是固有的。Trait 特質也是中性的，因此它既不是積極的也不是消極的。在某些情況下，我所描述的某些類型的 Trait 特質可能具有積極的含義，但我會保持中立的態度，以便你瞭解自己將要面對的是什麼。

Trait 特質也是內在的，因此你必須要接受它們，而不是與之抗爭，因爲這樣嘗試的話可能會付出相當大的代價。另一方面， Characteristic 特性需要花費精力去塑造它們，然而你仍有可能會把它們搞錯。

我還應該向大家介紹 Mike Roberts 的這篇文章，他也探討了 Serverless 服務 的 Traits 特質。儘管我們在這裏使用了相同的術語，但值得注意的是，本文所研究的是架構的 Traits 特質，而不是你所使用的服務的 Traits 特質。

本文的目的不是幫助你深入理解所有的主題，而是爲你提供一個大致的概述。以下是本文中定義的 Serverless 架構的 Traits 特質：

1. 入門門檻低（Low barrier-to-entry）

2. 無主機（Hostless）

3. 無狀態（Stateless）

4. 彈性（Elasticity）

5. 分佈式（Distributed）

6. 事件驅動（Event-driven）

1 入門門檻低

讓你的代碼開始在 Serverless 架構中運行相對來說是簡單的。你可以參照任何教程來開始，並讓代碼在生產級生態系統中運行。在許多方面，Serverless 架構的學習曲線並沒有典型的 DevOps 技能 那麼令人生畏——當你使用 Serverless 架構時，DevOps 的許多元素就都是不必要的了。例如，你不必學習服務器管理技能，如配置管理或補丁。這就是爲什麼入門門檻低是 Serverless 架構的 Traits 特質之一。

這意味着，最初開發人員的學習曲線比許多其他架構風格的曲線都要低。但這並不意味着學習曲線會一直保持在較低的水平，事實上，隨着開發人員繼續他們的旅程，整體學習曲線將會變得更陡峭。

由於這種架構特質，我看到許多新的開發人員很快就加入到了項目中，並且他們能夠有效地爲項目做出貢獻。開發人員能夠快速上手，這可能是 Serverless 項目能 更快上市的原因之一。

正如我們所指出的那樣，事情確實會變得更加複雜。例如，基礎設施即代碼（Infrastructure as a code，Iac）、日誌管理、監控，有時還包括網絡，這些仍然都是必不可少的。你必須要了解如何在 Serverless 的世界中實現它們。如果你來自不同的開發背景，那麼你需要了解一些 Serverless 架構的 Traits 特質（本文將介紹這些 Traits 特質）。

儘管最初的入門門檻很低，但開發人員不應該認爲他們可以忽略重要的架構原則。

我注意到，一些開發人員傾向於認爲 Serverless 架構意味着他們不必考慮代碼設計。理由是他們只是在處理函數，所以代碼設計是無關緊要的。事實上，像 SOLID 這樣的設計原則仍然適用——你不能將代碼的可維護性外包給你的 Serverless 平臺。儘管你可以將代碼打包並上傳到雲上運行，但我強烈建議你不要這樣做，因爲持續交付實踐在 Serverless 架構中仍然是相關的。

2 無主機

Serverless 架構的一個明顯特質是，你無需直接處理服務器。在這個時代，你可以在各種各樣的主機上安裝並運行服務——無論是物理機、虛擬機、容器等等——用一個詞來描述這一點是很有用的。爲了避免使用已經使用過的術語 “無服務器”（“serverless”），我將在這裏使用“主機”（“host”，術語“主機” 在 《構建微服務》 一書中使用過）這個詞，因此該 trait 特質名爲“無主機”（Hostless）。

無主機的一個優勢是，你在服務器維護方面的操作開銷將會大大減少。你無需再爲升級服務器而憂心，安全補丁將自動爲你執行。無主機還意味着在應用程序中你需要監控的度量指標也會不同。這是因爲你使用的大多數底層服務不會再發布 CPU、內存、磁盤大小等傳統度量指標了。這意味着你不再需要理解架構的低級操作細節。

但不同的監控指標意味着，你必須重新學習如何調整你的架構。AWS DynamoDB 提供了可以供你進行監控和調控的讀寫能力，這是一個你必須要了解的概念，而且這種學習是不能遷移到其他 Serverless 平臺的。你使用的每項服務都有其侷限性。AWS Lambda 具有併發執行的限制，你所擁有的 CPU 核數不存在限制。更奇怪的是，更改 Lambda 的內存分配大小將會更改獲得的 CPU 核數。如果你爲了性能測試和生產環境共享一個 AWS 帳戶，那麼如果性能測試意外地消耗了你的全部併發執行限制，可能會導致生產的宕機。AWS 很好地記錄了每項服務的限制，因此請務必檢查它們，以便做出正確的架構決策。

一個常見的誤解是，Serverless 應用程序更安全，因爲安全補丁會自動應用於你的底層服務器。這個假設很危險。

由於 Serverless 架構具有不同的攻擊向量，傳統的安全防護已不再適用。應用程序的安全實踐仍然適用，並且在代碼中存儲祕密仍然是一個很大的禁忌。AWS 在其 責任共擔模式 中概述了這一點，例如，如果數據包含敏感信息，你仍然需要保護數據。我強烈建議你閱讀 10 大 OWASP Serverless 項目 以獲得更多有關該主題的見解。

雖然你的運維操作開銷大大減少了，但值得注意的是，在極少數情況下，你仍然需要管理底層服務器更改後的影響。你的應用程序可能依賴於原生庫，並且你需要確保在升級基礎操作系統時它們仍可以工作。例如，在 AWS Lambda 中，操作系統最近已升級到了 AMI 2018.03。

3 無狀態

函數即服務，即 FaaS，是很短暫的，因此你不能在內存中存儲任何內容，因爲運行代碼的計算容器將由平臺自動創建和銷燬。因此，無狀態（Stateless）是 Serverless 架構中的一個 Trait 特質。

無狀態是水平擴展應用程序的一個很好的特質。無狀態的概念是鼓勵你在應用程序中不要存儲狀態。通過不在應用程序中存儲狀態，你將能夠啓動更多的實例，而無需擔心應用程序的狀態，從而實現水平擴展。我在這裏發現了一個有趣的點，實際上無狀態是被迫的，因此錯誤的空間大大減少了。是的，這裏有一些注意事項：例如，計算容器可能會被重複使用，你可以存儲狀態，但是如果你採用這種方法，請務必謹慎處理。

就應用程序開發而言，你將無法使用需要狀態的技術，因爲狀態管理的負擔是強加給調用方的。例如，不能使用 HTTP 會話，因爲你沒有具有持久化文件存儲的傳統 Web 服務器。如果你想使用 WebSockets 等需要狀態的技術，那麼你需要等待，等到相應的後端即服務（BaaS）支持這些技術爲止，或者應用你自己的解決方案。

4 彈性

由於你的架構是無主機的，那麼你的架構也將具有彈性的特質。你使用的大多數 Serverless 服務都被設計爲具有高彈性，你可以從零擴展到允許的最大值，然後再回到零，大部分是自動管理的。彈性是 Serverless 架構的一個 Trait 特質。

對於可擴展性來說，彈性的好處是巨大的。這意味着你不必手動管理資源擴展。資源分配的許多挑戰都消失了。在某些情況下，具有彈性可能只意味着你只需爲所使用的內容付費，因此，如果你的使用模式較低，則可以降低運行成本。

你可能需要將 Serverless 架構與不支持這種彈性的遺留系統集成。當這種情況發生時，你可能會破壞下游系統，因爲它們可能無法像 Serverless 架構那樣擴展。如果你的下游系統是關鍵系統，那麼考慮如何緩解此問題是至關重要的——可能是通過限制 AWS Lambda 的併發性或利用隊列與下游系統對話。

雖然在這種高彈性的情況下，“拒絕服務” 攻擊（denial of service，DOS）將會變得更加困難，反而更容易受到 “拒絕錢包”（denial of wallet）攻擊。在這種情況下，攻擊者試圖通過強制增加資源分配來迫使你超出雲帳戶的限制，從而破壞應用程序。爲了防止這種攻擊，你可能會發現在你的應用程序中使用 DDoS 保護（如 AWS Shield）是很有幫助的。在 AWS 中，設置 AWS 預算也很有用，這樣當你的雲賬單暴漲時，你就會收到通知。如果高彈性不是你所期望的，那麼在應用程序上設置約束是很有用的，比如通過限制 AWS Lambda 併發性。

5 分佈式

由於無狀態計算是一種特質，所有的持久性需求都將存儲在後端即服務（BaaS）中，通常是 BaaS 的組合中。一旦你更多地使用 FaaS，你還會發現你的部署單元（即函數）比你已習慣了的可能還要小。因此，在默認情況下，Serverless 架構是分佈式的，並且有許多組件必須要通過網絡來進行集成。你的架構還將包括將服務連接在一起，比如身份驗證、數據庫、分佈式隊列等。

分佈式系統有很多好處，比如我們前面討論過的彈性。在默認情況下，分佈式還能爲你的架構帶來了單區域的高可用性。在 Serverless 環境中，當雲供應商所在區域的某個可用性區域出現故障時，你的架構將能夠利用其他仍在運行的可用性區域——從開發人員的角度來看，所有這些都是不透明的。

在選擇架構時總要權衡利弊。在這個特質中，你犧牲了一致性來換取可用性。通常在雲上，每個 Serverless 服務也都有自己的一致性模型。例如，在 AWS S3 中，通過在 S3 桶中對新對象的 PUT 操作可以獲得 “寫後讀”（read-after-write）的一致性。對於對象更新，S3 是最終一致的。對於你來說，決定使用哪種 BaaS 是很常見的，因此要注意它們的一致性模型的行爲。

另一個挑戰是你需要熟悉分佈式消息的傳遞方法。例如，你需要熟悉並瞭解 精確一次投遞（exactly-once delivery） 這一難題，因爲分佈式隊列的常見消息投遞方式是至少一次投遞（at-least-once-delivery）。由於這種投遞方式，AWS Lambda 可以被多次調用，因此你必須確保你的實現是冪等的（瞭解 FaaS 的重試行爲也很重要，其中 AWS Lambda 可能會在失敗時多次執行）。你需要了解的其他挑戰還包括分佈式事務的行爲。然而，隨着微服務的普及，構建分佈式系統的學習資源一直在演進。

6 事件驅動

Serverless 平臺提供的許多 BaaS 自然會支持事件。對於第三方服務來說，這是一個很好的策略，它們可以爲其用戶提供可擴展性，因爲你無法控制他們服務的代碼。由於你將在 Serverless 架構中使用大量的 BaaS，因此你的架構是具有事件驅動這一 Trait 特質的。

我還認識到，即使你的架構是具有事件驅動這一 Trait 特質的，但這並不意味着你需要完全採用事件驅動的架構。然而，我觀察到，當將事件驅動架構自然地提供給團隊時，團隊更傾向於接受它。這個特質和彈性特質類似，不需要時，你仍然可以關閉它。

事件驅動能帶來很多好處。架構組件之間的耦合程度很低。在 Serverless 架構中，你可以很容易地引入一個新函數來監聽 blob 存儲中的更改：

注意，當添加函數 B 時，函數 A 並沒有改變（參見圖 1）。這增加了函數的內聚性。函數具有高內聚是有很多好處的，其中一個好處是當單個操作失敗時，你可以輕鬆地重試該操作。當函數 B 失敗重試時，意味着你不需要運行高昂的函數 A。

特別是在雲計算中，雲供應商將確保你的 FaaS 與他們的 BaaS 能夠輕鬆集成。FaaS 可以被設計成由 事件通知 觸發。

事件驅動架構的缺點是，開始時你可能會失去系統作爲一個整體的整體視圖。這會使得對系統進行故障排除變得更具挑戰性。分佈式跟蹤是你應該研究的一個領域，儘管它在 Serverless 架構中仍然是一個成熟的領域。AWS X-Ray 是一種可以在 AWS 中開箱即用的服務。X-Ray 確實有其自身的侷限性，如果你已經超越了它，你應該關注這個領域，因爲有第三方的產品正在湧現。這就是爲什麼記錄關聯 ID（Correlation IDs）的實踐是必不可少的，特別是在事務中使用多個 BaaS 的情況下。所以一定要確保實現關聯 ID。

7 結論

本文介紹了 Serverless 架構的六個 Traits 特質：入門門檻低、無主機、無狀態、彈性、分佈式和事件驅動。我的目的是倡導大家儘可能廣泛地採用 Serverless 架構。Serverless 架構帶來了一個有趣的範式轉變，這使得軟件開發的許多方面都變得更好了。但它也帶來了技術人員必須要適應的新挑戰。對於如何應對每種 Trait 特質所帶來的挑戰，我也給出一些簡短的建議，希望這些挑戰不會阻止你採用 Serverless 架構。

原文鏈接：

https://www.thoughtworks.com/insights/blog/traits-serverless-architecture

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/-wNcVePM2PpsOK6JtFMw7A