水平分层架构

为什么要分层

分层的好处：

较好的支撑系统扩展

如何分层：

各层之间的差异清晰，实现不同功能层级的分离
只能两两依赖，不能跨层调用

分层架构设计最核心的一点就是需要保证各层之间的差异足够清晰，边界足够明显，让人看到架构图后就能看懂整个架构。

分层架构之所以能够较好地支撑系统扩展，本质在于隔离关注点（separation of concerns），即每个层中的组件只会处理本层的逻辑。

当然，并不是简单地分层就一定能够实现隔离关注点从而支撑快速扩展，分层时要保证层与层之间的依赖是稳定的，才能真正支撑快速扩展。

例如，Linux 内核为了支撑不同的文件系统格式，抽象了 VFS 文件系统接口，架构图如下：

VFS

如果没有 VFS，只是简单地将 ext2、ext3、reiser 等文件系统划为“文件系统层”，那么这个分层是达不到支撑可扩展的目的的。因为增加一个新的文件系统后，所有基于文件系统的功能都要适配新的文件系统接口；而有了 VFS 后，只需要 VFS 适配新的文件系统接口，其他基于文件系统的功能是依赖 VFS 的，不会受到影响。

三层架构、四层架构

常见的三层架构 MVC，即View层，Controller层，Model层。

四层架构即展示层，业务逻辑层，持久层，数据库层。

这两种看上去没什么区别。这种分层体现在代码级别，而不是服务级别。

阿里Java规范中的代码上的分层

应用分层

图中默认上层依赖于下层，箭头关系表示可直接依赖，如：开放接口层可以依赖于Web 层，也可以直接依赖于 Service 层，依此类推。

开放接口层：可直接封装 Service 方法暴露成 RPC 接口；通过 Web 封装成 http 接口；网关控制层等。
终端显示层：各个端的模板渲染并执行显示的层。当前主要是 velocity 渲染，JS 渲染，JSP 渲染，移
动端展示等。
Web 层：主要是对访问控制进行转发，各类基本参数校验，或者不复用的业务简单处理等。
Service 层：相对具体的业务逻辑服务层。
Manager 层：通用业务处理层，它有如下特征：
1）对第三方平台封装的层，预处理返回结果及转化异常信息。
2）对 Service 层通用能力的下沉，如缓存方案、中间件通用处理。
3）与 DAO 层交互，对多个 DAO 的组合复用
DAO 层：数据访问层，与底层 MySQL、Oracle、Hbase、OB 等进行数据交互。
外部接口或第三方平台：包括其它部门 RPC 开放接口，基础平台，其它公司的 HTTP 接口。

互联网项目中的分层架构

一般的业务系统应该如何分层？

简单的画了个草图，这里重点说一下业务层以下的几层。

对于一般的小型项目，如果采用服务化架构，那么基本就是网关层+服务层就结束了，没有必要分层分得那么细。

对于中大型项目，服务拆分比较细，业务比较多，那么一般会先加一层“数据访问层”，这一层的主要作用是为了屏蔽上层服务对数据层的依赖，上层的业务服务通过数据访问层跟数据库打交道，不需要关心分库分表等细节。比如业务发展过程中数据库需要扩容，那么只需要修改“数据访问层”即可，上层的调动方不需要任何改动。

同样，业务服务一般业务逻辑比较复杂，但有一些通用的能力我们是可以进行下层，抽象出一层“基础服务层”，这一层主要是将一些基础的服务，不怎么变化的部分封装起来，提供给业务方进行调用。那么业务方就可以根据不同的业务需求进行快速开发，只需要关心业务部分，底层的能力则不需要关心。

网关层

网关层，即作为用户请求的接入网关，主要做一些鉴权之类的事情，就不展开了。

业务逻辑层

很明显，这一层就是直接处理用户请求的。
一般情况下，业务逻辑层的服务在实现自己的业务逻辑的同时会调用数据访问层进行数据的CRUD操作。

另外，我们还可能有一些数据聚合的操作，也是在这一层完成。

需要注意的一点是，业务逻辑层之间的服务是不能相互调用的，只能调用下层的数据访问层。这样是为了避免循环依赖。

基础服务层

也叫公共服务层，有点类似最近的中台。
因为当在业务逻辑层的服务中出现一些公共的业务逻辑，那么每个业务逻辑层的服务都需要实现一遍，即按照同样的方式和逻辑调用数据访问层。这就出现了重复实现的问题，那么解决这个问题的方法就是将一些通用的能力下层，抽象出基础服务，这些基础服务构成了基础服务层。

这时调用关系是，业务逻辑层可以调用基础服务层，也可以调用数据访问的层。总之同层之间不能调用，也不能下层调用上层，跨层调用可以。

数据访问层（可选）

屏蔽底层存储的差异。

拆分出数据访问层后，那么可以独立的对数据存储层进行升级，如从最开始的单数据库，到分库分表，再到NoSQL，数据访问层只与底层存储交互，上层的业务逻辑层或者基础服务则不需要关心。这样达到了分离分层的目的，达到较好地支持扩展的好处。

过去的SOA 架构

这里简单说一下以前的SOA架构。

SOA 的全称是 Service Oriented Architecture，中文翻译为“面向服务的架构”，诞生于上世纪 90 年代，1996 年 Gartner 的两位分析师 Roy W. Schulte 和 Yefim V. Natis 发表了第一个 SOA 的报告。

SOA 出现的背景是企业内部的 IT 系统重复建设且效率低下，主要体现在：

企业各部门有独立的 IT 系统
各个独立的 IT 系统可能采购于不同的供应商，实现技术不同
随着业务的发展，复杂度越来越高，更多的流程和业务需要多个 IT 系统合作完成

由于各个独立的 IT 系统没有标准的实现方式（例如，人力资源系统用 Java 开发，对外提供 RPC；而财务系统用 C# 开发，对外提供 SOAP 协议），每次开发新的流程和业务，都需要协调大量的 IT 系统，同时定制开发，效率很低。

SOA的3个关键概念

服务
ESB
松耦合

典型的 SOA 架构

SOA 架构是比较高层级的架构设计理念，一般情况下我们可以说某个企业采用了 SOA 的架构来构建 IT 系统，但不会说某个独立的系统采用了 SOA 架构。例如，某企业采用 SOA 架构，将系统分为“人力资源管理服务”“考勤服务”“财务服务”，但人力资源管理服务本身通常不会再按照 SOA 的架构拆分更多服务，也不会再使用独立的一套 ESB，因为这些系统本身可能就是采购的，ESB 本身也是采购的，如果人力资源系统本身重构为多个子服务，再部署独立的 ESB 系统，成本很高，也没有什么收益。

SOA的缺点
SOA 解决了传统 IT 系统重复建设和扩展效率低的问题，但其本身也引入了更多的复杂性。SOA 最广为人诟病的就是 ESB，ESB 需要实现与各种系统间的协议转换、数据转换、透明的动态路由等功能。