微服務(wù)架構(gòu)中10個(gè)常用的設(shè)計(jì)模式

微服務(wù)架構(gòu)中10個(gè)常用的設(shè)計(jì)模式從軟件開發(fā)早期（1960年代）開始，應(yīng)對(duì)大型軟件系統(tǒng)中的復(fù)雜性一直是一項(xiàng)令人生畏的任務(wù)。多年來為了應(yīng)對(duì)軟件系統(tǒng)的復(fù)雜性，軟件工程師和架構(gòu)師們做了許多嘗試：DavidParnas的模塊化和封裝（1972），EdsgerW.Dijkstra（1974）的關(guān)注點(diǎn)分離以及SOA（1988）。他們都是使用分而治之這項(xiàng)成熟的傳統(tǒng)技術(shù)來應(yīng)對(duì)大型系統(tǒng)的復(fù)雜性。自2010年開始，這些技術(shù)被證實(shí)無法繼續(xù)應(yīng)對(duì)Web級(jí)應(yīng)用或者現(xiàn)代大型企業(yè)級(jí)應(yīng)用的復(fù)雜性。因此架構(gòu)師和工程師們發(fā)展出了一種全新的現(xiàn)代方式來解決這個(gè)問題，就是微服務(wù)架構(gòu)。它雖然延續(xù)了分而治之的思想，但卻是以全新的方式來實(shí)現(xiàn)的。軟件設(shè)計(jì)模式是解決軟件設(shè)計(jì)中常見問題的通用、可復(fù)用的解決方案。設(shè)計(jì)模式讓我們可以分享通用詞匯并使用經(jīng)實(shí)戰(zhàn)檢驗(yàn)的方案，以免重復(fù)造輪子。我先簡(jiǎn)單介紹下微服務(wù)架構(gòu)。通過閱讀這篇文章，你會(huì)學(xué)到：微服務(wù)架構(gòu)微服務(wù)架構(gòu)的優(yōu)勢(shì)微服務(wù)架構(gòu)的劣勢(shì)何時(shí)使用微服務(wù)架構(gòu)最重要的微服務(wù)架構(gòu)設(shè)計(jì)模式，包括其優(yōu)缺點(diǎn)、用例、上下文、技術(shù)棧示例及可用資源。請(qǐng)注意，本清單中的大部分設(shè)計(jì)模式常出現(xiàn)在多種語境中，并且可以在非微服務(wù)架構(gòu)中使用。而我將在微服務(wù)這個(gè)特定語境中介紹它們。1微服務(wù)架構(gòu)我在之前的博客《微服務(wù)架構(gòu)概述及為什么要應(yīng)用在下個(gè)項(xiàng)目》和《單體軟件架構(gòu)真的終結(jié)了嗎？》中對(duì)微服務(wù)架構(gòu)有非常詳盡的介紹。如果你感興趣，可以閱讀這兩篇博客來深入了解。/microservice-architecture-a-brief-overview-and-why-you-should-use-it-in-your-next-project-a17b6e19adfd/looking-beyond-the-hype-is-modular-monolithic-software-architecture-really-dead-e386191610f8那到底什么是微服務(wù)架構(gòu)？有很多種定義方法。我的定義是這這樣的：微服務(wù)架構(gòu)指的是將大型復(fù)雜系統(tǒng)按功能或者業(yè)務(wù)需求垂直切分成更小的子系統(tǒng)，這些子系統(tǒng)以獨(dú)立部署的子進(jìn)程存在，它們之間通過輕量級(jí)的、跨語言的同步（比如REST，gRPC）或者異步（消息）網(wǎng)絡(luò)調(diào)用進(jìn)行通信。下面是基于微服務(wù)架構(gòu)的商業(yè)Web應(yīng)用的組件視圖：來自MdKamaruzzaman的微服務(wù)架構(gòu)

微服務(wù)架構(gòu)的重要特征整個(gè)應(yīng)用程序被拆分成相互獨(dú)立但包含多個(gè)內(nèi)部模塊的子進(jìn)程與模塊化的單體應(yīng)用（ModularMonoliths）或SOA相反，微服務(wù)應(yīng)用程序根據(jù)業(yè)務(wù)范圍或領(lǐng)域垂直拆分。微服務(wù)邊界是外部的，微服務(wù)之間通過網(wǎng)絡(luò)調(diào)用（RPC或消息）相互通信。微服務(wù)是獨(dú)立的進(jìn)程，它們可以獨(dú)立部署。它們以輕量級(jí)的方式進(jìn)行通信，不需要任何智能通信通道。

