文章一：10 Must-Know Cloud Native Architecture Patterns

前言

• 段落重點：在雲原生環境中，軟體架構的方法可能略有不同。這些應用程式廣泛地以微服務的形式建構。此外，為了利用雲端運算模型，這些應用程式應該能夠在動態編排和容器化的環境中運行。雲原生運算是軟體開發中的一種方法，它利用雲端運算來「在現代、動態的環境（如公有、私有和混合雲）中建構和運行可擴展的應用程式」。雲端環境中軟體架構的動機是關注點分離（separation of concerns），特別是為了在容器中模組化軟體元件。
• 段落總結：本段介紹雲原生架構的核心理念：應用程式應以微服務形式，在容器化環境中運行，其主要動機是透過關注點分離來達成軟體元件的模組化，以充分利用雲端的可擴展性與動態性。

1. 邊車/夥伴模式 (Sidecar/Sidekick)

• 段落重點：當您想將主應用程式的某些周邊部分抽象到不同的微服務中時，此模式很有幫助。這有助於實現服務之間的獨立性，打破緊密耦合的元件。如果應用程式使用相同的語言和函式庫，並且需要一個共享生命週期但可以獨立部署的服務，那麼邊車/夥伴模式是一個有用的選擇。此模式與主服務呈 1:1 的關係，例如，可以將日誌記錄、組態設定等功能抽象到另一個微服務中。
• 段落總結：邊車模式將輔助功能（如日誌、監控）從主應用程式中分離出來，作為一個獨立的容器運行，兩者共享生命週期。這實現了關注點分離，但需評估為每個實例額外部署邊車所帶來的資源成本。

2. 大使模式 (Ambassador)

• 段落重點：大使模式通常用於擴展現有服務的網路能力，特別是在該服務老舊或複雜到難以修改的情況下。大使服務可以被認為是與客戶端共同部署的「進程外代理」(out-of-process proxy)。與邊車模式不同，此模式可以用於多個服務。它有助於增強舊版服務的連接功能。但如果低延遲至關重要，則此模式不是一個好選擇，因為它會帶來代理的額外開銷。
• 段落總結：大使模式透過部署一個代理來封裝對遠端服務的網路存取，對客戶端應用程式透明化。它適用於為舊有或難以修改的服務提供統一的網路功能（如重試、監控），但會增加延遲。

3. 分散/收集模式 (Scatter/Gather)

• 段落重點：如果舊版應用程式正在使用多個冗餘的服務，則使用此模式。此模式的主要思想是有一個匯總器（aggregator），它總結來自不同服務的回應，並提供最佳的報價。此模式有利於控制流向所有微服務的訊息流程。
• 段落總結：分散/收集模式透過一個中央代理將請求「分散」到多個下游服務，然後「收集」它們的回應並整合成單一回應。它適用於需要從多個資料來源查詢資訊的場景。

4. 前端的後端模式 (Backends For Frontends, BFF)

• 段落重點：此模式的要點是在前端和真正的後端之間建立另一個後端層，稱為「前端的後端」。這是業界廣泛應用的最受歡迎的模式之一。通過添加這種額外的層，您可以協調不同的前端和後端伺服器，驗證和過濾來自前端的回應，以及對應和轉換從後端傳來的資料模型。
• 段落總結：BFF 模式主張為每種不同的前端客戶端（如 Web、行動 App）建立一個專屬的後端服務。這個中間層負責處理特定前端的資料剪裁、格式轉換和請求聚合，從而簡化前端開發並避免後端服務過於臃腫。

5. 防腐層模式 (Anti-Corruption Layer, ACL)

• 段落重點：如果您有不同的子系統或微服務，它們不共享相同的語意，那麼這個模式可能非常有用。防腐層會在這​​些服務之間進行通訊的翻譯或整合。這個模式最初由 Eric Evans 在《領域驅動設計》中描述。當您正在將舊有系統遷移到新系統，並且部分新系統需要使用舊系統的功能時，這種情況很可能發生。其缺點是增加了延遲和需要維護的額外服務。
• 段落總結：防腐層是一個位於新舊系統或兩個不同領域模型之間的轉譯層。它的作用是保護新系統的領域模型不被舊系統的複雜或不一致的模型所「腐蝕」，確保新系統的純粹性，常見於系統現代化改造的過程中。

6. 命令查詢責任分離模式 (CQRS)

• 段落重點：此模式基於資料庫讀取和更新方面的關注點分離。在傳統架構中，如果讀取執行許多查詢而寫入實現非常複雜的驗證和業務邏輯，就會出現資料複雜性問題。CQRS 將這些讀寫操作分離到不同的元件中：用於更新的「命令」(Commands) 和用於讀取的「查詢」(Queries)。命令應是基於任務的（例如「預訂飯店房間」），並透過非同步通訊實現。查詢永遠不會改變資料庫。此模式的一個缺點是需要保持讀寫元件的同步。
• 段落總結：CQRS 模式將資料的讀取（查詢）操作和寫入（命令）操作模型完全分離。這允許針對讀取和寫入的不同需求（如效能、一致性）進行獨立的優化和擴展，特別適用於讀寫負載不對稱的複雜系統。

