【转载】小小的公共库，大大的耦合，你痛过吗？

什么是耦合？

耦合，是架构中，本来不相干的代码、模块、服务、系统因为某些原因联系在一起，各自独立性差，影响则相互影响，变动则相互变动的一种架构状态。

感官上，怎么发现系统中的耦合？

作为技术人，每每在心中骂上下游，骂兄弟部门，“这个东西跟我有什么关系？为什么需要我来配合做这个事情？”。明明不应该联动，却要被动受影响，就可能有潜在的耦合。

因为公共库，导致相互受影响，就是一个耦合的典型案例。

场景还原

一个看似“公共”的业务库(*.so *.jar *.dll *.php)，很多业务系统都依赖于这个公共库，这个库使得这些系统都耦合在了一起。

注：这里的公共库不是指像“字符串操作”这样的不变化的工具库，更多是指通用业务的公共库。

耦合如何导致相互影响？

业务1，业务2，业务3都依赖于某一个biz.jar，业务1因为某个需求需要升级biz.jar。上线前，业务1的QA进行了大量的测试，确保无误后，代码发布，发布完线上验证无误后，上线完成，闪人。

突然，bug群里有人反馈，业务2的系统挂了，业务3的系统也挂了，一下炸开了锅：

• 业务2的大boss首先发飙：“技术都干啥了，怎么系统挂了”

• 业务2的rd一脸无辜：“业务1上线了，所以我们挂了”

额，然而，这个理由，好像在大boss那解释不通…

• 业务2的大boss：“业务1上线？业务1上线前测试了么”

• 业务1的qa自信满满：“测试了呀，上线前上线后都验证了，没问题呀”

• 业务2的大boss对业务2的rd吼道“还想甩锅，拖出去祭天”

不知道大家工作中会不会遇到这样的场景，因为公共库的耦合，兄弟部门上线，影响的确是你，此时你心里可能就在骂娘了，这帮不靠谱的**队友。

特别的，如果公共库的使用方很广，这个耦合很严重，可能影响很大的范围。

如何解除公共库耦合？

方案一：代码拷贝一份

别嘲笑这个方案，谁敢说自己写代码的时候没这么干过？

我们都知道这不是一个好的方案，但不可否认，拷贝之后，代码各自演化，一个地方升级出错，只影响一方，拷贝方只要不动原有代码，至少是不会受影响的。

代码拷贝缺点很多，系统拆分时，万不得已不要使用这个方案。

方案二：垂直拆分，将公共库里业务个性化的代码拆到调用方去，不要放在公共库里

需要把业务个性的代码拆分到各个业务线自己的工程，自己的业务库里去，例如s1.jar / s2.jar / s3.jar，修改各自的代码，至少不会扩大影响范围。

大家为什么都把代码往一个公共库里塞？

很多时候，因为惰性，一点一点的惰性，日积月累，终成大坑。

这个垂直拆分是一个架构重构的过程，需要各业务方配合。

方案三：服务化，将公共库里通用业务代码拆到下层去

完成了第一步，业务个性化的代码提取到业务侧上游。

接下来是第二步，业务通用的代码，下沉抽取一层服务，服务对上游提供RPC接口：

• 每次修改底层接口，需要测试接口的兼容性，保证不影响旧调用方

• 如果是新的业务，则建议新增接口

最终，达到通过服务RPC调用的方式来解除耦合。

有朋友会问：

• 底层服务接口的测试

• 上游业务层对公共库的测试

都是测试，为何前者能控制影响范围呢？

• 底层接口，所有人调用，接口没问题则调用方都没问题

• 上游业务层对公共库测试，只能保证自己的业务没有问题，并不能保证其他业务方没有问题

个性业务代码上浮，共性业务代码服务化下沉，只是一个很小的优化点，但对于公共库解耦却是非常的有效。

希望大家每天收获一点点，这样架构就能美好一点点。

别人上线，你的系统挂了，痛过吗？那帮转下。

【转自】58沈剑 架构师之路