微服務(wù)架構(gòu)的優(yōu)點(diǎn)更好的開發(fā)規(guī)模更快的開發(fā)速度支持迭代開發(fā)或現(xiàn)代化增量開發(fā)充分利用現(xiàn)代軟件開發(fā)生態(tài)系統(tǒng)的優(yōu)勢(shì)（云、容器、DevOps、Serverless）支持水平縮放和細(xì)粒度縮放小體量，較低了開發(fā)人員的認(rèn)知復(fù)雜性

微服務(wù)架構(gòu)的缺點(diǎn)更高數(shù)量級(jí)的活動(dòng)組件（服務(wù)、數(shù)據(jù)庫、進(jìn)程、容器、框架）復(fù)雜性從代碼轉(zhuǎn)移到基礎(chǔ)設(shè)施RPC調(diào)用和網(wǎng)絡(luò)通信的大量增加整個(gè)系統(tǒng)的安全性管理更具有挑戰(zhàn)性整個(gè)系統(tǒng)的設(shè)計(jì)變得更加困難引入了分布式系統(tǒng)的復(fù)雜性

何時(shí)使用微服務(wù)架構(gòu)大規(guī)模Web應(yīng)用開發(fā)跨團(tuán)隊(duì)企業(yè)級(jí)應(yīng)用協(xié)作開發(fā)長(zhǎng)期收益優(yōu)先于短期收益團(tuán)隊(duì)擁有能夠設(shè)計(jì)微服務(wù)架構(gòu)的軟件架構(gòu)師或高級(jí)工程師2微服務(wù)架構(gòu)的設(shè)計(jì)模式

獨(dú)享數(shù)據(jù)庫（DatabaseperMicroservice）當(dāng)一家公司將大型單體系統(tǒng)替換成一組微服務(wù)，首先要面臨的最重要決策是關(guān)于數(shù)據(jù)庫。單體架構(gòu)會(huì)使用大型中央數(shù)據(jù)庫。即使轉(zhuǎn)移到微服務(wù)架構(gòu)許多架構(gòu)師仍傾向于保持?jǐn)?shù)據(jù)庫不變。雖然有一些短期收益，但它卻是反模式的，特別是在大規(guī)模系統(tǒng)中，微服務(wù)將在數(shù)據(jù)庫層嚴(yán)重耦合，整個(gè)遷移到微服務(wù)的目標(biāo)都將面臨失?。ɡ纾瑘F(tuán)隊(duì)授權(quán)、獨(dú)立開發(fā)等問題）。更好的方法是為每個(gè)微服務(wù)提供自己的數(shù)據(jù)存儲(chǔ)，這樣服務(wù)之間在數(shù)據(jù)庫層就不存在強(qiáng)耦合。這里我使用數(shù)據(jù)庫這一術(shù)語來表示邏輯上的數(shù)據(jù)隔離，也就是說微服務(wù)可以共享物理數(shù)據(jù)庫，但應(yīng)該使用分開的數(shù)據(jù)結(jié)構(gòu)、集合或者表，這還將有助于確保微服務(wù)是按照領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的方法正確拆分的。MdKamaruzzaman的微服務(wù)獨(dú)享數(shù)據(jù)庫優(yōu)點(diǎn)數(shù)據(jù)由服務(wù)完全所有服務(wù)的開發(fā)團(tuán)隊(duì)之間耦合度降低缺點(diǎn)服務(wù)間的數(shù)據(jù)共享變得更有挑戰(zhàn)性在應(yīng)用范圍的保證ACID事務(wù)變得困難許多細(xì)心設(shè)計(jì)如何拆分單體數(shù)據(jù)庫是一項(xiàng)極具挑戰(zhàn)的任務(wù)何時(shí)使用獨(dú)享數(shù)據(jù)庫在大型企業(yè)應(yīng)用程序中當(dāng)團(tuán)隊(duì)需要完全把控微服務(wù)以實(shí)現(xiàn)開發(fā)規(guī)模擴(kuò)展和速度提升何時(shí)不宜使用獨(dú)享數(shù)據(jù)庫在小規(guī)模應(yīng)用中如果是單個(gè)團(tuán)隊(duì)開發(fā)所有微服務(wù)可用技術(shù)示例所有SQL、NoSQL數(shù)據(jù)庫都提供數(shù)據(jù)的邏輯分離（例如，單獨(dú)的表、集合、結(jié)構(gòu)、數(shù)據(jù)庫）。

