上一篇文章《小小的IP，大大的耦合，你痛过吗?》什么是联轴器？耦合是指原本互不相关的代码、模块、服务、系统由于某种原因连接在一起，独立性差的架构。影响相互影响，变化相互影响。变化的建筑状态。从感官上，如何发现系统中的耦合？作为一个技术人，经常在心里骂上下游，骂兄弟部门，“这东西跟我有什么关系？这件事我凭什么要配合？”。显然不应该挂钩，而是被动影响，可能存在潜在的耦合。因为是公共库，相互影响是耦合的典型案例。场景还原了一个看似“公开”的业务库（*.so*.jar*.dll*.php）。许多业务系统都依赖于这个公共库，这使得这些系统耦合在一起。注意：这里的公共库不是指像“字符串操作”这样的常量工具库，更多的是指一般业务的公共库。耦合如何导致相互影响？业务1、业务2、业务3都依赖于某个biz.jar，业务1因为某个需求需要升级biz.jar。上线前，业务1的QA进行了大量的测试。确保没有错误后，代码就发布了。突然bug群里有人反映业务2的系统宕机了，业务3的系统也宕机了，锅子炸了：业务2的大佬第一个疯了：“怎么了技术，为什么系统挂了”业务2一脸无辜：“业务1在线，所以我们挂了。嗯，不过，这个原因大佬好像也解释不了……业务2的大佬：“业务1上线了？我们在业务1上线前测试过什么？”业务1的qa信心满满：“我测试过了，上线前后都验证过了，没问题。”业务2的大老板对着业务2的rd大喊“我要把锅扔了拖出去拜天”不知道大家在工作中会不会遇到这样的场景。因为公共图书馆的耦合，兄弟系上线了，受影响的确实是你。这个时候你心里可能在咒骂你妈，这些不靠谱的**队友。特别是如果公共图书馆被广泛使用，这种耦合是非常严重的，可能会影响很大的范围。如何解耦公共图书馆？(1)方案一：复制代码。不要嘲笑这个解决方案。谁敢说你写代码的时候没有这样做过？我们都知道这不是一个很好的解决方案，但不可否认的是，复制之后，代码是各自进化的，如果一个地方出现升级错误，影响的只有一方，只要复制的一方不动原来的代码，至少不会受到影响。代码复制有很多缺点。当系统分裂时，不要将此解决方案作为最后的手段。(2)方案二：垂直拆分，将公库中的业务个性化代码拆分给调用方，不要放在公库中，需要将业务个性化代码拆分到各个业务线自己的项目中，自己的业务去对库，比如s1.jar/s2.jar/s3.jar，修改各自的代码，至少不扩大影响范围。为什么每个人都把代码放到公共图书馆？很多时候，因为惯性，一点点的惯性，日积月累，最终变成一个大坑。这种垂直拆分是一个架构重构的过程，需要所有业务方的通力合作。(3)方案三：服务化，第一步是将公共库中的通用业务代码下移到下层，将业务个性化代码提取到业务端上游。接下来就是第二步，业务的公共代码，下沉抽取一层服务，服务向上游提供RPC接口：每次修改底层接口，都需要接口的兼容性测试以确保旧呼叫者不受影响。如果是新业务，建议增加接口，通过服务RPC调用实现解耦。有朋友会问：底层服务接口的测试，上游业务层的测试，都是对公库的测试。为什么前者可以控制影响范围？公库测试只能保证自己的业务没有问题，不能保证其他业务方没有问题。非常有效。【本文为专栏作者《58神剑》原创稿件，转载请联系原作者】点此阅读更多该作者好文
