【编辑推荐】
NO.1 全球软件架构领域领军人物50年经验总结
NO.2 仅有的2次获得Jolt大奖的软件类著作
NO.3 在全球范围内被翻译为10余种文字
NO.4 卡内基·梅隆等多所世界名校选做教材
NO.5 豆瓣、B站、知乎高口碑作品
NO.6 被IEEE软件杂志评为“有史以来影响力的10本软件著作之一”
NO.7 内容系统全面，包含软件架构师需要的绝大部分硬技能和软技能
NO.8 注重实战，提供大量模式和解决方案，是架构师的工程行动指南
NO.9 与时具进，为云原生、分布式、移动系统等新技术场景提供架构方案
【内容简介】
本书着重讨论以下核心内容，并层层递进，逐步深入。
首先解释了什么是软件架构，为什么它很重要，以及如何以规范和有效的方式设计、实现、分析、演进和管理它。
其次系统阐述如何使用架构来应对需求和系统规模的加速增长，以及如何管理新增的质量属性。
后讲解如何利用架构优化关键质量属性（包括性能、可修改性、防护性、可用性、互操作性、可测试性、易用性、可部署性等），如何管理和优化现有架构，如何将它们用于解决新问题并构建成可作为战略资产的可重用架构。
【作者简介】
伦·巴斯（Len Bass）
全球软件架构和软件工程领域的领军人物，有超过50年的研发和教学经验，曾两次获得“Jolt生产力大奖”，成就卓著。计算机协会（ACM）、电气和电子工程师协会（IEEE）的会员；曾在卡内基梅隆大学软件工程研究所工作25年，担任高级首席研究院，专注于软件架构的分析；曾担任澳大利亚国家信息通信技术研究院（NICTA）高级主任研究员；有数十年的教学经验，曾在德克萨斯大学奥斯汀分校、奥克兰大学、马里兰大学帕克分校、新加坡国立大学担任计算机科学教授，教授软件架构和软件工程相关的课程。
因为其在软件架构领域的杰出贡献，曾获得ACM颁发的杰出论文奖、IEEE颁发的杰出教育奖，对全球的几代软件工程师产生了深远的影响。出版了多部软件架构方面的著作，其中的代表作《软件架构实践》被广泛认为是软件架构领域的开创性著作，于2010年被IEEE软件杂志评为“有史以来影响力的10本软件书籍之一”，两次获得Jolt大奖，在世界各地名校被广泛用作软件工程的教科书。
保罗·克莱门茨（Paul Clements）
资深软件架构专家和软件工程专家，是通用软件架构和产品线工程（PLE）领域的著名先锋人物，在软件领域有超过30年的实践和教学经验。全球产品线工程领域知名企业BigLever的副总裁，曾在卡内基·梅隆大学软件工程研究所担任高级技术人员近20年，在加利福尼亚大学欧文分校软件研究所担任访问科学家10余年，计算机协会（ACM）的高级会员和电气和电子工程师协会（IEEE）的会员。著有多本软件架构方面的著作，曾多次获得各类大奖，在软件架构领域影响深远。
瑞克·凯兹曼（Rick Kazman）
资深软件架构专家和软件工程专家，夏威夷大学的教授，卡内基·梅隆大学SEI的访问研究员，因为在软件架构的实践和教育方面做出了巨大贡献而闻名。参与创造了有影响力的架构分析方法和工具，包括SAAM、ATAM、CBAM、Dali和Titan，他在同行评审期刊和会议论文集上发表了 150 多篇文章，因其对软件工程研究和教育的贡献而获得了无数奖项，包括IEEE TCSE杰出教育奖和ACM SIGSOFT影响力教育家奖。
译者简介
周乐，曾供职于国有大型银行、头部证券公司，长期从事软件架构设计和企业架构管理工作。
特邀技术审校
茹炳晟，腾讯Tech Lead，腾讯研究院特约研究员，中国计算机学会(CCF)TF研发效能SIG主席，“软件研发效能宣言”发起人和主要起草人，著有《测试工程师全栈技术进阶与实践》《软件研发效能提升之美》《高效自动化测试平台:设计与开发实战》《软件研发效能提升实践》和《软件研发效能权威指南》等书，国内各大技术峰会的联席主席，出品人和Keynote演讲嘉宾。公众号“茹炳晟聊软件研发”作者。
【媒体评论】
读者评论
我是《软件架构实践》一书的忠实读者，20多年前我还是研究生的时候就读过它的第1版。我强烈推荐这本书给所有的软件工程师，无论你是经验丰富的还是刚刚入行的。第4版中的虚拟化、接口、移动性和云的新章节使我受益匪浅。
这是一本涵盖软件架构基础知识的宝典级图书，尤其是工程目标和质量属性，这在构建在线协作系统的架构时非常有用。此外，这本书经过二十多年的四次版本更新，易读性一直是它带给读者的惊喜，在讨论新产品/现有产品的结构时使用这本书会令你事半功倍。
《软件架构实践》是架构标准化和软件体系结构方面的经典图书，作者对软件架构进行了广泛而全面的概述。这本书的案例研究也是一大特色，可帮助软件架构师实现企业IT体系架构设计。
这本书涵盖了软件架构整个生命周期的方方面面，是能为任何软件架构项目（无论多么复杂）提供专家方法和测试模型的实用指南。
这本书内容丰富，帮助我为软件架构工作开发了更好的量化技术，我将这本书卡耐基梅隆大学的在线软件架构课程结合使用，
通过这本书，你不仅掌握什么是架构、架构的影响，更是能掌握如何评估架构质量。
【目录】
部分 入门介绍
第1章 什么是软件架构 1
1.1 什么是软件架构，什么不是软件架构 2
1.2 架构结构与视图 5
1.3 什么是“好的”架构 19
1.4 总结 21
1.5 进一步阅读 21
1.6 问题讨论 22
第2章 软件架构的重要性 25
2.1 抑制或支持系统的质量属性 26
2.2 关于变更的推理和管理 27
2.3 预测系统质量 28
2.4 利益相关者之间的沟通 28
2.5 早期设计决策 31
2.6 实现约束 31
2.7 对组织结构的影响 32
2.8 赋能增量开发 33
2.9 成本和进度估算 33
2.10 可转移、可重用模型 34
2.11 架构允许合并独立开发的元素 34
2.12 限制设计方案的术语 35
2.13 培训的基础 36
2.14 总结 36
2.15 进一步阅读 37
2.16 问题讨论 37
第二部分 质量属性
第3章 理解质量属性 39
3.1 功能性 40
3.2 质量属性注意事项 41
3.3 明确质量属性需求：质量属性场景 42
3.4 通过架构模式和战术实现质量属性 45
3.5 用战术设计 46
3.6 分析质量属性的设计决策：基于战术的调查问卷 48
3.7 总结 49
3.8 进一步阅读 49
3.9 问题讨论 50
第4章 可用性 51
4.1 可用性通用场景 53
4.2 可用性战术 55
4.3 基于战术的可用性调查问卷 62
4.4 可用性模式 66
4.5 进一步阅读 68
4.6 问题讨论 69
第5章 可部署性 71
5.1 持续部署 72
5.2 可部署性 75
5.3 可部署性通用场景 76
5.4 可部署性战术 78
5.5 基于战术的可部署性调查问卷 80
5.6 可部署性模式 81
5.7 进一步阅读 87
5.8 问题讨论 87
第6章 能源效率 89
6.1 能源效率通用场景 90
6.2 能源效率战术 92
6.3 基于战术的能源效率调查问卷 95
6.4 模式 97
6.5 进一步阅读 98
6.6 问题讨论 99
第7章 可集成性 101
7.1 评估架构的可集成性 102
7.2 可集成性通用场景 104
7.3 可集成性战术 105
7.4 基于战术的可集成性调查问卷 110
7.5 模式 112
7.6 进一步阅读 114
7.7 问题讨论 115
第8章 可修改性 117
8.1 可修改性通用场景 120
8.2 可修改性战术 121
8.3 基于战术的可修改性调查问卷 125
8.4 模式 126
8.5 进一步阅读 130
8.6 问题讨论 131
第9章 性能 133
9.1 性能通用场景 134
9.2 性能战术 137
9.3 基于战术的性能调查问卷 145
9.4 性能模式 146
9.5 进一步阅读 149
9.6 问题讨论 150
第10章 安全性 151
10.1 安全性通用场景 154
10.2 安全性战术 156
10.3 基于战术的安全性调查问卷 160
10.4 安全性模式 163
10.5 进一步阅读 165
10.6 问题讨论 166
第11章 防护性 169
11.1 防护性通用场景 170
11.2 防护性战术 172
11.3 基于战术的防护性调查问卷 176
11.4 防护性模式 179
11.5 进一步阅读 180
11.6 问题讨论 180
第12章 可测试性 183
12.1 可测试性通用场景 186
12.2 可测试性战术 187
12.3 基于战术的可测试性调查问卷 192
12.4 可测试性模式 192
12.5 进一步阅读 194
12.6 问题讨论 195
第13章 易用性 197
13.1 易用性通用场景 198
13.2 易用性战术 200
13.3 基于战术的易用性调查问卷 202
13.4 易用性模式 203
13.5 进一步阅读 205
13.6 问题讨论 205
第14章 使用其他质量属性 207
14.1 其他质量属性 207
14.2 是否使用标准质量属性清单 209
14.3 处理“X能力”：引入新的QA 212
14.4 进一步阅读 215
14.5 问题讨论 215
第三部分 架构解决方案
第15章 软件接口 217
15.1 接口的概念 218
15.2 设计一个接口 222
15.3 接口文档编制 228
15.4 总结 230
15.5 进一步阅读 230
15.6 问题讨论 231
第16章 虚拟化 233
16.1 共享资源 234
16.2 虚拟机 235
16.3 虚拟机映像 238
16.4 容器 239
16.5 容器和虚拟机 241
16.6 容器可移植性 242
16.7 Pod 242
16.8 无服务器架构 243
16.9 总结 244
16.10 进一步阅读 245
16.11 问题讨论 245
第17章 云和分布式计算 247
17.1 云基础 248
17.2 云中失效 251
17.3 使用多个实例提高性能和可用性 253
17.4 总结 261
17.5 进一步阅读 262
17.6 问题讨论 262
第18章 移动系统 263
18.1 能源 264
18.2 网络连通性 266
18.3 传感器和执行器 267
18.4 资源 268
18.5 生命周期 270
18.6 总结 273
18.7 进一步阅读 274
18.8 问题讨论 275
第四部分 可扩展架构实践
第19章 架构上的重要需求 277
19.1 从需求文档中收集ASR 278
19.2 通过访谈利益相关者收集ASR 279
19.3 通过理解业务目标收集ASR 282
19.4 在工具树中捕获ASR 284
19.5 发生了变化 286
19.6 总结 286
19.7 进一步阅读 287
19.8 问题讨论 287
第20章 设计架构 289
20.1 属性驱动的设计 289
20.2 ADD步骤 292
20.3 ADD步骤4的进一步说明：选择一个或多个设计概念 295
20.4 ADD步骤5的进一步说明：生成结构 298
20.5 ADD步骤6的进一步说明：在设计过程中创建初步文档 301
20.6 ADD步骤7的进一步说明：对当前设计进行分析并审查迭代目标和设计目的实现情况 304
20.7 总结 306
20.8 进一步阅读 306
20.9 问题讨论 307
第21章 架构评估 309
21.1 评估作为一项降低风险的活动 309
21.2 主要的评估活动 310
21.3 谁能执行评估 311
21.4 环境因素 312
21.5 架构权衡分析方法 313
21.6 轻量级架构评估 324
21.7 总结 326
21.8 进一步阅读 327
21.9 问题讨论 327
第22章 记录一个架构 329
22.1 架构文档的用途和受众 330
22.2 符号 331
22.3 视图 332
22.4 合并视图 339
22.5 记录的行为 340
22.6 视图以外 345
22.7 记录基本原理 346
22.8 架构利益相关者 347
22.9 实际问题 350
22.10 总结 353
22.11 进一步阅读 353
22.12 问题讨论 354
第23章 管理架构债 355
23.1 确定是否存在架构债问题 356
23.2 发现热点 358
23.3 示例 362
23.4 自动化 363
23.5 总结 364
23.6 进一步阅读 364
23.7 问题讨论 365
第五部分 架构和组织
第24章 架构师在项目中的角色 367
24.1 架构师和项目经理 367
24.2 增量架构和利益相关者 369
24.3 架构和敏捷开发 370
24.4 架构和分布式开发 373
24.5 总结 376
24.6 进一步阅读 376
24.7 问题讨论 377
第25章 架构能力 379
25.1 个人能力：架构师的职责、技能和知识 379
25.2 软件架构组织的能力 386
25.3 成为更好的架构师 387
25.4 总结 388
25.5 进一步阅读 388
25.6 问题讨论 389
第六部分 结论
第26章 展望未来：量子计算 391
26.1 单量子位 392
26.2 量子隐形传态 394
26.3 量子计算和加密 394
26.4 其他算法 395
26.5 潜在应用 396
26.6 后的想法 397
26.7 进一步阅读 398
参考资料 399
【前言】
◆ 译者序◆
在比尔·盖茨的众多称谓中，据说他更偏爱“首席软件架构师”。在网易创始人丁磊名字前，也有“首席架构师”这样的称谓。架构师是如此重要，以至于在《黑客帝国》中各色人物悉数登场，后你却发现这一切都是被一个称作“架构师”的白胡子老头左右的。
这是否意味着要成为架构师就要以“领导”权威来支撑或者以时间或实践来积累？当然不必这样，在修炼成“架构师”的道路上，一本好书能让你少走许多弯路，帮助你学会“架构师”思维，快速进入“架构师”角色。
随着数字时代的到来，各种云基础设施、微服务、框架层出不穷，互联和互操作变得唾手可得，集成和重用已有成果成为软件开发常态。在软件系统变得越来越复杂的同时，今天架构师似乎不再需要架构知识了，甚至软件开发的精髓被调侃是“Ctrl C和Ctrl V”。显然，在已有的架构上实现二次架构设计并不是架构师的未来，我们既要站在巨人的肩膀上，善于利用后发优势，更需要从原始创新上取得突破，这就需要你回到问题的原点，系统地掌握软件架构的知识，努力贡献优秀的原创架构。
《软件架构实践》就是这样一本书。本书是其第4版，在软件架构领域，本书已经成为标准。软件架构的术语或知识，大都可以在这本书中找到相关内容和准确的定义。
本书共分为六个部分。部分对软件架构进行了定义，并从13个方面揭示软件架构的重要性，希望这13个方面能激起你学习软件架构的兴趣。第二部分是关于质量属性的，你如果还分不清“可用性”（availability）和“易用性”（usability）的差别，或觉得“安全性”（safety）和“防护性”（security）就是一回事，那么应该仔细看看这一部分。这部分对10个颇具代表性的质量属性进行了全面介绍，给出了一种通用形式来描述质量属性，介绍了每个质量属性要关注的问题并给出了现成的“解决方案”，你甚至可以直接把这些知识运用到你当前的设计中去。第三部分具有很强的时代感，紧密结合当前流行的技术，包括虚拟化、云计算和移动技术，介绍了当下架构解决方案要关注的内容。第四部分是可扩展架构实践，为设计架构、评估架构和记录架构等活动提供了可操作的工程方法，旨在为完成这些复杂的架构活动提供指南，帮助普通人学习并熟练地完成架构相关工作。如果面对复杂设计你还不知从何下手，则完全可以按照书中介绍的工程方法和交付样式“照猫画虎”，相信通过亲自实践你会掌握书中方法的精髓。第五部分全面介绍了架构师在组织中的角色和应具备的能力，架构师不能活在象牙塔里，这部分知识可以让你根据个人的情况和组织的发展要求，找到自己的努力方向，理解相关处境，做出正确选择。后一部分介绍了的量子计算，并思考了其可能对架构的影响，也算是为读者留下一些悬念。
本书可以作为架构师的工具书，你不必从头开始，根据遇到的问题，找到相应章节就可以得到参考架构解决方案。你也可以把它当作工程行动指南，面对复杂问题，按照其中介绍的方法采取相应行动即可。本书将理论和实践紧密结合，如果你的单位很重视架构，但存在曲高和寡的现象，建议你单位的项目经理和架构师好好阅读一下本书。
◆ 前言 ◆
当我们开始编写本书第4版时，遇到的个问题是：架构还重要吗？随着云基础设施、微服务、框架和每个可能想象的领域以及质量属性的参考架构的兴起，人们可能会认为不再需要架构知识了。今天的架构师需要做的就是从丰富的工具和基础设施备选方案中选一个，实例化并配置它。瞧！一个架构就完成了。
我们过去（和现在）非常肯定这不是真的。诚然，我们有些偏见。因此，我们采访了一些在医疗保健、汽车、社交媒体、航空、国防、金融、电子商务等领域工作的架构师，他们都没有被教条的偏见所左右。我们所听到的证实了我们的信念，即架构在今天和20多年前（我们编写第1版时）一样重要。
我们来研究一下其中的一些原因。首先，新需求出现的速度多年来一直在加快，甚至还在持续加快。在客户和业务需求以及竞争压力的驱动下，今天的架构师面临着连续且不断增加的特性需求和要修复的bug等问题。如果架构师不重视系统的模块化（请记住微服务不是的），系统很快就会变得难以理解、变更、调试和修改，并拖累业务。
其次，当系统的抽象级别在增加时（我们可以并且确实经常使用许多复杂巧妙的服务，而不用关心它们是如何实现的），我们创建的系统的复杂性也在以同样的速度增加。这像一场军备竞赛，而架构师并没有获胜！架构一直致力于“驯服”复杂性，而这种情况在短期内是不会消失的。
说到提高抽象级别，基于模型的系统工程（Model-Based Systems Engineering，MBSE）在过去十年左右的时间里已经成为工程领域的一股强大力量。MBSE是一种形式化的支持系统设计的建模应用。国际系统工程理事会(InterNational Council On Systems Engineering，INCOSE)将MBSE列为一组“转型赋能者”之一，它是整个系统工程学科的基础。模型是对一个可以被推理的概念或结构进行的图形、数学或物理化表示。INCOSE正试图将工程领域从基于文档的思维转向基于模型的思维，其中结构模型、行为模型、性能模型等都被持续用于更好、更快、更便宜地构建系统。MBSE本身已经超出了本书的范围，但是我们不得不注意到正在被建模的是架构。那谁建立模型呢？答案是架构师。
再次，信息系统世界的飞速发展（以及前所未有的员工流动率）意味着，在任何现实世界的系统中，没有人了解一切。仅仅聪明和努力是不够的。
后，尽管有工具可以自动完成过去需要自己做的许多事情（例如Kubernetes中所有的编排、部署和管理功能），但仍然需要理解所依赖的系统的质量属性，当我们把系统组合在一起时，需要理解随之而来的质量属性。大多数质量属性（防护性、可用性、安全性等）都容易受到“短板”问题的影响，而“短板”问题只有在联调系统时才会出现并影响我们。如果没有引领者来避免灾难，联调很可能会失败，而这正是架构师的工作。
考虑到这些因素，我们觉得确实需要这本书。
但有必要推出第4版吗？当然有必要了！自上一版出版以来，计算机领域发生了很大变化，一些之前没有被考虑的质量属性已在许多架构师的日常实践中变得越来越重要。随着软件继续渗透到社会的各个方面，对许多系统（如无人驾驶系统）来说，安全性已经变得至关重要。同样，十年前很少有架构师会考虑能源效率这一质量属性，但现在从对能源有不可抑制需求的大型数据中心到我们周围的小型（甚至很小的）电池驱动的移动和物联网设备都必须考虑。此外，考虑到我们比以往任何时候都更多地利用现有的组件来构建系统，可集成性这一质量属性也越来越引起我们的注意。
后，我们正在构建不同种类的系统，并且以不同于十年前的方式构建它们。现在的系统通常构建在云中的虚拟化资源之上，它们需要提供并依赖显式接口。此外，它们的移动性越来越强，移动性带来的机遇和挑战也越来越多。因此，在第4版中，我们增加了关于虚拟化、接口、移动性和云的章节。
如你所见，我们说服了自己。希望我们同样说服了你，你会发现第4版会使你受益匪浅。
致谢
我们对所有与我们合作编写本书的人深表感谢。
首先，我们要感谢各章节的合著者，他们在这些领域的知识和洞察力是无价的。感谢卢加诺大学信息学院的Cesare pautasso教授、西门子移动系统公司的Yazid Hamdi、谷歌的Greg Hartman、伊斯塔帕拉帕市自治大学的Humberto Cervantes，以及德雷塞尔大学的Yuanfang Cai。感谢卡内基–梅隆大学软件工程研究所的Eduardo Miranda，他写了一篇关于“信息技术价值”的文章。
优秀的审稿对于优秀的作品来说是必不可少的，我们很幸运地请到了John Hudak、Mario Benitez、Grace Lewis、Robert Nord、Dan Justice和Krishna Guru来改进本书的内容。感谢James Ivers和Ipek Ozkaya从软件工程SEI系列的角度审阅本书。
多年来，我们从与同事的讨论和合作写作中受益，感谢他们。除了已经提到的，我们还要特别感谢David Garlan、Reed Little、Paulo Merson、Judith Stafford、Mark Klein、James Scott、Carlos Paradis、Phil Bianco、Jungwoo Ryoo和Phil Laplante。特别感谢John Klein，他以多种方式为本书的许多章节做出了贡献。
此外，我们还要感谢Pearson的每一位员工，感谢他们的辛勤工作，正是他们对无数细节的关注，才将我们的文字转化成你现在正在阅读的图书。尤其要感谢Haze Humbert，他监督了整个出版过程。
后，感谢许多研究人员、教师和实践者，他们多年来一直致力于将软件架构从一个好的想法转变为一门工程学科。本书是奉献给他们的。
