微服务设计pdf

过去十年中，分布式系统的粒度变得越来越细，包含大量代码的单块应用逐渐转变为自包含的微服务。但开发微服务系统也有一些让人头疼的问题。本书通过大量的例子，全面讨论了系统架构师和管理员在构建、管理和演化微服务架构时必须考虑的问题，并给出了实用的建议。

本书不但详细地阐述了微服务的基本概念，而且还深入探究了如何对自治服务进行建模、集成、测试、部署及监控。书中虚构了某个领域的一家公司，来帮助读者学习微服务架构是如何影响一个领域的。

了解微服务如何将系统设计与组织目标相匹配

掌握将一个服务和现有系统进行集成的不同方式

使用增量式的做法拆分单块代码库

通过持续集成部署各个微服务

审视对分布式系统进行测试和监控的复杂性

管理“用户-服务”和“服务-服务”两种模式下的安全性

理解微服务架构在规模化方面所面临的问题

微服务设计 内容简介

本书全面介绍了微服务的建模、集成、测试、部署和监控，通过一个虚构的公司讲解了如何建立微服务架构。主要内容包括认识微服务在保证系统设计与组织目标统一上的重要性，学会把服务集成到已有系统中，采用递增手段拆分单块大型应用，通过持续集成部署微服务，等等。

微服务设计 目录

前言

第1章微服务1

1.1什么是微服务2

1.1.1很小，专注于做好一件事2

1.1.2自治性3

1.2主要好处3

1.2.1技术异构性3

1.2.2弹性4

1.2.3扩展5

1.2.4简化部署5

1.2.5与组织结构相匹配6

1.2.6可组合性6

1.2.7对可替代性的优化6

1.3面向服务的架构7

1.4其他分解技术7

1.4.1共享库8

1.4.2模块8

1.5没有银弹9

1.6小结10

第2章演化式架构师11

2.1不准确的比较11

2.2架构师的演化视角12

2.3分区14

2.4一个原则性的方法15

2.4.1战略目标15

2.4.2原则15

2.4.3实践16

2.4.4将原则和实践相结合16

2.4.5真实世界的例子16

2.5要求的标准17

2.5.1监控18

2.5.2接口18

2.5.3架构安全性18

2.6代码治理18

2.6.1范例19

2.6.2裁剪服务代码模板19

2.7技术债务20

2.8例外管理21

2.9集中治理和领导21

2.10建设团队22

2.11小结23

第3章如何建模服务24

3.1MusicCorp简介24

3.2什么样的服务是好服务25

3.2.1松耦合25

3.2.2高内聚25

3.3限界上下文26

3.3.1共享的隐藏模型26

3.3.2模块和服务27

3.3.3过早划分28

3.4业务功能28

3.5逐步划分上下文29

3.6关于业务概念的沟通30

3.7技术边界30

3.8小结31

第4章集成32

4.1寻找理想的集成技术32

4.1.1避免破坏性修改32

4.1.2保证API的技术无关性32

4.1.3使你的服务易于消费方使用33

4.1.4隐藏内部实现细节33

4.2为用户创建接口33

4.3共享数据库33

4.4同步与异步35

4.5编排与协同35

4.6远程过程调用38

4.6.1技术的耦合38

4.6.2本地调用和远程调用并不相同39

4.6.3脆弱性39

4.6.4RPC很糟糕吗40

4.7REST41

4.7.1REST和HTTP41

4.7.2超媒体作为程序状态的引擎42

4.7.3JSON、XML还是其他44

4.7.4留心过多的约定44

4.7.5基于HTTP的REST的缺点45

4.8实现基于事件的异步协作方式46

4.8.1技术选择46

4.8.2异步架构的复杂性47

4.9服务即状态机48

4.10响应式扩展48

4.11微服务世界中的DRY和代码重用的危险49

4.12按引用访问50

4.13版本管理51

4.13.1尽可能推迟51

4.13.2及早发现破坏性修改52

4.13.3使用语义化的版本管理53

4.13.4不同的接口共存53

4.13.5同时使用多个版本的服务54

4.14用户界面55

4.14.1走向数字化56

4.14.2约束56

4.14.3API组合57

4.14.4UI片段的组合57

4.14.5为前端服务的后端59

4.14.6一种混合方式60

4.15与第三方软件集成61

4.15.1缺乏控制61

4.15.2定制化62

4.15.3意大利面式的集成62