事件源（EventSourcing）在微服務(wù)架構(gòu)中，特別使用獨(dú)享數(shù)據(jù)庫時(shí)，微服務(wù)之間需要進(jìn)行數(shù)據(jù)交換。對(duì)于彈性高可伸縮的和可容錯(cuò)的系統(tǒng)，它們應(yīng)該通過交換事件進(jìn)行異步通信。在這種情況，您可能希望進(jìn)行類似更新數(shù)據(jù)庫并發(fā)送消息這樣的原子操作，如果在大數(shù)據(jù)量的分布式場(chǎng)景使用關(guān)系數(shù)據(jù)庫，您將無法使用兩階段鎖協(xié)議（2PL），因?yàn)樗鼰o法伸縮。而NoSQL數(shù)據(jù)庫因?yàn)榇蠖嗖恢С謨呻A段鎖協(xié)議甚至無法實(shí)現(xiàn)分布式事務(wù)。在這些場(chǎng)景，可以基于事件的架構(gòu)使用事件源模式。在傳統(tǒng)數(shù)據(jù)庫中，直接存儲(chǔ)的是業(yè)務(wù)實(shí)體的當(dāng)前“狀態(tài)”，而在事件源中任何“狀態(tài)”更新事件或其他重要事件都會(huì)被存儲(chǔ)起來，而不是直接存儲(chǔ)實(shí)體本身。這意味著業(yè)務(wù)實(shí)體的所有更改將被保存為一系列不可變的事件。因?yàn)閿?shù)據(jù)是作為一系列事件存儲(chǔ)的，而非直接更新存儲(chǔ)，所以各項(xiàng)服務(wù)可以通過重放事件存儲(chǔ)中的事件來計(jì)算出所需的數(shù)據(jù)狀態(tài)。MdKamaruzzaman的事件源優(yōu)點(diǎn)為高可伸縮系統(tǒng)提供原子性操作自動(dòng)記錄實(shí)體變更歷史，包括時(shí)序回溯功能松耦合和事件驅(qū)動(dòng)的微服務(wù)缺點(diǎn)從事件存儲(chǔ)中讀取實(shí)體成為新的挑戰(zhàn)，通常需要額外的數(shù)據(jù)存儲(chǔ)（CQRS模式）。系統(tǒng)整體復(fù)雜性增加了，通常需要領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)。系統(tǒng)需要處理事件重復(fù)（冪等）或丟失變更事件結(jié)構(gòu)成為新的挑戰(zhàn)。何時(shí)使用事件源使用關(guān)系數(shù)據(jù)庫的、高可伸縮的事務(wù)型系統(tǒng)使用NoSQL數(shù)據(jù)庫的事務(wù)型系統(tǒng)彈性高可伸縮微服務(wù)架構(gòu)典型的消息驅(qū)動(dòng)或事件驅(qū)動(dòng)系統(tǒng)（電子商務(wù)、預(yù)訂和預(yù)約系統(tǒng)）何時(shí)不宜使用事件源使用SQL數(shù)據(jù)庫的低可伸縮性事務(wù)型系統(tǒng)在服務(wù)可以同步交換數(shù)據(jù)（例如，通過API）的簡(jiǎn)單微服務(wù)架構(gòu)中?？捎眉夹g(shù)示例事件存儲(chǔ)：EventStoreDB、ApacheKafka、ConfluentCloud、AWSKinesis、AzureEventHub、GCPPub/Sub、AzureCosmosDB、MongoDB、Cassandra、AmazonDynamoDB框架：Lagom、Akka、Spring、akkatecture、Axon、Eventuate

