软件架构设计：大型网站技术架构与业务架构融合之道-图书

推荐0
收藏10
浏览4.3K

软件架构设计：大型网站技术架构与业务架构融合之道

余春龙 (作者)　宋亚东 (责任编辑)

书　　号：978-7-121-35603-2
出版日期：2019-02-01
页　　数：256
开　　本：16(185*235)
出版状态：上市销售
维护人：宋亚东

电子书￥49.00

购买电子书

纸质版￥79.00

本书系统化地阐述了技术架构与业务架构的方法论与实践。本书内容分为5大部分，第1部分从行业背景出发定义架构的概念与范畴；第2部分细致讨论架构所需的计算机功底，包括编程语言、操作系统、数据库、网络、框架、中间件；第3部分从高并发、高可用、稳定性、分布式事务、Paxos/Raft一致性算法、CAP理论等方面探讨技术架构；第4部分从业务架构思维、微服务、领域驱动设计、技术架构与业务架构融合的角度探讨业务架构；第5部分从个人素质、团队能力两大方面，诠释从技术到管理的转变方法。通过本书，读者可以对大型业务系统的架构方法论有全局的认识，同时对软件架构的核心能力有深刻的理解，对个人的技术成长起到一定的借鉴作用。
本书不仅适合工程师、架构师阅读，也适合企业系统开发人员在内的软件开发从业人员阅读。

自成一派的架构设计方法论，教你体系化的架构设计思维。

余春龙，中科院软件所计算机硕士毕业。热衷于高并发高可用架构、业务建模、领域驱动设计，在十年的工作中，经历过游戏、社交、广告、电商等各种类型的项目，积累了较丰富的工程经验。

当我在撰写本书时，脑海中曾浮现出当初上学期间一个劲儿地啃UML建模、软件架构设计书籍的情景。对于一个没有太多项目经验的人来说有点可笑，但也正是这种“过早熏陶”，使得我之后在工作中接手一个个项目时，会“多想”一些架构方面的事情。
为什么说是“多想”了呢？因为无论在企业面试还是日常工作中，人们更多谈论的是语言、数据结构、算法、操作系统原理，框架或中间件的使用方式、原理等“硬”性的内容，因为这些“硬”性的内容比较容易表述，其中学问的深浅也容易衡量。而对于软件建模、架构设计等“软”性的内容，就不容易衡量了。人们都知道它们很重要，但又说不清楚里面到底包含了哪些学问，所以谈论这些内容时通常都比较“虚”，最终导致很少从方法论的角度去讲，而是在项目中遇到问题时再具体解决，属于实用主义思维的做法。
另一方面，随着互联网技术的发展，很多大型网站或系统要处理海量的用户访问，需要解决高并发、高可用和由此带来的数据一致性问题，这也使得大家把大部分精力都用在解决这些问题上。这些问题可以被称为“显性问题”，因为如果解决不好，会造成系统宕机，用户体验受损，给企业带来严重损失，人们能意识到这种问题很重要。解决的思路通常有两个：第一，利用分布式系统的特性不断地分拆，把大系统拆小，各个击破，降低风险；第二，小步快跑，快速迭代。
但还有一类问题是“隐性问题”，是指系统的可重用性、可扩展性、可维护性等。因为一个系统由于设计问题导致研发人力的投入和时间成本的增加，往往无法显性地衡量。也可能并非系统设计得不好，而是业务本身就很复杂，或者各部门之间的沟通协调问题导致开发效率低。即便系统设计得不好，做新功能有沉重的历史包袱，也能依靠加班加点解决。但其实“隐性问题”比“显性问题”的影响更大，因为它会让技术拖累业务，当有新需求的时候，系统无法跟随业务快速变化。
所以，本书不想偏废两者中的任意一个。因为对于一个系统来说，可能既面临高并发、高可用的技术问题，又面临复杂的业务问题，所以如何处理两者的关系，打通技术和业务的任督二脉，是本书想要探讨的内容。
架构是一种综合能力，而不是某一方面的技能。也正因为如此，本书提供的是一个全面的解决方案、方法论、成体系的设计思维。本书从基础技术谈起，之后到高层技术，再到业务、管理，提供一个架构能力的全局视图，从而诠释一个架构师的完整能力模型。
具体来说，全书分为5大部分：
第1部分：从行业背景出发，对架构做一个宏观概述，阐述架构是什么。
第2部分：计算机功底。功底非常重要，这是做架构的基本门槛。大学的教科书上教的全是功底，但经过多年实践之后，再回过头看书本内容，会有新的理解和体会。
第3部分：技术架构。这部分是纯技术，讲解如何应对高并发、高可用、一致性方面的问题。
第4部分：业务架构。如何从技术延展到业务，如何跳出技术细节抽象思考问题，如何通过业务建模把技术和业务进行融合。
第5部分：从职业发展的角度，从技术延展到管理。建立对公司、商业、团队管理的一些认知。
对于刚入行的新人，建议从头看到尾，从而对架构的能力体系有一个全面的认知；对于有经验的从业者，可以选取自己感兴趣的章节阅读。
由于编写时间紧张，书中难免存在不足之处，望广大读者批评指正。

