在構(gòu)建云原生應(yīng)用程序時，采用了一些不同的軟件架構(gòu)方法。云原生應(yīng)用程序通常采用微服務(wù)架構(gòu)，以最大程度地利用云計算模型的優(yōu)勢。這些應(yīng)用程序需要能夠在動態(tài)編排和容器化環(huán)境中運行。

云原生計算是一種在現(xiàn)代、動態(tài)環(huán)境（如公有云、私有云和混合云）中構(gòu)建和運行可擴(kuò)展應(yīng)用程序的軟件開發(fā)方法。

云環(huán)境中，軟件架構(gòu)的主要目標(biāo)是關(guān)注點的分離，特別是通過將軟件組件模塊化到容器中。為了實現(xiàn)這一目標(biāo)，有幾種模式可供選擇。本文介紹一些常用模式。

1 邊車/副車模式

邊車/副車模式（Sidecar/Adaptor Pattern）用于將主要應(yīng)用程序的一些外圍功能或附加功能抽象為獨立的微服務(wù)。這種模式可以實現(xiàn)服務(wù)之間的獨立性，打破緊密耦合的組件。

邊車/副車模式適用于應(yīng)用程序使用相同的語言和庫，并且需要一個共享生命周期但可以獨立部署的服務(wù)。然而，如果為每個實例部署邊車服務(wù)的資源成本超過隔離優(yōu)勢，那么在應(yīng)用程序中實施邊車/副車模式可能不是一個明智的決策。例如，將日志記錄、配置等功能抽象到單獨的微服務(wù)中，如下面的示例所示，每個主要服務(wù)都有一個關(guān)聯(lián)的輔助服務(wù)，它們之間形成一對一的關(guān)系。在應(yīng)用邊車/副車模式時，需要綜合考慮資源成本和隔離優(yōu)勢。

邊車/副車模式

2 大使模式

大使模式（Ambassador Pattern）經(jīng)常用于擴(kuò)展現(xiàn)有服務(wù)的網(wǎng)絡(luò)功能，特別是對于那些過于古老或復(fù)雜且無法修改的服務(wù)。

大使服務(wù)可以被視為與客戶端共存的一個進(jìn)程外代理。

通過此模式添加額外的代理會增加延遲。與邊車不同，這種模式可以用于多個服務(wù)。這種模式對于增強(qiáng)遺留服務(wù)的連接功能非常有效。如果低延遲是關(guān)鍵因素，使用大使模式可能會增加代理開銷成本，因此不是一個好的選擇。

大使模式

3 散點/聚集模式

散點/聚集模式（Scatter/Gather Pattern）是一種用于并行處理大規(guī)模數(shù)據(jù)集的設(shè)計模式。這種模式的要點是有一個聚合器，匯總來自不同服務(wù)的響應(yīng)并提供最佳報價。這種模式對于控制消息流到所有微服務(wù)非常有用。

散點/聚集模式

散點/聚集模式適用于需要對大量數(shù)據(jù)進(jìn)行并行處理的情況，如分布式計算、數(shù)據(jù)分析、并行搜索等。它可以提高系統(tǒng)的處理速度和吞吐量，利用多個處理單元同時處理數(shù)據(jù)，從而加快處理過程。

4 前端后端模式

前端后端模式（Backends For Frontends Pattern）的主要要點是在前端和實際后端之間添加另一層后端，這被稱為前端后端。這是工業(yè)界廣泛應(yīng)用的最受歡迎的模式之一。通過添加這種額外的層，可以在不同的前端和后端服務(wù)器之間進(jìn)行編排，驗證過濾來自前端的響應(yīng)，映射和轉(zhuǎn)換來自后端的數(shù)據(jù)模型。

BFF模式

5 反腐敗層模式

反腐敗層模式（Anti-Corruption Layer Pattern）用于解決在不同子系統(tǒng)或微服務(wù)之間通信時的語義不匹配問題。這種模式最初由埃里克·埃文斯在領(lǐng)域驅(qū)動設(shè)計中描述。

當(dāng)存在多個子系統(tǒng)或微服務(wù)它們各自使用不同的語義和數(shù)據(jù)結(jié)構(gòu)時，可能會導(dǎo)致通信困難和混亂。反腐敗層模式的目標(biāo)是在這些不兼容的系統(tǒng)之間建立一個翻譯或轉(zhuǎn)換層，以確保它們之間能夠正確地交互和通信。這個層充當(dāng)了一個中間件，負(fù)責(zé)將一個系統(tǒng)的請求轉(zhuǎn)換為另一個系統(tǒng)可以理解的格式，并將響應(yīng)從一個系統(tǒng)的格式轉(zhuǎn)換為另一個系統(tǒng)可以接受的格式。

反腐敗層模式的缺點和注意事項：

• 增加了額外的中間層，可能會引入性能延遲。
• 需要額外的開發(fā)和維護(hù)工作來處理轉(zhuǎn)換邏輯。
• 需要確保反腐敗層的正確性和穩(wěn)定性，以避免引入更多問題。

