如何發現系統架構中的耦合？

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

如果系統架構中經常出這類情況，往往架構上就有解耦優化的空間。

案例一：公共庫耦合。

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

那怎么解耦呢？

答：業務垂直拆分。

公共庫中應該是通用代碼，不應該實現個性化很強的業務邏輯。可以將biz.jar拆分為biz1.jar/biz2.jar/biz3.jar，個性化的業務邏輯各回各家，來對s12s3進行解耦。這樣的話，任何業務的改動，影響范圍只是自己，不會影響其他人。

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

什么是通信機制不當？

有一類業務場景，消息發送方不關注消息接收方的執行結果，如果采用RPC調用的方式來通信，會導致系統上下游耦合。

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

那怎么解耦呢？

答：通過MQ異步解耦。

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

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

何時會出現配置中的ip耦合？

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

那怎么解耦呢？

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

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

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

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

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

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

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

那怎么解耦呢？

業務特性代碼上浮，業務共性代碼下沉。

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

稍作總結：

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

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

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

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

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

知其然，知其所以然。

思路比結論更重要。