4.15.4在自己可控的平台进行定制化62

4.15.5绞杀者模式64

4.16小结65

第5章分解单块系统66

5.1关键是接缝66

5.2分解MusicCorp67

5.3分解单块系统的原因68

5.3.1改变的速度68

5.3.2团队结构68

5.3.3安全68

5.3.4技术68

5.4杂乱的依赖69

5.5数据库69

5.6找到问题的关键69

5.7例子：打破外键关系70

5.8例子：共享静态数据71

5.9例子：共享数据72

5.10例子：共享表73

5.11重构数据库74

5.12事务边界75

5.12.1再试一次76

5.12.2终止整个操作77

5.12.3分布式事务77

5.12.4应该怎么办呢78

5.13报告78

5.14报告数据库78

5.15通过服务调用来获取数据80

5.16数据导出81

5.17事件数据导出82

5.18数据导出的备份83

5.19走向实时84

5.20修改的代价84

5.21理解根本原因84

5.22小结85

第6章部署86

6.1持续集成简介86

6.2把持续集成映射到微服务87

6.3构建流水线和持续交付90

6.4平台特定的构建物91

6.5操作系统构建物92

6.6定制化镜像93

6.6.1将镜像作为构建物94

6.6.2不可变服务器95

6.7环境95

6.8服务配置96

6.9服务与主机之间的映射97

6.9.1单主机多服务97

6.9.2应用程序容器99

6.9.3每个主机一个服务100

6.9.4平台即服务101

6.10自动化101

6.11从物理机到虚拟机102

6.11.1传统的虚拟化技术103

6.11.2Vagrant104

6.11.3Linux容器104

6.11.4Docker106

6.12一个部署接口107

6.13小结109

第7章测试110

7.1测试类型110

7.2测试范围111

7.2.1单元测试112

7.2.2服务测试113

7.2.3端到端测试114

7.2.4权衡114

7.2.5比例115

7.3实现服务测试115

7.3.1mock还是打桩115

7.3.2智能的打桩服务116

7.4微妙的端到端测试117

7.5端到端测试的缺点118

7.6脆弱的测试118

7.6.1谁来写这些测试119

7.6.2测试多长时间119

7.6.3大量的堆积120

7.6.4元版本120

7.7测试场景，而不是故事121

7.8拯救消费者驱动的测试121

7.8.1Pact123

7.8.2关于沟通124

7.9还应该使用端到端测试吗124

7.10部署后再测试125

7.10.1区分部署和上线125

7.10.2金丝雀发布126

7.10.3平均修复时间胜过平均故障间隔时间127

7.11跨功能的测试128

7.12小结129

第8章监控131

8.1单一服务，单一服务器132

8.2单一服务，多个服务器132

8.3多个服务，多个服务器133

8.4日志，日志，更多的日志134

8.5多个服务的指标跟踪135

8.6服务指标135

8.7综合监控136

8.8关联标识137

8.9级联139

8.10标准化139

8.11考虑受众140

8.12未来140

8.13小结141

第9章安全143

9.1身份验证和授权143

9.1.1常见的单点登录实现144

9.1.2单点登录网关145

9.1.3细粒度的授权146

9.2服务间的身份验证和授权146

9.2.1在边界内允许一切146

9.2.2HTTP（S）基本身份验证147

9.2.3使用SAML或OpenIDConnect148

9.2.4客户端证书148

9.2.5HTTP之上的HMAC149

9.2.6API密钥149

9.2.7代理问题150

9.3静态数据的安全152

9.3.1使用众所周知的加密算法152

9.3.2一切皆与密钥相关153

9.3.3选择你的目标153

9.3.4按需解密153

9.3.5加密备份153

9.4深度防御154

9.4.1防火墙154

9.4.2日志154

9.4.3入侵检测（和预防）系统154

9.4.4网络隔离155

9.4.5操作系统155

9.5一个示例156

9.6保持节俭158

9.7人的因素158

9.8黄金法则158

9.9内建安全159

9.10外部验证159

9.11小结159

第10章康威定律和系统设计161

10.1证据161

10.1.1松耦合组织和紧耦合组织162

10.1.2WindowsVista162

10.2Netflix和Amazon162

10.3我们可以做什么163

10.4适应沟通途径163

10.5服务所有权164

10.6共享服务的原因164

10.6.1难以分割164

10.6.2特性团队164

10.6.3交付瓶颈165