命令和查詢職責(zé)分離（CQRS）如果我們使用事件源，那么從事件存儲(chǔ)中讀取數(shù)據(jù)就變得困難了。要從數(shù)據(jù)存儲(chǔ)中獲取實(shí)體，我們需要處理所有的實(shí)體事件。有時(shí)我們對(duì)讀寫操作還會(huì)有不同的一致性和吞吐量要求。這種情況，我們可以使用CQRS模式。在該模式中，系統(tǒng)的數(shù)據(jù)修改部分（命令）與數(shù)據(jù)讀取部分（查詢）是分離的。而CQRS模式有兩種容易令人混淆的模式，分別是簡(jiǎn)單的和高級(jí)的。在其簡(jiǎn)單形式中，不同實(shí)體或ORM模型被用于讀寫操作，如下所示：MdKamaruzzaman的CQRS（簡(jiǎn)單）它有助于強(qiáng)化單一職責(zé)原則和分離關(guān)注點(diǎn)，從而實(shí)現(xiàn)更簡(jiǎn)潔的設(shè)計(jì)。搜索公眾號(hào)頂級(jí)架構(gòu)師后臺(tái)回復(fù)“offer”，獲取一份驚喜禮包。在其高級(jí)形式中，會(huì)有不同的數(shù)據(jù)存儲(chǔ)用于讀寫操作。高級(jí)的CQRS通常結(jié)合事件源模式。根據(jù)不同情況，會(huì)使用不同類型的寫數(shù)據(jù)存儲(chǔ)和讀數(shù)據(jù)存儲(chǔ)。寫數(shù)據(jù)存儲(chǔ)是“記錄的系統(tǒng)”，也就是整個(gè)系統(tǒng)的核心源頭。MdKamaruzzaman的CQRS（高級(jí)）對(duì)于讀頻繁的應(yīng)用程序或微服務(wù)架構(gòu)，OLTP數(shù)據(jù)庫（任何提供ACID事務(wù)保證的關(guān)系或非關(guān)系數(shù)據(jù)庫）或分布式消息系統(tǒng)都可以被用作寫存儲(chǔ)。對(duì)于寫頻繁的應(yīng)用程序（寫操作高可伸縮性和大吞吐量），需要使用寫可水平伸縮的數(shù)據(jù)庫（如全球托管的公共云數(shù)據(jù)庫）。標(biāo)準(zhǔn)化的數(shù)據(jù)則保存在寫數(shù)據(jù)存儲(chǔ)中。對(duì)搜索（例如ApacheSolr、Elasticsearch）或讀操作（KV數(shù)據(jù)庫、文檔數(shù)據(jù)庫）進(jìn)行優(yōu)化的非關(guān)系數(shù)據(jù)庫常被用作讀存儲(chǔ)。許多情況會(huì)在需要SQL查詢的地方使用讀可伸縮的關(guān)系數(shù)據(jù)庫。非標(biāo)準(zhǔn)化和特殊優(yōu)化過的數(shù)據(jù)則保存在讀存儲(chǔ)中。數(shù)據(jù)是從寫存儲(chǔ)異步復(fù)制到讀存儲(chǔ)中的，所以讀存儲(chǔ)和寫存儲(chǔ)之間會(huì)有延遲，但最終是一致的。優(yōu)點(diǎn)在事件驅(qū)動(dòng)的微服務(wù)中數(shù)據(jù)讀取速度更快數(shù)據(jù)的高可用性讀寫系統(tǒng)可獨(dú)立擴(kuò)展缺點(diǎn)讀數(shù)據(jù)存儲(chǔ)是弱一致性的（最終一致性）整個(gè)系統(tǒng)的復(fù)雜性增加了，混亂的CQRS會(huì)顯著危害整個(gè)項(xiàng)目。何時(shí)使用CQRS在高可擴(kuò)展的微服務(wù)架構(gòu)中使用事件源在復(fù)雜領(lǐng)域模型中，讀操作需要同時(shí)查詢多個(gè)數(shù)據(jù)存儲(chǔ)。在讀寫操作負(fù)載差異明顯的系統(tǒng)中何時(shí)不宜使用CQRS在沒有必要存儲(chǔ)大量事件的微服務(wù)架構(gòu)中，用事件存儲(chǔ)快照來計(jì)算實(shí)體狀態(tài)是一個(gè)更好的選擇。在讀寫操作負(fù)載相近的系統(tǒng)中?？捎眉夹g(shù)示例寫存儲(chǔ)：EventStoreDB，ApacheKafka，ConfluentCloud，AWSKinesis，AzureEventHub，GCPPub/Sub，AzureCosmosDB，MongoDB，Cassandra.AmazonDynamoDB讀存儲(chǔ)：ElasticSearch，Solr，CloudSpanner，AmazonAurora，AzureCosmosDB，Neo4j框架：Lagom，Akka，Spring，akkatecture，Axon，Eventuate