目录

第1部分什么是架构
第1章五花八门的架构师职业 2
1.1 架构师职业分类 2
1.2 架构的分类 2

第2章架构的道与术 5
2.1 何为道，何为术 5
2.2 道与术的辩证关系 6
第2部分计算机功底

第3章语言 10
3.1 层出不穷的编程语言 10
3.2 精通一门语言 10

第4章操作系统 12
4.1 缓冲I/O和直接I/O 12
4.2 内存映射文件与零拷贝 14
4.2.1 内存映射文件 14
4.2.2 零拷贝 15
4.3 网络I/O模型 17
4.3.1 实现层面的网络I/O模型 17
4.3.2 Reactor模式与Preactor模式 20
4.3.3 select、epoll的LT与ET 20
4.3.4 服务器编程的1+N+M模型 22
4.4 进程、线程和协程 24
4.5 无锁（内存屏障与CAS） 27
4.5.1 内存屏障 27
4.5.2 CAS 30

第5章网络 31
5.1 HTTP 1.0 31
5.1.1 HTTP 1.0的问题 31
5.1.2 Keep-Alive机制与Content-Length属性 31
5.2 HTTP 1.1 32
5.2.1 连接复用与Chunk机制 32
5.2.2 Pipeline与Head-of-line Blocking问题 33
5.2.3 HTTP/2出现之前的性能提升方法 34
5.2.4 “一来多回”问题 35
5.2.5 断点续传 36
5.3 HTTP/2 36
5.3.1 与HTTP 1.1的兼容 37
5.3.2 二进制分帧 37
5.3.3 头部压缩 39
5.4 SSL/TLS 39
5.4.1 背景 39
5.4.2 对称加密的问题 40
5.4.3 双向非对称加密 41
5.4.4 单向非对称加密 42
5.4.5 中间人攻击 43
5.4.6 数字证书与证书认证中心 44
5.4.7 根证书与CA信任链 45
5.4.8 SSL/TLS协议：四次握手 47
5.5 HTTPS 48
5.6 TCP/UDP 49
5.6.1 可靠与不可靠 49
5.6.2 TCP的“假”连接（状态机） 51
5.6.3 三次握手（网络2将军问题） 53
5.6.4 四次挥手 54
5.7 QUIC 56
5.7.1 不丢包（Raid5算法和Raid6算法） 57
5.7.2 更少的RTT 58
5.7.3 连接迁移 58

第6章数据库 59
6.1 范式与反范式 59
6.2 分库分表 59
6.2.1 为什么要分 60
6.2.2 分布式ID生成服务 60
6.2.3 拆分维度的选择 60
6.2.4 Join查询问题 61
6.2.5 分布式事务 61
6.3 B+树 62
6.3.1 B+树逻辑结构 62
6.3.2 B+树物理结构 63
6.3.3 非主键索引 65
6.4 事务与锁 66
6.4.1 事务的四个隔离级别 66
6.4.2 悲观锁和乐观锁 67
6.4.3 死锁检测 71
6.5 事务实现原理之1：Redo Log 72
6.5.1 Write-Ahead 73
6.5.2 Redo Log的逻辑与物理结构 74
6.5.3 Physiological Logging 75
6.5.4 I/O写入的原子性（Double Write） 76
6.5.5 Redo Log Block结构 77
6.5.6 事务、LSN与Log Block的关系 78
6.5.7 事务Rollback与崩溃恢复（ARIES算法） 80
6.6 事务实现原理之2：Undo Log 86
6.6.1 Undo Log是否一定需要 86
6.6.2 Undo Log（MVCC） 88
6.6.3 Undo Log不是Log 89
6.6.4 Undo Log与Redo Log的关联 90
6.6.4 各种锁 91
6.7 Binlog与主从复制 94
6.7.1 Binlog与Redo Log的主要差异 94
6.7.2 内部XA – Binlog与Redo Log一致性问题 95
6.7.3 三种主从复制方式 96
6.7.3 并行复制 97
第7章框架、软件与中间件 99
7.1 对生态体系的认知 99
7.2 框架 99
7.3 软件与中间件 100

第3部分技术架构之道
第8章高并发问题 104
8.1 问题分类 104
8.1.1 侧重于“高并发读”的系统 104
8.1.2 侧重于“高并发写”的系统 105
8.1.3 同时侧重于“高并发读”和“高并发写”的系统 106
8.2 高并发读 108
8.2.1 策略1：加缓存 108
8.2.2 策略2：并发读 109
8.2.3 策略3：重写轻读 110
8.2.4 总结：读写分离（CQRS架构） 113
8.3 高并发写 114
8.3.1 策略1：数据分片 114
8.3.2 策略2：任务分片 115
8.3.3 策略3：异步化 117
8.3.4 策略4：批量 123
8.3.5 策略5：串行化+多进程单线程+异步I/O 124
8.4 容量规划 125
8.4.1 吞吐量、响应时间与并发数 125
8.4.2 压力测试与容量评估 127

