如何发现架构中的耦合（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

文章不长，可扩展阅读。

==全文完==