10.7内部开源166

10.7.1守护者的角色166

10.7.2成熟166

10.7.3工具167

10.8限界上下文和团队结构167

10.9孤儿服务167

10.10案例研究168

10.11反向的康威定律169

10.12人170

10.13小结170

第11章规模化微服务171

11.1故障无处不在171

11.2多少是太多172

11.3功能降级173

11.4架构性安全措施174

11.5反脆弱的组织175

11.5.1超时176

11.5.2断路器176

11.5.3舱壁178

11.5.4隔离179

11.6幂等179

11.7扩展180

11.7.1更强大的主机181

11.7.2拆分负载181

11.7.3分散风险181

11.7.4负载均衡182

11.7.5基于worker的系统184

11.7.6重新设计184

11.8扩展数据库185

11.8.1服务的可用性和数据的持久性185

11.8.2扩展读取185

11.8.2扩展写操作186

11.8.4共享数据库基础设施187

11.8.5CQRS187

11.9缓存188

11.9.1客户端、代理和服务器端缓存188

11.9.2HTTP缓存189

11.9.3为写使用缓存190

11.9.4为弹性使用缓存190

11.9.5隐藏源服务191

11.9.6保持简单191

11.9.7缓存中毒：一个警示192

11.10自动伸缩192

11.11CAP定理193

11.11.1牺牲一致性194

11.11.2牺牲可用性195

11.11.3牺牲分区容忍性195

11.11.4AP还是CP196

11.11.5这不是全部或全不196

11.11.6真实世界197

11.12服务发现197

11.13动态服务注册199

11.13.1Zookeeper199

11.13.2Consul200

11.13.4构造你自己的系统201

11.13.5别忘了人201

11.14文档服务201

11.14.1Swagger202

11.14.2HAL和HAL浏览器202

11.15自描述系统203

11.16小结203

第12章总结204

12.1微服务的原则204

12.1.1围绕业务概念建模205

12.1.2接受自动化文化205

12.1.3隐藏内部实现细节205

12.1.4让一切都去中心化206

12.1.5可独立部署206

12.1.6隔离失败206

12.1.7高度可观察207

12.2什么时候你不应该使用微服务207

12.3临别赠言208

关于作者209

关于封面209

微服务设计 精彩文摘

在介绍具体的技术选择之前，让我们先就服务如何协作这个问题做一些讨论。服务之间的通信应该是同步的还是异步的呢？这个基础性的选择会不可避免地引导我们使用不同的实现。

如果使用同步通信，发起一个远程服务调用后，调用方会阻塞自己并等待整个操作的完成。如果使用异步通信，调用方不需要等待操作完成就可以返回，甚至可能不需要关心这个操作完成与否。

同步通信听起来合理，因为可以知道事情到底成功与否。异步通信对于运行时间比较长的任务来说比较有用，否则就需要在客户端和服务器之间开启一个长连接，而这是非常不实际的。当你需要低延迟的时候，通常会使用异步通信，否则会由于阻塞而降低运行的速度。对于移动网络及设备而言，发送一个请求之后假设一切工作正常（除非被告知不正常），这种方式可以在很大程度上保证在网络很卡的情况下用户界面依然很流畅。另一方面，处理异步通信的技术相对比较复杂，后面会讨论。

这两种不同的通信模式有着各自的协作风格，即请求／响应或者基于事件。对于请求／响应来说，客户端发起一个请求，然后等待响应。这种模式能够与同步通信模式很好地匹配，但异步通信也可以使用这种模式。我可以发起一个请求，然后注册一个回调，当服务端操作结束之后，会调用该回调。

对于使用基于事件的协作方式来说，情况会颠倒过来。客户端不是发起请求，而是发布一个事件，然后期待其他的协作者接收到该消息，并且知道该怎么做。我们从来不会告知任何人去做任何事情。基于事件的系统天生就是异步的。整个系统都很聪明，也就是说，业务逻辑并非集中存在于某个核心大脑，而是平均地分布在不同的协作者中。基于事件的协作方式耦合性很低。客户端发布一个事件，但并不需要知道谁或者什么会对此做出响应，这也意味着，你可以在不影响客户端的情况下对该事件添加新的订阅者。
哪些因素会影响对这两种风格的选择呢？一个重要的因素是这种风格能否很好地解决复杂问题，比如如何处理跨服务边界的流程'_而且这种流程有可能会运行很长时间。