第9章高可用与稳定性 129
9.1 多副本 129
9.2 隔离、限流、熔断和降级 130
9.3 灰度发布与回滚 135
9.4 监控体系与日志报警 136

第10章事务一致性 138
10.1 随处可见的分布式事务问题 138
10.2 分布式事务解决方案汇总 139
10.2.1 2PC 139
10.2.2 最终一致性（消息中间件） 141
10.2.3 TCC 145
10.2.4 事务状态表+调用方重试+接收方幂等 147
10.2.5 对账 148
10.2.6 妥协方案：弱一致性+基于状态的补偿 149
10.2.7 妥协方案：重试+回滚+报警+人工修复 151
10.2.8 总结 152

第11章多副本一致性 153
11.1 高可用且强一致性到底有多难 153
11.1.1 Kafka的消息丢失问题 153
11.1.2 Kafka消息错乱问题 156
11.2 Paxos算法解析 158
11.2.1 Paxos解决什么问题 158
11.2.2 复制状态机 161
11.2.3 一个朴素而深刻的思想 163
11.2.4 Basic Paxos算法 164
11.2.5 Multi Paxos算法 167
11.3 Raft算法解析 169
11.3.1 为“可理解性”而设计 169
11.3.2 单点写入 170
11.3.3 日志结构 171
11.3.4 阶段1：Leader选举 174
11.3.5 阶段2：日志复制 176
11.3.6 阶段3：恢复阶段 177
11.3.7 安全性保证 177
11.4 Zab算法解析 180
11.4.1 Replicated State Machine vs. Primary-Backup System 180
11.4.2 zxid 182
11.4.3 “序”：乱序提交 vs. 顺序提交 182
11.4.4 Leader选举：FLE算法 184
11.4.5 正常阶段：2阶段提交 186
11.4.6 恢复阶段 186
11.5 三种算法对比 187

第12章 CAP理论 189
12.1 CAP理论的误解 189
12.2 现实世界不存在“强一致性”（PACELC理论） 190
12.3 典型案例：分布式锁 192

第4部分业务架构之道
第13章业务意识 196
13.1 产品经理vs.需求分析师 196
13.2 什么叫作一个“业务” 198
13.3 “业务架构”的双重含义 199
13.4 “业务架构”与“技术架构”的区分 200

第14章业务架构思维 202
14.1 “伪”分层 202
14.2 边界思维 204
14.3 系统化思维 205
14.4 利益相关者分析 206
14.5 非功能性需求分析（以终为始） 208
14.6 视角（横看成岭侧成峰） 209
14.7 抽象 210
14.8 建模 213
14.9 正交分解 215

第15章技术架构与业务架构的融合 218
15.1 各式各样的方法论 218
15.2 为什么要“领域驱动” 218
15.3 “业务流程”不等于“系统流程” 221
15.4 为何很难设计一个好的领域模型 222
15.5 领域驱动设计与微服务架构的“合” 223
15.6 领域驱动设计与读写分离（CQRS） 224
15.7 业务分层架构模式 225
15.8 管道—过滤器架构模式 226
15.9 状态机架构模式 226
15.10 业务切面/业务闭环架构模式 228

第5部分从架构到技术管理
第16章个人素质的提升 232
16.1 能力模型 232
16.2 影响力的塑造 234

第17章团队能力的提升 237
17.1 不确定性与风险把控 237
17.2 以价值为中心的管理 239
17.3 团队培养 241

全部展开

本书勘误

页码：9 • 行数：16 • 印次： 1 • 修订印次： 7

“利用MVCC(CopyOnWrite)解决高并发问题”
—》
“利用MVCC(Mutil-version concurrency control)解决高并发问题”

PS: 虽然cow也是一种技术，但是这里使用括号来说明，反而让人误解加深！不知道这里要讲述的对象到底是MVCC还是COW呢？？

天草二十六提交于 2020/10/8 21:32:24

宋亚东确认于 2020/10/13 9:14:46
页码：17 • 行数：28 • 印次： 1 • 修订印次： 3

于是，当调用read和write函数的时候，如果没有准备好数据，会理解【立即？】返回，不会阻塞，然后让应用程序不断地去轮询。

理解更改成立即？

lovesuch 提交于 2019/10/17 0:34:21

宋亚东确认于 2020/6/11 10:30:41
页码：20 • 行数：13 • 印次： 1 • 修订印次： 2

4.2.3Reactor模式与Preactor【Proactor】模式
应该是Proactor模式

第五名提交于 2020/8/11 7:40:50

宋亚东确认于 2020/8/14 14:36:44
页码：26 • 行数：24 • 印次： 1 • 修订印次： 6

最后，表4-3总结了多线程、多进程和多协程编程模型的对此【对比】。
应该是对比

第五名提交于 2020/8/11 7:43:09

宋亚东确认于 2020/8/14 14:37:57
页码：56 • 行数：8 • 印次： 1 • 修订印次： 7

（2）因为网络的2将军问题，图5-24【5-23】中的第四次发送的数据包
应该是：图5-23中的第四次发送的数据包

第五名提交于 2020/8/11 7:45:38

宋亚东确认于 2020/8/14 14:46:15