我去,拷贝代码,居然还有这等好处?

共 1763字,需浏览 4分钟

 ·

2021-08-09 23:37

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

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

 

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

 

场景还原

一个看似“公共”的业务库(*.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接口:

(1)每次修改底层接口,需要测试接口的兼容性,保证不影响旧调用方;

(2)如果是新的业务,则建议新增接口;

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

 

有朋友会问:

(1)底层服务接口的测试;

(2)上游业务层对公共库的测试;


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

(1)底层接口,所有人调用,接口没问题则调用方都没问题

(2)上游业务层对公共库测试,只能保证自己的业务没有问题,并不能保证其他业务方没有问题。

 

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


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

画外音:原来拷贝代码,还有解耦的功效? 

别人上线,你的系统挂了,痛过吗?

那帮下。


推荐文章
每秒100W次的计数,架构这样设计
数据库软件架构,到底要设计些什么
MySQL官方的数据库中间件
浏览 24
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报