前言
软件架构这个学科已经有半个世纪的历史了。此概念于20世纪60年代引入，它的灵感来源于建筑物的架构，其中涉及在开始盖楼之前拟定的一些蓝图，这些蓝图描述了建筑师对建筑物的结构所制定的设计方案与规格说明。建筑物的蓝图给出了建筑物在功能方面的设计方案，也就是楼层的空间布局示意图，以及每个建筑工件（例如门、窗、房间、浴室、楼梯等）的尺寸。在使建筑物得以运作的那些方面，蓝图也提供了详细的设计方案，例如承载建筑结构的地基、电线、水管和输气管道的设计，以及下水道系统等，要想使建筑物的功能全面运转并发挥效用，这些方面都是不可缺少的。
信息技术（information technology，IT）中的软件架构，其真正灵感来源于建筑架构学中的土木工程（civil engineering）这一学科。据此，我们可以把软件架构大致分成功能架构（functional architecture）和操作架构（operational architecture）两大类。软件架构在 20世纪70年代开始得到大规模实践，到了20世纪90年代，它已经成为IT界的主流，此时各种架构模式也相继涌现。这些模式会随着工作中反复出现的一些用法而演化，所谓反复出现（recurrence），是指这些用法会一直重复地出现在日常应用中。我们之所以能从软件架构中提炼出架构模式，是因为有一个先决条件已经得到了满足。这个条件就是软件架构已经得到了充分的实践，从而成为业界的主流做法，并且已经作为一门正式的研究与实践学科，得到了业界的认可。
IT系统的复杂度越来越高，因此各种IT项目都会频繁而且广泛地运用软件架构技术。软件架构的方式也随着运用面的扩大而变得丰富起来，并且还涌现出了很多流派，它们采用不同的观点来看待软件的架构，并根据其在开发软件系统时所取得的实际经验来总结并推广各自的观点。软件架构的流派和观点变得越来越多，这使很多IT工作者都不知道应该采信哪个流派的观点。大家不妨回想一下，看看自己有没有对下面这些问题表示过困惑？
我读过很多架构方面的书籍，也看过很多期刊和杂志，但是我究竟应该怎样把这些互不相同的架构流派汇整起来呢？
这些流派中有哪些方面是我比较喜欢的？
这些方面是否可以互补？
如果我是一名架构师，面对着一个时间和预算都受限制的复杂软件系统，那么应该从哪里开始实现它呢？
我是否能成为一名成功的软件架构师？
笔者也曾陷入这样的困惑中。软件架构师所要面对的一项艰难挑战，就是寻找一种最佳的方式，来确定系统或应用程序的架构，并对其进行设计。对软件架构的要义进行把握，既是一种科学，又是一种艺术。我们要用适当的描述语言来定义系统的软件架构，并对其加以分析和理解，从这个层面来看它是科学。同时，我们还要用清晰、明确并且简洁的方式把这个架构描绘出来，以便与不同的利益相关者就系统的解决方案架构进行有效的沟通，从这个层面来看它又是艺术。软件架构师怎样才能抓住关键的架构工件（architecture artifact），从而清晰地描述出整个解决方案呢？这正是难点所在。过度的设计和过多的文档，会拖慢项目的进度，并给项目的交付带来风险，而对软件架构所做的不恰当处理，则会使开发者无法领悟这套架构，这是个很关键的问题。如果开发者不能很好地理解软件的架构，那么他们就无法恰当地遵循技术方面的规范和限制，也无法恰当地使用这套架构来设计并开发系统中的各个部件。在软件开发的整个生命周期中，这个问题只会越来越严重。
2008年，笔者在IBM developerWorks网站上写了一系列专门谈论软件架构的文章。在连续发布4部分之后，由于某些个人原因，没有再往下写。接下来的几年，笔者看到了一些网友提出的问题，也收到了一些称赞，然而除此之外，还有另一类信息促使我进行更多的思考。比如，下面这两个问题：
“先生您好。我正在参考您的系列文章来撰写硕士论文。请问下一部分的文章什么时候发布？”
“Mitra先生，我们采用您所说的框架做了IT项目，但是项目暂停了，因为您的下一篇文章还没出来。求助。”
某一天早晨，我忽然感觉读者确实需要一本架构方面的书籍，它必须写得简单、明确、易于理解、便于描述，而且最为重要的是，它必须足够实用，能够执行。这本实用的书籍要能够给IT工作者和软件工程专业的学生带来较大的帮助，使他们明白怎样对软件系统进行架构。过了一段时间之后，我终于决定开始写书了。本书代表着软件架构领域中的集体智慧、经验、学问和知识，这些内容是笔者根据自己从业18年来的经历收集而成的。本书面对的读者有很多，其中包括：
软件架构师。书中会给出一些实用而且可以反复运用的指导原则，以帮助软件架构师来研发软件的架构。
项目经理。本书将会帮助读者理解并领会系统架构中的关键元素，它们是良好的架构所必备的元素，本书还会解释怎样才能在进行项目规划时把架构活动控制得恰到好处。
高校学生。本书将会帮助大家理解怎样把软件架构中的理论转述成实际的问题，并对其加以实现。无论技术如何发展，本书都可以当作长期的参考资料。
教师。通过本书，教师可以帮助学生把软件架构中的各种理论与实际工作联系起来，使学生变成能够应对实际项目的软件架构师。
首席管理者（C-level executive）或高层管理人员。本书将会帮助他们意识到研发良好的系统架构所必备的要素，对于IT界的任何一种创新活动来说，这种意识都会给公司带来间接的好处，使他们可以更好地领悟IT架构在整个公司中的基础地位。
笔者想把这本书写成一本实用的教程，使读者可以按照里面所说的方法，通过多个阶段的演进来迭代式地构建出软件的架构。书中会指出各种架构工件的运用方式，使大家可以把这些清晰、简明、精准而且易懂的工件，恰到好处地运用在实际的应用场景中。在整本书中，笔者会以较为随意的方式来使用“软件”（software）“系统”（system）和“解决方案”（solution）这三个词，由于它们在本书中指的都是架构（architecture），因此这三者之间是可以互换的。笔者之所以要采用这种不拘于字面意思的交替指称方式，是为了使大家明白：在IT界，这三个词之间的界限其实是相当模糊的。
从哲学角度来看，东方哲学和西方哲学之间的区别，在于它们对直觉和理性这两种感知形式的接受程度有所不同，前者更强调直觉，而后者更强调理性。西方世界普遍相信，并且主要依赖于理性的、科学的和演绎式的推理。而东方世界则更加看重凭直觉所获取的知识，他们认为，更高形式的意识（在这里指的是知识）是通过观察（也包括反思自己的内心世界）得来的，而不是仅仅通过实验式的归纳得来的。笔者生长于印度加尔各答一个文化较为多元的孟加拉家庭中，十分认同东方式的信仰和知识观念，我认为自觉的意识最终需要通过自觉的自由意志来获得，知识的奥义也要通过直觉和归纳式的推理来领悟。后来，笔者在西方世界生活了将近20年，在这段时间里，我开始看重科学和理性的知识形式。我认为，一个普通人要想在这个残酷竞争的世界中生存，就必须掌握由理性与科学手段所得到的知识，对于科学、技术和IT领域来说更是如此。等到自己的工作稳定下来之后，可以去深入探索直觉感知力和归纳式推理，这种探索虽然未必会带来回报，但或许会帮助我们从人生的存在中求得解脱。
在这本书中，笔者试着用一种解说的办法，通过归纳式的理性推理来帮助读者掌握实用的软件架构方式。等到掌握了这种理性的知识之后，读者可以把注意力放在归纳式的推理上，以探求更为玄妙的直觉知识。如果把解决最困难的架构问题比喻成寻求圣杯（Holy Grail），那么用直觉来感知软件的架构就相当于层次更高的开悟了，这种境界，我想应该是大家梦寐以求的吧。
等到看完本书并掌握了它的要义之后，希望你能焕然一新，变成一位务实的软件架构师。软件架构是个有趣的学科，其中的理性知识，我想读完这本书之后，大家应该就可以了解到。而凭直觉才能获得的那一部分知识，则需要以理性知识为基础，继续去探索。在这一方面，连笔者也只是刚刚入门而已。
另外再说一句，每章开头的那些格言，其实都是笔者自己编的。
目录
1.1.1 技术挑战
1.1.2 用例
1.1.3 在机器运转过程中进行实时处理与监控
1.1.4 为新机器提供无缝的激活服务
1.1.5 生成工作定单
1.1.6 尽量减少在为全球客户提供服务时所产生的延迟
2.3.1 把架构视为交流工具
2.3.2 对项目规划施加影响力
2.3.3 关注非功能方面的能力
2.3.4 与设计团队和实现团队做出约定
2.3.5 为影响力分析提供支持
2.6 参考资料
第4章 系统环境
4.1 业务环境与系统环境之间的辨析
4.2 捕获系统环境
4.2.1 系统环境图
4.2.2 信息流
4.3 案例研究：Elixir的系统环境
4.3.1 Elixir的系统环境图
4.3.2 Elixir的信息流
4.4 小结
4.5 参考资料
第5章 架构概述
5.1 什么是架构概述
5.2 为什么要做架构概
5.3 企业视图
5.3.1 用户与传输渠道
5.3.2 核心业务流程
5.3.3 数据与信息
5.3.4 技术推动力
5.4 分层视图
5.4.1 第1层：操作层
5.4.2 第2层：服务组件层
5.4.3 第3层：服务层
5.4.4 第4层：业务流程层
5.4.5 第5层：消费者层
5.4.6 第6层：集成层
5.4.7 第7层：QoS层
5.4.8 第8层：信息架构层
5.4.9 第9层：治理层
5.4.10 进一步研究分层视图的用法
5.5 IT系统视图
5.6 案例研究：Elixir的架构概述
5.6.1 Elixir的企业视图
5.6.2 Elixir的业务流程
5.6.3 Elixir的数据及信息
5.6.4 Elixir的技术推动力
5.6.5 Elixir的分层视图
5.6.6 Elixir的IT系统视图
5.7 小结
5.8 参考资料
第6章 架构决策
6.1 为什么需要做架构决策
6.2 怎样开始进行架构决策
6.3 创建架构决策
6.4 案例研究：Elixir的架构决策
6.5 小结
第7章 功能模型
7.1 为什么需要功能模型
7.2 可追溯性
7.3 制定功能模型
7.3.1 逻辑层面的设计
7.3.2 规格层面的设计
7.3.3 物理层面的设计
7.4 案例研究：Elixir的功能模型
7.4.1 逻辑层面
7.4.2 规格层面
7.4.3 物理层面
7.5 小结
7.6 参考资料
第8章 操作模型
8.1 为什么需要操作模型
8.2 可追溯性与服务级别协议
8.3 制定操作模型
8.3.1 概念操作模型
8.3.2 规格操作模型
8.3.3 物理操作模型
8.4 案例研究：Elixir的操作模型
8.4.1 COM
8.4.2 SOM
8.4.3 POM
8.5 小结
8.6 参考资料
第9章 集成：方式与模式
9.1 为什么需要进行集成
9.2 集成方式
9.2.1 用户界面的集成
9.2.2 数据层面的集成
9.2.3 消息层面的集成
9.2.4 API层面的集成
9.2.5 服务层面的集成
9.3 集成模式
9.3.1 同步的请求栂煊δＪ?
9.3.2 批次模式
9.3.3 同步的批次请求栍Υ鹉Ｊ?
9.3.4 异步的批次请求栍Υ鹉Ｊ?
9.3.5 存储并转发模式
9.3.6 发布柖┰哪Ｊ?
9.3.7 聚合模式
9.3.8 管道与过滤器模式
9.3.9 消息路由器模式
9.3.10 消息转换器模式
9.4 案例研究：Elixir的集成视图
9.4.1 标签1～5所表示的数据流
9.4.2 标签6～8所表示的数据流
9.4.3 标签9～10所表示的数据流
9.4.4 标签11～12所表示的数据流
9.5 小结
9.6 参考资料
第10章 基础设施问题
10.1 为什么要把基础设施做好
10.2 需要考虑的基础设施问题
10.2.1 网络
10.2.2 托管
10.2.3 高可用性与容错性
10.2.4 灾难恢复
10.2.5 能力规划
10.3 案例研究：Elixir系统的基础设施问题
10.4 小结
10.5 我们现在讲到什么地方了
10.6 参考资料
第11章 分析架构入门
11.1 为什么要做分析
11.2 进行数据分析所采用的维度
11.2.1 操作分析
11.2.2 描述性的分析
11.2.3 预测性的分析
11.2.4 指示性的分析
11.2.5 认知计算
11.3 分析架构的基础
11.3.1 分层视图中的各层及五大支柱
11.3.2 水平层
11.3.3 垂直层
11.3.4 五大支柱
11.4 架构构建块
11.4.1 数据类型层中的ABB
11.4.2 数据获取与访问层中的ABB
11.4.3 数据存储库层中的ABB
11.4.4 模型层中的ABB
11.4.5 数据集成与整合层中的ABB
11.4.6 分析解决方案层中的ABB
11.4.7 消费者层中的ABB
11.4.8 元数据层中的ABB
11.4.9 数据与信息安全层中的ABB
11.4.10 描述性的分析中的ABB
11.4.11 预测性的分析中的ABB
11.4.12 指示性的分析中的ABB
11.4.13 操作分析中的ABB
11.4.14 认知计算中的ABB
11.5 小结
11.6 参考资料
第12章 架构经验谈
12.1 各种敏捷开发观点应该加以融合
12.2 传统的需求收集技术过时了
12.3 MVP范式值得考虑
12.4 不要忙于应付各种事务
12.5 预测性的分析并不是唯一的分析切入点
12.6 领导能力也可以通过培养而获得
12.7 架构不应该由技术来驱动
12.8 开源软件很好，但要谨慎使用
12.9 把看似简单的问题总结起来
12.10 根据技术产品的核心优势来确定架构基线
12.11 小结
12.12 参考资料
附录A 25个实用小知识
附录B Elixir的功能模型（续）
4万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
