软件架构模式-读书笔记.doc

软件架构模式 本文是我在阅读OReilly免费的电子书? HYPERLINK /programming/free/software-architecture-patterns.csp \n _blankSoftware Architecture Patterns过程中做的笔记。首先这本书非常新，2015年3月30号订正后发布。其次将目前流行的几种架构详细进行了剖析和比较，除了传统的N层架构外，其它架构相当的前沿。并且，这篇小书连带封面才55页，短小精悍，值得一读。这本书的作者是 Mark Richards，有30多年行业经验，19年软件集成，企业级架构的经验，大部分是Java平台，也出版了多本书和论文。 如果你没有时间去阅读这本书，那么不妨看一下本篇文章。 我在笔记中将书中的主要知识点都记录下来。 不先进行正式的架构设计就直接开发对于程序员来说再普通不过了。没有清晰和很好的架构设计，大部分程序员和架构师实际上会采用传统的分层的架构模式， 自然地将代码模块分隔成几个包(package)。不幸地是，这种做法经常导致未能好好组织代码模块，这些模块缺乏清晰的角色，责任以及相互关系。这经常被成为 HYPERLINK /wiki/Big_ball_of_mud \n _blank大泥球反模式。 没有进行架构设计的应用程序通常是紧耦合的，玻璃心，难以改变，没有头绪。如果不理解应用的各个组件的内部工作方式的话很难看清它的架构特征。关于部署和维护的问题都很难回答：架构的规模如何？程序的性能如何？程序容易修改吗？程序的部署模型是怎么样？程序的响应如何？ 架构模式可以帮助你定义程序的基本特征和行为。例如一些架构模式很自然让程序成为大规模(scalable)的程序。有些模式让程序变得灵巧敏捷(agile)。知道这些架构的特征，优点和缺点，你就可以根据你特定的业务需求和目标从容的选择一种架构模式。 作为一位架构师，你总会为自己架构选择做解释，尤其你选择一个特别的架构模式的时候。OReilly的这本书提供了充足的信息来为你的架构选择提供证明。 分层架构 (Layered Architecture) 它是最通用的架构，也被叫做N层架构模式(n-tier architecture pattern)。这也是Java EE应用经常采用的标准模式。基本上是个程序员都知道它。这种架构模式非常适合传统的IT通信和组织结构，很自然地成为大部分应用的第一架构选择。 模式描述 在分层架构中的组件被划分成几个层，每个层代表应用的一个功能。分层架构本身没有规定要分成多少层，大部分的应用会分成表现层，业务层，持久层和数据库层。小的应用有时候会将业务层和持久层合在一起，更大规模的应用可能会划分更多的层，比如调用外部服务的层。 每一层都有特定的角色和职能。 分层架构的一个特性就是关注分离(separation of concerns)。在层中的组件只负责本层的逻辑。组件的划分很容易让它们实现自己的角色和职责，也比较容易地开发，测试管理和维护。 关键概念 注意每一层都是封闭的。这意味着Request必须经过每一层才能到达最底下一层。 为什么不允许展示层直接访问数据库层呢，这样不是更快吗？这就是分层架构的另一个特征：层隔离(layers of isolation)。层隔离的概念意味着你对任何一层的改变都不会影响其它层。这很好理解。层隔离也意味着一个层的组件并不会了解其它层的实现，或者知道很少。 比如业务层不需知道你持久层是由hibernate还是mybatis实现的。分层架构也很容易增加新的层。 比如你想将一些通用的服务重构成一个服务层，比如通用图片处理，远程账户审计等，可以在业务层下增加一个服务层。它不会对展示层造成影响，也不会改变持久层的代码。上面的这个例子带来一个问题，因为每一层丢失封闭的，业务层不得不通过服务层访问持久层，这没有天理啊。 所以有时候你会创建一个开放的层。这意味着上一层可以绕过这一层直接访问下一层。 架构例子 我们看一下淘宝前几年的架构的例子。 这是一个标准的分层的架构。每一层中又可以详细的分成更细的层，比如服务层。围着着这个主架构还有一些外围的产品。比如监控和审计。 架构考量 分层架构是一个可靠的通用的架构，对很多应用来说，如果你不确定哪种架构适合你的应用，可以用它作为一个初始架构。第一个要注意的是污水池反模式(architecture sinkhole anti-pattern).这个反模式是这样的，请求流简单的穿过几个层，每层里面基本没有做任何业务逻辑，或者做了很少的业务逻辑。比如一些JavaEE例子，业务逻辑层只是简单的调用了持久层的接口，本身没有什么业务逻辑。每一层或多或少都有可能遇到这样的场景。关键是分析这样的