『微服务治理之Dubbo』dubbo工作原理

为什么要用分布式

服务降级

比如服务A调用服务B，结果服务B挂掉了，服务A重试几次调用服务B，还是不行，直接降级，走一个备用的逻辑，给用户返回响应
现在就是mock，如果调用失败统一返回null
但是可以将mock改为true，然后跟接口同一个路径下实现一个mock类，命名规则是接口名称加mock后缀，然后在mock类里实现自己的降级逻辑。

---

失败重试和超时重试

retries，3次，设置retries。一般是在读请求的时候，比如你要查询数据，你可以设置个retries，如果第一次没读到，报错，充实指定的次数

---

dubbo架构设计，工作原理

service层：接口层，provider和consumer，接口，留给你来实现的
config层：配置层，任何一个 架，都需要提供配置文件，让你可以进行配置
proxy层：代理层，无论是consumer，还是provider，dubbo都会给你生成代理，代理之间进行网络通信
registry层：服务注册层 ，负责服务的注册与发现
cluster层：集群层，封装多个服务提供者的路由以及负载均衡，将多个实例组合成一个服务
monitor层：监控层，对rpc接口的调用次数和调用时间进行监控
protocol层：远程调用层，封装rpc调用
exchange层：信息交换层，封装请求响应模式，同步转异步
transport层：网络传输层，抽象mina和netty为统一接口
serialize层：数据序列化层

注册中心挂掉了，还可以继续通信吗？可以,消费者第一次在注册中心获取到提供者的信息会缓存到自己本地

---

dubbo都支持哪些通信协议以及序列化协议

dubbo 协议

默认就是走 dubbo 协议，单一长连接，进行的是 NIO 异步通信，基于 hessian 作为序列化协议。使用的场景是：传输数据量小（每次请求在 100kb 以内），但是并发量很高。

为了要支持高并发场景，一般是服务提供者就几台机器，但是服务消费者有上百台，可能每天调用量达到上亿次！此时用长连接是最合适的，就是跟每个服务消费者维持一个长连接就可以，可能总共就 100 个连接。然后后面直接基于长连接 NIO 异步通信，可以支撑高并发请求。

长连接，通俗点说，就是建立连接过后可以持续发送请求，无须再建立连接。

而短连接，每次要发送请求之前，需要先重新建立一次连接。

rmi 协议

走 Java 二进制序列化，多个短连接，适合消费者和提供者数量差不多的情况，适用于文件的传输，一般较少用。

hessian 协议

走 hessian 序列化协议，多个短连接，适用于提供者数量比消费者数量还多的情况，适用于文件的传输，一般较少用。

http 协议

走 json 序列化。

webservice

走 SOAP 文本序列化。

dubbo 支持的序列化协议

dubbo 支持 hession、Java 二进制序列化、json、SOAP 文本序列化多种序列化协议。但是 hessian 是其默认的序列化协议。

说一下 Hessian 的数据结构

Hessian 的对象序列化机制有 8 种原始类型：

原始二进制数据
boolean
64-bit date（64 位毫秒值的日期）
64-bit double
32-bit int
64-bit long
null
UTF-8 编码的 string
另外还包括 3 种递归类型：

list for lists and arrays
map for maps and dictionaries
object for objects
还有一种特殊的类型：

ref：用来表示对共享对象的引用。

为什么 PB 的效率是最高的？

可能有一些同学比较习惯于 JSON or XML 数据存储格式，对于 Protocol Buffer 还比较陌生。Protocol Buffer 其实是 Google 出品的一种轻量并且高效的结构化数据存储格式，性能比 JSON、XML 要高很多。

其实 PB 之所以性能如此好，主要得益于两个：第一，它使用 proto 编译器，自动进行序列化和反序列化，速度非常快，应该比 XML 和 JSON 快上了 20~100 倍；第二，它的数据压缩效果好，就是说它序列化后的数据量体积小。因为体积小，传输起来带宽和速度上会有优化。

---

dubbo支持哪些负载均衡、高可用以及动态代理的策略

dubbo 负载均衡策略

random loadbalance

默认情况下，dubbo 是 random load balance ，即随机调用实现负载均衡，可以对 provider 不同实例设置不同的权重，会按照权重来负载均衡，权重越大分配流量越高，一般就用这个默认的就可以了。

