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

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

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

1 邊車/副車模式

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

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

邊車/副車模式

2 大使模式

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

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

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

大使模式

3 散點(diǎn)/聚集模式

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

散點(diǎn)/聚集模式

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

4 前端后端模式

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

BFF模式

5 反腐敗層模式

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

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

反腐敗層模式的缺點(diǎn)和注意事項(xiàng)：

增加了額外的中間層，可能會(huì)引入性能延遲。

需要額外的開發(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ù)庫，這會(huì)產(chǎn)生一些問題，例如當(dāng)需要進(jìn)行復(fù)雜查詢時(shí)，可能會(huì)對(duì)寫操作的性能產(chǎn)生影響，或者在需要高并發(fā)寫操作時(shí)可能會(huì)影響讀操作的性能。

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

命令必須基于任務(wù)(例如“預(yù)訂酒店房間”而不是“將預(yù)訂狀態(tài)設(shè)置為已預(yù)訂”)。

命令通過異步通信實(shí)現(xiàn)。

查詢不會(huì)改變數(shù)據(jù)庫。查詢響應(yīng)使用不包含業(yè)務(wù)邏輯的數(shù)據(jù)傳輸對(duì)象(DTO)。

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

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

7 事件溯源模式

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

優(yōu)點(diǎn)：

通過實(shí)現(xiàn)強(qiáng)數(shù)據(jù)一致性來提高性能。

使用事件存儲(chǔ)簡化數(shù)據(jù)編輯的實(shí)現(xiàn)和管理。

事件對(duì)領(lǐng)域?qū)＜铱勺x，不僅對(duì)開發(fā)人員可理解。

防止對(duì)同一數(shù)據(jù)的并發(fā)更新，因?yàn)槠涫录臅r(shí)間順序。

事件存儲(chǔ)作為數(shù)據(jù)操作的單一數(shù)據(jù)源。

缺點(diǎn)：

對(duì)于小型領(lǐng)域應(yīng)用來說可能過于工程化。

不適用于實(shí)時(shí)數(shù)據(jù)驅(qū)動(dòng)的應(yīng)用程序。

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

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

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

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

斷路器

速率限制

條件速率限制

流量轉(zhuǎn)移

9 笨拙組件與智能組件(面向前端)模式

此模式是在關(guān)注點(diǎ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ù)綁定實(shí)現(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ū)動(dòng)。數(shù)據(jù)僅以一種方向流向視圖，而視圖的反饋會(huì)觸發(fā)不同的操作。這種設(shè)計(jì)使得對(duì)數(shù)據(jù)的控制更加精確。在處理數(shù)據(jù)流時(shí)，使用不同的庫如RxJs、NgRx、Flux，可以提供多種功能和工具。

推薦書單

《Tomcat源碼全解與架構(gòu)思維》

《Tomcat源碼全解與架構(gòu)思維》首先介紹了Tomcat的架構(gòu)、配置文件、源碼結(jié)構(gòu)，然后介紹了Tomcat的整體架構(gòu)與設(shè)計(jì)思維，幫助讀者建立一個(gè)整體的源碼構(gòu)建思維和Tomcat的“上帝視角”。然后詳細(xì)介紹了Tomcat的核心;組件生命周期與容器生命周期，因?yàn)樵赥omcat中，組件結(jié)構(gòu)是一棵多叉樹，我們需要統(tǒng)一管理它們的初始化、啟動(dòng)、停止、銷毀，而生命周期框架便貫穿始終。接下來向讀者展示了獨(dú)立部署的Tomcat啟動(dòng)器原理與內(nèi)嵌啟動(dòng)器原理(這里以SpringBoot內(nèi)嵌為例)，這樣有助于幫助讀者了解從哪些入口可以進(jìn)入Tomcat的源碼分析。緊接著向讀者展示了JDK的類加載器原理與Tomcat的類加載器設(shè)計(jì)，因?yàn)楦鶕?jù)Servlet的規(guī)范，每個(gè)Web應(yīng)用擁有自己的類加載器，簡稱Web類加載器，同時(shí)Tomcat自身也有自己的類加載器，所以當(dāng)采用獨(dú)立部署多個(gè)Web應(yīng)用時(shí)，就需要配置多級(jí)類加載器。最后以Server為項(xiàng)層組件從上到下，根據(jù)Tomcat的生命周期框架，順序向讀者逐一介紹了每個(gè)核心組件、子組件、容器、子容器的核心方法的實(shí)現(xiàn)原理。 《Tomcat源碼全解與架構(gòu)思維》適合以下讀者閱讀：需要求職進(jìn)入互聯(lián)網(wǎng)公司的讀者，對(duì)Tomcat底層知識(shí)感興趣的讀者，從事高并發(fā)支撐中間件及高并發(fā)業(yè)務(wù)支撐的讀者，以及對(duì)多線程感興趣的讀者和希望通過Tomcat源碼找到調(diào)優(yōu)點(diǎn)的讀者。