业务架构 序列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）越底层的系统越单一、越简单、越稳定；越上层的系统花样越多、越容易变化。这需要层与层之间有很好的隔离、抽象。