roundrobin loadbalance

这个的话默认就是均匀地将流量打到各个机器上去，但是如果各个机器的性能不一样，容易导致性能差的机器负载过高。所以此时需要调整权重，让性能差的机器承载权重小一些，流量少一些。

举个栗子。

跟运维同学申请机器，有的时候，我们运气好，正好公司资源比较充足，刚刚有一批热气腾腾、刚刚做好的虚拟机新鲜出炉，配置都比较高：8 核 + 16G 机器，申请到 2 台。过了一段时间，我们感觉 2 台机器有点不太够，我就去找运维同学说，“哥儿们，你能不能再给我一台机器”，但是这时只剩下一台 4 核 + 8G 的机器。我要还是得要。

这个时候，可以给两台 8 核 16G 的机器设置权重 4，给剩余 1 台 4 核 8G 的机器设置权重 2。

leastactive loadbalance

这个就是自动感知一下，如果某个机器性能越差，那么接收的请求越少，越不活跃，此时就会给不活跃的性能差的机器更少的请求。

consistanthash loadbalance

一致性 Hash 算法，相同参数的请求一定分发到一个 provider 上去，provider 挂掉的时候，会基于虚拟节点均匀分配剩余的流量，抖动不会太大。如果你需要的不是随机负载均衡，是要一类请求都到一个节点，那就走这个一致性 Hash 策略。

---

dubbo 集群容错策略

failover cluster 模式

失败自动切换，自动重试其他机器，默认就是这个，常见于读操作。（失败重试其它机器）

可以通过以下几种方式配置重试次数：

<dubbo:service retries="2" />

或者

<dubbo:reference retries="2" />

或者

<dubbo:reference>
    <dubbo:method name="findFoo" retries="2" />
</dubbo:reference>

failfast cluster 模式

一次调用失败就立即失败，常见于非幂等性的写操作，比如新增一条记录（调用失败就立即失败）

failsafe cluster 模式

出现异常时忽略掉，常用于不重要的接口调用，比如记录日志。

配置示例如下：

<dubbo:service cluster="failsafe" />

或者

<dubbo:reference cluster="failsafe" />

failback cluster 模式

失败了后台自动记录请求，然后定时重发，比较适合于写消息队列这种。

forking cluster 模式

并行调用多个 provider，只要一个成功就立即返回。常用于实时性要求比较高的读操作，但是会浪费更多的服务资源，可通过 forks=“2” 来设置最大并行数。

broadcacst cluster

逐个调用所有的 provider。任何一个 provider 出错则报错（从2.1.0 版本开始支持）。通常用于通知所有提供者更新缓存或日志等本地资源信息。

dubbo动态代理策略

默认使用 javassist 动态字节码生成，创建代理类。但是可以通过 spi 扩展机制配置自己的动态代理策略。

---

dubbo的spi思想是什么

SPI机制，一般用在插件扩展，使用场景：比如说你开发的是一个给别人使用的开源框架，如果你想让别人自己写个插件，插到你的开源框架里面，扩展某个功能。

---

分布式接口幂等性

保证幂等性三个要点：

1.对每个请求必须有一个唯一的标识，举个例子：订单支付请求，肯定包含订单id，一个订单id最多支付一次
2.每次处理完请求之后，必须有一个记录标识这个请求处理过了，比如说常见的方案是在mysql中记录个状态啥的，比如支付之前记录一条这个订单的支付流水，而且支付流水采用orderId作为唯一键。只有成功插入这个支付流水，才可以执行实际扣款。
3.每次接收请求需要进行判断之前是否处理过的逻辑处理，比如说，如果有一个订单已经支付，就已经有了一条支付流水，那么如果重复发送这个请求，则此时先插入支付流水，orderId已经存在了，唯一键约束生效，保存插入不进去的，然后你就不用再扣款了。
4.用Redis来保存一个是否处理过的标识也可以，服务的不同实例可以一起操作Redis。

---

分布式接口调用如何保证顺序性

大家凑合看吧，两张图片是一张大图。

---

如何设计一个类似的dubbo的rpc框架？架构上该如何考虑？

这是小编学习dubbo做的一个总结，欢迎小伙伴找小编交流。