什么是耦合？耦合是一种架构状态，架构中不相关的代码、模块、服务和系统由于某种原因被链接在一起，独立性很差。影响相互影响，变化相互改变。.从感官上，如何发现系统中的耦合？作为一个技术人，经常在心里骂上下游，骂兄弟部门，“这东西跟我有什么关系？这件事我凭什么要配合？”。显然不应该有联动，但被动配合可能会造成潜在的耦合。因为是公共库，相互影响是耦合的典型案例。场景还原了一个看似“公开”的业务库（*.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：复制代码。别笑这个方案，谁敢说他写代码的时候不是这么做的？我们都知道这不是一个好的解决方案，但不可否认的是，拷贝之后，代码是独立演化的，一个地方的升级错误只会影响一方，而拷贝方只要原代码不动，至少不会受到影响。代码复制有很多缺点。当系统分裂时，不要将此解决方案作为最后的手段。方案二：垂直拆分，将公库中的业务个性化代码拆分给调用方，不要放在公库中。需要将业务个性的代码拆分成每个业务线自己的项目和自己的业务库，比如s1.jar/s2.jar/s3.jar，修改各自的代码，至少不要扩大范围影响。为什么每个人都把代码放到公共图书馆？很多时候，因为惯性，一点点的惯性，日积月累，最终变成一个大坑。这种垂直拆分是一个架构重构的过程，需要所有业务方的通力合作。方案三：服务化，将公共库中的通用业务代码下放。第一步完成，将业务个性化代码提取到业务端上游。接下来就是第二步，业务的公共代码，下沉提取一层服务，服务向上游提供RPC接口：每次修改底层接口，都需要测试接口的兼容性确保老来电不受影响；如果是新业务，建议增加接口；最后，通过服务RPC调用实现解耦。有朋友会问：底层服务接口的测试；上游业务层在公库上的测试；都是考验，为什么前者能控制影响范围？公库层层测试只能保证自身业务没有问题，不能保证其他业务方没有问题。个别业务代码上去和普通业务代码服务化只是一个小的优化点，但是对于公共库的解耦是非常有效的。希望大家每天都有一点收获，这样结构才能好一点。画外音：原来复制代码有解耦的效果？
