Layered Architecture 分层架构(完整翻译)

原文：https://www.oreilly.com/programming/free/files/software-architecture-patterns.pdf

分层架构是最常见的架构模式，通常它也被称作n-层架构模式。大多数JAVA应用都采用这个模式，因此它也被架构师、设计师和开发者所熟知。分层架构模式和大多数公司传统的IT以及组织结构非常接近，使得它成为大多数业务应用开发任务的天然选择。

模式描述

分层架构模式的组成部分通常会按水平层来排列，每一层都在应用中扮演一个特定的角色(比如，显示逻辑与业务逻辑)。尽管分层架构模式并不指定层的数量和类型，大多数封层架构都由一下四个标准层组成：显示、业务、持久、数据库（如图1）。在一些案例中，业务层和持久层会被合并成一个业务层，尤其是当持久层逻辑(如 SQL或HSQL)是嵌入到业务层组件中的时候。因此，更小的应用也可能只有三个层，而更大的更复杂的业务应用可能包含五到六层。

 

分层架构模式中的每一层都在应用中扮演特定的角色。比如说，显示层会负责处理所有的用户接口和交互逻辑，而一个业务层主要负责执行特定的业务和用户请求密切联系的任务。架构中的每一层都是满足某种业务请求需要做的事情的一个抽象。举例来说，显示层不需要知道或者关心怎么获取用户数据；它只需要以某种格式在屏幕上显示信息。类似地，业务层也不需要关心数据是以什么格式显示的甚至数据时从哪来的；它只需要从持久层拿到数据，对数据按照业务逻辑进行处理，然后将信息传给显示层。

 

分层架构一个非常重要的特征是各个组件的任务分离。在一个特定的层中，组件也只需要处理这个层需要处理的逻辑。距离来说，在显示层的组件只需要处理显示逻辑而业务层的组件只需要处理业务逻辑。组件的分类可以更有效地在架构中分配角色以及责任，也更容易开发、测试、管理以及维护应用，因为每个组件的接口和范围都会定义的很清楚。

关键概念

看图1-2，架构中的每一层都被标记为关闭。这在分层架构中是非常重要的概念。关闭的层意味着请求必须逐层传递而不能跨层。举例来说，一个产生于显示层的请求必须首先通过业务层然后经过持久层最后到数据库层。

为什么不允许显示层直接接触持久层或者数据库层呢？毕竟，直接从显示层调用数据库比一层层的传递调用快得多。答案在另一个关键概念中：层的隔离。

层的隔离意味着在某一层的改变通常不会影响其他层的组件：改变被隔离在对应层的组件中，以及可能另外相关的层(比如包含SQL的持久层)。如果我们允许显示层直接调用持久层，那么SQL的改变将会对业务层和显示层都造成影响，因此导致一个非常紧耦合的应用，各个组件会有非常多的相互依赖。这种架构就会变得非常难改变。

层的隔离的概念也意味着每一层与其他层都是独立的，因此也不需要知道架构中其他层的工作。为了理解这个概念的重要性，想象一下如果我们要做一个大重构，将显示层的框架从JSP改为JSF，因为层的隔离，所以显示层和业务层的接口保持不变，业务层根本就不会受到此次重构的影响，因其完全不依赖显示层UI接口框架。

尽管关闭的层促进层见隔离而且因此隔离了架构内的变化，但是有时候我们还是需要打开一些层。举例来说，假设我们想在架构中添加一个共享服务层，包含一些通用服务组件，由业务层组件来调用(如 数据和字符串工具类或者编辑和日志类等)。创建一个服务层通常是一个好方法，因为架构只把通用服务层的权限给业务层(而不包括显示层)。如果没有独立的层，架构将不能限制显示层调用通用服务层，这就使得调用限制非常难管理。

在上面的例子中，新的服务层很可能将位于业务的下面来避免显示层的调用。但是这也带来一个问题，因为业务层是需要调用持久层的，中间加了通用服务层之后，使得业务层也不直接和持久层相连。这在分层架构中是一个老生常谈的问题，它可以通过在架构中创建一些开放的层来解决。

如图1-3，例子中的服务层被标记为开放，意味着请求可以直接通过这一层到底它的下一层。在例子中，因为服务层是开放的，业务层可以直接越过它去调用持久层，这就完美解决了上面提到的问题。

 

引入开放和关闭的层概念，可以帮我们定义不同层的关系以及请求的传递，而且也给设计师和开发者提供理解各种层限制的必要信息。如果一个架构无法说明为什么这个层是开放或关闭，通常是因为这个架构本身是一个紧耦合且不可靠的架构，也将使得它很难测试、维护和部署。

模式举例

为了说明这种分层架构是这么工作的，设想一个用户的请求，要获取某个人的信息，这个过程如图1-4所示。黑色的箭头表示的是请求朝下流动直到数据库提取用户信息，红色箭头指向反馈一路向上直到显示数据。在这个例子中，消息者的信息由消费者数据和订单数据。

 