Saga如果微服務(wù)使用獨(dú)享數(shù)據(jù)庫，那么通過分布式事務(wù)管理一致性是一個(gè)巨大的挑戰(zhàn)。你無法使用傳統(tǒng)的兩階段提交協(xié)議，因?yàn)樗床豢缮炜s（關(guān)系數(shù)據(jù)庫），要么不被支持（多數(shù)非關(guān)系數(shù)據(jù)庫）。但您還是可以在微服務(wù)架構(gòu)中使用Saga模式實(shí)現(xiàn)分布式事務(wù)。Saga是1987年開發(fā)的一種古老模式，是關(guān)系數(shù)據(jù)庫中關(guān)于大事務(wù)的一個(gè)替代概念。但這種模式的一種現(xiàn)代變種對(duì)分布式事務(wù)也非常有效。Saga模式是一個(gè)本地事務(wù)序列，其每個(gè)事務(wù)在一個(gè)單獨(dú)的微服務(wù)內(nèi)更新數(shù)據(jù)存儲(chǔ)并發(fā)布一個(gè)事件或消息。Saga中的首個(gè)事務(wù)是由外部請(qǐng)求（事件或動(dòng)作）初始化的，一旦本地事務(wù)完成（數(shù)據(jù)已保存在數(shù)據(jù)存儲(chǔ)且消息或事件已發(fā)布），那么發(fā)布的消息或事件則會(huì)觸發(fā)Saga中的下一個(gè)本地事務(wù)。MdKamaruzzaman的Saga如果本地事務(wù)失敗，Saga將執(zhí)行一系列補(bǔ)償事務(wù)來回滾前面本地事務(wù)的更改。Saga事務(wù)協(xié)調(diào)管理主要有兩種形式：事件編排Choreography：分散協(xié)調(diào)，每個(gè)微服務(wù)生產(chǎn)并監(jiān)聽其他微服務(wù)的事件或消息然后決定是否執(zhí)行某個(gè)動(dòng)作。命令編排Orchestration：集中協(xié)調(diào)，由一個(gè)協(xié)調(diào)器告訴參與的微服務(wù)哪個(gè)本地事務(wù)需要執(zhí)行。優(yōu)點(diǎn)為高可伸縮或松耦合的、事件驅(qū)動(dòng)的微服務(wù)架構(gòu)提供一致性事務(wù)。為使用了不支持2PC的非關(guān)系數(shù)據(jù)庫的微服務(wù)架構(gòu)提供一致性事務(wù)。缺點(diǎn)需要處理瞬時(shí)故障，并且提供等冪性。難以調(diào)試，而且復(fù)雜性隨著微服務(wù)數(shù)量增加而增加。何時(shí)使用Saga在使用了事件源的高可伸縮、松耦合的微服務(wù)中。在使用了分布式非關(guān)系數(shù)據(jù)庫的系統(tǒng)中。何時(shí)不宜使用Saga使用關(guān)系數(shù)據(jù)庫的低可伸縮性事務(wù)型系統(tǒng)。在服務(wù)間存在循環(huán)依賴的系統(tǒng)中。可用技術(shù)示例Axon，Eventuate，Narayana

