10 Must-Know Cloud Native Architecture Patterns

原始來源與檔名：10 Must-Know Cloud Native Architecture Patterns.md

這篇文章介紹了十種在雲原生環境中至關重要的架構模式，這些模式旨在解決微服務架構中常見的挑戰，如服務解耦、通訊、數據管理和關注點分離。

段落 段落重點 & 總結
引言 重點：雲原生應用程式廣泛地以微服務形式構建，運行於動態編排和容器化的環境中，以充分利用雲端運算模型。這些架構模式的動機是實現關注點分離，特別是將軟體元件模組化到容器中。

總結：在雲原生環境中，軟體架構採取了略微不同的方法。這些應用程式以微服務的形式大量構建，並且應該能夠在動態編排和容器化的環境中運行，以利用雲端運算的優勢。雲原生運算是一種軟體開發方法，它利用雲端運算來「在公有、私有和混合雲等現代動態環境中，建構和運行可擴展的應用程式」。在雲端環境中，軟體架構背後的動機是關注點分離 (separation of concerns)，特別是為了將軟體元件模組化到容器中。
1. Sidecar/Sidekick 重點：Sidecar 模式用於將主要應用程式的周邊功能（如日誌、監控）抽象到一個獨立的微服務中。它與主服務有 1:1 的關係，共享生命週期但可獨立部署。

總結：當您希望將主應用程式的某些周邊部分抽象到不同的微服務中時，此模式非常有用。Sidecar/Sidekick 模式適用於應用程式使用相同語言和函式庫，且需要一個共享生命週期但可獨立部署的服務。如果為每個實例部署 Sidecar 服務的資源成本不值得隔離所帶來的好處，那麼這將是一個糟糕的決定。如下方案例所示，諸如日誌記錄、組態等功能可以被抽象到另一個微服務中。此模式與主服務呈 1:1 的關係。

Sidecar/Sidekick Pattern
2. Ambassador 重點：Ambassador 模式作為一個同地部署的跨進程代理，用來擴展現有服務（特別是難以修改的舊版服務）的網路能力。它會帶來延遲，但可以被多個服務共用。

總結：Ambassador 模式通常用於擴展現有服務的網路能力，特別是當該服務過於老舊或複雜以致難以修改時。一個 Ambassador 服務可以被視為一個與客戶端同地部署 (co-located) 的跨進程代理。透過此模式增加額外的代理會帶來延遲。與 Sidecar 不同，此模式可以被多個服務使用。此模式有助於增強舊版服務的連接功能。如果低延遲至關重要，則此模式不是一個好的選擇，因為它有代理的開銷。

Ambassador Pattern
3. Scatter/Gather 重點：此模式透過一個聚合器，將請求分散到多個服務，然後收集並匯總它們的回應，以提供最佳結果。它適合用來控制流向所有微服務的訊息流。

總結：如果舊版應用程式正在使用冗餘的服務，此模式將被使用。該模式的主要思想是擁有一個聚合器，它會匯總來自不同服務的回應，並提供最佳的報價。此模式適合用來控制流向所有微服務的訊息流。

Scatter/Gather Pattern
4. Backends For Frontends (BFF) 重點：BFF 模式是在前端和真正的後端之間增加一個專為前端設計的後端層。這個層級可以針對不同的前端（如 Web、Mobile）進行請求的編排、驗證和數據轉換。

總結：此模式的主旨是在前端和真正的後端之間建立另一個後端層，這被稱為前端的後端 (Backend For Frontend)。這是業界廣泛應用的最受歡迎的模式之一。通過增加這樣一個額外的層，您可以在不同的前端和後端伺服器之間進行編排，驗證和過濾來自前端的回應，並對從後端傳遞的數據模型進行映射和轉換。

BFF Pattern
5. Anti-Corruption Layer (ACL) 重點：當不同子系統或微服務之間語義不一致時，ACL 作為一個翻譯層存在，轉換它們之間的通訊。它在從舊系統遷移到新系統時特別有用，但會增加延遲和資源消耗。

總結：當您有多個子系統或微服務不共享相同語義時，此模式可能非常有用。防腐層 (Anti-corruption Layer) 會翻譯或整合這些服務之間的通訊。這個模式最早由 Eric Evans 在《領域驅動設計》中描述。當您正在將舊系統遷移到新系統，並且部分新系統需要使用舊系統的資源或功能時，這種情況很可能發生。其缺點和副作用可能包括：這個額外的層增加了更多延遲，並且也是一個會佔用資源的額外服務。
6. Command and Query Responsibility Segregation (CQRS) 重點：CQRS 模式將數據庫的讀取（Query）和更新（Command）操作分離為不同的組件。命令是基於任務且異步的，而查詢則永不修改數據庫，從而應對讀寫不對稱的性能需求。

