一、緣起

---

很多公司，技術(shù)經(jīng)常遇到這樣的場(chǎng)景：
1）硬件升級(jí)，要換一臺(tái)高配機(jī)器
2）網(wǎng)絡(luò)重新規(guī)劃，若干服務(wù)器要調(diào)整機(jī)架
3）服務(wù)器宕機(jī)，要重新部署恢復(fù)服務(wù)
…

更具體的，如上圖：數(shù)據(jù)庫(kù)換了一個(gè)ip，此時(shí)往往連接此數(shù)據(jù)庫(kù)的上游需要修改配置重啟，如果數(shù)據(jù)庫(kù)有很多上游調(diào)用方，改配置重啟的調(diào)用方會(huì)很多，每次換ip的成本往往很高，成為大家共性的痛點(diǎn)。

由A的調(diào)整（數(shù)據(jù)庫(kù)換ip），配合修改和調(diào)整的卻是BCDE（改配置重啟），BCDE內(nèi)心非常的郁悶：明明換ip的是你，憑什么配合重啟的卻是我？

根本上，這是一個(gè)“架構(gòu)耦合”的問題，是一個(gè)架構(gòu)設(shè)計(jì)上“反向依賴”的問題，本文將討論的是架構(gòu)設(shè)計(jì)中常見的“反向依賴”的設(shè)計(jì)，以及對(duì)應(yīng)的優(yōu)化方案，希望對(duì)大伙有所啟示。

二、如何尋找不合理“反向依賴”

---

方法論：
變動(dòng)方是A，配合方卻是BCDE
（或者說(shuō)需求方是A，改動(dòng)方確是BCDE）
想想“換IP的是你，配合重啟的卻是我”更好理解。

如果系統(tǒng)中經(jīng)常出現(xiàn)了這類情況，就是“反向依賴”的特征，往往架構(gòu)上有優(yōu)化的空間。

三、常見的“反向依賴”與優(yōu)化方案

---

【case1：公共庫(kù)導(dǎo)致耦合】

三個(gè)服務(wù)s1/s2/s3，通過(guò)一個(gè)公共的庫(kù)biz.jar來(lái)實(shí)現(xiàn)一段業(yè)務(wù)邏輯，s1/s2/s3其實(shí)間接通過(guò)biz.jar耦合在了一起，一個(gè)業(yè)務(wù)s1修改一塊公共的代碼，導(dǎo)致影響其他業(yè)務(wù)s2/s3，架構(gòu)上是不合理的。
 
優(yōu)化方案1：業(yè)務(wù)垂直拆分

如果biz.jar中實(shí)現(xiàn)的邏輯“業(yè)務(wù)特性”很強(qiáng)，可以拆分為biz1.jar/biz2.jar/biz3.jar，來(lái)對(duì)s1/s2/s3進(jìn)行解耦。這樣的話，任何業(yè)務(wù)的改動(dòng)，影響范圍只是自己，不會(huì)影響其他人。
 
優(yōu)化方案2：服務(wù)化

如果biz.jar中實(shí)現(xiàn)的邏輯“業(yè)務(wù)共性”很強(qiáng)，可以將biz.jar優(yōu)化為biz.service服務(wù)，來(lái)對(duì)s1/s2/s3進(jìn)行解耦。服務(wù)化之后，兼容性能更好的通過(guò)接口自動(dòng)化回歸測(cè)試來(lái)保證。

基礎(chǔ)服務(wù)的抽象，本身是一種共性聚焦，是系統(tǒng)解耦常見的方案。

【case2：服務(wù)化不徹底導(dǎo)致耦合】

服務(wù)化是解決“業(yè)務(wù)共性”組件庫(kù)導(dǎo)致系統(tǒng)耦合的常見方案之一，但如果服務(wù)化不徹底，service本身也容易成為業(yè)務(wù)耦合點(diǎn)。

典型的服務(wù)化不徹底導(dǎo)致的業(yè)務(wù)耦合的特征是，共性服務(wù)中，包含大量“根據(jù)不同業(yè)務(wù)，執(zhí)行不同個(gè)性分支”的代碼。
switch (biz-type)
case biz-1 : exec1
case biz-2 : exec2
case biz-3 : exec3
…

在這種架構(gòu)下，biz-1/biz-2/biz-3有個(gè)性的業(yè)務(wù)需求，可能導(dǎo)致修改代碼的是共性的biz-service，使其成為研發(fā)瓶頸，架構(gòu)上也是不合理的。

優(yōu)化方案：業(yè)務(wù)特性代碼上浮，業(yè)務(wù)共性代碼下沉，徹底解耦

把swithc case中業(yè)務(wù)特性代碼放到業(yè)務(wù)層實(shí)現(xiàn)，這樣biz-1/biz-2/biz-3有個(gè)性的業(yè)務(wù)需求，升級(jí)的是自己的業(yè)務(wù)系統(tǒng)。

