软件架构：架构模式、特征及实践指南

适读人群 ：有志成为软件架构师的软件开发人员

全球范围内的薪酬调查经常将软件架构师列为十大最佳工作岗位，但并没有真正的指南来帮助开发人员成为架构师。于是，本书出现了。本书首次全面概述了软件架构的方方面面，涉及架构特征、架构模式、组件识别、图表化和展示架构、演进架构，以及其他许多主题。

软件开发世界日新月异，软件架构师必须在这样一个不断变化的环境中做出决策，在学习架构时，必须记住一点：与许多艺术品一样，架构只能在上下文中理解。架构师的许多决策都基于他们所处的实际环境而产生。

Mark Richards和Neal Ford讲授软件架构课程多年，他们关注的是适用于所有技术栈的架构原则。本书从现代的角度看待软件架构，综合了过去十年的所有创新，以及一些适用于当下的新结构和视角的新的度量标准和方法。本书还讨论了至关重要的权衡分析问题。本书为现有和新兴的架构（从结构到软技能等方面）提供一个良好的现代化软件架构概览。

本书将探讨：

架构模式：众多架构决策的技术基础。

组件：识别、耦合、内聚、分区和粒度。

软技能：有效的团队管理、会议、谈判、展示等。

现代化：在过去的几年里，工程实践和操作方法发生了根本性的变化。

作为工程学科的架构：可重复的结果、度量和具体的评估增加了软件架构的严谨性。

本书全面概述了软件架构的方方面面，涉及架构特征、架构模式、组件识别、图表化和展示架构、演进架构，以及许多其他主题。本书分为三部分。

第1部分介绍关于组件化、模块化、耦合和度量软件复杂度的基本概念和术语。

第2部分详细介绍各种架构风格：分层架构风格、管道架构风格、微内核架构风格、基于服务的架构风格、事件驱动的架构风格、基于空间的架构风格、编制驱动的面向服务的架构、微服务架构。

第3部分介绍成为一个成功的软件架构师所必需的关键技巧和软技能。

★Mark Richards是一位经验丰富的软件架构师，他参与了微服务架构、事件驱动架构和其他分布式架构的架构、设计和实现。

★Neal Ford在ThoughtWorks担任总监、软件架构师和meme wrangler。ThoughtWorks是一家专注于端到端软件开发和交付的全球IT咨询公司。Neal也担任过DSW集团的首席技术官。

他是《卓有成效的程序员》一书的作者。

★Neal和Mark不仅是杰出的软件架构师，也是无与伦比的老师。他们汇聚几十年经验，成功地将架构的庞大主题浓缩为本书。无论你是新人还是有多年实践经验的架构师，本书都将帮助你更好地完成工作。我多么希望在我职业生涯的初期就能看到这本书。

—Nathaniel Schutta，ntschutta.io架构师

★Mark和Neal开始着手实现一个令人生畏的目标—阐明在软件架构中取胜所必需的众多分层的基本原理—并且完成了任务。软件架构领域仍在不断发展，而架构师这个角色需要在知识和技能方面兼具令人咂舌的广度和深度。本书将成为许多人掌握软件架构的向导。

—Rebecca J. Parsons，ThoughtWorks CTO

★Mark和Neal为技术人员推动架构的卓越性提供了真实世界的建议。他们通过指出共同的架构特征和驱动成功所必需的权衡来实现这一点。

—Cassie Shum，ThoughtWorks技术总监

★软件架构不是一门技术，而是一门艺术。世界上没有哪所大学培养软件架构师，软件架构师的成长一般是通过长期的软件工程实践经验提炼而来。拥有一位优秀的软件架构师是任何一个企业负责人，特别是CTO梦寐以求的事情。在我个人的CTO生涯中，总是在寻找、观察和培养优秀的软件架构师。我感觉本书帮了世界上所有CTO一个大忙，因为它为CTO成功解决了培养软件架构师的一些问题。我强烈推荐有志成为软件架构师的工程师认真学习本书。

