微服務(wù)架構(gòu)10個(gè)最重要的設(shè)計(jì)模式

微服務(wù)架構(gòu)10個(gè)最重要的設(shè)計(jì)模式自從軟件開(kāi)發(fā)的早期(I960年代)以來(lái)，解決大型軟件系統(tǒng)中的復(fù)雜性一直是一項(xiàng)艱巨的任務(wù)。多年來(lái)，軟件工程師和架構(gòu)師為解決軟件系統(tǒng)的復(fù)雜性進(jìn)行了許多嘗試：DavidParnas的模塊化和信息隱藏(1972)，EdsgerW.Dijkstra的關(guān)注分離(1974)，面向服務(wù)的體系結(jié)構(gòu)(1998)。他們所有人都使用了久經(jīng)考驗(yàn)的成熟技術(shù)來(lái)解決大型系統(tǒng)的復(fù)雜性：分而治之。自2010年代以來(lái)，這些技術(shù)不足以解決Web規(guī)模應(yīng)用程序或現(xiàn)代大型企業(yè)應(yīng)用程序的復(fù)雜性。結(jié)果，架構(gòu)師和工程師開(kāi)發(fā)了一種新方法來(lái)解決現(xiàn)代軟件系統(tǒng)的復(fù)雜性：微服務(wù)架構(gòu)。它也使用了相同的舊"分而治之"技術(shù)，盡管采用了新穎白勺方式。軟件設(shè)計(jì)模式是解決軟件設(shè)計(jì)中常見(jiàn)問(wèn)題的通用，可重用的解決方案。設(shè)計(jì)模式可幫助我們共享通用詞匯，并使用經(jīng)過(guò)實(shí)戰(zhàn)檢驗(yàn)的解決方案，而不是重新發(fā)明輪子。今天描述的是一組設(shè)計(jì)模式，以幫助您實(shí)現(xiàn)這些最佳實(shí)踐。本文主要內(nèi)容：?微服務(wù)架構(gòu)?微服務(wù)架構(gòu)的優(yōu)勢(shì)?微服務(wù)架構(gòu)的缺點(diǎn)?何時(shí)使用微服務(wù)架構(gòu)?微服務(wù)架構(gòu)設(shè)計(jì)模式請(qǐng)注意，此清單的大多數(shù)設(shè)計(jì)模式都有幾種上下文，可以在非微服務(wù)體系結(jié)構(gòu)中使用。但是我將在微服務(wù)架構(gòu)的背景下對(duì)其進(jìn)行描述。微服務(wù)架構(gòu)微服務(wù)體系結(jié)構(gòu)：簡(jiǎn)要概述以及為什么要在下一個(gè)項(xiàng)目中使用它以及模塊化單片軟件體系結(jié)構(gòu)真的死了嗎？我的微服務(wù)架構(gòu)定義是：微服務(wù)架構(gòu)旨在將大型，復(fù)雜的系統(tǒng)垂直（按功能或業(yè)務(wù)要求）劃分為較小的子系統(tǒng)，這些子系統(tǒng)屬于流程（因此可獨(dú)立部署），并且這些子系統(tǒng)之間通過(guò)與語(yǔ)言無(wú)關(guān)的輕量級(jí)網(wǎng)絡(luò)通信相互通信（例如REST，gRPC）或異步（通過(guò)消息傳遞）方式。這是具有微服務(wù)架構(gòu)的業(yè)務(wù)Web應(yīng)用程序的組件視圖：>MicroserviceArchitecturebyMdKamaruzzaman微服務(wù)架構(gòu)的重要特征:?整個(gè)應(yīng)用程序分為多個(gè)單獨(dú)的進(jìn)程，每個(gè)進(jìn)程可以包含多個(gè)內(nèi)部模塊。?與模塊化Monoliths或SOA相反，微服務(wù)應(yīng)用程序是垂直拆分的（根據(jù)業(yè)務(wù)能力或領(lǐng)域）微服務(wù)邊界是外部的。結(jié)果，微服務(wù)通過(guò)網(wǎng)絡(luò)調(diào)用（RPC或消息）相互通信。?由于微服務(wù)是獨(dú)立的流程，因此它們可以獨(dú)立部署。他們以輕巧的方式交流，不需要任何智能交流渠道。微服務(wù)架構(gòu)的優(yōu)勢(shì):?更好的開(kāi)發(fā)規(guī)模。?更高的發(fā)展速度。?支持迭代或增量現(xiàn)代化。?充分利用現(xiàn)代軟件開(kāi)發(fā)生態(tài)系統(tǒng)（云，容器，DevOps，無(wú)服務(wù)器）的優(yōu)勢(shì)。?支持水平縮放和粒度縮放。?由于尺寸較小，它降低了開(kāi)發(fā)人員的認(rèn)知復(fù)雜度。微服務(wù)架構(gòu)的缺點(diǎn):?大量的活動(dòng)部件（服務(wù)，數(shù)據(jù)庫(kù)，流程，容器，框架）。?復(fù)雜性從代碼轉(zhuǎn)移到基礎(chǔ)架構(gòu)。RPC調(diào)用和網(wǎng)絡(luò)流量的激增。?管理整個(gè)系統(tǒng)的安全性具有挑戰(zhàn)性。?設(shè)計(jì)整個(gè)系統(tǒng)比較困難。?介紹分布式系統(tǒng)的復(fù)雜性。何時(shí)使用微服務(wù)架構(gòu)：Web規(guī)模應(yīng)用程序開(kāi)發(fā)。?當(dāng)多個(gè)團(tuán)隊(duì)處理應(yīng)用程序時(shí)，進(jìn)行企業(yè)應(yīng)用程序開(kāi)發(fā)。?長(zhǎng)期收益優(yōu)先于短期收益。?該團(tuán)隊(duì)擁有能夠設(shè)計(jì)微服務(wù)架構(gòu)的軟件架構(gòu)師或高級(jí)工程師。微服務(wù)架構(gòu)的設(shè)計(jì)模式每個(gè)微服務(wù)獨(dú)占數(shù)據(jù)庫(kù)—旦公司用許多較小的微服務(wù)替換了大型的單片系統(tǒng)，它面臨的最重要的決定就是關(guān)于數(shù)據(jù)庫(kù)。在整體架構(gòu)中，使用大型中央數(shù)據(jù)庫(kù)。許多架構(gòu)師都喜歡保留數(shù)據(jù)庫(kù)原樣，即使他們轉(zhuǎn)向微服務(wù)架構(gòu)也是如此。盡管它提供了一些短期好處，但它是一種反模式，尤其是在大規(guī)模系統(tǒng)中，因?yàn)槲⒎?wù)將緊密耦合在數(shù)據(jù)庫(kù)層中。轉(zhuǎn)向微服務(wù)的整個(gè)目標(biāo)將失?。ɡ?，團(tuán)隊(duì)授權(quán)，獨(dú)立開(kāi)發(fā)）。更好的方法是為每個(gè)微服務(wù)都提供自己的數(shù)據(jù)存儲(chǔ)，以使數(shù)據(jù)庫(kù)層中的服務(wù)之間不存在強(qiáng)耦合。在這里，我使用數(shù)據(jù)庫(kù)一詞來(lái)表示數(shù)據(jù)的邏輯分離，即微服務(wù)可以共享同一物理數(shù)據(jù)庫(kù)，但是它們應(yīng)該使用單獨(dú)的架構(gòu)/集合/表。它還將確保根據(jù)域驅(qū)動(dòng)設(shè)計(jì)正確隔離微服務(wù)。>DatabaseperMicroservicebyMdKamaruzzaman優(yōu)點(diǎn)：?數(shù)據(jù)對(duì)服務(wù)的完全所有權(quán)。?開(kāi)發(fā)服務(wù)的團(tuán)隊(duì)之間的松耦合。缺點(diǎn)：?在服務(wù)之間共享數(shù)據(jù)變得充滿挑戰(zhàn)。?提供應(yīng)用程序范圍的ACID事務(wù)保證變得更加困難。?將Monolith數(shù)據(jù)庫(kù)分解為較小的零件需要仔細(xì)設(shè)計(jì)，這是一項(xiàng)艱巨的任務(wù)。每個(gè)微服務(wù)何時(shí)使用數(shù)據(jù)庫(kù)：?在大型企業(yè)中的應(yīng)用。?當(dāng)團(tuán)隊(duì)需要其微服務(wù)的完全所有權(quán)以進(jìn)行開(kāi)發(fā)擴(kuò)展和提高開(kāi)發(fā)速度時(shí)。什么時(shí)候不使用每個(gè)微服務(wù)的數(shù)據(jù)庫(kù)：?在小型應(yīng)用中。?如果一個(gè)團(tuán)隊(duì)開(kāi)發(fā)所有微服務(wù)。啟用技術(shù)示例:所有SQL和NoSQL數(shù)據(jù)庫(kù)都提供邏輯上的數(shù)據(jù)分離（例如，分離的表，集合，模式，數(shù)據(jù)庫(kù)）。事件源EventSourcing在微服務(wù)架構(gòu)中，尤其是在每個(gè)微服務(wù)使用數(shù)據(jù)庫(kù)的情況下，微服務(wù)需要交換數(shù)據(jù)。對(duì)于有彈性，高度可擴(kuò)展和容錯(cuò)的系統(tǒng)，它們應(yīng)通過(guò)交換事件進(jìn)行異步通信。在這種情況下，可能需要進(jìn)行原子操作，例如，更新數(shù)據(jù)庫(kù)并發(fā)送消息。如果您有SQL數(shù)據(jù)庫(kù)，并且希望為大量數(shù)據(jù)分配分布式事務(wù)，則不能使用兩階段鎖定(2PL)，因?yàn)樗鼰o(wú)法擴(kuò)展。如果使用NoSQL數(shù)據(jù)庫(kù)并希望具有分布式事務(wù)，則不能使用2PL，因?yàn)樵S多NoSQL數(shù)據(jù)庫(kù)不支持兩階段鎖定。在這種情況下，請(qǐng)結(jié)合使用基于事件的體系結(jié)構(gòu)和事件源。在傳統(tǒng)數(shù)據(jù)庫(kù)中，具有當(dāng)前"狀態(tài)"的業(yè)務(wù)實(shí)體被直接存儲(chǔ)。在事件源中，將存儲(chǔ)任何狀態(tài)更改事件或其他重要事件，而不是實(shí)體。這意味著業(yè)務(wù)實(shí)體的修改將保存為一系列不可變的事件。通過(guò)在給定時(shí)間重新處理該業(yè)務(wù)實(shí)體的所有事件，可以扣除該業(yè)務(wù)實(shí)體的狀態(tài)。因?yàn)閿?shù)據(jù)存儲(chǔ)為一系列事件，而不是通過(guò)直接更新數(shù)據(jù)存儲(chǔ)來(lái)存儲(chǔ)，所以各種服務(wù)可以從事件存儲(chǔ)中重播事件以計(jì)算其各自數(shù)據(jù)存儲(chǔ)的適當(dāng)狀態(tài)。>EventSourcingbyMdKamaruzzaman優(yōu)點(diǎn)：?為高度可擴(kuò)展的系統(tǒng)提供原子性。?實(shí)體的自動(dòng)歷史記錄，包括時(shí)間旅行功能。?松散耦合和事件驅(qū)動(dòng)的微服務(wù)。缺點(diǎn)：?從事件存儲(chǔ)中讀取實(shí)體變得具有挑戰(zhàn)性，通常需要額外的數(shù)據(jù)存儲(chǔ)（CQRS模式）?系統(tǒng)的整體復(fù)雜性增加，通常需要域驅(qū)動(dòng)設(shè)計(jì)。?系統(tǒng)需要處理重復(fù)事件（幕等）或丟失事件。?遷移事件模式變得具有挑戰(zhàn)性。何時(shí)使用事件來(lái)源：?具有SQL數(shù)據(jù)庫(kù)的高度可擴(kuò)展的事務(wù)系統(tǒng)。?帶有NoSQL數(shù)據(jù)庫(kù)的事務(wù)系統(tǒng)。?高度可擴(kuò)展且具有彈性的微服務(wù)架構(gòu)。?典型的消息驅(qū)動(dòng)或事件驅(qū)動(dòng)系統(tǒng)（電子商務(wù)，預(yù)訂和預(yù)訂系統(tǒng)）。何時(shí)不使用事件來(lái)源：?具有SQL數(shù)據(jù)庫(kù)的低伸縮性事務(wù)系統(tǒng)。?在簡(jiǎn)單的微服務(wù)架構(gòu)中，微服務(wù)可以同步交換數(shù)據(jù)（例如，通過(guò)API）。啟用技術(shù)示例:?事件存儲(chǔ)：EventStoreDB，ApacheKafka，ConfluentCloud，AWSKinesis，Azure事件中心，GCP發(fā)布/訂閱，AzureCosmosDB，MongoDB，Cassandra。AmazonDynamoDB，?框架:Lagom，Akka，Spring，akkatecture，Axon，Eventuate命令查詢職責(zé)隔離（CQRS）如果我們使用事件源，那么從事件存儲(chǔ)中讀取數(shù)據(jù)將變得充滿挑戰(zhàn)。要從數(shù)據(jù)存儲(chǔ)中獲取實(shí)體，我們需要處理所有實(shí)體事件。另外，有時(shí)我們對(duì)讀寫(xiě)操作有不同的一致性和吞吐量要求。在這種用例中，我們可以使用CQRS模式。在CQRS模式中，系統(tǒng)的數(shù)據(jù)修改部分（命令）與數(shù)據(jù)讀?。ú樵儯┎糠址珠_(kāi)。CQRS模式有兩種形式：簡(jiǎn)單和高級(jí)，這導(dǎo)致軟件工程師之間產(chǎn)生一些混淆。以簡(jiǎn)單的形式，不同的實(shí)體或ORM模型用于讀取和寫(xiě)入，如下所示：>CQRS（simple）byMdKamaruzzaman它有助于實(shí)施"單一責(zé)任原則"和"關(guān)注點(diǎn)分離"，從而使設(shè)計(jì)更簡(jiǎn)潔。在其高級(jí)形式中，不同的數(shù)據(jù)存儲(chǔ)區(qū)用于讀取和寫(xiě)入操作。高級(jí)CQRS與事件來(lái)源一起使用。根據(jù)使用情況，使用不同類型的寫(xiě)入數(shù)據(jù)存儲(chǔ)和讀取數(shù)據(jù)存儲(chǔ)。寫(xiě)入數(shù)據(jù)存儲(chǔ)區(qū)是"記錄系統(tǒng)"，即整個(gè)系統(tǒng)的黃金來(lái)源。>CQRS（advaneed）byMdKamaruzzaman對(duì)于重讀應(yīng)用程序或微服務(wù)體系結(jié)構(gòu)，將OLTP數(shù)據(jù)庫(kù)（任何提供ACID事務(wù)保證的SQL或NoSQL數(shù)據(jù)庫(kù)）或分布式消息平臺(tái)用作寫(xiě)存儲(chǔ)。對(duì)于繁重的寫(xiě)程序（高寫(xiě)可伸縮性和吞吐量），使用了水平可寫(xiě)伸縮的數(shù)據(jù)庫(kù)（公共云全局?jǐn)?shù)據(jù)庫(kù)）。規(guī)范化的數(shù)據(jù)保存在寫(xiě)入數(shù)據(jù)存儲(chǔ)中。為搜索（例如ApacheSolr,Elasticsearch）或讀?。ㄦI值數(shù)據(jù)存儲(chǔ)，文檔數(shù)據(jù)存儲(chǔ)）而優(yōu)化的NoSQL數(shù)據(jù)庫(kù)用作讀取存儲(chǔ)。在許多情況下，在需要SQL查詢的地方使用可伸縮的SQL數(shù)據(jù)庫(kù)。歸一化和優(yōu)化的數(shù)據(jù)將保存在讀取存儲(chǔ)中。數(shù)據(jù)從寫(xiě)入存儲(chǔ)異步復(fù)制到讀取存儲(chǔ)。結(jié)果，讀存儲(chǔ)區(qū)滯后于寫(xiě)存儲(chǔ)區(qū)，并且最終保持一致。優(yōu)點(diǎn):?在事件驅(qū)動(dòng)的微服務(wù)中更快地讀取數(shù)據(jù)。?數(shù)據(jù)的高可用性。?讀寫(xiě)系統(tǒng)可以獨(dú)立擴(kuò)展。缺點(diǎn)：?讀取數(shù)據(jù)存儲(chǔ)弱一致性（最終一致性）?系統(tǒng)的整體復(fù)雜性增加。貨運(yùn)培訓(xùn)CQRS可能會(huì)嚴(yán)重危害整個(gè)項(xiàng)目。何時(shí)使用CQRS:?在使用事件源的高度可擴(kuò)展的微服務(wù)體系結(jié)構(gòu)中。?在讀取數(shù)據(jù)需要查詢到多個(gè)數(shù)據(jù)存儲(chǔ)區(qū)的復(fù)雜域模型中。?在讀寫(xiě)操作具有不同負(fù)載的系統(tǒng)中。何時(shí)不使用CQRS:?在微事件數(shù)量微不足道的微服務(wù)體系結(jié)構(gòu)中，使用事件存儲(chǔ)快照來(lái)計(jì)算實(shí)體狀態(tài)是更好的選擇。?在讀寫(xiě)操作具有相似負(fù)載的系統(tǒng)中。啟用技術(shù)示例:?寫(xiě)存儲(chǔ):EventStoreDB‘ApacheKafka,ConfluentCloud,AWSKinesis，AzureEventHub,GCP發(fā)布/訂閱,AzureCosmosDBJMongoDB,Cassandra。亞馬遜DynamoDB?閱讀商店：ElasticSearch,Solr,CloudSpanner,AmazonAurora,AzureCosmosDB,Neo4j?框架:Lagom,Akka,Spring,akkatecture,Axon,EventuateSAGA如果您將微服務(wù)體系結(jié)構(gòu)與每個(gè)微服務(wù)的數(shù)據(jù)庫(kù)一起使用，那么通過(guò)分布式事務(wù)管理一致性就具有挑戰(zhàn)性。您不能使用傳統(tǒng)的兩階段提交協(xié)議，因?yàn)樗鼰o(wú)法擴(kuò)展（SQL數(shù)據(jù)庫(kù)）或不被支持（許多NoSQL數(shù)據(jù)庫(kù)）。您可以將Saga模式用于MicroserviceArchitecture中的分布式事務(wù)。Saga是一種舊模式，于1987年開(kāi)發(fā)，作為SQL數(shù)據(jù)庫(kù)中長(zhǎng)期運(yùn)行的數(shù)據(jù)庫(kù)事務(wù)的概念替代方案。但是，這種模式的現(xiàn)代變體對(duì)于分布式事務(wù)也非常有效。Saga模式是一個(gè)本地事務(wù)序列，其中每個(gè)事務(wù)在單個(gè)微服務(wù)中更新數(shù)據(jù)存儲(chǔ)中的數(shù)據(jù)并發(fā)布事件或消息。傳奇中的第一個(gè)事務(wù)由外部請(qǐng)求（事件或操作）啟動(dòng)。一旦本地事務(wù)完成（數(shù)據(jù)存儲(chǔ)在數(shù)據(jù)存儲(chǔ)中，并且發(fā)布消息或事件），發(fā)布的消息/事件將觸發(fā)Saga中的下一個(gè)本地事務(wù)。>SagabyMdKamaruzzaman如果本地事務(wù)失敗，則Saga執(zhí)行一系列補(bǔ)償事務(wù)，以撤消先前本地事務(wù)的更改。Saga交易協(xié)調(diào)主要有兩種變體：?分散的協(xié)調(diào)，每個(gè)微服務(wù)生成并收聽(tīng)其他微服務(wù)的事件/消息，并決定是否應(yīng)該采取措施。?統(tǒng)籌協(xié)調(diào)，協(xié)調(diào)器告訴協(xié)調(diào)的微服務(wù)哪些本地事務(wù)需要執(zhí)行。優(yōu)點(diǎn)：?通過(guò)高度可擴(kuò)展的或松散耦合的，事件驅(qū)動(dòng)的微服務(wù)架構(gòu)中的事務(wù)來(lái)提供—致性。?通過(guò)使用沒(méi)有2PC支持的NoSQL數(shù)據(jù)庫(kù)的微服務(wù)體系結(jié)構(gòu)中的事務(wù)來(lái)提供一致性。缺點(diǎn)：?需要處理短暫故障，并應(yīng)提供幕等性。?難以調(diào)試，并且隨著微服務(wù)數(shù)量的增加，復(fù)雜性也隨之增加。何時(shí)使用：?在使用事件源的高度可擴(kuò)展的，松散耦合的微服務(wù)架構(gòu)中。?在使用分布式NoSQL數(shù)據(jù)庫(kù)的系統(tǒng)中。什么時(shí)候不使用:?具有SQL數(shù)據(jù)庫(kù)的低伸縮性事務(wù)系統(tǒng)。?在服務(wù)之間存在循環(huán)依賴性的系統(tǒng)中。啟用技術(shù)示例：Axon，Eventuate，Narayana前端的后端但FF)在現(xiàn)代業(yè)務(wù)應(yīng)用程序開(kāi)發(fā)中，尤其是在微服務(wù)體系結(jié)構(gòu)中，前端和后端應(yīng)用程序是分離的和獨(dú)立的服務(wù)。它們通過(guò)API或GraphQL連接。如果應(yīng)用程序還具有MobileApp客戶端，則對(duì)Web和Mobile客戶端使用相同的后端微服務(wù)將成為問(wèn)題。移動(dòng)客戶端的API要求通常與Web客戶端不同，因?yàn)樗鼈兙哂胁煌钠聊淮笮。@示，性能，能源和網(wǎng)絡(luò)帶寬。后端的后端模式可用于每個(gè)UI都有為特定UI定制的單獨(dú)后端的場(chǎng)景。它還提供了其他優(yōu)勢(shì)，例如充當(dāng)下游微服務(wù)的外觀，從而減少了UI與下游微服務(wù)之間的閑聊通信。同樣，在高度安全的情況下，下游微服務(wù)部署在DMZ網(wǎng)絡(luò)中，BFF用于提供更高的安全性。>BackendsforFrontendsbyMdKamaruzzaman優(yōu)點(diǎn)：BFF之間的關(guān)注點(diǎn)分離。我們可以針對(duì)特定的UI優(yōu)化它們。?提供更高的安全性。?減少UI與下游微服務(wù)之間的交流。缺點(diǎn)：BFF之間的代碼重復(fù)。?如果使用其他許多UI（例如，智能電視，Web，移動(dòng)設(shè)備，臺(tái)式機(jī)），BFF的數(shù)量也會(huì)激增。BFF不應(yīng)包含任何業(yè)務(wù)邏輯，而應(yīng)僅包含特定于客戶的邏輯和行為，因此需要仔細(xì)設(shè)計(jì)和實(shí)施。何時(shí)將后端用于前端：?如果應(yīng)用程序具有多個(gè)具有不同API要求的UI。?如果出于安全原因在UI和下游微服務(wù)之間需要額外的一層。?如果在UI開(kāi)發(fā)中使用微前端。何時(shí)不使用后端作為前端：?如果應(yīng)用程序具有多個(gè)UI，但是它們使用相同的API。?如果未在DMZ中部署核心微服務(wù)。啟用技術(shù)示例：任何后端框架(Node.js,Spring,Django,Laravel,Flask,Play等)都支持它。API網(wǎng)它。API網(wǎng)在微服務(wù)架構(gòu)中JJI通常與多個(gè)微服務(wù)連接。如果微服務(wù)是細(xì)粒度的（FaaS）,則客戶端可能需要連接許多微服務(wù)，這變得很繁瑣且具有挑戰(zhàn)性。而且，服務(wù)（包括其API）可以發(fā)展。大型企業(yè)還希望擁有其他跨領(lǐng)域的問(wèn)題（SSL終止，身份驗(yàn)證，授權(quán)，限制，日志記錄等）。解決這些問(wèn)題的一種可能方法是使用API網(wǎng)關(guān)。API網(wǎng)關(guān)位于客戶端APP和后端微服務(wù)之間，并充當(dāng)外觀。它可以用作反向代理，將客戶端請(qǐng)求路由到適當(dāng)?shù)暮蠖宋⒎?wù)。它還可以支持將客戶端請(qǐng)求的扇出擴(kuò)展到多個(gè)微服務(wù)，然后將匯總的響應(yīng)返回給客戶端。它還支持基本的跨領(lǐng)域關(guān)注。>APIGatewaybyMdKamaruzzaman優(yōu)點(diǎn)：?提供前端和后端微服務(wù)之間的松散耦合。?減少客戶端和微服務(wù)之間的往返呼叫次數(shù)。?通過(guò)SSL終止，身份驗(yàn)證和授權(quán)實(shí)現(xiàn)高安全性。?集中管理的跨領(lǐng)域問(wèn)題，例如日志記錄和監(jiān)視，節(jié)流，負(fù)載平衡。缺點(diǎn):?可能導(dǎo)致微服務(wù)架構(gòu)中的單點(diǎn)故障。?由于額外的網(wǎng)絡(luò)呼叫，延遲增加了。?如果不進(jìn)行擴(kuò)展，它們很容易成為整個(gè)企業(yè)的瓶頸。?額外的維護(hù)和開(kāi)發(fā)成本。何時(shí)使用API網(wǎng)關(guān)：?在復(fù)雜的微服務(wù)架構(gòu)中，這幾乎是強(qiáng)制性的。?在大型公司中，必須使用API網(wǎng)關(guān)來(lái)集中安全性和跨領(lǐng)域問(wèn)題。何時(shí)不使用API網(wǎng)關(guān):?在安全性和中央管理不是最高優(yōu)先級(jí)的私人項(xiàng)目或小型公司中。?如果微服務(wù)的數(shù)量很小。啟用技術(shù)示例：AmazonAPIGateway，AzureAPI管理，Apigee，Kong，WSO2API管理器扼殺者如果要在棕地項(xiàng)目中使用微服務(wù)架構(gòu)，則需要將舊版或現(xiàn)有的Monolithic應(yīng)用程序遷移到微服務(wù)。將現(xiàn)有的大型生產(chǎn)單片式應(yīng)用程序遷移到微服務(wù)中具有很大的挑戰(zhàn)性，因?yàn)檫@可能會(huì)破壞應(yīng)用程序的可用性。一種解決方案是使用Strangler模式。Strangler模式意味著通過(guò)逐步用新的微服務(wù)替換特定功能，將Monolithic應(yīng)用程序逐步遷移到微服務(wù)架構(gòu)。此外，新功能僅在微服務(wù)中添加，繞過(guò)了傳統(tǒng)的Monolithic應(yīng)用程序。然后將Facade（API網(wǎng)關(guān)）配置為在舊版Monolith和微服務(wù)之間路由請(qǐng)求。一旦功能從Monolith遷移到微服務(wù)，F(xiàn)acade就會(huì)攔截客戶端請(qǐng)求并路由到新的微服務(wù)。一旦所有舊版Monolithic功能都已遷移，舊版Monolithic應(yīng)用程序?qū)⒈?勒死"，即退役。>StranglerbyMdKamaruzzaman優(yōu)點(diǎn)：?將Monolithic應(yīng)用程序安全遷移到微服務(wù)。?遷移和新功能開(kāi)發(fā)可以并行進(jìn)行。?遷移過(guò)程可以有自己的進(jìn)度。缺點(diǎn)：?在現(xiàn)有的Monolith和新的微服務(wù)之間共享數(shù)據(jù)存儲(chǔ)變得充滿挑戰(zhàn)。?添加外觀（API網(wǎng)關(guān)）將增加系統(tǒng)延遲。?端到端測(cè)試變得困難。何時(shí)使用Strangler:將大型后端單片應(yīng)用程序增量遷移到微服務(wù)。何時(shí)不使用Strangler:?如果后端整體組件較小，則批量替換是一個(gè)更好的選擇。?如果客戶端對(duì)舊版Monolithic應(yīng)用程序的請(qǐng)求無(wú)法被攔截。推動(dòng)技術(shù)：帶有API網(wǎng)關(guān)的后端應(yīng)用程序框架。在微服務(wù)體系結(jié)構(gòu)中，微服務(wù)進(jìn)行同步通信，微服務(wù)通常調(diào)用其他服務(wù)來(lái)滿足業(yè)務(wù)需求。由于瞬態(tài)故障（網(wǎng)絡(luò)連接速度慢，超時(shí)或時(shí)間不可用），對(duì)另一個(gè)服務(wù)的調(diào)用可能會(huì)失敗。在這種情況下，重試呼叫可以解決此問(wèn)題。但是，如果存在嚴(yán)重問(wèn)題（微服務(wù)完全失?。?，則微服務(wù)將長(zhǎng)時(shí)間不可用。在這種情況下，重試是沒(méi)有意義的，并且浪費(fèi)了寶貴的資源（線程被阻塞，浪費(fèi)了CPU周期）。同樣，一項(xiàng)服務(wù)的故障可能會(huì)導(dǎo)致整個(gè)應(yīng)用程序級(jí)聯(lián)故障。在這種情況下，立即失敗是一種更好的方法。對(duì)于此類用例，可以使用斷路器模式。微服務(wù)應(yīng)通過(guò)代理來(lái)請(qǐng)求另一個(gè)微服務(wù)，該代理的工作方式類似于斷路器。代理應(yīng)該計(jì)算最近發(fā)生的故障數(shù)，并使用它來(lái)決定是允許操作繼續(xù)進(jìn)行還是直接返回異常。>CircuitBreakerbyMdKamaruzzaman斷路器可以具有以下三種狀態(tài):?已關(guān)閉：斷路器將請(qǐng)求發(fā)送到微服務(wù)，并計(jì)算給定時(shí)間段內(nèi)的故障數(shù)。如果在一定時(shí)間內(nèi)的故障數(shù)量超過(guò)閾值，則它將跳閘并進(jìn)入"打開(kāi)狀態(tài)"。?打開(kāi)：來(lái)自微服務(wù)的請(qǐng)求立即失敗，并返回異常。超時(shí)后，斷路器進(jìn)入半開(kāi)狀態(tài)。?半開(kāi)放式：僅允許來(lái)自微服務(wù)的有限數(shù)量的請(qǐng)求通過(guò)并調(diào)用該操作。如果這些請(qǐng)求成功，則斷路器將進(jìn)入閉合狀態(tài)。如果任何請(qǐng)求失敗，則斷路器進(jìn)入"打開(kāi)"狀態(tài)。優(yōu)點(diǎn)：?提高微服務(wù)架構(gòu)的容錯(cuò)性和彈性。?停止將故障級(jí)聯(lián)到其他微服務(wù)。缺點(diǎn):?需要復(fù)雜的異常處理。?記錄和監(jiān)視。?應(yīng)該支持手動(dòng)重置。何時(shí)使用斷路器:?在緊密耦合的微服務(wù)體系結(jié)構(gòu)中，微服務(wù)進(jìn)行同步通信。?—個(gè)微服務(wù)是否依賴于多個(gè)其他微服務(wù)。何時(shí)不使用斷路器：?松散耦合的，事件驅(qū)動(dòng)的微服務(wù)架構(gòu)。?微服務(wù)是否不依賴于其他微服務(wù)。推動(dòng)技術(shù)：API網(wǎng)關(guān)，服務(wù)網(wǎng)格，各種斷路器庫(kù)（Hystrix，Reselience4J，Polly。外部化配置每個(gè)業(yè)務(wù)應(yīng)用程序都有許多用于各種基礎(chǔ)結(jié)構(gòu)的配置參數(shù)（例如，數(shù)據(jù)庫(kù)，網(wǎng)絡(luò)，連接的服務(wù)地址，憑據(jù)，證書(shū)路徑）。同樣，在企業(yè)環(huán)境中，應(yīng)用程序通常部署在各種運(yùn)行時(shí)中（本地，開(kāi)發(fā)，生產(chǎn)）。實(shí)現(xiàn)此目標(biāo)的一種方法是通過(guò)內(nèi)部配置，這是一種致命的不良做法。由于很容易破壞生產(chǎn)憑據(jù)，因此可能導(dǎo)致嚴(yán)重的安全風(fēng)險(xiǎn)。另外，配置參數(shù)的任何更改都需要重建應(yīng)用程序。在微服務(wù)架構(gòu)中，這一點(diǎn)尤為重要，因?yàn)槲覀兛赡軗碛袛?shù)百種服務(wù)。更好的方法是外部化所有配置。結(jié)果，將構(gòu)建過(guò)程與運(yùn)行時(shí)環(huán)境分開(kāi)。此外，由于生產(chǎn)配置文件僅在運(yùn)行時(shí)或通過(guò)環(huán)境變量使用，因此將安全風(fēng)險(xiǎn)降到最低。優(yōu)點(diǎn)：?生產(chǎn)配置不是代碼庫(kù)的一部分，因此可以最大程度地減少安全漏洞。?無(wú)需重新構(gòu)建即可更改配置參數(shù)。缺點(diǎn):我們需要選擇一個(gè)支持外部化配置的框架。何時(shí)使用外部化配置:任何重要的生產(chǎn)應(yīng)用程序都必須使用外部配置。何時(shí)不使用外部化配置：在概念發(fā)展的證明。推動(dòng)技術(shù)：幾乎所有企業(yè)級(jí)的現(xiàn)代框架都支持外部化配置。消費(fèi)者驅(qū)動(dòng)的合同測(cè)試在微服務(wù)架構(gòu)中，通常由獨(dú)立的團(tuán)隊(duì)開(kāi)發(fā)許多微服務(wù)。這些微服務(wù)一起工作來(lái)滿足業(yè)務(wù)需求（例如，客戶請(qǐng)求），并且彼此同步或異步地通信。消費(fèi)者微服務(wù)的集成測(cè)試具有挑戰(zhàn)性。通常，在這種情況下使用TestDouble可以進(jìn)行更快，更便宜的測(cè)試。但是TestDouble通常并不代表真正的提供程序微服務(wù)。另外，如果提供者微服務(wù)更改了其API或消息，則TestDouble無(wú)法確認(rèn)這一點(diǎn)。另一個(gè)選擇是進(jìn)行端到端測(cè)試。雖然在生產(chǎn)之前必須進(jìn)行端到端測(cè)試，但它脆弱，緩慢，昂貴，并且不能替代集成測(cè)試（測(cè)試金字塔）。消費(fèi)者驅(qū)動(dòng)的合同測(cè)試可以在這方面為我們提供幫助。此處，消費(fèi)者微服務(wù)所有者團(tuán)隊(duì)編寫(xiě)了一個(gè)測(cè)試套件，其中包含針對(duì)特定提供者微服務(wù)的請(qǐng)求和預(yù)期響應(yīng)（用于同步通信）或預(yù)期消息（用于異步通信）。這些測(cè)試套件稱為顯式合同。對(duì)