作者 | Wisen Tanasa
編譯 | 劉雅夢
策劃 | 辛曉亮

本文介紹了 Serverless（無服務器）架構的六個特質（Traits）：入門門檻低（Low barrier-to-entry）、無主機（Hostless）、無狀態（Stateless）、彈性（Elasticity）、分布式（Distributed）和事件驅動（Event-driven）。其目的是倡導大家盡可能廣泛地采用 Serverless 架構。

Serverless 架構帶來了一個有趣的范式轉變，這使得軟件開發的許多方面都變得更好了。但它也帶來了技術人員必須要適應的新挑戰。對于如何應對每種特質所帶來的挑戰，我也給出一些簡短的建議，希望這些挑戰不會阻止大家采用 Serverless 架構。
每當新技術出現時，技術專家的首要任務就是要理解采用新技術的意義。Serverless（無服務器）架構就是一個很好的例子。
不幸的是，目前關于 Serverless 架構的文獻大多都只關注于它的優點。許多文章（以及使用示例）都是由云供應商推出的，因此，會毫不意外地談論其積極方面。本文的意圖是讓大家更好地理解 Serverless 架構的特質。

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

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

無主機（Hostless）

無狀態（Stateless）

彈性（Elasticity）

分布式（Distributed）

事件驅動（Event-driven）

01 入門門檻低

讓你的代碼開始在 Serverless 架構中運行相對來說是簡單的。你可以參照任何教程來開始，并讓代碼在生產級生態系統中運行。在許多方面，Serverless 架構的學習曲線并沒有典型的 DevOps 技能 那么令人生畏——當你使用 Serverless 架構時，DevOps 的許多元素就都是不必要的了。
例如，你不必學習服務器管理技能，如配置管理或補丁。這就是為什么入門門檻低是 Serverless 架構的 Traits 特質之一。
這意味著，最初開發人員的學習曲線比許多其他架構風格的曲線都要低。但這并不意味著學習曲線會一直保持在較低的水平，事實上，隨著開發人員繼續他們的旅程，整體學習曲線將會變得更陡峭。
由于這種架構特質，我看到許多新的開發人員很快就加入到了項目中，并且他們能夠有效地為項目做出貢獻。開發人員能夠快速上手，這可能是 Serverless 項目能 更快上市的原因之一。
正如我們所指出的那樣，事情確實會變得更加復雜。例如，基礎設施即代碼（Infrastructure as a code，Iac）、日志管理、監控，有時還包括網絡，這些仍然都是必不可少的。你必須要了解如何在 Serverless 的世界中實現它們。如果你來自不同的開發背景，那么你需要了解一些 Serverless 架構的 Traits 特質（本文將介紹這些 Traits 特質）。

02 無主機

Serverless 架構的一個明顯特質是，你無需直接處理服務器。在這個時代，你可以在各種各樣的主機上安裝并運行服務——無論是物理機、虛擬機、容器等。
無主機的一個優勢是，你在服務器維護方面的操作開銷將會大大減少。你無需再為升級服務器而憂心，安全補丁將自動為你執行。無主機還意味著在應用程序中你需要監控的度量指標也會不同。這是因為你使用的大多數底層服務不會再發布 CPU、內存、磁盤大小等傳統度量指標了。這意味著你不再需要理解架構的低級操作細節。
但不同的監控指標意味著，你必須重新學習如何調整你的架構。AWS DynamoDB 提供了可以供你進行監控和調控的讀寫能力，這是一個你必須要了解的概念，而且這種學習是不能遷移到其他 Serverless 平臺的。你使用的每項服務都有其局限性。AWS Lambda 具有并發執行的限制，你所擁有的 CPU 核數不存在限制。更奇怪的是，更改 Lambda 的內存分配大小將會更改獲得的 CPU 核數。如果你為了性能測試和生產環境共享一個 AWS 帳戶，那么如果性能測試意外地消耗了你的全部并發執行限制，可能會導致生產的宕機。AWS 很好地記錄了每項服務的限制，因此請務必檢查它們，以便做出正確的架構決策。
一個常見的誤解是，Serverless 應用程序更安全，因為安全補丁會自動應用于你的底層服務器。這個假設很危險。
由于 Serverless 架構具有不同的攻擊向量，傳統的安全防護已不再適用。應用程序的安全實踐仍然適用，并且在代碼中存儲秘密仍然是一個很大的禁忌。AWS 在其責任共擔模式中概述了這一點。例如，如果數據包含敏感信息，你仍然需要保護數據。我強烈建議你閱讀 10 大 OWASP Serverless 項目 以獲得更多有關該主題的見解。
雖然你的運維操作開銷大大減少了，但值得注意的是，在極少數情況下，你仍然需要管理底層服務器更改后的影響。你的應用程序可能依賴于原生庫，并且你需要確保在升級基礎操作系統時它們仍可以工作。例如，在 AWS Lambda 中，操作系統最近已升級到了AMI 2018.03。

03 無狀態