總結：此模式基於關注點分離 (SoC) 的原則，分離數據庫的讀取和更新操作。在傳統架構中，如果讀取執行大量查詢而寫入實現非常複雜的驗證和業務邏輯，就會出現數據複雜性問題。CQRS 的解決方案是將這些讀寫操作分離成不同的組件：用於更新的命令 (Commands) 和用於讀取的查詢 (Queries)。
* 命令必須是基於任務的（例如，「預訂飯店房間」，而不是「將預訂狀態設置為已預訂」）。
* 查詢永遠不會改變數據庫。查詢會回應一個不包含業務邏輯的 DTO。
此模式的一個缺點是需要保持讀寫組件的同步。
7. Event Sourcing 重點：事件溯源模式不儲存數據的當前狀態，而是以僅附加 (append-only) 的方式儲存對數據執行的完整操作序列（事件）。這提供了完整的審計追蹤和強大的數據一致性。

總結：事件溯源模式是近十年來流行的技術之一，特別適用於 CRUD 應用程式缺乏一致性的情況。事件溯源的核心思想是將數據以僅附加的方式保存，以儲存對數據採取的完整系列操作，而不是僅僅保存當前狀態。它為交易數據提供一致性，並對編輯歷史保持完整的審計控制。
優點：
* 通過允許強數據一致性來提高性能。
* 事件對領域專家來說是可讀的。
* 防止對相同數據的並行更新。
缺點：
* 對於小型領域應用程式可能被視為過度設計。
8. Service Mesh 重點：服務網格是一個專用的基礎設施層，使用代理來促進服務間的通訊。它將通訊、監控、安全等橫切關注點從核心業務邏輯中分離出來。

總結：在軟體架構中，服務網格 (Service Mesh) 是一個專用的基礎設施層，用於促進服務或微服務之間的服務到服務通訊，使用代理。其主要思想是將與應用程式無關的橫切關注點，如通訊、監控、安全、身份驗證/授權等，從核心業務邏輯中隔離出來。除了身份驗證/授權、服務發現之外，服務網格模式還提供了一些其他關鍵功能，如：
* 熔斷 (Circuit Breaking)
* 速率限制 (Rate Limiting)
* 流量轉移 (Traffic Shifting)
9. Dumb-Smart Components 重點：這是一個面向前端的模式，將組件分為只負責呈現的「笨組件 (Dumb components)」和負責數據流的「智慧組件 (Smart components)」，實現了呈現與數據注入的分離。

總結：這是另一個由關注點分離 (SoC) 衍生的模式。這裡我們有兩種組件：僅用於呈現的笨組件，以及負責數據流的智慧組件，從而將呈現與數據注入分離。這主要通過笨組件中基於 @Input 和 @Output (EventEmitter<T>) 的雙向數據綁定來實現。智慧組est 則通常注入服務 (Service) 或外觀 (Facade) 來處理數據流。
10. Unidirectional Architecture 重點：這是一個面向前端的響應式編程模式，數據流僅朝單一方向（流向視圖）流動，視圖再觸發不同的操作，從而更好地控制數據。

總結：這個模式主要與響應式編程 (reactive programming) 相關。現今前端框架中的數據流是單向的，由數據流驅動。數據僅朝一個方向流動，即流向視圖。視圖進而會激活不同的操作。這提供了對數據更好的控制。像 RxJs、NgRx、Flux 等不同的函式庫在處理數據流時啟用了多種功能。

整體結論

這篇文章精闢地介紹了十種雲原生架構中不可或缺的設計模式。作為資深工程師，我認為這些模式是現代微服務架構的基石。它們不僅是理論，更是解決實際工程挑戰的實用工具集。從 Sidecar 和 Ambassador 解決服務擴展與解耦，到 CQRS 和 Event Sourcing 應對複雜的數據管理，再到 BFF 和 ACL 處理前後端及異質系統間的通訊，這些模式共同構成了一個強大的框架，旨在打造高內聚、低耦合、可擴展且具備韌性的系統。對於任何致力於構建雲原生應用的架構師或開發者來說，深刻理解並在適當時機應用這些模式，是通往成功專案的關鍵。