—陈斌，NETSTARS CTO

前言：失效的公理1

第1章 概述5

1.1 定义软件架构7

1.2 架构师的角色期望10

1.3 与架构的交集14

1.4 软件架构定律19

【第一部分 基础21】

第2章 架构思维23

2.1 架构与设计24

2.2 技术广度25

2.3 分析权衡28

2.4 理解业务驱动因素31

2.5 平衡架构和动手编码31

第3章 模块化34

3.1 定义34

3.2 度量模块化36

3.3 从模块到组件48

第4章 现有的架构特征49

4.1 部分已罗列出来的架构特征51

4.2 权衡和最差可用的架构56

第5章 识别架构特征57

5.1 从领域问题中提取架构特征57

5.2 从需求中提取架构特征59

5.3 案例研究：硅三明治60

第6章 度量和治理架构特征66

6.1 度量架构特征66

6.2 治理和适应度函数70

第7章 架构特征的范围76

7.1 耦合与共生性76

7.2 架构量子与粒度77

第8章 组件化思维83

8.1 组件范围83

8.2 架构师角色84

8.3 开发人员角色90

8.4 组件识别流程90

8.5 组件粒度91

8.6 组件设计92

8.7 案例研究：“前进，前进，消失”之发现组件94

8.8 架构量子回归：单体架构和分布式架构之间的选择96

【第二部分 架构风格99】

第9章 基础101

9.1 基础模式101

9.2 单体架构与分布式架构104

第10章 分层架构风格112

10.1 拓扑结构112

10.2 分层隔离性113

10.3 增加分层114

10.4 其他考虑116

10.5 为什么使用这种架构风格116

10.6 架构特征评级117

第11章 管道架构风格119

11.1 拓扑结构119

11.2 示例121

11.3 架构特征评级122

第12章 微内核架构风格124

12.1 拓扑结构124

12.2 注册129

12.3 契约130

12.4 示例和用例131

12.5 架构特征评级132

第13章 基于服务的架构风格134

13.1 拓扑结构134

13.2 拓扑结构变体135

13.3 服务设计和粒度137

13.4 数据库分区138

13.5 架构示例139

13.6 架构特征评级141

13.7 何时使用这种架构风格143

第14章 事件驱动的架构风格144

14.1 拓扑结构145

14.2 代理拓扑145

14.3 中介拓扑149

14.4 异步能力156

14.5 错误处理157

14.6 防止数据丢失160

14.7 广播功能162

14.8 请求-应答163

14.9 在基于请求和基于事件之间进行选择165

14.10 混合的事件驱动的架构166

14.11 架构特征评级166

第15章 基于空间的架构风格169

15.1 常规拓扑结构170

15.2 数据冲突179

15.3 云实现与预置实现181

15.4 复制缓存与分布式缓存182

15.5 近缓存中的注意事项184

15.6 实现示例185

15.7 架构特征评级186

第16章 编制驱动的面向服务的架构188

16.1 历史和哲学188

16.2 拓扑结构188

16.3 分类189

16.4 重用与解耦191

16.5 架构特征评级193

第17章 微服务架构195

17.1 历史195

17.2 拓扑结构196

17.3 分布式196

17.4 有界上下文197

17.5 API层198

17.6 运维重用199

17.7 前端201

17.8 通信202

17.9 架构特征评级209

17.10 附加参考210

第18章 选择合适的架构风格211

18.1 改变架构“时尚”211

18.2 决策标准212

18.3 单体案例研究：硅三明治214

18.4 分布式案例研究：前进，前进，消失216

【第三部分 技巧和软技能221】

第19章 架构决策223

19.1 架构决策反模式223

19.2 具备架构意义225

19.3 架构决策记录226

第20章 分析架构风险235

20.1 风险矩阵235

20.2风险评估236

20.3 风险风暴238

20.4 敏捷用户故事的风险分析244

20.5 风险风暴范例244

