分布式服务框架原理与实践pdf

适读人群 ：本书适合架构师、设计师、软件开发工程师、测试工程师以及其他对互联网分布式架构感兴趣的相关人士阅读。

1、微服务是当前非常热的技术关键词之一，那么微服务如何落地呢？首先要实现服务化，微服务架构是一种服务化架构风格。《分布式服务框架原理与实践》对如何构建分布式服务化系统，提供了原理分析、关键技术、开发案例以及业界技术对比，非常系统化，不论是学习分布式服务技术还是深入大型互联网架构都非常实用。

2、《分布式服务框架原理与实践》作者李林锋多年来在华为一直从事核心代码的架构设计和开发，属于实战型架构师，这本书集合了他多年的架构思路，书中内容组织清晰，图例详实，非常便于理解与吸收。

3、《分布式服务框架原理与实践》首先分析了作为一个分布式服务框架所需具备的能力，包括服务注册中心、服务调用、服务路由、服务发布／灰度发布等；接着分析了服务底层如何有效地进行通信，包括通信框架、序列化／反序列化及协议栈等；然后分析了服务如何做到高可靠性及高安全性等重要特性；最后也阐述了从服务化如何向微服务演进。干货满满！

分布式服务框架原理与实践 内容简介

本书作者具有丰富的分布式服务框架、平台中间件的架构设计和实践经验，主导设计的华为分布式服务框架已经在全球数十个国家成功商用。书中依托工作实践，从分布式服务框架的架构设计原理到实践经验总结，涵盖了服务化架构演进、订阅发布、路由策略、集群容错和服务治理等多个专题，全方位剖析服务框架的设计原则和原理，结合大量实践案例与读者分享作者对分布式服务框架设计和运维的体会。同时，对基于Docker部署微服务以及基于微服务架构开发、部署和运维业务系统进行了详细介绍。

分布式服务框架原理与实践 目录

第1章应用架构演进1

1.1传统垂直应用架构2

1.1.1垂直应用架构介绍2

1.1.2垂直应用架构面临的挑战4

1.2RPC架构6

1.2.1RPC框架原理6

1.2.2最简单的RPC框架实现8

1.2.3业界主流RPC框架14

1.2.4RPC框架面临的挑战17

1.3SOA服务化架构18

1.3.1面向服务设计的原则18

1.3.2服务治理19

1.4微服务架构21

1.4.1什么是微服务21

1.4.2微服务架构对比SOA22

1.5总结23

第2章分布式服务框架入门25

2.1分布式服务框架诞生背景26

2.1.1应用从集中式走向分布式.26?

2.1.2亟需服务治理28

2.2业界分布式服务框架介绍29

2.2.1阿里Dubbo30

2.2.2淘宝HSF33

2.2.3亚马逊CoralService35

2.3分布式服务框架设计36

2.3.1架构原理36

2.3.2功能特性37

2.3.3性能特性39

2.3.4可靠性39

2.3.5服务治理40

2.4总结41

第3章通信框架42

3.1关键技术点分析43

3.1.1长连接还是短连接43

3.1.2BIO还是NIO43

3.1.3自研还是选择开源NIO框架46

3.2功能设计47

3.2.1服务端设计48

3.2.2客户端设计50

3.3可靠性设计53

3.3.1链路有效性检测54

3.3.2断连重连机制56

3.3.3消息缓存重发57

3.3.4资源优雅释放58

3.4性能设计59

3.4.1性能差的三宗罪59

3.4.2通信性能三原则60

3.4.3高性能之道61

3.5最佳实践61

3.6总结64

第4章序列化与反序列化65

4.1几个关键概念澄清66

4.1.1序列化与通信框架的关系66

4.1.2序列化与通信协议的关系66

4.1.3是否需要支持多种序列化方式67

4.2功能设计67

4.2.1功能丰富度67

4.2.2跨语言支持68

4.2.3兼容性69

4.2.4性能70

4.3扩展性设计71

