如何发现架构中的耦合（5大场景）？（第36讲）
《架构师之路：架构设计中的100个知识点》
36.耦合，解耦
如何发现系统架构中的耦合？
答：架构痛点是别人，被动修改配合方却是你。这是一个架构设计上“反向依赖”的问题，这就是典型的耦合特征。
如果系统架构中经常出这类情况，往往架构上就有解耦优化的空间。
案例一：公共库耦合。
如上图所示，三个服务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有个性的业务需求，升级的是自己的业务系统，而不是下游的微服务。
稍作总结
1. 公共库耦合，业务垂直拆分解耦；
2. 通信机制不当耦合，MQ异步解耦；
3. 配置中的ip耦合，通过内网域名解耦；
4. 服务化不彻底耦合，业务特性代码上浮，业务共性代码下沉解耦。
总而言之，痛的是你，被动修改的却是我，大概率就有耦合。
案例五：下游扩容导致的耦合。
如上图所示，这次不是换换ip这么简单了，下游服务提供方原来是集群123，要扩容为12345，使用的是内网域名，上游却还是需要被动修改配置，新增扩容后的节点，再重启。
这种情况下，怎么解耦呢？
知其然，知其所以然。
思路比结论更重要。
补充阅读材料：
《事件驱动架构：紧耦合与松耦合》
https://serverlessland.com/event-driven-architecture/tight-coupling-vs-loose-coupling
文章不长，可扩展阅读。
==全文完==
20年，系列1（已完结）：
《架构师定会遇到的80个经典架构问题！》
21年，系列2（已完结）：
《关于即时通讯架构的一切！》
24年，系列3（进行中）：
《架构设计中的100个知识点》
短视频+图文+直播+星球社群，免费。
讲技术的宝藏号，日更，保护起来。
点赞，转发，在看，感激不尽！