1.由于很多公司的出身，技术上经常会遇到这样的场景：1）硬件升级，需要更换一台高端机2）网络重新规划，几台服务器需要调整到机架3)服务器宕机，需要重新部署恢复Service...更具体的，如上图所示：数据库换了ip。这时候连接数据库的upstream往往需要修改配置重启。如果数据库的上游调用者很多，就会有很多调用者改配置重启。每次更换ip的成本往往很高，成为大家共同的痛点。从A（数据库更改ip）的调整来看，配合修改调整的是BCDE（配置重启）。BCDE很郁闷：改ip的是你，怎么配合重启的是我？从根本上说，这是一个“架构耦合”的问题，是架构设计中“反向依赖”的问题。本文将讨论架构设计中常见的“反向依赖”设计以及相应的优化方案。希望对大家有所帮助。启发。2、如何找到不合理的“反向依赖”方法论：变更方是A，但合作方是BCDE（或者需求方是A，变更方确实是BCDE）。是我”比较好理解，如果系统中经常出现这种情况，就是“反向依赖”的一个特点，往往在架构上有优化的空间。3.常见的“反向依赖”和优化方案【案例】1：公库导致耦合】三个服务s1/s2/s3通过一个公库biz.jar实现了一段业务逻辑，s1/s2/s3其实是通过biz.jar间接耦合在一起的，一个业务s1修改了一段公共代码，影响到其他业务s2/s3，在架构上不合理优化方案一：业务垂直拆分如果biz.jar中实现的逻辑“业务特性”很强，可以拆分成biz1。jar/biz2.jar/biz3.jar对s1/s2/s3进行解耦，这样任何业务变化只会影响自己，不会影响别人优化方案2：Servicing如果逻辑“业务通用”在biz实现。jar强大，biz.jar可以优化为biz.servic解耦s1/s2/s3的服务。面向服务后，通过接口自动化回归测试可以更好的保证兼容性。基础服务的抽象是一个共同的关注点，也是系统解耦的共同解决方案。【案例2：服务化不彻底导致的耦合】服务化是解决“业务共性”组件库导致的系统耦合的常用方案之一，但如果服务化不彻底，服务本身很可能成为业务耦合观点。不完全服务化导致的业务耦合的典型特征是公共服务中包含大量“根据不同业务执行不同个性分支”的代码。switch(biz-type)casebiz-1:exec1casebiz-2:exec2casebiz-3:exec3...该架构下，biz-1/biz-2/biz-3有个别业务需求，可能导致代码修改通用biz-service使其成为研发瓶颈，架构也不合理。优化方案：业务特性代码上浮，业务通用代码下沉，将switchcase中的业务特性代码完全解耦到业务层实现，使biz-1/biz-2/biz-3有个性化的业务需求和可以升级的是自己的业务系统。【case3：notify实现不合理导致的耦合】《究竟什么时候该使用MQ》文中有一种业务场景。消息发送者不关注消息接收者的执行结果。如果通知是通过调用来实现的，消息发送者和消息接收者耦合。如何添加消息接收者biz-4，你会发现修改代码的是消息发送者，添加对biz-4的调用是极其不合理的。优化方案：解耦消息发送端上层通过MQ发布消息到MQ，消息接收端从MQ订阅。对于任何新的消息消费，上层不需要修改代码。【case4：配置中的ip导致上下游耦合】即在《出处》给出的例子中，更改下游服务的ip可能会导致多个服务调用者修改配置并重启。上下游通过ip配置间接耦合在一起，架构不合理。优化方案：下行连接使用内网域名，不使用ip。如果在配置中使用内网域名进行下游连接，当下游服务或数据库更改ip时，只需在运维层面将内网域名指向新的ip即可。然后统一切断原来的老连接，连接就可以自动切换到新的ip上了。这个过程不需要所有upstream配合，很帅气，强烈推荐！【case5：下游扩容导致上下游耦合】这次不是换ip那么简单，下游服务商竟然是一个集群（ip1/ip2/ip3，当然，上游配置的是内网域名），现在集群需要扩容到（ip1/ip2/ip3/ip4/ip5），如果没有特殊的架构设计，上游往往需要修改配置，增加扩容节点，然后重启，导致上游和下游耦合。4.总结如何发现系统架构中不合理的“反向依赖”设计？答：（1）变更方是A，但是协调方是BCDE（2）需求方是A，变更方确实是BCDE想想“变更”你是拥有IP的，我是与重启合作的人。”这时候往往可以对架构进行解耦和优化。常见的反向依赖和优化方案？(1)公共库导致耦合优化1：如果公共库是业务专有代码，则对公共库进行垂直拆分优化2：如果公共库是业务通用代码，则进行面向服务的下沉抽象(2)未完成服务化导致耦合特性：服务包含大量“根据不同业务执行不同个性分支”的代码优化方案：个性化代码在业务层实现，使服务化更加彻底和纯粹（3）NotifyCoupling合理实现导致的特点：调用者不关注执行结果，通过调用实现通知，新增订阅者，修改代码是发布者优化方案：通过MQ解耦（4）配置中的IP导致上下游耦合特性：多个上游需要修改配置重启Optimization方案：使用内网域名代替内网ip，使用“修改DNS指向，统一切断旧连接”无意义切换上游（5）下游扩展导致上下游耦合特性：多个上游需要修改配置并重启【本文为专栏作家《58神剑》原创稿件，转载请联系原作者】点此阅读更多该作者好文
