业务架构 序列3 真的分层 vs.伪分层架构?

说到分层架构,相信没有人不知道,一个被说烂的词。无论业务架构,还是技术架构;无论做C端业务,B端业务;无论做服务器,还是客户端,还是别的什么地方,所有人都会用这个。

但就是这样一个熟悉的不能再熟悉的架构方法,却往往被滥用。

下面这个图,展示了一个最常见的一个互联网系统的分层架构:

但是它只是停留在PPT上面,实际的代码、系统是否是按这个分层架构严格执行的呢? 如果你把所有系统梳理一遍,把系统之间的依赖关系图画出来,往往就不是这样一个分层结构,可能是一个网状结构了。

以上图为例,下面列举一下伪分层架构的可能具有的一些特征(不绝对,但大多时候会反映出问题):

(1)底层调用上层

比如某个基础服务,调用上层的业务服务。那如果出现了底层调用上层,怎么解决呢?

办法1:你要去思考,这个业务逻辑是否放错了地方?或者这个业务逻辑是否需要1分为2, 1部分放在业务服务,1部分放在基础服务。也就避免了底层调用上层。

办法2:OOD中的典型办法,DIP(依赖反转)。底层定义接口,上层去实现,而不是底层直接调用上层。关于依赖反转的详细内容,此处不再详述,可以百度之。

(2)同层之间,服务之间各种双向调用

比如业务服务1,业务服务2,业务服务3之间都是双向调用。

那你就要思考,服务1,2, 3之间的职责分配是不是有问题,出现了服务之间的紧耦合?

是不是应该有一个公共的服务,让这个公共服务和业务服务1,业务服务2,业务服务3去交互,而1,2,3之间相互独立?

(3)地基不稳:层之间没有隔离,参数层层透传,一直穿透到最底层。导致底层系统经常变动。

举个例子,APP一直发版本,为了做兼容,服务器端有类似下面的代码:

if(version = 1.0)

xxx

else if (version = 1.1)

xxx

else if (version = 2.0)

xxx

然后你发现这样的代码,聚合层有,业务服务层有,基础服务里面也有。这就是典型的“透传”,没有隔离,也就是没有抽象。

虽然是严格分了层,层层调用,但“底层服务“已经不是底层服务,而成了1个大杂烩。

(4)聚合层特别多,为了满足客户端需求,各种拼装

遇到这种情况,往往意味着业务服务层太薄,纯粹是从技术角度去拆的业务。而不是从业务角度,让服务成为1个完整的闭环,或者说1个领域。

总结

上面列举了一个不好的分层架构的种种特征,对应的,也就是一个良好的分层架构应该具有的特征:

(1)系统实际应该和PPT保持一致。PPT上画的分层,实际系统依赖图应该也是如此。

(2)越底层的系统越单一、越简单、越稳定;越上层的系统花样越多、越容易变化。这需要层与层之间有很好的隔离、抽象。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180526G0DHOB00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券