微服務(wù)，每個(gè)微服務(wù)配置一個(gè)數(shù)據(jù)源好還是在微服務(wù)中配置多個(gè)號(hào)好...在我們這邊，所有服務(wù)使用同一個(gè)數(shù)據(jù)源，數(shù)據(jù)庫(kù)連接信息配置到環(huán)境變量中，所有微服務(wù)統(tǒng)一讀取這組環(huán)境變量。主服務(wù)器更新、插入和刪除復(fù)制的數(shù)據(jù)；從服務(wù)器負(fù)責(zé)查詢(讀寫(xiě)分離，減輕服務(wù)器壓力)，2.主服務(wù)器同時(shí)更新從服務(wù)器的數(shù)據(jù)(數(shù)據(jù)備份)，3.當(dāng)文件出現(xiàn)在主服務(wù)器上時(shí)，從服務(wù)器可以代替主服務(wù)器保證網(wǎng)站的正常運(yùn)行，并檢測(cè)主服務(wù)器存在的問(wèn)題。

申請(qǐng)?zhí)峤晃⒎?wù)獲取訂單中心發(fā)送的開(kāi)戶申請(qǐng)預(yù)訂單，其中，開(kāi)戶申請(qǐng)預(yù)訂單包括用戶身份信息、用戶選擇的號(hào)碼和產(chǎn)品類型，并根據(jù)開(kāi)戶申請(qǐng)預(yù)訂單對(duì)應(yīng)的產(chǎn)品詳細(xì)數(shù)據(jù)獲取消息，搶占用戶選擇的號(hào)碼；開(kāi)戶提交微服務(wù)解析消息并進(jìn)行費(fèi)用處理，獲得開(kāi)戶信息，并將開(kāi)戶信息提交給業(yè)務(wù)支撐系統(tǒng)；寫(xiě)卡數(shù)據(jù)查詢微服務(wù)根據(jù)開(kāi)戶信息獲取寫(xiě)卡數(shù)據(jù)，并將寫(xiě)卡數(shù)據(jù)存儲(chǔ)在白卡中；卡數(shù)據(jù)同步微服務(wù)占用用戶選擇號(hào)碼的資源，寫(xiě)回開(kāi)戶指令，從而完成用戶在業(yè)務(wù)支撐系統(tǒng)的開(kāi)戶。

當(dāng)我們的數(shù)據(jù)庫(kù)壓力主鍵變大時(shí)，我們會(huì)嘗試增加一些從節(jié)點(diǎn)來(lái)分擔(dān)主節(jié)點(diǎn)的查詢壓力。一般來(lái)說(shuō)，我們采用一主多從的結(jié)構(gòu)作為讀寫(xiě)分離的基本結(jié)構(gòu)。一般來(lái)說(shuō)，我們有兩種常用的方法來(lái)實(shí)現(xiàn)讀分架構(gòu):客戶端直接分離數(shù)據(jù)庫(kù)，由客戶端或者我們的微服務(wù)直接選擇。將閱讀選擇路由到主圖書(shū)館，將查詢路由到從主圖書(shū)館。

使用數(shù)據(jù)中間件代理的方法是一個(gè)代理層分布數(shù)據(jù)讀寫(xiě)，業(yè)務(wù)層通過(guò)代理實(shí)現(xiàn)所有請(qǐng)求。這種方式的好處是業(yè)務(wù)層不需要知道數(shù)據(jù)庫(kù)的存在，但問(wèn)題是對(duì)數(shù)據(jù)中間件的性能要求高，需要專人進(jìn)行優(yōu)化和維護(hù)，整體架構(gòu)復(fù)雜。但是我們發(fā)現(xiàn)，雖然這兩種方法各有利弊。但核心是通過(guò)數(shù)據(jù)寫(xiě)入和查詢請(qǐng)求路由來(lái)實(shí)現(xiàn)的，所以這樣會(huì)導(dǎo)致題頭的問(wèn)題:主備同步有延遲，所以在延遲時(shí)間內(nèi)查詢插入的內(nèi)容找不到最新的事務(wù)。

簡(jiǎn)單來(lái)說(shuō)，API主導(dǎo)的連接方法可以看作是API設(shè)計(jì)的分層方法(至少在本文中)。其中，系統(tǒng)API公開(kāi)了系統(tǒng)的資產(chǎn)數(shù)據(jù)信息；中間是流程API，與系統(tǒng)API排列組合；頂級(jí)體驗(yàn)API公開(kāi)來(lái)自后端數(shù)據(jù)源的數(shù)據(jù)，并提供最終用戶體驗(yàn)。這種API分層方法與細(xì)粒度的SOA模式結(jié)合得很好。通常，這兩者可以共存，或者細(xì)粒度SOA模式演變?yōu)榛诩?xì)粒度SOA的分層API模式。

然而，基于細(xì)粒度SOA的分層API模式也有一些類似于細(xì)粒度SOA模式的深層問(wèn)題(這很直觀):在細(xì)粒度SOA模式執(zhí)行單個(gè)API調(diào)用的地方，基于細(xì)粒度SOA的分層API模式現(xiàn)在必須通過(guò)層執(zhí)行多個(gè)調(diào)用。從“網(wǎng)絡(luò)跳數(shù)”的角度來(lái)看，這種模式可能是低效的。但是在基于細(xì)粒度SOA的分層API模式中，層次結(jié)構(gòu)的存在并不強(qiáng)制每個(gè)API跨網(wǎng)絡(luò)調(diào)用。