15微服務(編輯修改稿)
2025-03-16 02:23 本頁面
【文章內(nèi)容簡介】 模式 ? 這種模式是聚合器模式的擴展，允許同時調(diào)用兩個微服務鏈 分數(shù)據(jù)共享微服務設計模式 ? 自治是微服務的設計原則之一，就是說微服務是全棧式服務。但在重構(gòu)現(xiàn)有的“單體應用（ monolithic application）”時， SQL數(shù)據(jù)庫反規(guī)范化可能會導致數(shù)據(jù)重復和不一致。因此，在單體應用到微服務架構(gòu)的過渡階段，可以使用這種設計模式。 ? 在這種情況下，部分微服務可能會共享緩存和數(shù)據(jù)庫存儲。不過，這只有在兩個服務之間存在強耦合關(guān)系時才可以。對于基于微服務的新建應用程序而言，這是一種反模式。 分數(shù)據(jù)共享微服務設計模式 異步消息傳遞微服務設計模式 ? REST設計模式非常流行，但它是同步的，會造成阻塞。因此部分基于微服務的架構(gòu)可能會選擇使用消息隊列代替 REST請求 /響應。 案例分析 ? 案例一：如何拆分單塊系統(tǒng)結(jié)構(gòu) 案例一：如何拆分單塊系統(tǒng)結(jié)構(gòu) ? 對于一個單塊系統(tǒng)，往往首先要從數(shù)據(jù)庫入手進行拆分，規(guī)劃好哪些是財務代碼的表，哪些是客戶代碼的表，將二者進行分離。 ? 這時單塊系統(tǒng)的應用結(jié)構(gòu)并沒有拆分，這還需要我們在進行設計單塊系統(tǒng)的時候，客戶代表和財務代碼的表字段不能混在一起，要設計成不同的表才能方便將來拆分，雖然系統(tǒng)是在一起的，但是卻為未來作了拆分準備。 ? 最后將應用系統(tǒng)拆分獨立布署，這個過程就結(jié)束了。 案例分析 ? 案例二：如何跨系統(tǒng)訪問數(shù)據(jù)表 案例二：如何跨系統(tǒng)訪問數(shù)據(jù)表 ? 有兩個服務，分別是產(chǎn)品目錄和財務，左圖的場景是財務服務直接調(diào)用產(chǎn)品目錄的數(shù)據(jù)表進行數(shù)據(jù)獲取。 ? 這種跨服務的數(shù)據(jù)獲取方式是有問題的，首先無法把控財務服務是如何獲取數(shù)據(jù)的，是否對數(shù)據(jù)表造成影響，其次從設計的角度來說無疑又增長了系統(tǒng)之間調(diào)用的耦合度，系統(tǒng)之間的依賴增強了。 ? 因此演變成右圖這樣，左圖只需提供服務接口給右圖調(diào)用即可。 案例分析 ? 案例三：服務設計中的不良習慣 案例二：如何跨系統(tǒng)訪問數(shù)據(jù)表 ? 在此系統(tǒng)中， ABCD四個系統(tǒng)進行了串聯(lián)，這樣就要求這四個系統(tǒng)分別都是高可用的，如果其中任何一個系統(tǒng)掛了或者發(fā)生問題，都會直接影響其他所有系統(tǒng)。 ? 所以設計微服務架構(gòu)的時候要盡量避免這種集中式的架構(gòu)。 如何大規(guī)模使用微服務 ? 真正使用微服務，有很多需要關(guān)注的點： ? 故障無所不在 ? 網(wǎng)絡是不可靠，只能盡力限制引起故障的因數(shù)，達到一定規(guī)模后，故障不可避免。 ? 跨功能需求 ? 服務吞吐量、可用性和數(shù)據(jù)持久性等這些需求需要持續(xù)測量，并保證服務滿足可接受的目標。 ? 功能降級 ? 構(gòu)建彈性系統(tǒng)，因微服務功能分散，在有可能 down機的微服務上，能夠安全的降級以保證彈性 如何大規(guī)模使用微服務 ? 反服務脆弱 ? 為了不會引起嚴重級聯(lián)影響，需要正確的設置超時、實現(xiàn)艙壁隔離或斷路層等以避免在第一時間調(diào)用一個不健康的服務。 ? 超時 ? 設置超時時間對于
研究報告相關(guān)推薦
鄂ICP備17016276號-1