《发布·设计与部署稳定的分布式系统 第2版＝RELEASE IT!DESIGN AND DEPLOY PRODUCTION-READY SOFTWARE》求取 ⇩

第1章生产环境的生存法则1

1.1 瞄准正确的目标1

1.2 应对不断扩大的挑战范围2

1.3 多花5万美元来节省100万美元3

1.4 让“原力”与决策同在4

1.5 设计务实的架构4

1.6 小结5

第一部分创造稳定性8

第2章案例研究：让航空公司停飞的代码异常8

2.1 进行变更9

2.2 遭遇停机10

2.3 严重后果12

2.4 事后分析12

2.5 寻找线索13

2.6 证据确凿16

2.7 预防管用吗18

第3章让系统稳定运行19

3.1 定义稳定性20

3.2 延长系统寿命20

3.3 系统失效方式21

3.4 阻止裂纹蔓延22

3.5 系统失效链23

3.6 小结24

第4章稳定性的反模式25

4.1集成点26

4.1.1 套接字协议29

4.1.2 凌晨5点的紧急电话31

4.1.3 HTTP协议35

4.1.4 供应商的API程序库36

4.1.5 应对集成点的问题37

4.1.6 要点回顾37

4.2 同层连累反应38

4.3 层叠失效41

4.4用户42

4.4.1 网络流量42

4.4.2 难伺候的用户46

4.4.3 不受欢迎的用户47

4.4.4 恶意用户50

4.4.5 要点回顾51

4.5线程阻塞51

4.5.1 发现阻塞53

4.5.2 程序库55

4.5.3 要点回顾56

4.6自黑式攻击57

4.6.1 避免自黑式攻击57

4.6.2 要点回顾58

4.7放大效应58

4.7.1 点对点通信59

4.7.2 共享资源60

4.7.3 要点回顾61

4.8失衡的系统容量62

4.8.1 通过测试发现系统容量失衡63

4.8.2 要点回顾63

4.9 一窝蜂64

4.10做出误判的机器66

4.10.1 被放大的停机事故66

4.10.2 控制和防护措施69

4.10.3 要点回顾69

4.11 缓慢的响应70

4.12无限长的结果集71

4.12.1 黑色星期一71

4.12.2 要点回顾73

4.13 小结74

第5章稳定性的模式75

5.1 超时75

5.2 断路器78

5.3 舱壁80

5.4稳态83

5.4.1 数据清除84

5.4.2 日志文件85

5.4.3 内存中的缓存86

5.4.4 要点回顾86

5.5 快速失败87

5.6任其崩溃并替换89

5.6.1 有限的粒度89

5.6.2 快速替换90

5.6.3 监管90

5.6.4 重新归队91

5.6.5 要点回顾91

5.7 握手91

5.8 考验机93

5.9 中间件解耦96

5.10 卸下负载98

5.11 背压机制99

5.12 调速器101

5.13 小结102

第二部分为生产环境而设计104

第6章案例研究：屋漏偏逢连夜雨104

6.1 宝宝的第一个感恩节105

6.2 把脉106

6.3 感恩节106

6.4 黑色星期五107

6.5 生命体征108

6.6 进行诊断109

6.7 求助专家110

6.8 如何应对111

6.9 应对奏效吗111

6.10 尾声112

第7章基础层114

7.1数据中心和云端的联网115

7.1.1 网卡和名字116

7.1.2 多网络编程118

7.2物理主机、虚拟机和容器119

7.2.1 物理主机119

7.2.2 数据中心的虚拟机119

7.2.3 数据中心的容器120

7.2.4 云上的虚拟机123

7.2.5 云上的容器125

7.3 小结125

第8章实例层126

8.1代码128

8.1.1 构建代码128

8.1.2 不可变、易处理的基础设施129

8.2配置130

8.2.1 配置文件131

8.2.2 易处理基础设施的配置131

8.3明晰性132

8.3.1 明晰性设计133

8.3.2 提升明晰性的实现技术134

8.3.3 记录日志134

8.3.4 实例的健康度量指标137

8.3.5 健康状况检查138

8.4 小结138

第9章互连层139

9.1 不同规模的解决方案139

9.2使用DNS140