消费者的屏幕负责接收请求并显示消费者信息。它不知道数据在哪、怎么提取或者需要检索多少数据库来获得这些信息。一旦顾客屏幕接收到请求，要获取一个特定个人的信息，显示层把这个请求交给代理模块。代理模块方负责和业务层相应的模块对接，传递参数。业务层的顾客对象负责狙击所有业务请求需要的信息。该模块调用持久层的customer dao(data access object)模块来获取顾客数据以及订单的dao模块来获取订单数据。这些dao模块会执行SQL语句来提取相应的数据并传回给业务层的顾客对象。一旦顾客对象接收到数据，马上聚合数据并将信息传回给顾客代理，然后由代理将数据传给顾客屏幕并显示给用户。

 

从科技的角度，理论上有很多的方法来实现这些模块。比如，在JAVA平台上，顾客屏幕可以是JSF(Java Server Faces)屏幕并耦合一个顾客代理，来管理组件。业务层的顾客对象可以是一个local Spring bean 或 一个远程EJB3 bean。数据接入对象可以用简单的POJO’s(Plain Old Java Objects)，MyBatis XML Mapper文件，甚至封装了原始JDBC calls或者Hibernate queries的对象。从微软平台的角度来说，顾客屏幕可以是一个ASP模块，使用.NET框架来和业务层的C#模块交互，顾客数据和订单数据模块可以用ADO(ActiveX Data Objects)实现。

思考

分层架构模式时一套非常通用的模式，对大多数应用来说都是一个非常好的模式，尤其是当你不确定什么模式最适合你的应用的时候。然而，也有一些事情需要考虑，以便做出正确的架构选择。

首先要注意的是被称作”architecture sinkhole anti-pattern”的问题。这个问题描述的是，上层请求实际上是要调用底层接口，而在各个中间层只做了一个过渡，并没有任何实质逻辑处理。举例来说，假设显示层从用户接受请求要获取顾客数据。显示层传递请求到业务层，业务层仅仅只是把请求传给持久层，经过一个简单的SQL调用数据库之后，获取到顾客数据。这个数据然后一路向上传回给显示层，中间不经过任何逻辑、计算、转换等处理。这个例子中，各个层没有进行实质上的逻辑处理，但是却平白无故增加了函数调用，这就是anti-pattern。

每个分层架构都会有至少一些场景是落入这个anti-pattern中的。关键在于，我们要分析落入这个anti-patter的请求在所的比例。80-20原则通常是个不错的方法来告诉我们架构整体是否陷入了anti-pattern中。如果20%是anti-pattern，80%都是需要在中间层做一些操作处理，那么这个分层架构就是合理的，并没有整体陷入anti-pattern中。如果我们发现大多数请求都是anti-pattern，那么久需要思考分层架构是否适合这个应用了。或者我们需要将一些层置位开放，来避免anti-pattern。

还有一个需要考虑的是，尽管我们把显示层业务层等分成了独立可部署的单元，但是分层架构往往是基于整个应用而言的。这对一些应用来说，会造成一些可能的问题，比如部署、鲁棒性、可信度、性能和伸缩性等。

分析

当我们想说一个架构好还是不好的时候，需要一些指标来帮我们完成这个任务。下面的表包含对分层架构特性的评分和分析。每个特性的评分都是基于分层架构最典型的实现方法。

整体灵活度

评分：低

分析：整体灵活度是架构对持续变化环境的反应能力。尽管变化可以被隔离在各个层中，但是分层架构应对变化还是很笨重也很耗时。因为这个架构通常都是对应一个庞大的应用系统，而且各个层之间的组件一般来说也都耦合的比较紧。

部署的容易程度

评分：低

分析：根据你实现分层架构的方法，部署也许会成为一个问题，尤其是对大型应用。一个组件中很小的改动可能需要整个应用(或者应用的大部分)重新部署，导致很多需要下班时间或者周末来进行部署计划、排期和执行。所以，整体部署容易程度偏低。

可测试性

评分：高

分析：因为架构中属于不同层的组件之间是隔离的，是的这个架构相对来说会比较容易测试。开发者可以模拟一个显示层的组件或者屏幕来单独测试业务层逻辑，或者模拟一个业务层来测试显示层的功能。

性能

评分：低

分析：尽管某些层的实现可能会非常搞笑，但是这个架构模式并不是十分高效。因为在这个模式中我们要穿过多层来完成一个商业请求，非常的不方便。

伸缩性：

评分：低

分析：由于现在的趋势倾向于紧耦合，而这个模式往往很庞大，使用这种架构的应用通常都很难伸缩。我们可以将一些层拆分成不同的物理部署单元或者将整个应用非诚多个节点，但是总体来说粒度都太粗，是的它不好伸缩。

开发容易程度

评分：高

分析：开发容易程度获得一个相对高的分数，很大程度上因为这种架构模式已经非诚常见而且实现起来也不是很复杂。因为大多数公司都在开发应用的时候都按功能划分层（显示、业务、数据库），使得这种模式对大多数商业应用开发来说都是天然的选择。一个公司公司的组织结构和它开发软件方法回见的关系可以概括成”Conway’s Law”。大意是，公司采用什么样的组织结构形式，就会倾向于使用类似的方法来开发软件。比如分层的组织结构对应了分层架构。