分层架构简单高效，业内有很多成熟的应用。非常适合那些项目刚刚起步，架构师还没有决定采用哪种架构模式的系统。 引言软件刚出现的时候还是大型计算机时代，一个软件系统一般只运行在一台机器上。 随着软硬件技术的革新，计算机的体积和成本逐渐变小。这时，工程师们发现，一个只在单机上运行的软件系统会有各种各样的瓶颈。 如果将系统按照功能分为前台和后台，分别部署在两台服务器上，问题就会得到缓解，这时就出现了客户端/服务器架构。 随后，个人电脑的兴起导致了许多丰富的桌面应用程序的出现，这些应用程序是基于操作系统上的用户界面开发的，数据存储在单独部署的数据库服务器中，数据通过标准的网络协议进行通信。 这种桌面+数据库服务器的架构和C/S架构一样，属于两层架构。 随着90年代互联网的迅速崛起，浏览器+Web服务器+数据库服务器的组合逐渐流行起来。 浏览器是表现层，提供客户交互界面；服务器是业务层，解决具体的业务逻辑；数据库服务器是数据层，存储系统数据。 三个层次各司其职，就是大家最熟悉的三层架构。 上述架构模式都属于分层架构的范畴。分层架构对必须有多少层没有限制，可以根据应用场景灵活控制层数，所以也叫n层架构。 它结构简单，基于这种架构的系统开发成本也很低(很多公司在组织架构上分为前端工程师、后端工程师、DBA。根据康威定律，这自然具备了分层架构发展的良好条件)，所以在业界很受欢迎。 如果你的团队不确定选择什么样的架构，或者你想实现敏捷宣言中的“刚开始编码”，那么分层架构将是一个不错的选择。 体系结构在分层体系结构中，组件根据其功能分为不同的级别。虽然级别的数量和类型不受限制，但大多数分层架构都由以下四层组成:表示层、业务层、持久层和数据层，如下图所示。 在少数简单的系统中，持久层的逻辑(如SQL)嵌入业务层，形成经典的三层架构；在少数复杂系统中，会根据具体业务分为五个或更多的层次。 体系结构的标准逻辑分层上面提到的四个层(如实施层)是逻辑分区方法。在实际部署中，一般有如下图所示的几种部署形式。 在形式1中，表示层、业务层和持久层是一个部署单元，而数据层是单独部署的，具体是作为独立部署的数据库或文件系统；形式2中，表示层是分离的，单独部署，业务层和持久层组成一个部署单元，数据层仍然是单独部署的数据库或文件系统；在Form 3中，包括数据层在内的所有四层都在同一个部署单元中，这在业务简单的系统中很常见。他们经常使用嵌入式数据库或内存数据库。 分层架构的部署形式分层架构中的每一层都有自己的作用。比如表示层负责解决所有客户请求和浏览器交互，业务层负责执行每个请求下的具体业务逻辑；表示层不需要担心从哪里获取客户数据，它只需要在浏览器上以特定的格式显示数据。 类似地，业务层不需要关心客户数据来自哪里以及如何呈现。它只需要从持久层取出数据，执行特定的业务逻辑(比如聚合数据)，然后将结果返回给表示层。 每一层都是特定行为的概括，这种职责划分使组织能够快速有效地创建职责模型，并围绕每一层建立开发团队。 隔离分层体系结构中的每一层都可以是封闭的或开放的。Closed是指当一个请求在层间自顶向下传递时，不能跳过任何一层。 例如，当表示层收到请求时，它必须经过业务层和持久层才能到达数据层，如下图所示。 对于简单的数据获取请求，如果表示层可以直接访问数据层来获取数据，封闭的层次架构无疑是最简单、最高效的。 也就是说，业务层和持久层是开放的，请求在层间传递时允许跳过这一层。 所以，封闭好还是开放好？要回答这个问题，要回到层间隔离的出发点。 所谓层间隔离，目的是减少一个层次的变化对其他层次的元件的影响。简单来说，每个层次对其他层次的功能了解得越少越好。 为了达到层间隔离的目的，需要将各层置于封闭状态。 假设表示层可以直接访问持久层，持久层的变更会直接影响业务层和表示层，加剧层间耦合，导致系统变更成本高。 层间隔离可以减少层次变化对系统的影响，任何事情都不是绝对的。在某些情况下，将特定的层次结构设置为开放状态是一件好事。 考虑下面的例子。业务层有几个共享组件，承载着业务层的常用功能(如日志类、审计类、日期和字符串工具类等。) 现在，有一个架构决策要求实现层不能直接访问这些共享组件。但矛盾的是，实现层可以根据规则直接访问业务层，而这个需要违反规则的决策将很难做出。 处理业务层中的共享组件的一种方法是添加一个新的服务层，它包含业务层中的这些共享组件。 因为业务层是关闭的，所以表示层不能访问这些共享组件。 但是，新添加的服务层必须打开，否则业务层将无法直接访问持久层。 增加一个新的服务层，并将其置于开放状态，既做出了架构决策，又不影响原有功能，一举两得。 向分层体系结构添加新层。几个音符。使用分层架构时，要注意以下两点:1。做好将模块划分成层次结构的工作。做好模块划分主要是为后续架构演进做准备。比如，当业务复杂到可以做微服务架构的时候，每个模块都可以很自然地演化成一个微服务。 所以要避免类的继承层次太深，导致代码耦合严重，不利于后续架构演进的现象。 2.避免落入sinkhole反模式的陷阱。所谓的sinkhole反模式是指请求简单地通过所有级别，没有少量的业务解决方案。 例如，表示层接收对基本客户数据(姓名、地址等)的请求。)并传递给业务层；但是业务层没有做任何业务解决方案，直接把请求传递给持久层；持久层只构造一个简单的SQL语句从数据层查询客户数据。最后，数据按照原路由返回到表示层，不需要任何数据聚合、转换等操作。 Sinkhole反模式会导致大量不必要的对象实例化开销，增加系统的内存消耗，影响性能。 然而，一个系统或多或少会有少量的sinkhole反模式场景。判断一个系统是否完全陷入了sinkhole反模式的陷阱，主要是看这种业务请求的百分比。 根据二八法则，当系统中80%以上的业务请求都是类似sinkhole的请求时，就说明系统已经陷入了sinkhole反模式的陷阱，这也从侧面说明了系统已经不适合分层架构，是时候考虑架构演进了。 综合得分分层架构综合得分从综合得分来看，分层架构的整体成本和简单性得分都很高，这很大程度上是因为分层架构本身是单一架构，降低了很多分布式系统的复杂度。 然而，这导致了较低的可部署性分数，因为三行代码的改变就足以导致整个系统被重新部署。 测试性分数低也是原因。当整个系统再次上线时，通常需要重新执行测试用例，这增加了许多额外的工作量。 弹性、容错性、可扩展性都是单一架构的天然劣势，自然分层架构在这些方面得分较低。 此外，sinkhole反模式的存在也降低了层次结构的性能分数。 总结分层架构简单高效，业内有很多成熟的应用。非常适合那些项目刚刚起步，架构师还没有决定采用哪种架构模式的系统。 在实现层次架构时，我们需要适当设置每一级的关闭或打开状态，隔离各层，避免陷入sinkhole反模式陷阱。 随着业务的不断扩展，分层架构在可维护性、可测试性、可扩展性等方面的缺点逐渐显现。会逐渐放大，所以要考虑向其他架构模式的演进。