架构分层—高并发场景微服务实战（四）

你好，我是程序员Alan。

在《系统架构设计— 高并发场景微服务实战（三）》一文中，我提了一个问题“系统架构设计为什么要分层?”，这篇文章我会详细说一下我的见解，写的比较浅薄，见笑了。

什么是分层架构

软件架构分层在软件工程中是一种常见的设计方式，它是将整体系统拆分成N个层级，每个层级有独立的职责，多个层级协同提供完整的功能。下面给大家分享一些我收藏的分层架构图。

分层有什么好处

如果公司要开发一款小程序但是只有你一个程序员，前后端都要你来写，即使程序很简单但如果你对前端或者后端开发不熟悉，是不是很痛苦。因为你必须是一个通晓全栈开发的程序员，要知道前后端的知识以及各种异常情况的处理。而如果前后端分离，有一个前端或者后端配合你，你只需要专注自己会的领域就可以了，剩下的交给其他同事，是不是就很幸福了。

再以发生在我自己身上的一件事情举个例子吧，在写上一篇文章《系统架构设计— 高并发场景微服务实战（三）》时候，我非常非常想把高并发技术栈和微服务技术栈开发中我所知道的问题全部都讲清楚了但是我的能力又不足以让我在短短的一篇推文中表达清楚矛盾纠结，所以我觉得很痛苦。痛苦的程度，您只要再读一遍我上面这长长的一串不带标点符号的句子就能够深切地感受到了。

为什么会这么痛苦，在写这篇文章时我大概想明白了，主要有两个原因。第一点是我自己能力不够，对各各组件的掌握还不够。第二点是我没有把任务分层解耦，所有的事情都揉在一起来思考，提升了任务的复杂度。总结一下就是自己过于贪大求全了。

我不是一个全才，现在不是，未来也不会是。会遇到很多复杂的问题，这时候需要把问题分层解耦，拆分成一个个小问题去解决。会遇到很多我个人无力解决但又不得不去解决的问题，这个时候需要寻求朋友的帮助，不用非常清楚朋友怎么解决问题的，但要需要知道向哪些朋友寻找帮助以及感恩。

如何来做系统分层

分层架构的优点还有很多很多，那么我们要如何来做分层设计呢，有哪些关键因素需要考虑？

我个人认为，最重要的一点是要理清楚每个层次的边界是什么。即使是层次分明 Web 项目，当业务逻辑复杂后，也会存在边界越来越模糊的问题，举个简单的例子。

大家开发过的系统中应该都有一个用户服务，最基本的接口就是查询用户信息接口，它的请求链路是，DTO -> Controller -> Service . DTO层接收前端传入的请求参数，序列化后传入给 Controller层调用Service层接口。

这个时候如果PO提出一个需求，当查询的用户不存在时，要自动的创建一个用户，并返回。这个时候逻辑层的边界就开始变得模糊了，因为表现层也承担了一部分的业务逻辑（查询用户和创建用户编排起来）。这个时候我们可以怎么处理? 参照阿里发布的《阿里巴巴 Java 开发手册 v1.4.0（详尽版）》，我们可以将原先的三层架构细化成下面的样子 :

在这个分层架构中增加了Manager层，它与Service层的关系是：Manager层提供原子的服务接口，Service层负责依据业务逻辑来编排原子接口。

以上面的例子来说，Manager 层提供创建用户和获取用户信息的接口，而 Service 层负责将这两个接口组装起来。这样就把原先散布在表现层的业务逻辑都统一到了 Service 层，每一层的边界就非常清晰了。

除此之外，分层架构需要考虑的另一个因素，是层次之间一定是相邻层互相依赖，数据的流转也只能在相邻的两层之间流转。

分层架构的不足

虽然分层架构有很多优势，但它也有不少缺陷，它最重要的一个缺陷就是增加了代码的复杂度。这是显而易见的，明明我们可以在接收到请求后直接查询和操作数据库，却偏偏在中间插入了多个层次，并且每个层次可能只是简单的做数据传递，有时候增加一个小小的需求也可能要修改一整个链路上的代码，这个时候如果还增加了同事的负担那一定是会引来不少吐槽的。

另外，如果我们把每个层级独立部署，那么层级之间通过网络来交互，在性能上就会有损耗。

留些问题

你知道什么是单一职责原则吗？
你知道什么是迪米特法则吗？
你知道开闭原则吗？

站在巨人的肩膀上

唐扬—高并发系统设计40问
码闻强—SpringCloud微服务实战
从 0 开始学架构