面向前端的后端（BFF）在現(xiàn)代商業(yè)應(yīng)用開發(fā)，特別是微服務(wù)架構(gòu)中，前后端應(yīng)用是分離和獨(dú)立的服務(wù)，它們通過API或GraphQL連接。如果應(yīng)用程序還有移動(dòng)App客戶端，那么Web端和移動(dòng)客戶端使用相同的后端微服務(wù)就會(huì)出現(xiàn)問題。因?yàn)橐苿?dòng)客戶端和Web客戶端有不同的屏幕尺寸、顯示屏、性能、能耗和網(wǎng)絡(luò)帶寬，它們的API需求不同。面向前端的后端模式適用于需要為特殊UI定制單獨(dú)后端的場(chǎng)景。它還提供了其他優(yōu)勢(shì)，比如作為下游微服務(wù)的封裝，從而減少UI和下游微服務(wù)之間的頻繁通信。此外，在高安全要求的場(chǎng)景中，BFF為部署在DMZ網(wǎng)絡(luò)中的下游微服務(wù)提供了更高的安全性。MdKamaruzzaman的面向前端的后端優(yōu)點(diǎn)分離BFF之間的關(guān)注點(diǎn)，使得我們可以為具體的UI優(yōu)化他們。提供更高的安全性減少UI和下游微服務(wù)之間頻繁的通信缺點(diǎn)BFF之間代碼重復(fù)大量的BFF用于其他用戶界面（例如，智能電視，Web，移動(dòng)端，PC桌面版）需要仔細(xì)的設(shè)計(jì)和實(shí)現(xiàn)，BFF不應(yīng)該包含任何業(yè)務(wù)邏輯，而應(yīng)只包含特定客戶端邏輯和行為。何時(shí)使用BFF如果應(yīng)用程序有多個(gè)含不同API需求的UI出于安全需要，UI和下游微服務(wù)之間需要額外的層。如果在UI開發(fā)中使用微前端。何時(shí)不宜使用BFF如果應(yīng)用程序雖有多個(gè)UI，但使用的API相同。如果核心微服務(wù)不是部署在DMZ網(wǎng)絡(luò)中?？捎眉夹g(shù)示例任何后端框架（Node.js，Spring，Django，Laravel，F(xiàn)lask，Play，…）都能支持。

API網(wǎng)關(guān)在微服務(wù)架構(gòu)中，UI通常連接多個(gè)微服務(wù)。如果微服務(wù)是細(xì)粒度的（FaaS），那么客戶端可能需要連接非常多的微服務(wù)，這將變得繁雜和具有挑戰(zhàn)性。此外，這些服務(wù)包括它們的API還將不斷進(jìn)化。大型企業(yè)還希望能有其他橫切關(guān)注點(diǎn)（SSL終止、身份驗(yàn)證、授權(quán)、節(jié)流、日志記錄等）。一個(gè)解決這些問題的可行方法是使用API網(wǎng)關(guān)。API網(wǎng)關(guān)位于客戶端APP和后端微服務(wù)之間充當(dāng)facade，它可以是反向代理，將客戶端請(qǐng)求路由到適當(dāng)?shù)暮蠖宋⒎?wù)。它還支持將客戶端請(qǐng)求扇出到多個(gè)微服務(wù)，然后將響應(yīng)聚合后返回給客戶端。它還支持必要的橫切關(guān)注點(diǎn)。MdKamaruzzaman的API網(wǎng)關(guān)優(yōu)點(diǎn)在前端和后端服務(wù)之間提供松耦合減少客戶端和微服務(wù)之間的調(diào)用次數(shù)通過SSL終端、身份驗(yàn)證和授權(quán)實(shí)現(xiàn)高安全性集中管理的橫切關(guān)注點(diǎn)，例如，日志記錄和監(jiān)視、節(jié)流、負(fù)載平衡。缺點(diǎn)可能導(dǎo)致微服務(wù)架構(gòu)中的單點(diǎn)故障額外的網(wǎng)絡(luò)調(diào)用帶來的延遲增加如果不進(jìn)行擴(kuò)展，它們很容易成為整個(gè)企業(yè)應(yīng)用的瓶頸。額外的維護(hù)和開發(fā)費(fèi)用何時(shí)使用API網(wǎng)關(guān)在復(fù)雜的微服務(wù)架構(gòu)中，它幾乎是必須的。在大型企業(yè)中，API網(wǎng)關(guān)是中心化安全性和橫切關(guān)注點(diǎn)的必要工具。何時(shí)不宜使用API網(wǎng)關(guān)在安全和集中管理不是最優(yōu)先要素的私人項(xiàng)目或小公司中。如果微服務(wù)的數(shù)量相當(dāng)少。可用技術(shù)示例AmazonAPI網(wǎng)關(guān)，AzureAPI管理，Apigee，Kong，WSO2API管理器

