软件架构模式 mark Richards - 读后总结 1 - 分层架构

软件架构模式 Mark Richards 著 版权归 © 2015 O’Reilly Media, Inc. 所有.

原书发布链接为  Software Architecture Patterns [Book]

第一章 分层架构

分层架构是一种很常见的架构模式(也叫N层架构)。这种架构是⼤大多数Jave EE应⽤用的实际标准，因此很多 的架构师，设计师，还有程序员都知道它。许多传统IT公司的组织架构和分层模式⼗十分的相似。所以它很⾃自 然的成为⼤大多数应⽤用的架构模式。
分层架构模式⾥里的组件被分成⼏几个平⾏行的层次，每⼀一层都代表了应⽤用的一个功能(展⽰示逻辑或者业务逻辑)。 尽管分层架构没有规定⾃自⾝身要分成⼏几层⼏几种，⼤大多数的结构都分成四个层次:展⽰示层，业务层，持久层，和数 据库层。如表1-1，有时候，业务层和持久层会合并成单独的⼀一个业务层，尤其是持久层的逻辑绑定在业务层 的组件当中。因此，有一些⼩小的应⽤用可能只有3层，一些有着更复杂的业务的⼤大应⽤用可能有5层或者更多的分 层。
分层架构中的每⼀一层都着特定的⾓角⾊色和职能。举个例⼦子，展⽰示层负责处理所有的界⾯面展⽰示以及交互逻辑，业 务层负责处理请求对应的业务。架构⾥里的层次是具体⼯工作的⾼高度抽象，它们都是为了实现某种特定的业务请 求。⽐比如说展⽰示层并不需要关⼼心怎样得到⽤用户数据，它只需在屏幕上以特定的格式展⽰示信息。业务层并不关 ⼼心要展⽰示在屏幕上的⽤用户数据格式，也不关⼼心这些⽤用户数据从哪⾥里来。它只需要从持久层得到数据，执⾏行与 数据有关的相应业务逻辑，然后把这些信息传递给展示层。

那么为什么不允许展⽰示层直接访问数据层呢。如果只是获得以及读取数据，展⽰示层直接访问数据层，⽐比穿过
关键概念
一层一层来得到数据来的快多了。这涉及到一个概念:层隔离。 层隔离就是说架构中的某一层的改变不会影响到其他层:这些变化的影响范围限于当前层次。如果展示层能够 直接访问持久层了，假如持久层中的SQL变化了，这对业务层和展示层都有一定的影响。这只会让应⽤用变得 紧耦合，组件之间互相依赖。这种架构会⾮非常的难以维护。
从另外⼀一个⽅方⾯面来说，分层隔离使得层与层之间都是相互独⽴立的，架构中的每一层的互相了解都很少。为了 说明这个概念的⽜牛逼之处，想象⼀一个超级重构，把展⽰示层从JSP换成JSF。假设展⽰示层和业务层的之间的联系 保持一致，业务层不会受到重构的影响，它和展⽰示层所使⽤用的界⾯面架构完全独⽴立。
然⽽而封闭的架构层次也有不便之处，有时候也应该开放某一层。如果想往包含了一些由业务层的组件调⽤用的 普通服务组件的架构中添加一个分享服务层。在这个例⼦子⾥里，新建一个服务层通常是一个好主意，因为从架 构上来说，它限制了分享服务访问业务层(也不允许访问展⽰示层)。如果没有隔离层，就没有任何架构来限制 展⽰示层访问普通服务，难以进⾏行权限管理。
在这个例⼦子中，新的服务层是处于业务层之下的，展⽰示层不能直接访问这个服务层中的组件。但是现在业务 层还要通过服务层才能访问到持久层，这一点也不合理。这是分层架构中的⽼老问题了，解决的办法是开放某 些层。如表1-3所⽰示，服务层现在是开放的了。请求可以绕过这一层，直接访问这一层下⾯面的层。既然服务层 是开放的，业务层可以绕过服务层，直接访问数据持久层。这样就⾮非常合理。
 

示例

注意事项

分层架构是一个很可靠的架构模式。它适合⼤大多数的应⽤用。如果你不确定在项目中使⽤用什么架构，分层架构 是再好不过的了。然后，从架构的⾓角度上来说，选择这个模式还要考虑很多的东⻄西。

第一个要注意的就是 污⽔水池反模式(architecture sinkhole anti-pattern)。 在这个模式中，请求流只是简单的 穿过层次，不留一点云彩，或者说只留下一阵⻘青烟。⽐比如说界⾯面层响应了一个获得数据的请求。响应层把这 个请求传递给了业务层，业务层也只是传递了这个请求到持久层，持久层对数据库做简单的SQL查询获得⽤用 户的数据。这个数据按照原理返回，不会有任何的⼆二次处理，返回到界⾯面上。 每个分层架构或多或少都可能遇到这种场景。关键在于这样的请求有多少。80-20原则可以帮助你确定架构是 否处于反污⽔水模式。大概有百分之二⼗十的请求仅仅是做简单的穿越，百分之八十的请求会做一些业务逻辑操 作。然⽽而，如果这个⽐比例反过来，⼤大部分的请求都是仅仅穿过层，不做逻辑操作。那么开放⼀一些架构层会⽐比 较好。不过由于缺少了层次隔离，项⺫⽬目会变得难以控制。

整体灵活性
评级:低 分析:总体灵活性是响应环境变化的能⼒力。尽管分层模式中的变化可以隔绝起来，想在这种架构中做⼀一些也改 变也是并且费时费⼒力的。分层模式的笨重以及经常出现的组件之间的紧耦合是导致灵活性降低的原因。

易于部署

评级:低 分析:这取决于你怎么发布这种模式，发布程序可能⽐比较⿇麻烦，尤其是很⼤大的项⺫⽬目。⼀一个组件的⼩小⼩小改动可能 会影响到整个程序的发布(或者程序的⼤大部分)。发布必须是按照计划，在⾮非⼯工作时间或者周末进⾏行发布。因 此。分层模式导致应⽤用发布⼀一点也不流畅，在发布上降低了灵活性

可测试性

评级:⾼ 分析:因为组件都处于各⾃自的层次中，可以模拟其他的层，或者说直接去掉层，所以分层模式很容易测试。开 发者可以单独模拟⼀一个展⽰示组件，对业务组件进⾏行隔绝测试。还可以模拟业务层来测试某个展示功能。

性能
评级:低 分析:尽管某些分层架构的性能表现的确不错，但是这个模式的特点导致它⽆无法带来⾼高性能。因为⼀一次业务请 求要穿越所有的架构层，做了很多不必要的⼯工作。
 

伸缩性

评级:低 分析:由于这种模式以紧密耦合的趋势在发展，规模也⽐比较⼤大，⽤用分层架构构建的程序都⽐比较难以扩展。你可 以把各个层分成单独的物理模块或者干脆把整个程序分成多个节点来扩展分层架构，但是总体的关系过于紧模式分析整体灵活性易于部署可测试性性能伸缩性密，这样很难扩展

易开发性
评级:容易 分析:在开发难度上⾯面，分层架构得到了⽐比较⾼高的分数。因为这种架构对⼤大家来说很熟悉，不难实现。⼤大部分 公司在开发项⺫⽬目的都是通过层来区分技术的，这种模式对于⼤大多数的商业项⺫⽬目开发来说都很合适。公司的组 织架构和他们软件架构之间的联系被戏称为"Conway's law"。你可以Google⼀一下查查这个有趣的联系。