第21章 架构绘图和演示250

21.1 绘图251

21.2 演示255

第22章 打造高效团队259

22.1 团队边界259

22.2 架构师的个性260

22.3 有多少控制力263

22.4 团队告警信号267

22.5 利用检查清单269

22.6 提供指导273

22.7 总结275

第23章 谈判和领导能力276

23.1 谈判和推进276

23.2 软件架构师作为领导者281

23.3 与开发团队集成287

23.4 总结289

第24章 打造职业发展路径290

24.1 20分钟规则290

24.2 开发个人雷达291

24.3 使用社交媒体295

24.4 临别赠言296

附录A 自我评估问题297

关于作者

关于封面

公理：被认为已经成立、被采纳或不证自明的真理的陈述或命题。

数学家在公理（即对事物无可争议的假设）的基础上建立理论。软件架构师也将理论建立在公理之上，但是软件世界比数学世界要更加“软性”：基础的事物持续快速变化，甚至包括我们的理论所基于的公理。

软件开发生态系统处于一个恒定的动态平衡状态：尽管在任何给定的时间点都处于平衡状态，但在长期内表现出动态行为。当下容器化的提升及其产生的变化能够很好地说明生态系统的这一特质：像Kubernetes这样的工具在十年前还不存在，但是现在甚至有了Kubernetes用户大会。软件生态系统的变化是混沌的：一个小变化引起另一个小变化，如此重复数百次就会产生一个新的生态系统。

架构师有一个重要的责任，即质疑从过去的年代遗留下来的假设和公理。许多关于软件架构的书籍都是在一个与当今世界几乎没有什么相似之处的年代写成的。事实上，作者认为，我们必须经常质疑基本公理：从改进的工程实践、可操作的生态系统、软件开发过程的角度—在架构师和开发人员日常工作中产生混乱、动态平衡的方方面面。

随着时间的推移，细心观察软件架构的人见证了其能力的演变。从极限编程的工程实践开始，继之以持续交付、DevOps革命、微服务、容器化，现在则是云资源，所有这些创新都带来了新的能力和权衡。随着能力的变化，架构师对行业的看法也发生了变化。多年来，软件架构的半开玩笑的定义是“以后很难改变的东西”。后来出现了微服务架构风格，变化则是最重要的设计考虑因素。

每个新时代都需要新的实践、工具、度量、模式和一系列其他变化。本书从现代的角度看待软件架构，综合了过去十年的所有创新，以及一些适用于当下的新结构和视角的新的度量标准和方法。

长期以来，开发人员一直希望将软件开发从手工活（熟练的工匠只能产生一次性的工作）转变为工程学科，这意味着可重复性、严谨性和有效的分析。尽管软件工程相比其他类型的工程学科仍然落后许多个数量级（公平地说，与大多数其他类型的工程相比，软件工程是一个非常年轻的学科），架构师已经做出了巨大的改进，我们将对此进行讨论。特别是，现代敏捷工程实践在系统类型方面的架构设计上取得了很大进展。

我们还讨论了至关重要的权衡分析问题。软件开发人员很容易迷恋某种特定的技术或方法。但是，架构师必须总是冷静地评估每一个选择的好与坏、美与丑，实际上，在现实世界中没有什么东西能提供完美的二元选择—一切都是权衡。鉴于这种实用主义的观点，我们努力消除对技术的价值判断，专注于分析权衡，让读者带着审视的眼光进行技术选择。

本书不会让人一夜之间成为一个软件架构师—软件架构是一个包括很多方面的微妙领域。我们希望为现有的和新兴的架构（从结构到软技能等方面）提供一个良好的现代化软件架构概览。虽然本书涵盖了众所周知的模式，但依靠所获得的经验教训、工具、工程实践和其他输入，我们采用了一种新的方法。我们将现代化的轮廓考虑在内，借鉴了软件架构中的许多现有公理，根据当前的生态系统重新思考它们，并设计架构。