dubbo是一个rpc框架,主要有5个节点组成,分别是consumer(消费方),provider(提供者),register(注册中心),monitor(监控中心),container(服务容器)。
http 与 rpc 的不同
HTTP 只是传输协议,协议只是规范了一定的交流格式,而且 RPC 是早于 HTTP 的,所以真要问也是问有 RPC 为什么还要 HTTP。
RPC 对比的是本地过程调用,是用来作为分布式系统之间的通信,它可以用 HTTP 来传输,也可以基于 TCP 自定义协议传输。
所以你要先提出这两个不是一个层级的东西,没有可比性,然后再表现一下,可以说 HTTP 协议比较冗余,所以 RPC 大多都是基于 TCP 自定义协议,定制化的才是最适合自己的。
Dubbo集群容错方案
Failover Cluster:失败重试(默认)
当服务消费方调用服务提供者失败后自动切换到其他服务提供者服务器进行重试。可通过 retries=”2” 来设置重试次数(不含第一次)。
接口级别配置重试次数方法
针对某个方法配置重试次数如下:
Failfast Cluster:快速失败 出现异常时立即报错
Failsafe Cluster:失败安全 出现异常时忽略异常
Failback Cluster:失败自动恢复 当服务消费端用服务出现异常后,在后台记录失败的请求,并按照一定的策略后期再进行重试
Forking Cluster:并行调用 并行调用多个服务提供者的服务,只要一个成功即返回
Broadcast Cluster:广播调用 逐个调用所有服务提供者,任意一台调用异常则这次调用就标志失败
读操作建议使用 Failover 失败自动切换,默认重试两次其他服务器。
写操作建议使用 Failfast 快速失败,发一次调用失败就立即报错。
Dubbo负载均衡策略
- Random 随机,按权重设置随机概率(默认)
2. RoundRobin 轮询,按公约后的权重设置轮询比率
3. LeastActive 最少活跃调用数,相同活跃数的随机
4. ConsistatHash 一致性 Hash,相同参数的请求总是发到同一提供者
注册中心挂了,consumer还可以调用provider。因为刚开始初始化的时候,consumer会将需要的所有提供者的地址等信息拉取到本地缓存,所以注册中心挂了可以继续通信。但是provider挂了,那就没法调用了。Dubbo服务限流
一、executes直接限流– 仅提供者端
可以设置为接口级别,也可以设置为方法级别。限制的是服务(方法)并发执行数量。
二、accepts限流 – 仅提供者端
连接数量进行限制
三、actives限流 – 两端
该限流方式与前两种不同的是,其可以设置在提供者端,也可以设置在消费者端。可以设置为接口级别,也可以设置为方法级别
A、提供者端限流
- 长连接:表示当前长连接最多可以处理的请求个数
- 短连接:表示当前服务可以同时处理的短连接数量
B、消费者端限流
根据消费者与提供者间建立的连接类型的不同,其意义也不同:
- 长连接:表示当前消费者所发出的长连接中最多可以提交的请求个数。与长连接的数量没有关系。
- 短连接:表示当前消费者可以提交的短连接数量
四、connections限流
可以设置在提供者端,也可以设置在消费者端。限定连接的个数。对于短连接,该属性效果与actives相同。但对于长连接,其限制的是长连接的个数。
一般情况下,会使connectons与actives联用,让connections限制长连接个数,让actives限制一个长连接中可以处理的请求个数。联用前提:使用默认的Dubbo服务暴露协议
五、间接限流
延迟连接 – 仅消费者端
仅可设置在消费者端,且不能设置为方法级别。仅作用于Dubbo服务暴露协议。
将长连接的建立推迟到消费者真正调用提供者时。
可以减少长连接的数量
六、粘连连接 – 仅消费者
仅能设置在消费者端,其可以设置为接口级别,也可以设置为方法级别。仅作用于Dubbo服务暴露协议。其会使客户端尽量向同一个提供者发起调用,除非该提供者挂了,其会连接另一台。只要启用了粘连连接,其就会自动启用延迟连接。其限制的是流向,而非流量。
七、负载均衡