三位著名的软件架构师的新版著作,阐述了软件架构师如何管理和优化现有体系结构,转换它们以解决新问题,并构建可重用的体系结构,使之成为战略业务资产。更新了移动,云,能源管理,DevOps,量子计算等新内容
当开始编写本书第4版时,我们遇到的个问题是:架构还重要吗?随着云基础设施、微服务、框架和每个可能想象的领域以及质量属性参考架构的兴起,人们可能会认为不再需要架构知识了。今天的架构师需要做的就是从丰富的工具和基础设施备选方案中选一个,再将它们实例化并加以配置,一个架构就完成了。
我们过去(以及现在)非常肯定架构仍然重要。为此,我们采访了一些架构师(他们在医疗保健、汽车、社交媒体、航空、国防、金融、电子商务等领域工作),他们谁也没有被教条的偏见所左右。他们的回答证实了我们的信念,即架构在今天和20多年前我们编写第1版时一样重要。
让我们来研究一下架构仍然重要的原因。,新需求的增长速度多年来一直在加快,甚至现在还在继续加快。在客户和业务需求以及竞争压力的驱动下,今天的架构师面临着不断增加的特性需求和永无休止的待修复bug。如果架构师不注意系统的模块化(而且请记住微服务不是的),系统很快就将抛锚—难以理解、变更、调试和修改,并拖累业务。
第二,当系统的抽象级别在增加时(我们可以并且确实经常使用许多复杂巧妙的服务,而不用关心它们是如何实现的),我们创建的系统的复杂性也在以同样快的速度增加。这像一场军备竞赛,而架构师并没有获胜!架构一直致力于驯服复杂性,而这一点在短期内是不会消失的。
说到提高抽象级别,基于模型的系统工程(Model-Based Systems Engineering,MBSE)在过去10年的时间里已经成为工程领域的一股强大力量。MBSE是一种形式化的支持系统设计的建模应用。国际系统工程理事会(International Council on Systems Engineering,INCOSE)将MBSE列为“转型赋能者”之一,它是整个系统工程学科的基础。模型是对一个可以被推理的概念或结构进行图形化、数学化或物理化表示。INCOSE正试图将工程领域从基于文档的思维转向基于模型的思维,其中结构模型、行为模型、性能模型等都被持续用于更好、更快、更便宜地构建系统。MBSE本身已经超出了本书的范围,但是我们不得不注意到正在被建模的是架构。那谁建立模型呢?回答是:架构师。
第三,信息系统世界的飞速增长(以及前所未有的员工流动率)意味着,在任何现实世界的系统中,没有人了解一切。仅仅聪明和努力是不够的。
第四,尽管工具可以自动完成我们过去人工做的许多事情(例如Kubernetes中所有的编排、部署和管理功能),但我们仍然需要理解所依赖的这些系统的质量属性,并在把系统组合到一起时理解突现的质量属性。大多数质量属性(如性能、防护性、可用性、安全性等)都容易受到“短板”问题的影响,而这些短板只有在联调系统时才会出现并影响我们。如果没有指路之手来避免灾难,联调很可能会失败。那只指路之手属于架构师,不论他们的头衔是什么。
考虑到这些因素,我们觉得确实需要这本书。
但有必要推出第4版吗?当然有必要!这应该是非常明显的。自上一版出版以来,计算机领域发生了很大变化。一些之前没有被考虑的质量属性在许多架构师的日常实践中变得重要。随着软件继续渗透到社会的各个方面,对许多系统来说,安全性考虑已经变得至关重要,如软件控制驾驶的汽车。同样,十年前,能源效率是少数架构师考虑的质量属性,但现在必须注意它,从对能源有强烈需求的大型数据中心到我们周围的小型(甚至很小的)电池驱动的移动和物联网设备。此外,考虑到我们比以往任何时候都更多地利用现有的组件来构建系统,可集成性的质量属性正在消耗我们越来越多的注意力。
后,我们正在构建不同种类的系统,并且以不同于10年前的方式构建它们。现在的系统通常构建在云中的虚拟化资源之上,它们需要提供并依赖显式接口。此外,它们的移动性越来越强,移动性带来的机遇和挑战也越来越多。因此,在这个版本中,我们增加了关于虚拟化、接口、移动性和云的章节。
如你所见,我们说服了自己。希望我们同样说服了你,你会发现第4版对你的书架是一个有用的补充。
部分 入门介绍
第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能力”:引入新的QA212
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 Pod242
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 从需求文档中收集ASR278
19.2 通过访