反腐敗層模式

6 命令與查詢職責(zé)分離模式

命令與查詢職責(zé)分離模式（Command and Query Responsibility Segregation，CQRS）旨在將讀操作（查詢）和寫操作（命令）分離開來，以優(yōu)化系統(tǒng)的性能、可伸縮性和靈活性。

在傳統(tǒng)的應(yīng)用程序中，讀操作和寫操作通常共享相同的數(shù)據(jù)模型和數(shù)據(jù)庫，這會產(chǎn)生一些問題，例如當(dāng)需要進(jìn)行復(fù)雜查詢時，可能會對寫操作的性能產(chǎn)生影響，或者在需要高并發(fā)寫操作時可能會影響讀操作的性能。

解決方案是命令查詢職責(zé)分離（CQRS），將讀取和寫入分為不同的組件：

• 命令必須基于任務(wù)（例如“預(yù)訂酒店房間”而不是“將預(yù)訂狀態(tài)設(shè)置為已預(yù)訂”）。
• 命令通過異步通信實現(xiàn)。
• 查詢不會改變數(shù)據(jù)庫。查詢響應(yīng)使用不包含業(yè)務(wù)邏輯的數(shù)據(jù)傳輸對象（DTO）。

這種模式的缺點是需要保持讀取和寫入組件的同步。

命令查詢職責(zé)分離模式

7 事件溯源模式

事件溯源模式（Event Sourcing Pattern）是過去十年中流行的一種技術(shù)，用于處理CRUD應(yīng)用程序缺乏一致性的情況。與傳統(tǒng)CRUD應(yīng)用程序僅保存當(dāng)前狀態(tài)不同，事件溯源的主要是以追加方式保存數(shù)據(jù)，以存儲對數(shù)據(jù)執(zhí)行的完整系列操作。它提供了事務(wù)數(shù)據(jù)的一致性，保持了完整的編輯歷史記錄，提供完全的審計控制。

優(yōu)點：

• 通過實現(xiàn)強(qiáng)數(shù)據(jù)一致性來提高性能。
• 使用事件存儲簡化數(shù)據(jù)編輯的實現(xiàn)和管理。
• 事件對領(lǐng)域?qū)＜铱勺x，不僅對開發(fā)人員可理解。
• 防止對同一數(shù)據(jù)的并發(fā)更新，因為其事件的時間順序。
• 事件存儲作為數(shù)據(jù)操作的單一數(shù)據(jù)源。

缺點：

• 對于小型領(lǐng)域應(yīng)用來說可能過于工程化。
• 不適用于實時數(shù)據(jù)驅(qū)動的應(yīng)用程序。

8 服務(wù)網(wǎng)格模式

服務(wù)網(wǎng)格模式（Service Mesh Pattern）旨在提供對微服務(wù)之間通信、安全、監(jiān)控和可觀察性的細(xì)粒度控制。

此模式要點是將與應(yīng)用程序無關(guān)的橫切關(guān)注點（如通信、監(jiān)控、安全性、身份驗證/授權(quán)等）與核心業(yè)務(wù)邏輯隔離開來。這種專用基礎(chǔ)設(shè)施層為低延遲、可配置性增加了價值。

除了身份驗證/授權(quán)、服務(wù)發(fā)現(xiàn)，服務(wù)網(wǎng)格模式還提供其他重要功能，如：

• 斷路器
• 速率限制
• 條件速率限制
• 流量轉(zhuǎn)移

9 笨拙組件與智能組件（面向前端）模式

此模式是在關(guān)注點分離（SoC）原則基礎(chǔ)上的一種進(jìn)階模式。在這種模式中，將前端組件分為兩種類型：笨拙組件（Dumb Components）和智能組件（Smart Components）。笨拙組件主要負(fù)責(zé)呈現(xiàn)和展示數(shù)據(jù)，而智能組件則負(fù)責(zé)處理數(shù)據(jù)流和業(yè)務(wù)邏輯，將數(shù)據(jù)注入到笨拙組件中。主要通過在笨拙組件中基于@Input和@Output（EventEmitter）的雙向數(shù)據(jù)綁定實現(xiàn)。通過這些注解，笨拙組件從智能組件獲取相關(guān)數(shù)據(jù)，或?qū)?shù)據(jù)發(fā)送到智能組件。智能組件通常注入服務(wù)或外觀（Facade）并處理數(shù)據(jù)流。

10 單向架構(gòu)（面向前端）模式

單向架構(gòu)（面向前端）模式是一種結(jié)合響應(yīng)式編程的主要模式。在當(dāng)今的前端框架中，數(shù)據(jù)流是單向的，由數(shù)據(jù)流向驅(qū)動。數(shù)據(jù)僅以一種方向流向視圖，而視圖的反饋會觸發(fā)不同的操作。這種設(shè)計使得對數(shù)據(jù)的控制更加精確。在處理數(shù)據(jù)流時，使用不同的庫如RxJs、NgRx、Flux，可以提供多種功能和工具。