分层模式的认知

Posted 2020-11-09 蘑菇蘑菇终于开花了

分层模式认知（参考：https://www.jianshu.com/p/c498aaf124c7

　　　　　　　　       https://www.cnblogs.com/youxin/archive/2013/05/20/3089095.html）

分层模式：分层体系架构模式模式也称为多层体系架构模式。它可以用来构造可以分解为子任务组的程序，每个子任务都处于一个特定的抽象级别。每个层都为下一个提供更高层次服务。在分层架构中的组件被划分成几个层,每个层代表应用的一个功能.分层架构本身没有规定要分成多少层,大部分的应用会分成表现层,业务层,持久层和数据库层.小的应用有时候会将业务层和持久层合在一起,更大规模的应用可能会划分更多的层,比如调用外部服务的层.

一、特定环境：一个需要分解的比较大的系统。这种模式对大部分JAVAEE应用程序来说是标准模式，因此被大部分架构师、软件设计师、开发者广泛知晓。由于分层架构模式和公司里传统的IT沟通以及组织结构非常类似，使得它成为大多数商务应用开发最自然的选择。分层的开发方式实现了人类对复杂事物的普遍处理方式——分而治之。通过把复杂的系统分解成为相对简单的独立系统，低耦合的分解既可以实现开发人员的并行工作，又可以实现开发人员的任务分工。而且通过分层，对组件拼装和流水化作业提供了理论和事实的基础。

 

二、分层模式用来解决什么问题？

分层模式的关键点在于确定依赖：即通过分层，可以限制子系统间的依赖关系，使系统以更松散的方式耦合，从而更易于维护。

典型的分层方式是应用程序专用功能位于上层，跨越应用程序领域的功能位于中层，而配置环境专用功能位于低层。层的数量与组成取决于问题领域和解决方案的复杂程度。通常而言只有一个应用程序专用层。应当把子系统组织成分层结构，架构的上层是应用程序专用子系统，架构的低层是硬件和操作专用子系统，中间件层是通用服务。
对系统进行分层有如下基本原则：
— 可见度。各子系统只能与同一层及其下一层的子系统存在依赖关系。 
— 易变性。最上层放置随用户需求的改变而改变的元素。最底层放置随实施平台（硬件、语言、操作系统、数据库等）的改变而改变的元素。中间的夹层放置广泛适用于各种系统和实施环境的元素。如果在这些大类中进一步划分有助于对模型进行组织，则添加更多的层。 
— 通用性。一般将抽象的模型元素放置在模型的低层。如果它们不针对于具体的实施，则倾向于将其放置在中间层。 
— 层数。对于小型系统，三层就足够了。对于复杂系统，通常需要5-7层。无论复杂程度如何，如果超过10层，就需要慎重考虑了。层数越多，越需慎重。

 

三、解决方案。

分层架构是常用的架构模式，对于一个大系统可以划分为几个子系统，各子系统位于不同的抽象层次。各层间上层依赖下层服务，下层不能依赖上层。消息可以从上向下，也可以从下向上。自顶向下调用下层接口，称为请求。自低向上的通信，称为通知，一般使用回调方法，从而实现单路径耦合。

【分层的步骤】

1、定义抽象准则

2、根据准则定义抽象层数

3、给每个层命名并指定任务

4、指定服务

5、细化分层，重复上述步骤，直到一个稳定的分层结构

6、为每层指定接口

7、构建独立层

8、指定层间通信，分离临接层

9、设计错误处理策略

【分层的变体】

松散分层结构：注重性能，损失可维护性

继承分层结构：访问直接，依赖性强

【分层的优点】

分层架构模式是个可靠的通用模式，对于大部分应用它是个很好的开始，尤其当不知道哪种结构适合使用时。

　　1、降低复杂度，上层不需要关注下层细节。

       2、提高灵活性，可以灵活替换某层的实现。

       3、减小耦合度，将层次间的依赖减到最低。

 　  4、有利于重用，同一层次可以有多种用途。

       5、有利于标准化。

它有如下几点优势：重用性好、标准化支持、局部依赖、可替换性

【分层的缺点】

分层主要有以下的缺点：影响多层次的修改；降低了效率；多层传递，重复的工作；层的粒度难以把握。

　　1、不能封装所有工作，可能会带来及联修改。

　　2、过多层次影响性能。

难点：1、如何划分层次。

 　　　　2、定义层次职责。

分层的多层传递中有现象被称为污水池反模式（architecture sinkhole anti-pattern）。该反模式描述的是这样的场景，请求流穿过架构的很多层，每一层只有少量的甚至没有业务逻辑。例如，假设展示层响应用户的请求获取客户信息，展示层将请求传递给业务层，业务层什么也不做，仅仅将请求直接传递给持久层，持久层执行SQL语句获取数据。数据在回传过程中没有经过任何的处理。

