服务化了,没想到耦合更加严重?

12-06 08:36

通过“库”来实现业务,可能会引发业务系统之间耦合, 需要通用业务服务化 ,将通用业务下沉,详见《 小小的公共库,大大的耦合,你痛过吗 》。

通过“join”来实现业务,可能会导致数据库之间耦合, 需要基础数据服务化 ,实现数据库私有化,解除数据库之间的耦合,详见《 小小的数据库,大大的耦合,你通过吗 》。

但如果服务化不合理,将部分个性化业务下沉到了底层,耦合与瓶颈会更加严重

场景还原

业务1,业务2,业务3,因为join导致数据库实例耦合在了一起。

为了实现通用数据库table-user的解耦,实施了服务化,将通用user数据的访问抽象出了服务。

由于服务化不合理, 会有很少很少的个性化业务逻辑,实现在底层的服务中 ,典型的伪代码是:

switch(biz_type){

case(1) : exec_logic1();

case(2) : exec_logic2();

case(3) : exec_logic3();

default : exec_default();

}

为什么会引发耦合呢?

不妨设,业务1来了一个新的 个性化需求 ,这个需求本来实现在业务1自己的代码里是合理的,但工程师S想到,底层的通用服务里也有业务1的一小撮个性化代码, 评估后,发现实现在底层新的需求改动的代码最小,时间最短 ,于是来找底层服务的负责人工程师B。

  • 业务1工程师S :“有个小需求,帮个忙呗”

  • 底层工程师B :“个性化实现在底层不合理”

  • 业务1工程师S :“反正都有switch case的代码了, 再改一点也不麻烦,在我这边实现特别复杂 ,要xxoo这么搞”

  • 底层工程师B :“确实很复杂,那我来吧”

遗留了不合理的代码,就会有第一次妥协,妥协了业务1,就会妥协业务2,随着时间的推移, 底层服务越来越复杂

  • 业务1,业务2,业务3的 个性化代码越来越多

  • 业务1,业务2,业务3的 需求越来越多提给底层工程师

  • 底层工程师慢慢成了项目瓶颈 ,业务1,业务2,业务3的项目逐步delay,但逐步都怪到了底层工程师的头上

直到有一天, 底层服务出了一个小bug,影响了业务1,业务2,业务3 ,历史总是惊人的相似:

  • 业务1的大boss 在群里首先发飙:“ 技术都干啥了,怎么系统挂了

  • 业务1的工程师S 一脸无辜:“ 底层系统改造,工程师S的bug

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

  • 底层服务工程师B 一脸委屈: “...” 明明需求是业务方的,为什么修改代码的是我底层呢,业务代码出了问题,为什么责怪的是我底层呢 ,每每心中骂娘,系统中很可能就存在耦合。

如何解耦呢?

业务代码上浮,通用代码下沉,服务化彻底

解决方案并不复杂,分层架构中, 每一层都有自己的职责,每一层都应该守住自己的底线

启示

一、讨论技术方案时,不要总以:

“放在你那边做代码少”

“放在你那边做时间短”

作为设计折衷的理由,而要多问:

“怎么做合理”

二、尽量杜绝底层出现switch case(biz_type)走不同分支的代码。

业务代码上浮,通用代码下沉,服务化彻底 ,只是一个很小的优化点,但对于 底层服务解耦 却是非常的有效。

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

你痛过吗,你被反问过“ 你实现代价小,你来搞 ”吗?你被迫实现过“ switch case ”吗?那帮 下。

相关文章:

小小的数据库,大大的耦合,你痛过吗?

小小的IP,大大的耦合,你痛过吗?

小小的公共库,大大的耦合,你痛过吗?

原文链接:http://mp.weixin.qq.com/s/m5VNvwobA3r40T6EDJISDQ?utm_source=tuicool&utm_medium=referral
标签: 数据库
© 2014 TuiCode, Inc.