9.2.1 基于DNS的服务发现140

9.2.2 基于DNS的负载均衡141

9.2.3 基于DNS的GSLB142

9.2.4 DNS的可用性144

9.2.5 要点回顾144

9.3负载均衡144

9.3.1 软件负载均衡145

9.3.2 硬件负载均衡146

9.3.3 健康状况检查147

9.3.4 会话黏性147

9.3.5 按请求类型分隔流量148

9.3.6 要点回顾148

9.4控制请求数量148

9.4.1 系统为何会失效149

9.4.2 防止灾难150

9.4.3 要点回顾151

9.5 网络路由151

9.6 发现服务153

9.7 迁移虚拟IP地址154

9.8 小结155

第10章控制层156

10.1 适合的控制层工具156

10.2机械效益157

10.2.1 属于系统失效，而非人为错误158

10.2.2 运行得太快也有问题158

10.3 平台和生态系统159

10.4 开发环境就是生产环境160

10.5整个系统的明晰性161

10.5.1 真实用户监控162

10.5.2 经济价值高于技术价值162

10.5.3 碎片化的风险164

10.5.4 日志和统计信息164

10.5.5 要监控什么165

10.6 配置服务166

10.7 环境整备和部署服务167

10.8命令与控制169

10.8.1 要控制什么169

10.8.2 发送命令170

10.8.3 可编写脚本的界面170

10.8.4 要点回顾171

10.9 平台厂商171

10.10 工具清单172

10.11 小结172

第11章安全性173

11.1OWASP十大安全漏洞173

11.1.1 注入174

11.1.2 失效的身份验证和会话管理175

11.1.3 跨站脚本攻击178

11.1.4 失效的访问控制179

11.1.5 安全配置出现失误181

11.1.6 敏感数据泄露182

11.1.7 防范攻击不足183

11.1.8 CSRF183

11.1.9 使用含有已知漏洞的组件184

11.1.10 API保护不足185

11.2 最小特权原则186

11.3 密码的配置187

11.4 安全即持续的过程187

11.5 小结188

第三部分将系统交付190

第12章 案例研究：等待戈多190

第13章为部署而设计193

13.1 机器与服务193

13.2 计划停机时间的谬误193

13.3 自动化部署194

13.4 持续部署197

13.5部署中的各个阶段198

13.5.1 关系数据库模式200

13.5.2 无模式数据库202

13.5.3 Web资源205

13.5.4 推出新代码206

13.5.5 清理208

13.6 像行家一样部署209

13.7 小结210

第14章处理版本问题211

14.1帮助他人处理版本问题211

14.1.1 不会破坏API的变更211

14.1.2 破坏API的变更215

14.2 处理其他系统的版本问题217

14.3 小结219

第四部分解决系统性问题222

第15章案例研究：不能承受的巨大顾客流量222

15.1 倒计时后推出新系统222

15.2 以QA测试为目标223

15.3 负载测试225

15.4 被众多因素所害227

15.5 测试仍然有差距229

15.6 善后229

第16章适应性232

16.1 努力与回报的关系232

16.2过程和组织233

16.2.1 平台团队235

16.2.2 愉快地发布236

16.2.3 演化最重要的部分是灭绝237

16.2.4 在团队级别实现自治239

16.2.5 谨防高效率240

16.2.6 过程和组织小结242

16.3系统架构242

16.3.1 演进式架构242

16.3.2 松散的集群245

16.3.3 显式上下文246

16.3.4 创造更多选项247

16.3.5 系统架构小结252

16.4信息架构252

16.4.1 消息、事件和命令253

16.4.2 让服务自己控制其资源的标识符254

16.4.3 URL的两重性256

16.4.4 拥抱多义性259

16.4.5 避免概念泄露260

16.4.6 信息架构小结261

16.5 小结261

第17章混沌工程262

17.1 不可能构建第二个Facebook去做测试262

17.2 混沌工程的先驱263

17.3 猴子军团264

17.4使用自己的混沌猴265

17.4.1 先决条件266

17.4.2 设计实验266

17.4.3 3种混沌注入267

17.4.4 有针对性地注入混沌268

17.4.5 自动和重复269

17.5 从人的方面模拟灾难270

17.6 小结271