参考：http://www.ruanyifeng.com/blog/2016/09/software-architecture.html
https://blog.csdn.net/bboyfeiyu/article/details/45136299
https://www.cnblogs.com/zdxster/p/5305155.html
1. 什么是分层架构
分层架构是一种很常见的架构模式，它也叫N层架构。这种架构是大多数Jave EE应用的实际标准，因此很多的架构师，设计师，还有程序员都知道它。许多传统IT公司的组织架构和分层模式十分的相似。所以它很自然的成为大多数应用的架构模式。
2. 模式分析
分层架构模式里的组件被分成几个平行的层次，每一层都代表了应用的一个功能(展示逻辑或者业务逻辑)。尽管分层架构没有规定自身要分成几层几种，大多数的结构都分成四个层次:展示层，业务层，持久层，和数据库层。有时候，业务层和持久层会合并成单独的一个业务层，尤其是持久层的逻辑绑定在业务层的组件当中。因此，有一些小的应用可能只有3层，一些有着更复杂的业务的大应用可能有5层或者更多的分层。
分层架构中的每一层都有着特定的角色和职能。
举个例子，展示层负责处理所有的界面展示以及交互逻辑，业务层负责处理请求对应的业务。架构里的层次是具体工作的高度抽象，它们都是为了实现某种特定的业务请求。比如说展示层并不需要关心怎样得到用户数据，它只需在屏幕上以特定的格式展示信息。业务层并不关心要展示在屏幕上的用户数据格式，也不关心这些用户数据从哪里来。它只需要从持久层得到数据，执行与数据有关的相应业务逻辑，然后把这些信息传递给展示层。
分层架构的一个突出特性是组件间关注点分离 (separation of concerns)。一个层中的组件只会处理本层的逻辑。比如说，展示层的组件只会处理展示逻辑，业务层中的组件只会去处理业务逻辑。多亏了组件分离，让我们更容易构造有效的角色和强力的模型。这样应用变的更好开发，测试，管理和维护。
3. 关键概念——层隔离
这是分层架构中非常重要的特点。这意味request必须一层一层的传递。举个例子，从展示层传递来的请求首先会传递到业务层，然后传递到持久层，最后才传递到数据层。
那么为什么不允许展示层直接访问数据层呢。如果只是获得以及读取数据，展示层直接访问数据层，比穿过一层一层来得到数据来的快多了。这涉及到一个概念:层隔离。
层隔离就是说架构中的某一层的改变不会影响到其他层:这些变化的影响范围限于当前层次。如果展示层能够直接访问持久层了，假如持久层中的SQL变化了，这对业务层和展示层都有一定的影响。这只会让应用变得紧耦合，组件之间互相依赖。这种架构会非常的难以维护。
从另外一个方面来说，分层隔离使得层与层之间都是相互独立的，架构中的每一层的互相了解都很少。为了说明这个概念的厉害之处，想象一个超级重构，把展示层从JSP换成JSF。假设展示层和业务层的之间的联系保持一致，业务层不会受到重构的影响，它和展示层所使用的界面架构完全独立。
然而封闭的架构层次也有不便之处，有时候也应该开放某一层。如果想往包含了一些由业务层的组件调用的普通服务组件的架构中添加一个分享服务层。在这个例子里，新建一个服务层通常是一个好主意，因为从架构上来说，它限制了分享服务访问业务层(也不允许访问展示层)。如果没有隔离层，就没有任何架构来限制展示层访问普通服务，难以进行权限管理。
开放和封闭层的概念确定了架构层和请求流之间的关系，并且给设计师和开发人员提供了必要的信息理解架构里各种层之间的访问限制。如果随意的开放或者封闭架构里的层，整个项目可能都是紧耦合，一团糟的。以后也难以测试，维护和部署。
4. 分层架构使用的特定环境
一个需要分解的比较大的系统。这种模式对大部分JAVAEE应用程序来说是标准模式，因此被大部分架构师、软件设计师、开发者广泛知晓。由于分层架构模式和公司里传统的IT沟通以及组织结构非常类似，使得它成为大多数商务应用开发最自然的选择。分层的开发方式实现了人类对复杂事物的普遍处理方式——分而治之。通过把复杂的系统分解成为相对简单的独立系统，低耦合的分解既可以实现开发人员的并行工作，又可以实现开发人员的任务分工。而且通过分层，对组件拼装和流水化作业提供了理论和事实的基础。
5. 分层模式用来解决什么问题？
分层模式的关键点在于确定依赖：即通过分层，可以限制子系统间的依赖关系，使系统以更松散的方式耦合，从而更易于维护。
典型的分层方式是应用程序专用功能位于上层，跨越应用程序领域的功能位于中层，而配置环境专用功能位于低层。层的数量与组成取决于问题领域和解决方案的复杂程度。通常而言只有一个应用程序专用层。应当把子系统组织成分层结构，架构的上层是应用程序专用子系统，架构的低层是硬件和操作专用子系统，中间件层是通用服务。
对系统进行分层有如下基本原则：
●可见度。各子系统只能与同一层及其下一层的子系统存在依赖关系。
●易变性。最上层放置随用户需求的改变而改变的元素。最底层放置随实施平台（硬件、语言、操作系统、数据库等）的改变而改变的元素。中间的夹层放置广泛适用于各种系统和实施环境的元素。如果在这些大类中进一步划分有助于对模型进行组织，则添加更多的层。
●通用性。一般将抽象的模型元素放置在模型的低层。如果它们不针对于具体的实施，则倾向于将其放置在中间层。
●层数。对于小型系统，三层就足够了。对于复杂系统，通常需要5-7层。无论复杂程度如何，如果超过10层，就需要慎重考虑了。层数越多，越需慎重。
6. 分层模式的解决方案
分层架构是常用的架构模式，对于一个大系统可以划分为几个子系统，各子系统位于不同的抽象层次。各层间上层依赖下层服务，下层不能依赖上层。消息可以从上向下，也可以从下向上。自顶向下调用下层接口，称为请求。自低向上的通信，称为通知，一般使用回调方法，从而实现单路径耦合。
【分层的步骤】
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定律可用来分析是否落入了污水池反模式。当反模式的比例比较大时，你或许考虑将某些层开放，这时要注意缺乏层隔离，会使得以后修改时比较困难。
分层架构会使应用变得庞大，即使把表示层和业务层分成了单独的部署单元。这对某些应用不需要考虑，但是也会带来一些部署的隐患，如健壮性、可靠性、性能和可伸缩性。
【分层演化过程】
单层架构-->两层架构-->三层架构-->N层架构
单层架构：早期批处理系统
两层架构：C/S 客户/服务器模式
特点：没有复杂的领域逻辑
优点：有非常好的工具支持，VB、Delphi、PowerBuilder
缺点：代码冗余，难于维护。
模式：1、领域逻辑写在客户端
2、领域逻辑写在数据库（存储过程）
面向对象技术、WEB兴起、Java出现共同推进了三层架构。
Layer与Tier的区别：1、Tier强调物理上的分离，Two Tier System。2、Layer强调逻辑上的分层。
三层架构：表现层-领域层-数据源层（持久层）
1、表现层：提供服务，显示信息。
2、领域层：系统核心逻辑。
3、数据源层：与数据库、消息系统以及其他软件包通信
7.分层架构应用实例
为了演示分层架构是如何工作的，想象一个场景，如图，用户发出了一个请求要获得客户的信息。黑色的箭头是从数据库中获得用户数据的请求流，红色箭头显示用户数据的返回流的方向。在这个例子中，用户信息由客户数据和订单数组组成（客户下的订单）。
其中，Presentation 层代表了代码中的jsp界面层；Business 层代表代码中处理请求并返回结果的servlet层；Persistence持久层代表代码中的dao层；Database数据层代表了代码中的sql语句。
用户界面只管接受请求以及显示客户信息。它不管怎么得到数据的，或者说得到这些数据要用到哪些数据表。如果用户界面接到了一个查询客户信息的请求，它就会转发这个请求给用户委托(Customer Delegate）模块。这个模块能找到业务层里对应的模块处理对应数据（约束关系）。业务层里的customer object聚合了业务请求需要的所有信息（在这个例子里获取客户信息）。这个模块调用持久层中的custom dao来得到客户信息，调用order dao来得到订单信息。这些模块会执行SQL语句，然后返回相应的数据给业务层当customer object收到数据以后，它就会聚合这些数据然后传递给customer delegate，然后传递这些数据到customer screen展示在用户面前。
8. 分层架构与MVC之间的区别
我相信很多人都会对这两个概念模糊，下面我们来分析一下这两者之间的区别与联系。
三层架构是一个分层式的软件体系架构设计，它可适用于任何一个项目。
MVC是一个设计模式，它是根据项目的具体需求来决定是否适用于该项目。
那么架构跟设计模式有什么区别呢？
我们从接手一个项目开始，首先，我们需要进行架构设计，一般我们采用的就是分层式的架构设计，即我们的三层架构。然后，在确定了架构以后，我们再根据项目的具体需求去考虑是否需要应用一些设计模式，比如是否应用我们的MVC模式，抽象工厂模式等等。最后，确定了模式以后，就是我们的一些具体的实现了。
其次，它俩划分的层次不同。
三层架构将整个项目划分为：表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL）。
MVC 即Model（模型），View（视图），Controller（控制）。
而我们通常所见到的MVC一般也都是在应用三层架构的基础上，即将Model层再进行分层。而如果Model不再进行划分的话，那么使用MVC的意义也就不大了。
然后，它俩的目的着重点不同。
三层架构的目的着重点是“高内聚，低耦合”，即解耦。
MVC的目的则是实现Web系统的职能分工，即职责划分。
其实职责划分也是解耦，但是三层侧重的是整体的一个解耦，而MVC侧重的是web系统的解耦，即侧重jsp和Servlet的一个解耦。
MVC和三层架构MVC与三层架构类似么？
三层架构是典型的架构模式（Architecture Pattern），三层架构的分层模式是典型的上下关系，上层依赖于下层。但MVC作为表现模式是不存在上下关系的，而是相互协作关系。即使将MVC当作架构模式，也不是分层模式。MVC和三层架构基本没有可比性，是应用于不同领域的技术。
分层架构是常用的架构模式，对于一个大系统可以划分为几个子系统，各子系统位于不同的抽象层次。各层间上层依赖下层服务，下层不能依赖上层。消息可以从上向下，也可以从下向上。自顶向下调用下层接口，称为请求。自低向上的通信，称为通知，一般使用回调方法，从而实现单路径耦合。