7. 事件溯源模式 (Event Sourcing)

• 段落重點：事件溯源模式是近十年來流行的技術之一，用於解決 CRUD 應用程式缺乏一致性的情況。其主要思想不是僅僅保存當前狀態，而是以僅附加（append-only）的方式保存對資料執行的完整系列操作（事件）。它為交易資料提供了一致性，並對編輯歷史保持了完整的審計控制。事件對於領域專家來說是可讀的。缺點是對於小型領域應用程式可能被視為過度設計。
• 段落總結：事件溯源模式不直接儲存物件的最終狀態，而是儲存導致該狀態的一系列不可變的「事件」。系統的當前狀態可以透過重播這些事件來重建。這提供了完整的歷史追蹤、簡化了業務邏輯，並常與 CQRS 結合使用。

8. 服務網格模式 (Service Mesh)

• 段落重點：在軟體架構中，服務網格是一個專用的基礎設施層，用於促進服務或微服務之間的服務到服務通訊，通常使用代理（proxy）。其主要思想是將與應用程式無關的橫切關注點（如通訊、監控、安全性、身份驗證/授權等）與核心業務邏輯隔離。這種專用的基礎設施層為低延遲和可配置性增加了價值，並提供斷路（Circuit Breaking）、速率限制（Rate Limiting）等關鍵能力。
• 段落總結：服務網格是一個獨立的基礎設施層，它透過在每個微服務旁部署一個輕量級代理（通常是 Sidecar 模式）來處理服務間通訊。它將網路流量管理、可觀測性和安全性等複雜問題從業務邏輯中抽離，實現了集中管理和控制。

9. 笨拙-智慧元件模式 (Dumb-Smart Components)

• 段落重點：這是由關注點分離引發的下一個模式，主要面向前端。這裡我們有兩種元件：僅用於展示的「笨拙元件」(Dumb components)，以及負責資料流的「智慧元件」(Smart Components)，從而將展示與資料注入分離。智慧元件通常注入服務或外觀（Facade）並處理資料流。
• 段落總結：此前端架構模式將元件分為兩類：「智慧元件」（或稱容器元件）負責獲取資料和處理業務邏輯，「笨拙元件」（或稱展示元件）則只負責根據傳入的資料（props）進行渲染，不包含任何業務邏輯。這種分離提高了元件的可複用性和可測試性。

10. 單向架構模式 (Unidirectional Architecture)

• 段落重點：這主要與響應式編程（reactive programming）相結合。現今前端框架中的資料流是單向的，由資料流（data flow streams）驅動。資料僅朝著一個方向流動，即流向視圖（view）。視圖反過來會觸發不同的操作（actions）。這提供了對資料更好的控制。像 RxJs、NgRx、Flux 這樣的函式庫在處理資料流時啟用了多種功能。
• 段落總結：此前端模式強調資料流只能有一個方向：從狀態（State）流向視圖（View），而任何對狀態的更改都必須通過觸發一個動作（Action）來發起。這種可預測的資料流動方式簡化了應用程式的狀態管理，使除錯變得更加容易，是現代前端框架（如 React、Vue）的核心思想。

文章一總結

這篇文章介紹了十種在建構雲原生應用時必須了解的關鍵架構模式。作者指出，雲原生架構的核心在於利用微服務和容器化技術實現「關注點分離」，從而建構出可擴展、有彈性的系統。

文章涵蓋的模式從服務層級的協作到資料管理的策略，再到前端的設計思想，構成了一套完整的雲原生架構工具箱：

• 服務協作與擴展：

  • Sidecar：將輔助功能（如日誌）分離到伴生容器中。
  • Ambassador：作為外部服務的本地代理，封裝網路複雜性。
  • Anti-Corruption Layer：在新舊系統間建立翻譯層，保護新模型。
  • Service Mesh：透過代理網格將服務間通訊的通用功能（如安全、監控）從業務邏輯中抽離。

• 請求處理與聚合：

  • Scatter/Gather：將請求分發給多個服務並匯總結果。
  • Backends For Frontends (BFF)：為不同前端提供量身定制的後端 API。

• 資料管理策略：

  • CQRS：將資料的讀（查詢）和寫（命令）操作分離，以便獨立優化。
  • Event Sourcing：不儲存最終狀態，而是儲存導致該狀態的所有事件序列，提供完整的審計追蹤。

• 前端架構：

  • Dumb-Smart Components：將負責資料邏輯的「智慧元件」與只負責渲染的「笨拙元件」分離。
  • Unidirectional Architecture：確保資料流的單向性，使狀態管理更可預測。

總結來說，這些模式並非孤立存在，而是相輔相成，共同解決了在分散式、動態的雲端環境中會遇到的模組化、通訊、資料一致性和可維護性等挑戰。對於任何希望建構穩健、可擴展的雲原生應用的架構師或開發者而言，理解並掌握這些模式至關重要。