前言只要是从事软件开发的，系统架构都是必备的知识。可能有的朋友会说，我只是个打工的，怎么接触到架构知识呢？其实除了架构设计师（也就是架构师），作为普通的开发者，他们也无时无刻不在进行着系统架构的实践。理论。毕竟架构再好，也需要码农去实现。只是当你对软件架构没有系统的了解时，你可能无法感知。本文将带你系统地了解软件架构的分层。学完你就会明白为什么系统需要分层。同时，你也可以准确的看到自己的系统目前采用了什么样的分层架构。不使用架构分层可以吗？首先我们想一个问题，如果一个系统不采用分层架构，有没有可能？这个问题就像在问，代码中不用设计模式可以吗？答案当然是肯定的。但是如果架构不分层，会带来很大的未知风险，或者代码会极度熵增。作为一个创业软件，可能没有任何业务逻辑和用户量，软件的主要目标是快速上线，践行商业模式。此时，可以不考虑分层。但随着业务逻辑的复杂化和业务细分的增加，相互之间会产生错综复杂的依赖关系，从而导致逻辑不清晰、可读性差、维护困难、改一处牵一发而动全身等问题。什么是架构分层？分层体系结构是将软件模块按水平切分划分为多个层次。一个系统由多层组成，每一层又由多个模块组成。同时，每一层都有自己独立的职责，多层协作提供完整的功能。比如我们经常提到的MVC架构，就是一种非常典型和基础的分层方式。分层设计的本质是将复杂的问题简单化，让每一层代码基于单一职责的原则各司其职，基于“高内聚低耦合”的设计思想实现相关层对象之间的交互.从而提高了代码的可维护性和可扩展性。系统架构分层后，往往需要实现以下目标：高内聚：分层设计可以简化系统设计，让不同的层专注于某个模块；低耦合：层之间通过接口或API进行交互，依赖方不需要知道依赖方的细节；可复用：分层后，代码或函数可以复用；可扩展性：分层架构可以更容易地水平扩展代码。通信领域的OSI参考模型存在于计算机领域。最典型的分层架构设计是OSI参考模型和TCP/IP参考模型。关于这个模型，我们在《一篇文章，只用看三遍，终生不忘网络分层! 》一文中有详细介绍。我们直接看一下相关的模型图：对于上面的三种分层模式，想象一下如果没有分层，当一个服务或者协议需要改变的时候，我们只能对整个系统进行修改或者扩展。分层之后，可以方便的提取出不同功能的模块，修改对应的模块。并且不同层是可以复用的，只要确保遵循这一层的协议即可。软件系统整体分层以Java软件应用为例，整个软件系统也可以分层，如部署的硬件环境、操作系统、所需的中间件、承载业务的应用、软件接入层等。大家可以从下图中得到一个整体的认识：对于上面的层次，也有相应的职位，比如运维工程师、中间件工程师、产品经理、开发工程师、测试工程师等工种。在我们的实践中，我们接触最多、使用最多的层是应用软件层，其次是中间件层。下面我们来看一下应用软件层常用的分层方式。经典的三层架构三层应用架构（3-tierapplication）通常将整个业务应用划分为：表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL）。表现层（UI），通俗的说就是展示给用户的界面，对应项目中的Web层包括Servlet和Controller。业务逻辑层（BLL）：也称为领域层，负责系统业务逻辑的处理，对应项目中的Service和ServiceImpl。数据访问层（DAL）：这一层所做的事务直接操作数据库，对数据进行增删改查等操作，对应项目中的Dao。在提出这种分层架构的时代，大多数系统往往比较简单，本质上是一个单体架构（MonolithicArchitecture）的数据库管理系统。这种分层架构已经是Client-Server架构的演进，有效隔离了业务逻辑和数据访问逻辑，使得这两个不同的关注点可以相对自由独立地演进。在开源技术框架中，表现层的代表作品是Struts1/2和SpringMVC，业务层的代表作品是Spring，持久层的代表作品是Hibernate和Mybatis。MVCMVC的全称是ModelViewController，是模型（model）-视图（view）-controller（控制器）的缩写。将业务逻辑集中到一个组件中，在改进和定制界面和用户交互的同时，无需重写业务逻辑。MVC是专门为在逻辑GUI结构中映射传统的输入、处理和输出功能而开发的。标准的MVC交互模型如下图所示：View：View为用户提供用户界面，直接与用户进行交互。Model：模型，承载数据，计算用户提交的请求。分为两类，一类叫数据承载Bean，一类叫业务处理Bean。承载数据的Bean是指专门承载业务数据的实体类，比如Student、User。业务处理bean是指Service或Dao对象，专门用来处理用户提交的请求。Controller：控制器用于将用户的请求转发给对应的Model进行处理，并对Model的计算结果进行处理，提供给用户的响应。从图中可以看出，标准MVC中的模型可以主动推送数据到视图进行更新（观察者设计模式，将视图注册到模型上，模型更新时自动更新视图），但是模型不能积极更新Web开发中的视图。推送到视图（用户界面不能主动更新），因为web开发是请求-响应模型。WebMVC标准架构，如下图所示：在WebMVC模式下，模型不能主动向视图推送数据。如果用户想要更新视图，他需要发送另一个请求（即请求-响应模型）。MVC用于分离Web(UI)层的责任。严格来说，MVC是三层架构中的UI层。也就是说，MVC将三层架构中的UI层划分为三个部分：controller、view和entity，controller完成页面逻辑，通过entity与接口层通信，而C层直接与第三层的BLL通信。三层架构和MVC可以共存。三层架构是基于业务逻辑的，而MVC是基于页面的。MVC是一种表现模式，三层架构是典型的架构模式。三层架构的分层模式是典型的上下层关系，上层依赖于下层。但是，作为一种性能模式，MVC没有上下关系，而是相互协作的关系。即使把MVC看作一种架构模式，它也不是一种分层模式。MVC和三层架构基本上没有可比性，是应用在不同领域的技术。阿里的四层架构和三层架构实现起来比较简单。很多朋友可能会觉得项目分层应该是这样的。结果就是很多业务逻辑往往堆在Service层。《阿里巴巴 Java 开发手册 》中进一步细化了原有的三层架构，增加了Manager通用业务处理层。Manager层可以下沉一些原有Service层的通用能力，比如与缓存和存储的交互策略，中间件的接入等；也可以封装对第三方接口的调用，比如调用支付服务，调用审计服务等RPC接口。通用业务处理层，具有以下特点：第三方平台封装层，对返回结果进行预处理，异常信息转换。Service层通用能力的下沉，比如缓存方案和中间件的通用处理。与DAO层交互，复用多个DAO的组合。各层的作用如下：终端展示层：各端进行模板渲染展示的层。目前主要是Velocity渲染、JS渲染、JSP渲染、移动端展示等。接口层开放：将Service层方法封装成一个开放接口，同时进行网关安全控制和流量控制。Web层：主要用于访问控制的转发，各种基础参数的验证，或者对不可复用服务的简单处理等。服务层：业务逻辑层。管理层：一般业务处理层。DAO层：数据访问层，与底层MySQL、Oracle、HBase等进行数据交互。对外接口或第三方平台：包括其他部门的RPC开放接口、基础平台、其他公司的HTTP接口。系统工程结构学习了上面的分层架构，我们来看一下软件系统中分层的对照表：以上分层定义仅供参考。在上表中，还有对外接口层和接入层。对外接口层：所有的对外接口都放在这一层，不能包含任何业务逻辑，只有数据对象的转换和异常的封装。接入层：所有外部系统依赖都放在这一层。优点是一旦修改了外部系统接口，只需要修改一处即可。DDD分层架构DDD是一种用于处理高度复杂领域的设计思想，试图将技术实现的复杂性分离出来，同时围绕业务概念构建领域模型，提出软件架构设计的方法论。DDD分层架构，将数据、缓存等作为基础层，各层都可以调用；领域层分离，负责核心业务逻辑处理，领域层通过接口调用所有外部依赖，保证领域层100%的单一性覆盖度量；应用层聚合了多个领域层的能力，只做功能组合和转发，不负责具体的业务逻辑。这里只简单介绍一下DDD分层架构。DDD的概念就不展开太多了，相关的架构模型可以专门研究一下。看一下DDD分层架构图：对应层的功能介绍如下：接口层（Interfaces）：该层包含所有与其他系统交互的内容，如Web服务器、RESTful接口等。接口层处理传入数据的解释、验证、编码和解码以及序列化。同时可以考虑引入专门的DTO（数据转换对象）来辅助数据转换；应用层（Application）：这一层负责驱动应用程序完成工作过程。一个非常薄的层，协调多个域对象（实体、聚合根、域服务）以实现服务编排和组合以完成工作流。该层通常不应包含特定的业务逻辑。该层涉及：其他微服务RPC调用、微服务编排与组合、分布式事务实现、消息驱动事件驱动、日志记录等领域层（Domain）：该层是软件的核心，包括业务逻辑的具体实现，包括实体、值对象、聚合、领域服务和存储接口等领域对象。通常，这一层应该配备图标来说明软件是如何工作的；基础层（Infrastructure）：包括网关、缓存、数据库存储、消息中间件、监控、应用服务等通用技术和基础服务。基础层以不同的方式支持其他三层，促进层与层之间的通信。配置文件、数据库模式定义和存储接口实现都是基础设施的一部分；DDD传统三层架构的分层架构对比DDD四层架构也是基于传统三层架构的，我们来看看它们之间的对比：DDD四层架构与传统三层架构的区别架构如下：侧重点不同：三层架构侧重于请求调用的顺序；DDD架构侧重于领域服务。水平划分方式不同：三层架构主要侧重于垂直划分，对水平划分没有约定；DDD架构更注重垂直划分，即多个领域层之间的划分和交互。资源的定位不同：三层架构将所有依赖的数据放在数据访问层；DDD架构只是将领域内强相关的数据放到Repository中，其他如API层缓存、文件等都作为基础服务处理。关于DDD架构的分层，有整齐架构和六边形架构两种形式，这里不再展开。感兴趣的朋友可以自行查找相关资料进行学习。总结本文介绍了市场上常见的架构层。分层架构的目的是通过关注点分离降低系统的复杂性，同时满足单一职责、高内聚、低耦合，提高复用性，降低维护成本。但是，分层架构也存在一定的缺点，如开发成本高、性能稍差、可扩展性差等。在实践中，可以根据需要选择合适的分层架构。