Strangler如果想在運(yùn)行中的項(xiàng)目中使用微服務(wù)架構(gòu)，我們需要將遺留的或現(xiàn)有的單體應(yīng)用遷移到微服務(wù)。將現(xiàn)有的大型在線單體應(yīng)用程序遷移到微服務(wù)是相當(dāng)有挑戰(zhàn)性的，因?yàn)檫@可能破壞應(yīng)用程序的可用性。一個(gè)解決方案是使用Strangler模式。Strangler模式意味著通過使用新的微服務(wù)逐步替換特定功能，將單體應(yīng)用程序增量地遷移到微服務(wù)架構(gòu)。此外，新功能只在微服務(wù)中添加，而不再添加到遺留的單體應(yīng)用中。然后配置一個(gè)Facade（API網(wǎng)關(guān)）來路由遺留單體應(yīng)用和微服務(wù)間的請(qǐng)求。當(dāng)某個(gè)功能從單體應(yīng)用遷移到微服務(wù)，F(xiàn)acade就會(huì)攔截客戶端請(qǐng)求并路由到新的微服務(wù)。一旦遷移了所有的功能，遺留單體應(yīng)用程序就會(huì)被“扼殺（Strangler）”，即退役。搜索公眾號(hào)后端架構(gòu)師后臺(tái)回復(fù)“架構(gòu)整潔”，獲取一份驚喜禮包。MdKamaruzzaman的Strangler優(yōu)點(diǎn)安全的遷移單體應(yīng)用程序到微服務(wù)可以并行地遷移已有功能和開發(fā)新功能遷移過程可以更好把控節(jié)奏缺點(diǎn)在現(xiàn)有的單體應(yīng)用服務(wù)和新的微服務(wù)之間共享數(shù)據(jù)存儲(chǔ)變得具有挑戰(zhàn)性添加Facade（API網(wǎng)關(guān)）將增加系統(tǒng)延遲端到端測(cè)試變得困難何時(shí)使用Strangler將大型后端單體應(yīng)用程序的增量遷移到微服務(wù)何時(shí)不宜使用Strangler如果后端單體應(yīng)用很小，那么全量替換會(huì)更好。如果無法攔截客戶端對(duì)遺留的單體應(yīng)用程序的請(qǐng)求?？捎眉夹g(shù)示例API網(wǎng)關(guān)后端應(yīng)用框架。

斷路器在微服務(wù)架構(gòu)中，微服務(wù)通過同步調(diào)用其他服務(wù)來滿足業(yè)務(wù)需求。服務(wù)調(diào)用會(huì)由于瞬時(shí)故障（網(wǎng)絡(luò)連接緩慢、超時(shí)或暫時(shí)不可用）導(dǎo)致失敗，這種情況重試可以解決問題。然而，如果出現(xiàn)了嚴(yán)重問題（微服務(wù)完全失?。?，那么微服務(wù)將長(zhǎng)時(shí)間不可用，這時(shí)重試沒有意義且浪費(fèi)寶貴的資源（線程被阻塞，CPU周期被浪費(fèi)）。此外，一個(gè)服務(wù)的故障還會(huì)引發(fā)整個(gè)應(yīng)用系統(tǒng)的級(jí)聯(lián)故障。這時(shí)快速失敗是一種更好的方法。在這種情況，可以使用斷路器模式挽救。一個(gè)微服務(wù)通過代理請(qǐng)求另一個(gè)微服務(wù)，其工作原理類似于電氣斷路器，代理通過統(tǒng)計(jì)最近發(fā)生的故障數(shù)量，并使用它來決定是繼續(xù)請(qǐng)求還是簡(jiǎn)單的直接返回異常。MdKamaruzzaman的斷路器斷路器可以有以下三種狀態(tài)：關(guān)閉：斷路器將請(qǐng)求路由到微服務(wù)，并統(tǒng)計(jì)給定時(shí)段內(nèi)的故障數(shù)量，如果超過閾值，它就會(huì)觸發(fā)并進(jìn)入打開狀態(tài)。打開：來自微服務(wù)的請(qǐng)求會(huì)快速失敗并返回異常。在超時(shí)后，斷路器進(jìn)入半開啟狀態(tài)。半開：只有有限數(shù)量的微服務(wù)請(qǐng)求被允許通過并進(jìn)行調(diào)用。如果這些請(qǐng)求成功，斷路器將進(jìn)入閉合狀態(tài)。如果任何請(qǐng)求失敗，斷路器則會(huì)進(jìn)入開啟狀態(tài)。優(yōu)點(diǎn)提高微服務(wù)架構(gòu)的容錯(cuò)性和彈性阻止引發(fā)其他微服務(wù)的級(jí)聯(lián)故障缺點(diǎn)需要復(fù)雜的異常處理日志和監(jiān)控應(yīng)該支持人工復(fù)位何時(shí)使用斷路器在微服務(wù)間使用同步通信的緊耦合的微服務(wù)架構(gòu)中如果微服務(wù)依賴多個(gè)其他微服務(wù)何時(shí)不宜使用斷路器松耦合、事件驅(qū)動(dòng)的微服務(wù)架構(gòu)如果微服務(wù)不依賴于其他微服務(wù)可用技術(shù)示例API網(wǎng)關(guān)，服務(wù)網(wǎng)格，各種斷路器庫（Hystrix，Reselience4J，Polly）。

