如何發(fā)現(xiàn)系統(tǒng)架構(gòu)中的耦合？

答：架構(gòu)痛點(diǎn)是別人，被動(dòng)修改配合方卻是你。這是一個(gè)架構(gòu)設(shè)計(jì)上“反向依賴”的問題，這就是典型的耦合特征。

如果系統(tǒng)架構(gòu)中經(jīng)常出這類情況，往往架構(gòu)上就有解耦優(yōu)化的空間。

案例一：公共庫耦合。

如上圖所示，三個(gè)服務(wù)s123，通過一個(gè)公共的庫biz.jar來實(shí)現(xiàn)一段業(yè)務(wù)邏輯，s123其實(shí)間接通過公共庫耦合在了一起，一個(gè)業(yè)務(wù)s1主動(dòng)修改一塊公共的代碼，導(dǎo)致影響s23被動(dòng)受影響，這種耦合不合理。

那怎么解耦呢？

答：業(yè)務(wù)垂直拆分。

公共庫中應(yīng)該是通用代碼，不應(yīng)該實(shí)現(xiàn)個(gè)性化很強(qiáng)的業(yè)務(wù)邏輯?？梢詫iz.jar拆分為biz1.jar/biz2.jar/biz3.jar，個(gè)性化的業(yè)務(wù)邏輯各回各家，來對(duì)s12s3進(jìn)行解耦。這樣的話，任何業(yè)務(wù)的改動(dòng)，影響范圍只是自己，不會(huì)影響其他人。

案例二：通信機(jī)制不當(dāng)耦合。

什么是通信機(jī)制不當(dāng)？

有一類業(yè)務(wù)場(chǎng)景，消息發(fā)送方不關(guān)注消息接收方的執(zhí)行結(jié)果，如果采用RPC調(diào)用的方式來通信，會(huì)導(dǎo)致系統(tǒng)上下游耦合。

如上圖所示，上游通過RPC調(diào)用的方式通知下游，如果新增消息接收方biz4，會(huì)發(fā)現(xiàn)修改代碼的是消息發(fā)送方，新增一個(gè)對(duì)biz-4的調(diào)用，你的主動(dòng)需求，我的被動(dòng)修改，這種耦合不合理。

那怎么解耦呢？

答：通過MQ異步解耦。

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

案例三：配置中的ip耦合。

何時(shí)會(huì)出現(xiàn)配置中的ip耦合？

如上圖所示，在配置中使用了IP，當(dāng)服務(wù)方修改IP時(shí)，如果需要調(diào)用方被動(dòng)配合修改配置重啟，則上下游間接的通過ip這個(gè)配置耦合在了一起，架構(gòu)不合理。

那怎么解耦呢？

答：通過內(nèi)網(wǎng)域名而不是IP來進(jìn)行下游連接。

如上圖所示，如果使用內(nèi)網(wǎng)域名，當(dāng)服務(wù)方要更換IP時(shí)，只需要運(yùn)維層面將內(nèi)網(wǎng)域名指向新的ip，然后統(tǒng)一切斷原有舊的連接，連接就能夠自動(dòng)切換到新的ip上來。這個(gè)過程不需要所有上游配合，就能完成解耦。

案例四：服務(wù)化不徹底耦合。

微服務(wù)是互聯(lián)網(wǎng)非常典型的架構(gòu)模式，但如果服務(wù)化不徹底，service本身也容易成為業(yè)務(wù)耦合點(diǎn)。

如上圖所示，共性服務(wù)biz.service中，可能包含“根據(jù)不同業(yè)務(wù)，執(zhí)行不同個(gè)性分支”的代碼。

• switch (biz-type)
• case biz-1 : exec1
• case biz-2 : exec2
• case biz-3 : exec3
• …

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

那怎么解耦呢？

業(yè)務(wù)特性代碼上浮，業(yè)務(wù)共性代碼下沉。

如上圖所示，把swithc case中業(yè)務(wù)特性代碼放到業(yè)務(wù)層實(shí)現(xiàn)，這樣biz123有個(gè)性的業(yè)務(wù)需求，升級(jí)的是自己的業(yè)務(wù)系統(tǒng)，而不是下游的微服務(wù)。

稍作總結(jié)：

• 公共庫耦合，業(yè)務(wù)垂直拆分解耦；
• 通信機(jī)制不當(dāng)耦合，MQ異步解耦；
• 配置中的ip耦合，通過內(nèi)網(wǎng)域名解耦；
• 服務(wù)化不徹底耦合，業(yè)務(wù)特性代碼上浮，業(yè)務(wù)共性代碼下沉解耦。

總而言之，痛的是你，被動(dòng)修改的卻是我，大概率就有耦合。

案例五：下游擴(kuò)容導(dǎo)致的耦合。

如上圖所示，這次不是換換ip這么簡(jiǎn)單了，下游服務(wù)提供方原來是集群123，要擴(kuò)容為12345，使用的是內(nèi)網(wǎng)域名，上游卻還是需要被動(dòng)修改配置，新增擴(kuò)容后的節(jié)點(diǎn)，再重啟。

這種情況下，怎么解耦呢？

知其然，知其所以然。

思路比結(jié)論更重要。