函數即服務，即 FaaS，是很短暫的，因此你不能在內存中存儲任何內容，因為運行代碼的計算容器將由平臺自動創建和銷毀。因此，無狀態（Stateless）是 Serverless 架構中的一個 Trait 特質。
無狀態是水平擴展應用程序的一個很好的特質。無狀態的概念是鼓勵你在應用程序中不要存儲狀態。通過不在應用程序中存儲狀態，你將能夠啟動更多的實例，而無需擔心應用程序的狀態，從而實現水平擴展。我在這里發現了一個有趣的點，實際上無狀態是被迫的，因此錯誤的空間大大減少了。是的，這里有一些注意事項：例如，計算容器可能會被重復使用，你可以存儲狀態，但是如果你采用這種方法，請務必謹慎處理。
就應用程序開發而言，你將無法使用需要狀態的技術，因為狀態管理的負擔是強加給調用方的。例如，不能使用 HTTP 會話，因為你沒有具有持久化文件存儲的傳統 Web 服務器。如果你想使用 WebSockets 等需要狀態的技術，那么你需要等待，等到相應的后端即服務（BaaS）支持這些技術為止，或者應用你自己的解決方案。

04 彈性

由于你的架構是無主機的，那么你的架構也將具有彈性的特質。你使用的大多數 Serverless 服務都被設計為具有高彈性，你可以從零擴展到允許的最大值，然后再回到零，大部分是自動管理的。彈性是 Serverless 架構的一個 Trait 特質。
對于可擴展性來說，彈性的好處是巨大的。這意味著你不必手動管理資源擴展。資源分配的許多挑戰都消失了。在某些情況下，具有彈性可能只意味著你只需為所使用的內容付費，因此，如果你的使用模式較低，則可以降低運行成本。
你可能需要將 Serverless 架構與不支持這種彈性的遺留系統集成。當這種情況發生時，你可能會破壞下游系統，因為它們可能無法像 Serverless 架構那樣擴展。如果你的下游系統是關鍵系統，那么考慮如何緩解此問題是至關重要的——可能是通過限制 AWS Lambda 的并發性或利用隊列與下游系統對話。
雖然在這種高彈性的情況下，“拒絕服務”攻擊（denial of service，DOS）將會變得更加困難，反而更容易受到“拒絕錢包”（denial of wallet）攻擊。在這種情況下，攻擊者試圖通過強制增加資源分配來迫使你超出云帳戶的限制，從而破壞應用程序。為了防止這種攻擊，你可能會發現在你的應用程序中使用 DDoS 保護（如 AWS Shield）是很有幫助的。在 AWS 中，設置 AWS 預算也很有用，這樣當你的云賬單暴漲時，你就會收到通知。如果高彈性不是你所期望的，那么在應用程序上設置約束是很有用的，比如通過限制 AWS Lambda 并發性。

05 分布式

由于無狀態計算是一種特質，所有的持久性需求都將存儲在后端即服務（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 可能會在失敗時多次執行）。你需要了解的其他挑戰還包括分布式事務的行為。然而，隨著微服務的普及，構建分布式系統的學習資源一直在演進。

06 事件驅動

Serverless 平臺提供的許多 BaaS 自然會支持事件。對于第三方服務來說，這是一個很好的策略，它們可以為其用戶提供可擴展性，因為你無法控制他們服務的代碼。由于你將在 Serverless 架構中使用大量的 BaaS，因此你的架構是具有事件驅動這一 Trait 特質的。
我還認識到，即使你的架構是具有事件驅動這一 Trait 特質的，但這并不意味著你需要完全采用事件驅動的架構。然而，我觀察到，當將事件驅動架構自然地提供給團隊時，團隊更傾向于接受它。這個特質和彈性特質類似，不需要時，你仍然可以關閉它。
事件驅動能帶來很多好處。架構組件之間的耦合程度很低。在 Serverless 架構中，你可以很容易地引入一個新函數來監聽 blob 存儲中的更改：
注意，當添加函數 B 時，函數 A 并沒有改變。這增加了函數的內聚性。函數具有高內聚是有很多好處的，其中一個好處是當單個操作失敗時，你可以輕松地重試該操作。當函數 B 失敗重試時，意味著你不需要運行高昂的函數 A。
特別是在云計算中，云供應商將確保你的 FaaS 與他們的 BaaS 能夠輕松集成。FaaS 可以被設計成由 事件通知 觸發。
事件驅動架構的缺點是，開始時你可能會失去系統作為一個整體的整體視圖。這會使得對系統進行故障排除變得更具挑戰性。分布式跟蹤是你應該研究的一個領域，盡管它在 Serverless 架構中仍然是一個成熟的領域。AWS X-Ray 是一種可以在 AWS 中開箱即用的服務。X-Ray確實有其自身的局限性，如果你已經超越了它，你應該關注這個領域，因為有第三方的產品正在涌現。這就是為什么記錄關聯 ID（Correlation IDs）的實踐是必不可少的，特別是在事務中使用多個 BaaS 的情況下。所以一定要確保實現關聯 ID。

07 結論

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

總結

以上是生活随笔為你收集整理的盘点 Serverless 架构的六个特质的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。