4.3.1内置的序列化/反序列化功能类71

4.3.2反序列化扩展72

4.3.3序列化扩展75

4.4最佳实践77

4.4.1接口的前向兼容性规范77

4.4.2高并发下的稳定性78

4.5总结78

第5章协议栈79

5.1关键技术点分析.80

5.1.1是否必须支持多协议80

5.1.2公有协议还是私有协议80

5.1.3集成开源还是自研81

5.2功能设计82

5.2.1功能描述82

5.2.2通信模型82

5.2.3协议消息定义84

5.2.4协议栈消息序列化支持的字段类型85

5.2.5协议消息的序列化和反序列化86

5.2.6链路创建89

5.2.7链路关闭90

5.3可靠性设计90

5.3.1客户端连接超时90

5.3.2客户端重连机制91

5.3.3客户端重复握手保护91

5.3.4消息缓存重发92

5.3.5心跳机制92

5.4安全性设计92

5.5最佳实践—协议的前向兼容性94

5.6总结95

第6章服务路由96

6.1透明化路由97

6.1.1基于服务注册中心的订阅发布97

6.1.2消费者缓存服务提供者地址98

6.2负载均衡98

6.2.1随机98

6.2.2轮循99

6.2.3服务调用时延99

6.2.4一致性哈希100

6.2.5粘滞连接101

6.3本地路由优先策略102

6.3.1injvm模式102

6.3.2innative模式102

6.4路由规则103

6.4.1条件路由规则103

6.4.2脚本路由规则104

6.5路由策略定制105

6.6配置化路由106

6.7最佳实践—多机房路由107

6.8总结108

第７章集群容错109

7.1集群容错场景110

7.1.1通信链路故障110

7.1.2服务端超时111

7.1.3服务端调用失败111

7.2容错策略112

7.2.1失败自动切换（Failover）112

7.2.2失败通知（Failback）113

7.2.3失败缓存（Failcache）113

7.2.4快速失败（Failfast）114

7.2.5容错策略扩展114

7.3总结115

第8章服务调用116

8.1几个误区117

8.1.1NIO就是异步服务117

8.1.2服务调用天生就是同步的118

8.1.3异步服务调用性能更高120

8.2服务调用方式120

8.2.1同步服务调用120

8.2.2异步服务调用121

8.2.3并行服务调用125

8.2.4泛化调用129

8.3最佳实践130

8.4总结131

第９章服务注册中心132

9.1几个概念133

9.1.1服务提供者133

9.1.2服务消费者133

9.1.3服务注册中心133

9.2关键功能特性设计134

9.2.1支持对等集群135

9.2.2提供CRUD接口136

9.2.3安全加固136

9.2.4订阅发布机制137

9.2.5可靠性138

9.3基于ZooKeeper的服务注册中心设计139

9.3.1服务订阅发布流程设计139

9.3.2服务健康状态检测141

9.3.3对等集群防止单点故障142

9.3.4变更通知机制144

9.4总结144

第10章服务发布和引用145

10.1服务发布设计146

10.1.1服务发布的几种方式146

10.1.2本地实现类封装成代理148

10.1.3服务发布成指定协议148

10.1.4服务提供者信息注册149

10.2服务引用设计150

10.2.1本地接口调用转换成远程服务调用150

10.2.2服务地址本地缓存151

10.2.3远程服务调用151

10.3最佳实践152

10.3.1对等设计原则152

10.3.2启动顺序问题153

10.3.3同步还是异步发布服务153

10.3.4警惕网络风暴154

10.3.5配置扩展154

10.4总结156

第11章服务灰度发布157

11.1服务灰度发布流程设计158

11.1.1灰度环境准备158

11.1.2灰度规则设置159

11.1.3灰度规则下发160

11.1.4灰度路由161

11.1.5失败回滚162

11.1.6灰度发布总结163

11.2总结163

第12章参数传递164

12.1内部传参165

12.1.1业务内部参数传递165

12.1.2服务框架内部参数传递168

