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

答：架構痛點是別人，被動修改配合方卻是你。這是一個架構設計上“反向依賴”的問題，這就是典型的耦合特征。

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

案例一：公共庫耦合。

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

那怎么解耦呢？

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

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

案例二：通信機制不當耦合。

什么是通信機制不當？

有一類業(yè)務場景，消息發(fā)送方不關注消息接收方的執(zhí)行結果，如果采用RPC調用的方式來通信，會導致系統(tǒng)上下游耦合。

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

那怎么解耦呢？

答：通過MQ異步解耦。

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

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

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

如上圖所示，在配置中使用了IP，當服務方修改IP時，如果需要調用方被動配合修改配置重啟，則上下游間接的通過ip這個配置耦合在了一起，架構不合理。

那怎么解耦呢？

答：通過內網域名而不是IP來進行下游連接。

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

案例四：服務化不徹底耦合。

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

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

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

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

那怎么解耦呢？

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

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

稍作總結：

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

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

案例五：下游擴容導致的耦合。

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

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

知其然，知其所以然。

思路比結論更重要。