外部化配置每個(gè)業(yè)務(wù)應(yīng)用都有許多用于各種基礎(chǔ)設(shè)施的配置參數(shù)（例如，數(shù)據(jù)庫、網(wǎng)絡(luò)、連接的服務(wù)地址、憑據(jù)、證書路徑）。此外在企業(yè)應(yīng)用程序通常部署在各種運(yùn)行環(huán)境（Local、Dev、Prod）中，實(shí)現(xiàn)這些的一個(gè)方法是通過內(nèi)部配置。這是一個(gè)致命糟糕實(shí)踐，它會(huì)導(dǎo)致嚴(yán)重的安全風(fēng)險(xiǎn)，因?yàn)樯a(chǎn)憑證很容易遭到破壞。此外，配置參數(shù)的任何更改都需要重新構(gòu)建應(yīng)用程序，這在在微服務(wù)架構(gòu)中會(huì)更加嚴(yán)峻，因?yàn)槲覀兛赡軗碛袛?shù)百個(gè)服務(wù)。更好的方法是將所有配置外部化，使得構(gòu)建過程與運(yùn)行環(huán)境分離，生產(chǎn)的配置文件只在運(yùn)行時(shí)或通過環(huán)境變量使用，從而最小化了安全風(fēng)險(xiǎn)。優(yōu)點(diǎn)生產(chǎn)配置不屬于代碼庫，因而最小化了安全漏洞。修改配置參數(shù)不需要重新構(gòu)建應(yīng)用程序。缺點(diǎn)我們需要選擇一個(gè)支持外部化配置的框架。何時(shí)使用外部化配置任何重要的生產(chǎn)應(yīng)用程序都必須使用外部化配置。何時(shí)不宜使用外部化配置在驗(yàn)證概念的開發(fā)中?？捎眉夹g(shù)示例幾乎所有企業(yè)級(jí)的現(xiàn)代框架都支持外部化配置。

消費(fèi)端驅(qū)動(dòng)的契約測(cè)試在微服務(wù)架構(gòu)中，通常有許多有不同團(tuán)隊(duì)開發(fā)的微服務(wù)。這些微型服務(wù)協(xié)同工作來滿足業(yè)務(wù)需求（例如，客戶請(qǐng)求），并相互進(jìn)行同步或異步通信。消費(fèi)端微服務(wù)的集成測(cè)試具有挑戰(zhàn)性，通常用TestDouble以獲得更快、更低成本的測(cè)試運(yùn)行。但是TestDouble通常并不能代表真正的微服務(wù)提供者，而且如果微服務(wù)提供者更改了它的API或消息，那么TestDouble將無法確認(rèn)這些。另一種選擇是進(jìn)行端到端測(cè)試，盡管它在生產(chǎn)之前是強(qiáng)制性的，但卻是脆弱的、緩慢的、昂貴的且不能替代集成測(cè)試（TestPyramid）。在這方面消費(fèi)端驅(qū)動(dòng)的契約測(cè)試可以幫助我們。在這里，負(fù)責(zé)消費(fèi)端微服務(wù)的團(tuán)隊(duì)針對(duì)特定的服務(wù)端微服務(wù)，編寫一套包含了其請(qǐng)求和預(yù)期響應(yīng)（同步）或消息（異步）的測(cè)試套件，這些測(cè)試