【case3：notify的不合理實(shí)現(xiàn)導(dǎo)致的耦合】

《究竟什么時(shí)候該使用MQ》一文中有一類業(yè)務(wù)場(chǎng)景，消息發(fā)送方不關(guān)注消息接收方的執(zhí)行結(jié)果，如果采用調(diào)用的方式來(lái)實(shí)現(xiàn)通知，會(huì)導(dǎo)消息發(fā)送方和消息接收方耦合。

如何新增消息接收方biz-4，會(huì)發(fā)現(xiàn)修改代碼的是消息發(fā)送方，新增一個(gè)對(duì)biz-4的調(diào)用，極不合理。

優(yōu)化方案：通過(guò)MQ實(shí)現(xiàn)解耦

消息發(fā)送方upper將消息發(fā)布給MQ，消息接收方從MQ去訂閱，任何新增對(duì)消息的消費(fèi)，upper都不需要修改代碼。

【case4：配置中的ip導(dǎo)致上下游耦合】

即“緣起”中舉的例子，下游服務(wù)換ip，可能導(dǎo)致多個(gè)服務(wù)調(diào)用方修改配置重啟。上下游間接的通過(guò)ip這個(gè)配置耦合在了一起，架構(gòu)不合理。

優(yōu)化方案：通過(guò)內(nèi)網(wǎng)域名而不是ip來(lái)進(jìn)行下游連接

如果在配置中使用內(nèi)網(wǎng)域名來(lái)進(jìn)行下游連接，當(dāng)下游服務(wù)或者數(shù)據(jù)庫(kù)更換ip時(shí)，只需要運(yùn)維層面將內(nèi)網(wǎng)域名指向新的ip，然后統(tǒng)一切斷原有舊的連接，連接就能夠自動(dòng)切換到新的ip上來(lái)。這個(gè)過(guò)程不需要所有上游配合，非常帥氣，強(qiáng)烈推薦！

【case5：下游擴(kuò)容導(dǎo)致上下游耦合】

這次不是換換ip這么簡(jiǎn)單了，下游服務(wù)提供方原來(lái)是集群（ip1/ip2/ip3，當(dāng)然，上游配置的是內(nèi)網(wǎng)域名），現(xiàn)在集群要擴(kuò)容為（ip1/ip2/ip3/ip4/ip5），如果沒有特殊的架構(gòu)設(shè)計(jì)，上游往往需要修改配置，新增擴(kuò)容后的節(jié)點(diǎn)，再重啟，導(dǎo)致上下游耦合。

這類case，大伙有什么好的方案解耦么？
技術(shù)細(xì)節(jié)，且聽下回分解。

四、總結(jié)

---

如何發(fā)現(xiàn)系統(tǒng)架構(gòu)中不合理的“反向依賴”設(shè)計(jì)？
回答：
（1）變動(dòng)方是A，配合方卻是BCDE
（2）需求方是A，改動(dòng)方確是BCDE
想想“換IP的是你，配合重啟的卻是我”，此時(shí)往往架構(gòu)上可以進(jìn)行解耦優(yōu)化。
 
常見反向依賴及優(yōu)化方案？
（1）公共庫(kù)導(dǎo)致耦合
優(yōu)化一：如果公共庫(kù)是業(yè)務(wù)特性代碼，進(jìn)行公共庫(kù)垂直拆分
優(yōu)化二：如果公共庫(kù)是業(yè)務(wù)共性代碼，進(jìn)行服務(wù)化下沉抽象

（2）服務(wù)化不徹底導(dǎo)致耦合
特征：服務(wù)中包含大量“根據(jù)不同業(yè)務(wù)，執(zhí)行不同個(gè)性分支”的代碼
優(yōu)化方案：個(gè)性代碼放到業(yè)務(wù)層實(shí)現(xiàn)，將服務(wù)化更徹底更純粹

（3）notify的不合理實(shí)現(xiàn)導(dǎo)致的耦合
特征：調(diào)用方不關(guān)注執(zhí)行結(jié)果，以調(diào)用的方式去實(shí)現(xiàn)通知，新增訂閱者，修改代碼的是發(fā)布者
優(yōu)化方案：通過(guò)MQ解耦

（4）配置中的ip導(dǎo)致上下游耦合
特征：多個(gè)上游需要修改配置重啟
優(yōu)化方案：使用內(nèi)網(wǎng)域名替代內(nèi)網(wǎng)ip，通過(guò)“修改DNS指向，統(tǒng)一切斷舊連接”的方式來(lái)上游無(wú)感切換

（5）下游擴(kuò)容導(dǎo)致上下游耦合

特性：多個(gè)上游需要修改配置重啟