这是我参与8月更文挑战的第11天，活动详情查看：8月更文挑战程序员

架构设计模式

没有进行架构设计的应用程序一般是紧耦合的，难以维护和扩展。若是不理解应用的各个组件的内部工做方式的话很难看清它的架构特征。数据库

关于部署和维护的问题都很难回答：设计模式

软件架构模式能够帮助你定义程序的基本特征和行为。例如一些架构模式很天然让程序成为大规模(scalable)的程序。有些模式让程序变得灵巧敏捷(agile)。知道这些架构的特征，优势和缺点，你就能够根据你特定的业务需求和目标从容地选择一种架构模式。性能

做为一位架构师，你总会为本身的架构选择作解释，尤为你选择一个特别的架构模式的时候。学习

软件架构法则

软件架构第必定律：软件架构中的全部东西都是一种权衡(Everything in software architecture is a trade-off)

咱们对软件架构的定义超越告终构的范畴，包含了原则、特性等，架构的范围比单纯的结构更广，体如今咱们的软件架构第二定律中：为何比怎么作更重要（Why is more important than how）

分层架构 (Layered Architecture)

它是最通用的架构，也被叫作 N 层架构模式(n-tier architecture pattern)。这也是 Java EE 应用常常采用的标准模式。基本上是个程序员都比较熟悉它。

这种架构模式很是适合传统的 IT 通讯和组织结构，很天然地成为大部分应用的第一架构选择。

在分层架构中的组件被划分红几个层，每一个层表明应用的一个功能，都有本身特定的角色和职能。

分层架构自己没有规定要分红多少层，大部分的应用会分红表现层、业务层、持久层和数据层。

小的应用有时候会将业务层和持久层合在一块儿，更大规模的应用可能会划分更多的层，好比调用外部服务的层。

分层架构的一个特性就是关注分离(separation of concerns)。该层中的组件只负责本层的逻辑，组件的划分很容易让它们实现本身的角色和职责，也比较容易地开发，测试管理和维护。

注意每一层都是封闭的，这意味着 Request 必须通过每一层才能到达最底下一层。

Q：为何不容许展现层直接访问数据库层呢，这样不是更快吗？

这就是分层架构的另外一个特征：层隔离(layers of isolation)。

层隔离的概念意味着你对任何一层的改变都不会影响其它层，这很好理解，同时也意味着一个层的组件并不会了解其它层的实现，或者知道不多。

好比业务层不需知道你持久层是如何具体实现的。

分层架构也很容易增长新的层。

好比你想将一些通用的服务重构成一个服务层，好比通用图片处理，远程帐户审计等，能够在业务层下增长一个服务层。它不会对展现层形成影响，也不会改变持久层的代码。

上面的这个例子带来一个问题，由于每一层丢失封闭的，业务层不得不经过服务层访问持久层，这没有天理啊。因此有时候你会建立一个开放的层。这意味着上一层能够绕过这一层直接访问下一层。

分层架构是一个可靠的通用的架构，对不少应用来讲，若是你不肯定哪一种架构适合你的应用，能够用它做为一个初始架构。一、要注意的是污水池反模式(architecture sinkhole anti-pattern)

所谓污水池反模式，就是请求流简单的穿过几个层，每层里面基本没有作任何业务逻辑，或者作了不多的业务逻辑。好比一些 JavaEE 例子，业务逻辑层只是简单的调用了持久层的接口，自己没有什么业务逻辑。

每一层或多或少都有可能遇到这样的场景，关键是分析这样的请求的百分比是多少。二八原则能够帮助你决定是否正在遇到污水池反模式。若是你的请求超过 20%，你应该考虑让一些层变成开放的。

二、须要考虑的是分层架构可能会让你的应用变得庞大

即便你的展现层和业务层能够独立发布（好比展现层使用单页技术框架 AngularJS, EmberJS）。

它的确会带来一些潜在的问题，好比分布模式复杂，健壮性降低，可靠性，性能和规模等。

结合上文分析，分层架构设计模式总体分析以下：

- END -

做者：架构精进之路，十年研发风雨路，大厂架构师，CSDN 博客专家，专一架构技术沉淀学习及分享，职业与认知升级，坚持分享接地气儿的干货文章，期待与你一块儿成长。
关注并私信我回复“01”，送你一份程序员成长进阶大礼包，欢迎勾搭。

文章首发于同名公众号《架构精进之路》，原文连接：软件架构模式之分层架构

Thanks for reading!