12.2外部传参169

12.2.1通信协议支持169

12.2.2传参接口定义170

12.3最佳实践171

12.3.1防止参数互相覆盖171

12.3.2参数生命周期管理171

12.4总结172

第13章服务多版本173

13.1服务多版本管理设计174

13.1.1服务版本号管理174

13.1.2服务提供者175

13.1.3服务消费者175

13.1.4基于版本号的服务路由176

13.1.5服务热升级177

13.2与OSGi的对比178

13.2.1模块化开发179

13.2.2插件热部署和热升级184

13.2.3不使用OSGi的其他理由185

13.3总结185

第14章流量控制186

14.1静态流控187

14.1.1传统静态流控设计方案187

14.1.2传统方案的缺点188

14.1.3动态配额分配制188

14.1.4动态配额申请制190

14.2动态流控191

14.2.1动态流控因子192

14.2.2分级流控192

14.3并发控制193

14.3.1服务端全局控制193

14.3.2服务消费者流控194

14.4连接控制195

14.4.1服务端连接数流控195

14.4.2服务消费者连接数流控195

14.5并发和连接控制算法195

14.6总结197

第15章服务降级198

15.1屏蔽降级199

15.1.1屏蔽降级的流程199

15.1.2屏蔽降级的设计实现200

15.2容错降级202

15.2.1容错降级的工作原理202

15.2.2运行时容错降级.204

15.3业务层降级205

15.4总结205

第16章服务优先级调度207

16.1设置服务优先级208

16.2线程调度器方案209

16.3Java优先级队列210

16.4加权优先级队列211

16.5服务迁入迁出212

16.6总结213

第17章服务治理214

17.1服务治理技术的历史变迁215

17.1.1SOAGovernance215

17.1.2分布式服务框架服务治理217

17.1.3AWS云端微服务治理217

17.2应用服务化后面临的挑战218

17.2.1跨团队协作问题219

17.2.2服务的上下线管控220

17.2.3服务安全220

17.2.4服务SLA保障.221

17.2.5故障快速定界定位221

17.3服务治理222

17.3.1服务治理架构设计223

17.3.2运行态服务治理功能设计225

17.3.3线下服务治理232

17.3.4安全和权限管理234

17.4总结237

第18章分布式消息跟踪239

18.1业务场景分析240

18.1.1故障的快速定界定位240

18.1.2调用路径分析241

18.1.3调用来源和去向分析242

18.2分布式消息跟踪系统设计242

18.2.1系统架构243

18.2.2埋点日志244

18.2.3采样率247

18.2.4采集和存储埋点日志248

18.2.5计算和展示249

18.2.6调用链扩展251

18.3总结251

第19章可靠性设计253

19.1服务状态检测254

19.1.1基于服务注册中心状态检测254

19.1.2链路有效性状态检测机制255

19.2服务健康度检测256

19.3服务故障隔离257

19.3.1进程级故障隔离257

19.3.2VM级故障隔离259

19.3.3物理机故障隔离260

19.3.4机房故障隔离261

19.4其他可靠性特性262

19.4.1服务注册中心262

19.4.2监控中心262

19.4.3服务提供者262

19.5总结263

第20章微服务架构264

20.1微服务架构产生的历史背景265

20.1.1研发成本挑战265

20.1.2运维成本高267

20.1.3新需求上线周期长268

20.2微服务架构带来的改变268

20.2.1应用解耦268

20.2.2分而治之270

20.2.3敏捷交付271

20.3微服务架构解析271

20.3.1微服务划分原则272

20.3.2开发微服务272

20.3.3基于Docker容器部署微服务274

20.3.4治理和运维微服务277

20.3.5特点总结278

20.4总结279

第21章服务化最佳实践280

21.1性能和时延问题281

21.1.1RPC框架高性能设计281

21.1.2业务最佳实践285

21.2事务一致性问题286

21.2.1分布式事务设计方案287

21.2.2分布式事务优化288

