分层模式是最通用的架构,也被叫做N层架构模式(n-tier architecture pattern).这也是Java EE应用经常采用的标准模式.基本上都知道它.这种架构模式非常适合传统的IT通信和组织结构,很自然地成为大部分应用的第一架构选择.
模式描述
在分层架构中的组件被划分成几个层,每个层代表应用的一个功能.分层架构本身没有规定要分成多少层,大部分的应用会分成表现层,业务层,持久层和数据库层.小的应用有时候会将业务层和持久层合在一起,更大规模的应用可能会划分更多的层,比如调用外部服务的层.
每一层都有特定的角色和职能.各层实现的功能如下:
- 表现层(presentation):用户界面,负责视觉和用户互动
- 业务层(business):实现业务逻辑
- 持久层(persistence):提供数据,SQL 语句就放在这一层
- 数据库(database):保存数据
分层架构的一个特性就是关注分离(separation of concerns).在层中的组件只负责本层的逻辑.组件的划分很容易让它们实现自己的角色和职责,也比较容易地开发,测试管理和维护.
关键概念
注意每一层都是封闭的.这意味着Request必须经过每一层才能到达最底下一层.
为什么不允许展示层直接访问数据库层呢,这样不是更快吗?这就是分层架构的另一个特征:层隔离(layers of isolation).
层隔离的概念意味着你对任何一层的改变都不会影响其它层,这很好理解.层隔离也意味着一个层的组件并不会了解其它层的实现,或者知道很少. 比如业务层不需知道你持久层是由hibernate还是mybatis实现的.
分层架构也很容易增加新的层. 比如你想将一些通用的服务重构成一个服务层,比如通用图片处理,远程账户审计等,可以在业务层下增加一个服务层.它不会对展示层造成影响,也不会改变持久层的代码.
上面的这个例子带来一个问题,因为每一层是封闭的,业务层不得不通过服务层访问持久层. 所以有时候你会创建一个开放的层.这意味着上一层可以绕过这一层直接访问下一层.
架构例子
架构考量
分层架构是一个可靠的通用的架构,对很多应用来说,如果你不确定哪种架构适合你的应用,可以用它作为一个初始架构.第一个要注意的是污水池反模式(architecture sinkhole anti-pattern).这个反模式是这样的,请求流简单的穿过几个层,每层里面基本没有做任何业务逻辑,或者做了很少的业务逻辑,比如一些JavaEE例子,业务逻辑层只是简单的调用了持久层的接口,本身没有什么业务逻辑.每一层或多或少都有可能遇到这样的场景.关键是分析这样的请求的百分比是多少.80-20原则可以帮助你决定是否正在遇到污水池反模式,如果你的请求超过20%,你应该考虑让一些层变成开放的.
另一个需要考虑的是分层架构可能会让你的应用变得庞大,即使你的展示层和业务层可以独立发布（比如展示层使用单页技术框架AngularJS, EmberJS）.它的确会带来一些潜在的问题,比如分布模式复杂,健壮性下降,可靠性,性能和规模等.
模式分析
- 总体灵活性: 低
- 发布易用性:低
- 可测试性: 高
- 性能:低
- 规模扩展性: 低
- 开发容易度: 高
优点
- 结构简单,容易理解和开发
- 不同技能的程序员可以分工,负责不同的层,天然适合大多数软件公司的组织架构
- 每一层都可以独立测试,其他层的接口通过模拟解决
- 一旦环境变化,需要代码调整或增加功能时,通常比较麻烦和费时
- 部署比较麻烦,即使只修改一个小地方,往往需要整个软件重新部署,不容易做持续发布
- 软件升级时,可能需要整个服务暂停
- 扩展性差.用户请求大量增加时,必须依次扩展每一层,由于每一层内部是耦合的,扩展会很困难