每个分层架构都可能会有一些场景落入污水池反模式。然而关键是分析这样的请求占了多少比例。通常80-20定律可用来分析是否落入了污水池反模式。当反模式的比例比较大时，你或许考虑将某些层开放，这时要注意缺乏层隔离，会使得以后修改时比较困难。

分层架构会使应用变得庞大，即使把表示层和业务层分成了单独的部署单元。这对某些应用不需要考虑，但是也会带来一些部署的隐患，如健壮性、可靠性、性能和可伸缩性。

【常用分层】

常见的分层架构模式
1．客户端-服务器模型（Client-Server，C/S）。
2．三层模型：用户表示层、业务逻辑层、数据层。
3．多层结构的技术组成模型：表现层、中间层、数据层。
4．网络系统常用三层结构：核心层、汇聚层和接入层。
5．RUP典型分层方法：应用层、专业业务层、中间件层、系统软件层。
6．基于Java的B/S模式系统结构：浏览器端、服务器端、请求接收层、请求处理层。
7．某六层结构：功能层（用户界面）、模块层、组装层（软件总线）、服务层（数据处理）、数据层、核心层。

【分层演化过程】

　　单层架构-->两层架构-->三层架构-->N层架构

　　单层架构：早期批处理系统

　　两层架构：C/S 客户/服务器模式

　　　　特点：没有复杂的领域逻辑

　　　　优点：有非常好的工具支持，VB、Delphi、PowerBuilder

　　　　缺点：代码冗余，难于维护。

　　模式：1、领域逻辑写在客户端

 　　         2、领域逻辑写在数据库（存储过程）

　　　　面向对象技术、WEB兴起、Java出现共同推进了三层架构。

　　　　　　Layer与Tier的区别：1、Tier强调物理上的分离，Two Tier System。2、Layer强调逻辑上的分层。

　　三层架构：表现层-领域层-数据源层（持久层）

　　　　1、表现层：提供服务，显示信息。

　　　　2、领域层：系统核心逻辑。

　　　　3、数据源层：与数据库、消息系统以及其他软件包通信

 

四、实例。

　　为了演示分层架构是如何工作的，想象一个场景，如图，用户发出了一个请求要获得客户的信息。黑色的箭头是从数据库中获得用户数据的请求流，红色箭头显示用户数据的返回流的方向。在这个例子中，用户信息由客户数据和订单数组组成（客户下的订单）。

　　其中，Presentation 层代表了代码中的jsp界面层；Business 层代表代码中处理请求并返回结果的servlet层；Persistence持久层代表代码中的dao层；Database数据层代表了代码中的sql语句。

　　用户界面只管接受请求以及显示客户信息。它不管怎么得到数据的，或者说得到这些数据要用到哪些数据表。如果用户界面接到了一个查询客户信息的请求，它就会转发这个请求给用户委托(Customer Delegate）模块。这个模块能找到业务层里对应的模块处理对应数据（约束关系）。业务层里的customer object聚合了业务请求需要的所有信息（在这个例子里获取客户信息）。这个模块调用持久层中的custom dao来得到客户信息，调用order dao来得到订单信息。这些模块会执行SQL语句，然后返回相应的数据给业务层当customer object收到数据以后，它就会聚合这些数据然后传递给customer delegate，然后传递这些数据到customer screen展示在用户面前。

总结一下分层模式：

　　“模式的模式”——强大同时灵活

　　适应：集成不同类型功能 ——当我们需要把很多不同功能的代码集成起来的时候，这种模式提供了最合理的结构。能让我们的代码有足够的灵活性去应对需求变更。
　　不适应：简单业务模型——如果系统本身不复杂（或者叫做可预期的修改很少），建立各种层次，然后为了符合层次间调用的规定，会增加很多不必要的代码，陷入过度设计的泥坑。
　　方法论：以业务逻辑特征建模 ——使用分层模式，往往需要我们在大脑里对问题领域进行层次抽象，这种抽象最可信赖的原则，就是按照业务逻辑去做。比如现实业务中有一个角色，我们就建立一个角色的模块；如果我们有一个场景，就以此为名建立一个这样的模块……。以业务逻辑建立的模块，本身也会让系统更容易被理解，因为在代码里能找到和现实中一一对应的概念。

　　设计模式实现：
　　门面模式 ——我们对于每个模块或者每个层次都会设计一个“门面”来降低耦合的复杂程度。
　　策略模式——抽象层次会隐藏底层的实现细节，这就是策略模式最基本的设计，我们往往会把上层作为功能接口，下层作为可选的策略来实现。