21.3研发团队协作问题289

21.3.1共用服务注册中心290

21.3.2直连提供者290

21.3.3多团队进度协同291

21.3.4服务降级和Mock测试291

21.3.5协同调试问题292

21.3.6接口前向兼容性292

21.4总结292

分布式服务框架原理与实践 精彩文摘

8.2.2　异步服务调用

基于JDK的Future机制，可以非常方便地实现异步服务调用，JDK的Future接口定义如图8-5所示。

JDK原生的Future主要用于异步操作，它代表了异步操作的执行结果，用户可以通过调用它的get方法获取结果。如果当前操作没有执行完，get操作将阻塞调用线程。

在实际项目中，往往会扩展JDK的Future，提供Future-Listener机制，它支持主动获取和被动异步回调通知两种模式，适用于不同的业务场景。

以Netty的Future接口定义为例，新增了监听器管理接口，监听器主要用于异步通知回调。

异步服务调用的工作流程如下：

1） 消费者调用服务端发布的接口，接口调用由分布式服务框架包装成动态代理，发起远程服务调用。

2） 通信框架异步发送请求消息，如果没有发生I/O异常，返回。

3） 请求消息发送成功后，I/O线程构造Future对象，设置到RPC上下文中。

4） 用户线程通过RPC上下文获取Future对象。

5） 构造Listener对象，将其添加到Future中，用于服务端应答异步回调通知。

6） 用户线程返回，不阻塞等待应答。

7） 服务端返回应答消息，通信框架负责反序列化等。

8） I/O线程将应答设置到Future对象的操作结果中。

9） Future对象扫描注册的监听器列表，循环调用监听器的operationComplete方法，将结果通知给监听器，监听器获取到结果之后，继续后续业务逻辑的执行，异步服务调用结束。

需要指出的是，还有另外一种异步服务调用形式，就是不添加Listener，用户连续发起N次服务调用，然后依次从RPC上下文中获取Future对象，最终再主动get结果，业务线程阻塞，相比于老的同步服务调用，它的阻塞时间更短，其工作原理如图8-8所示。

异步服务调用的代码示例如下：

xxxService1.xxxMethod(Req);

Future f1 = RpcContext.getContext().getFuture();

xxxService2.xxxMethod(Req);

Future f2 = RpcContext.getContext().getFuture();

Object xxResult1 = f1.get(3000);

Object xxResult2 = f2.get(3000); }

假如xxxService1和xxxService2发布成异步服务，则调用xxxMethod之后当前业务线程不阻塞，立即返回null。用户不能直接使用它的返回值，而是通过当前线程上下文RPCContext获取异步操作结果Future。获取到Future之后继续发起其他异步服务调用，然后获取另一个Future……最后，通过Future的get方法集中获取结果。无论有多少个Future，采用此种方式用户线程最长阻塞时间为耗时最长的Future，即T = Max t(future1N)。如果采用同步服务调用，用户线程的阻塞时间T = t(future1) + t(future2) + ……+ t(futureN)。

异步服务调用相比于同步服务调用有两个优点：

◎ 化串行为并行，提升服务调用效率，减少业务线程阻塞时间。

◎ 化同步为异步，避免业务线程阻塞。

由于每次服务调用都是同步阻塞，三个服务调用总耗时为T = T1 + T2 + T3。下面我们看下采用异步服务调用之后的优化效果。

采用异步服务调用模式，最后调用三个服务异步操作结果Future的get方法同步等待应答，它的总执行时间T = Max(T1, T2, T3)，相比于同步服务调用，性能提升效果非常明显。

第二种基于Future-Listener的纯异步服务调用，它的代码示例如下：

xxxService1.xxxMethod(Req);

Future f1 = RpcContext.getContext().getFuture();

Listener l = new xxxListener();

f1.addListener(l);

后续代码省略 }

基于Future-Listener的异步服务调用相比于Future-get模式更好，但是在实际使用中有一定的局限性，具体的使用限制留给读者自己思考。