插： 前些天發(fā)現(xiàn)了一個(gè)巨牛的人工智能學(xué)習(xí)網(wǎng)站，通俗易懂，風(fēng)趣幽默，忍不住分享一下給大家镊绪。點(diǎn)擊跳轉(zhuǎn)到網(wǎng)站。
堅(jiān)持不懈洒忧，越努力越幸運(yùn)蝴韭，大家一起學(xué)習(xí)鴨~~~
獨(dú)享數(shù)據(jù)庫（Database per Microservice）
當(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)都將面臨失敿跤唷（例如综苔，團(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ì)的方法正確拆分的妖胀。
優(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ù)庫）。
延伸閱讀
微服務(wù)模式：獨(dú)享數(shù)據(jù)庫
https://microservices.io/patterns/data/database-per-service.html
分布式數(shù)據(jù)存儲(chǔ)
https://docs.microsoft.com/en-us/dotnet/architecture/cloud-native/distributed-data
事件源（Event Sourcing）
在微服務(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)蛋欣。
優(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)中脱羡。
可用技術(shù)示例
事件存儲(chǔ)：EventStoreDB， Apache Kafka免都， Confluent Cloud锉罐， AWS Kinesis， Azure Event Hub绕娘， GCP Pub/Sub脓规， Azure Cosmos DB， MongoDB险领， Cassandra. Amazon DynamoDB
框架： Lagom侨舆， Akka秒紧， Spring， akkatecture挨下， Axon熔恢，Eventuate
延伸閱讀
事件驅(qū)動(dòng)
https://martinfowler.com/eaaDev/EventSourcing.html
事件驅(qū)動(dòng)模式-云設(shè)計(jì)模式
https://docs.microsoft.com/en-us/azure/architecture/patterns/event-sourcing
微服務(wù)模式：事件驅(qū)動(dòng)
https://microservices.io/patterns/data/event-sourcing.html
命令和查詢職責(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 模型被用于讀寫操作，如下所示：
它有助于強(qiáng)化單一職責(zé)原則和分離關(guān)注點(diǎn)在验，從而實(shí)現(xiàn)更簡(jiǎn)潔的設(shè)計(jì)玷氏。
在其高級(jí)形式中，會(huì)有不同的數(shù)據(jù)存儲(chǔ)用于讀寫操作腋舌。高級(jí)的 CQRS 通常結(jié)合事件源模式盏触。根據(jù)不同情況，會(huì)使用不同類型的寫數(shù)據(jù)存儲(chǔ)和讀數(shù)據(jù)存儲(chǔ)块饺。寫數(shù)據(jù)存儲(chǔ)是“記錄的系統(tǒng)”赞辩，也就是整個(gè)系統(tǒng)的核心源頭。
對(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ì)搜索（例如 Apache Solr、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)中垦缅。
可用技術(shù)示例
寫存儲(chǔ)：EventStoreDB， Apache Kafka驹碍， Confluent Cloud壁涎， AWS Kinesis， Azure Event Hub志秃， GCP Pub/Sub怔球， Azure Cosmos DB， MongoDB浮还， Cassandra. Amazon DynamoDB
讀存儲(chǔ)： Elastic Search竟坛， Solr， Cloud Spanner碑定， Amazon Aurora流码， Azure Cosmos DB， Neo4j
框架： Lagom延刘， Akka漫试， Spring， akkatecture碘赖， Axon驾荣， Eventuate
延伸閱讀
bliki：CQRS
https://martinfowler.com/bliki/CQRS.html
CQRS模式 - Azure 架構(gòu)中心
https://docs.microsoft.com/en-us/azure/architecture/patterns/cqrs
微服務(wù)模式：命令和查詢職責(zé)分離（CQRS）
https://microservices.io/patterns/data/cqrs.html
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ù)。
如果本地事務(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
延伸閱讀
Saga分布式事務(wù)-Azure設(shè)計(jì)模式
https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/saga/saga
微服務(wù)模式：Sagas
https://microservices.io/patterns/data/saga.html
Saga 模式：微服務(wù)中的應(yīng)用程序事務(wù)
https://blog.couchbase.com/saga-pattern-implement-business-transactions-using-microservices-part/
面向前端的后端 （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ù)提供了更高的安全性煤篙。
[圖片上傳失敗...(image-4815c4-1625241631007)]
優(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ò)中困介。
可用技術(shù)示例
任何后端框架（Node.js大审，Spring，Django座哩，Laravel徒扶，F(xiàn)lask，Play八回，…）都能支持酷愧。
延伸閱讀
Sam Newman - 面向前端的后端
https://samnewman.io/patterns/architectural/bff/
面向前端的后端模式 - 云設(shè)計(jì)模式
https://docs.microsoft.com/en-us/azure/architecture/patterns/backends-for-frontends
微服務(wù)模式：API 網(wǎng)關(guān)模式
https://microservices.io/patterns/apigateway.html
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)酵熙。
優(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ù)示例
Amazon API 網(wǎng)關(guān)诚亚， Azure API 管理， Apigee午乓， Kong站宗， WSO2 API 管理器
延伸閱讀
微服務(wù)模式：API 網(wǎng)關(guān)模式
https://microservices.io/patterns/apigateway.html
API 網(wǎng)關(guān)-Azure 架構(gòu)中心
https://docs.microsoft.com/en-us/azure/architecture/microservices/design/gateway
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）”县爬，即退役。
*Md Kamaruzzaman *的 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)求秕岛。
可用技術(shù)示例
API 網(wǎng)關(guān)后端應(yīng)用框架碌燕。
延伸閱讀
bliki：StranglerFig 應(yīng)用程序
https://martinfowler.com/bliki/StranglerFigApplication.html
Strangler 模式 - 云設(shè)計(jì)模式
https://docs.microsoft.com/en-us/azure/architecture/patterns/strangler-fig
微服務(wù)模式：Strangler 應(yīng)用程序
https://microservices.io/patterns/refactoring/strangler-application.html
斷路器
在微服務(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)單的直接返回異常。
*Md Kamaruzzaman *的斷路器
斷路器可以有以下三種狀態(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）。
延伸閱讀
bliki：斷路器
https://martinfowler.com/bliki/CircuitBreaker.html
斷路器模式 - 云設(shè)計(jì)模式
https://docs.microsoft.com/en-us/azure/architecture/patterns/circuit-breaker
微型服務(wù)模式：斷路器
https://microservices.io/patterns/reliability/circuit-breaker.html
外部化配置
每個(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ā)中。
可用技術(shù)示例
幾乎所有企業(yè)級(jí)的現(xiàn)代框架都支持外部化配置跪妥。
延伸閱讀
微服務(wù)模式：外部化配置
https://microservices.io/patterns/externalized-configuration.html
一次構(gòu)建鞋喇，到處運(yùn)行：外部化你的配置
https://reflectoring.io/externalize-configuration/
消費(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è)試（Test Pyramid）。
在這方面消費(fèi)端驅(qū)動(dòng)的契約測(cè)試可以幫助我們蛇损。在這里赁温，負(fù)責(zé)消費(fèi)端微服務(wù)的團(tuán)隊(duì)針對(duì)特定的服務(wù)端微服務(wù)坛怪，編寫一套包含了其請(qǐng)求和預(yù)期響應(yīng)（同步）或消息（異步）的測(cè)試套件，這些測(cè)試套件稱為顯式的約定股囊。對(duì)于微服務(wù)服務(wù)端袜匿，將其消費(fèi)端所有約定的測(cè)試套件都添加到其自動(dòng)化測(cè)試中。當(dāng)特定服務(wù)端微服務(wù)的自動(dòng)化測(cè)試執(zhí)行時(shí)毁涉，它將一起運(yùn)行自己的測(cè)試和約定的測(cè)試并進(jìn)行驗(yàn)證沉帮。通過這種方式，契約測(cè)試可以自動(dòng)的幫助維護(hù)微服務(wù)通信的完整性贫堰。
優(yōu)點(diǎn)
如果提供程序意外更改 API 或消息穆壕，可以被快速的自動(dòng)發(fā)現(xiàn)。
更少意外其屏、更健壯喇勋，特別是包含大量微服務(wù)的企業(yè)應(yīng)用程序。
改善團(tuán)隊(duì)自主性偎行。
缺點(diǎn)
需要額外的工作來開發(fā)和集成微服務(wù)服務(wù)端的契約測(cè)試川背，因?yàn)樗麄兛赡苁褂猛耆煌臏y(cè)試工具。
如果契約測(cè)試與真實(shí)服務(wù)情況不匹配蛤袒，將可能導(dǎo)致生產(chǎn)故障熄云。
何時(shí)使用需求驅(qū)動(dòng)的契約測(cè)試
- 在大型企業(yè)業(yè)務(wù)應(yīng)用程序中，通常由不同的團(tuán)隊(duì)開發(fā)不同服務(wù)妙真。
何時(shí)不宜使用消費(fèi)端驅(qū)動(dòng)的契約測(cè)試
所有微服務(wù)由同一團(tuán)隊(duì)負(fù)責(zé)開發(fā)的小型簡(jiǎn)單的應(yīng)用程序缴允。
如果服務(wù)端微服務(wù)是相對(duì)穩(wěn)定的，并且不處在活躍的開發(fā)狀態(tài)珍德。
可用技術(shù)示例
Pact练般， Postman， Spring Cloud Contract
延伸閱讀
需求驅(qū)動(dòng)契約：一種服務(wù)演進(jìn)模式
https://martinfowler.com/articles/consumerDrivenContracts.html
微服務(wù)模式：服務(wù)集成契約測(cè)試
https://microservices.io/patterns/testing/service-integration-contract-test.html
什么是消費(fèi)端驅(qū)動(dòng)的契約測(cè)試锈候？
https://pactflow.io/what-is-consumer-driven-contract-testing/
總結(jié)
在現(xiàn)代大規(guī)模企業(yè)軟件開發(fā)中薄料，微服務(wù)架構(gòu)能夠幫助開發(fā)擴(kuò)展規(guī)模并帶來很多長(zhǎng)期收益。但是微服務(wù)架構(gòu)并不是隨處可用的銀彈泵琳，如果應(yīng)用在錯(cuò)誤的應(yīng)用程序類型摄职，微服務(wù)架構(gòu)將弊大于利。希望采用微服務(wù)架構(gòu)的開發(fā)團(tuán)隊(duì)?wèi)?yīng)該遵循最佳實(shí)踐获列，并使用一系列可重用的琳钉、久經(jīng)錘煉的設(shè)計(jì)模式。
微服務(wù)架構(gòu)中至關(guān)重要的設(shè)計(jì)模式是獨(dú)享數(shù)據(jù)庫蛛倦。實(shí)現(xiàn)這種設(shè)計(jì)模式具有挑戰(zhàn)性歌懒，需要其他幾種密切相關(guān)的設(shè)計(jì)模式（事件驅(qū)動(dòng)、 CQRS溯壶、 Saga）來支持及皂。在具有多個(gè)客戶端（Web甫男、 Mobile、 Desktop验烧、 Smart Devices）的典型業(yè)務(wù)應(yīng)用程序中板驳，客戶端和微服務(wù)之間的通信量可能是很大的，并且需要統(tǒng)一的安全控制碍拆，在這種情況面向前端的后端和 API 網(wǎng)關(guān)的設(shè)計(jì)非常有用若治。此外，斷路器模式可以大大地幫助應(yīng)對(duì)這類應(yīng)用程序的錯(cuò)誤處理場(chǎng)景感混。遷移遺留的單體應(yīng)用到微服務(wù)是極具挑戰(zhàn)性的端幼，而 Strangler 模式可以幫助做到這點(diǎn)。消費(fèi)端驅(qū)動(dòng)的契約測(cè)試是微服務(wù)集成測(cè)試的基礎(chǔ)模式弧满。另外外部化配置是任何現(xiàn)代化應(yīng)用程序開發(fā)中的一種必備模式婆跑。
這個(gè)系列并不全面，在實(shí)際情況中您可能需要其他的設(shè)計(jì)模式庭呜，但這個(gè)系列能為您提供一個(gè)關(guān)于微服務(wù)架構(gòu)設(shè)計(jì)模式的極好介紹滑进。
