【架构】后端项目经典分层架构介绍

前言

开发后端项目时，我们最常见的一种架构模式就是分层架构 。

所谓的分层架构，就是把系统自上而下分为多个不同的层，每一层都有特定的功能和职责，且只和自己的直接上层与直接下层 “打交道”。

分层架构的优点是：每一层都有明确定义的职责，易于理解和维护；而且各层可以独立扩展，以适应不同的需求。

所以分层架构也是最适合新手入门学习、并且实际开发中应用最多的架构。

分层架构

下面给大家一种 Java 企业级后端项目开发时常用的分层架构，一般从前端界面（表示层）发送的请求出发，需要经历接入层、控制层、业务逻辑层、通用业务层、数据访问层、系统资源层等。

• 表示层 通常是指让用户交互和查看信息的前端界面，比如用户点击按钮后能够发送一个请求，也可以叫用户层、界面层等。

• 发送请求后，会经过 接入层 ，比如 Nginx 网关、或者其他中间件，对请求做一个预处理或转发，比如实现负载均衡。这一层不是必须存在的，通常更适用于中大型项目，前端也可以直接请求后端。

• 接入层会将请求转发到 控制层（Controller），负责接受请求、调用业务逻辑层（Service）的代码实现功能、然后响应结果。控制层一般不建议写复杂的业务逻辑，尽量保持精简。
  接下来是 业务逻辑层（Service），负责处理复杂的业务逻辑，比如对请求数据进行校验、处理、调用数据访问层以将结果存到数据库中等，也是我们做系统时主要开发编码的部分。
  通用业务层（Manager、Module）是一种特殊的业务逻辑层，主要的作用是抽取了一些需要被多个业务调用的公共代码，比如上传文件到对象存储、鉴权等，从而实现复用。

• 数据访问层（Dao / Mapper）负责操作底层的数据源，比如对数据库、文件、缓存等进行增删改查。

• 最后是 系统资源层 ，也可以叫基础设施层，包括各种基础服务、系统环境等，比如数据库、消息队列、Redis、文件存储、Linux 系统、Docker 等。复杂的基础设施可能还包括 K8S 容器资源编排、资源调度平台等。

需要注意的是，并不是所有的分层架构都需要这么划分，不同业务和团队可能有自己的分层选择与规范。

项目实践

比如我带大家开发的 OJ 在线判题系统 ，分层架构如下：

示例项目结构

基于分层架构，我们可以将项目按照特定的目录名（包名）来组织代码，比如：

• controller：控制层
• service：业务逻辑层
• mapper：数据访问层
• model：数据模型

还可以按照业务或文件的类型来划分目录，比如：

• constant：常量
• annotation：注解类
• common：公共类
• config：配置类
• job：任务
• exception：异常处理相关
• utils：工具类

以之前带大家做过的为例，项目的目录结构如图：

其他知识

1. 计算机网络也是采用了经典的分层架构，OSI 七层参考模型中，把计算机网络自底向上分为了物理层、数据链路层、网络层、传输层、会话层、表示层和应用层。每个层只处理特定的功能，比如数据传输、数据的路由；层与层之间通过接口（或者叫协议）进行通信。

2. 需要注意的是，我们常用的后端开发框架 Spring MVC 是基于 MVC（Model-View-Controller）设计模式构建的，而不能算是传统的分层架构。而且一般现在的项目中只使用 Spring MVC 作为整个项目的控制层，不过大多数用了 Spring MVC 框架的项目基本都使用了分层架构。