一、介绍
dubbo 主要是一个分布式服务治理解决方案。那么什么是服务治理?
服务治理主要是针对大规模服务化以后,服务之间的路由、负载均衡、容错机制、服务降级这些问题的解决方案,而 Dubbo 实现的不仅仅是远程服务通信,并且还解决了服务路由、负载、降级、容错等功能。
二、基本使用
三、Dubbo 的终端操作方法
如果不看 zookeeper、也不看监控平台(dubbo-admin,直接改下配置war部署就可以看到了),如何知道这个服务是否正常呢?
Dubbo 里面提供了一种基于终端操作的方法来实现服务治理,使用 telnet localhost 20880 连接到服务对应的端口
常见命令
ls
ls: 显示服务列表
ls -l: 显示服务详细信息列表
ls XxxService: 显示服务的方法列表
ls -l XxxService: 显示服务的方法详细信息列表
ps
ps: 显示服务端口列表
ps -l: 显示服务地址列表
ps 20880: 显示端口上的连接信息
ps -l 20880: 显示端口上的连接详细信息
cd
cd XxxService: 改变缺省服务,当设置了缺省服务,凡是需要输入服务名作
为参数的命令,都可以省略服务参数
cd /: 取消缺省服务
pwd
pwd: 显示当前缺省服务
count
count XxxService: 统计 1 次服务任意方法的调用情况
count XxxService 10: 统计 10 次服务任意方法的调用情况
count XxxService xxxMethod: 统计 1 次服务方法的调用情况
count XxxService xxxMethod 10: 统计 10 次服务方法的调用情况
四、负载均衡
负载均衡可以分为软件负载和硬件负载,基础软件负载比较多,比如 nginx,硬件负载现在用得比较少而且有专门的人来维护。
Dubbo 里面默认就集成了负载均衡的算法和实现, 默认提供了 4 中负载均衡实现。
配置
能配置的属性名称有: roundrobin/random/ leastactive/ consistenthash
配置方法:
<dubbo:service interface="..." loadbalance="roundrobin" />
<dubbo:reference interface="..." loadbalance="roundrobin" />
可以在服务端配置,也可以在客户端配置。
如果是基于注解,配置如下
@Service(loadbalance = "roundrobin")
public class HelloServiceImpl implements IHelloService{
或者
@Reference(loadbalance = "random")
IHelloService helloService;
默认提供了 4 中负载均衡实现。 roundrobin/random/ leastactive/ consistenthash
RandomLoadBalance
权重随机算法,根据权重值进行随机负载 。
一组服务器 servers = [A, B, C],他们对应的权重为weights = [5, 3, 2],权重总和为 10。现在把这些权重值平铺在一维坐标值上, [0, 5) 区间属于服务器 A, [5, 8) 区间属于服务器 B, [8, 10) 区间属于服务器 C。接下来通过随机数生成器生成一个范围在 [0, 10) 之间的随机数,然后计算这个随机数会落到哪个区间上,就分给谁。
LeastActiveLoadBalance
最少活跃调用数算法, 每个服务提供者对应一个活跃数 active。
初始情况下,所有服务提供者活跃数均为 0。每收到一个请求,活跃数加 1,完成请求后活跃数减 1。
在服务运行一段时间后,性能好的服务提供者处理请求的速度更快,因此活跃数下降的也越快,此时这样的服务提供者能够优先获取到新的服务请求
ConsistentHashLoadBalance
hash 一致性算法, 相同参数的请求总是发到同一提供者
当某一台提供者挂时,原本发往该提供者的请求,基于虚拟节点,平摊到其它提供者,
不会引起剧烈变动
RoundRobinLoadBalance
加权轮询算法 。
轮询基础上加权重,服务器 A、 B、 C 权重比为 5:2:1。那么在 8 次请求中,服务器 A 将收到其中的 5 次请求,服务器 B 会收到其中的 2 次请求,服务器 C 则收到其中的 1 次请求
五、集群容错
在集群调用失败时, Dubbo 提供了多种容错方案,缺省为 failover 重试。
@Service(loadbalance = "random", cluster = "failsafe")
总共有多种:
Failover Cluster
失败自动切换,当出现失败,重试其它服务器。 (缺省)
通常用于读操作,但重试会带来更长延迟。可通过 retries="2" 来设置重试次数(不含第一次)。
Failfast Cluster
快速失败,只发起一次调用,失败立即报错。通常用于非幂等性的写操作,比如新增记录。
Failsafe Cluster
失败安全,出现异常时,直接忽略。通常用于写入审计日志等操作。
Failback Cluster
失败自动恢复,后台记录失败请求,定时重发。通常用于消息通知操作。
Forking Cluster
并行调用多个服务器,只要一个成功即返回。通常用于实时性要求较高的读操作,但需要浪费更多服务资源。可通过 forks="2" 来设置最大并行数。
Broadcast Cluster
广播调用所有提供者,逐个调用,任意一台报错则报错。 (2.1.0 开始支持)
通常用于通知所有提供者更新缓存或日志等本地资源信息。
六、服务降级
Dubbo 中提供了一个 mock 的配置,可以通过mock 来实现当服务提供方出现网络异常或者挂掉以后,客户端不抛出异常,而是通过Mock 数据返回自定义的数据
@RestController
public class DubboController {
//Dubbo提供的注解,失败了就调用mock里写的方法
@Reference(loadbalance = "roundrobin",timeout = 1,
cluster ="failfast",mock = "com.xxx.SayHelloServiceMock")
ISayHelloService sayHelloService;
@GetMapping("/sayhello")
public String sayHello() throws InterruptedException {
return sayHelloService.sayHello();
}
}
多版本支持
当一个接口实现,出现不兼容升级时,可以用版本号过渡,版本号不同的服务相互间不引用。可以按照以下的步骤进行版本迁移:
-1. 在低压力时间段,先升级一半提供者为新版本
-2. 再将所有消费者升级为新版本
-3. 然后将剩下的一半提供者升级为新版本
七、Dubbo 新的功能
动态配置规则
Dubbo2.7 版本引入的一个新的功能,简单来说,就是把 dubbo.properties中的属性进行集中式存储,存储在其他的服务器上。
目前 Dubbo 能支持的配置中心有: apollo、 nacos、 zookeeper
之前用 zookeeper 实现服务注册和发现,本质上就是使用 zookeeper 实现了配置中心, 这个配置中心只是维护了服务注册和服务感知的功能。 在 2.7 版本中, dubbo 对配置中心做了延展
元数据中心
在 Dubbo2.7 之前,所有的配置信息,比如服务接口名称、重试次数、版本号、 负载策略、容错策略等等,所有参数都是基于 url 形式配置在 zookeeper 上的。这种方式会造成一些问题
-1. url 内容过多,导致数据存储空间增大
-2. url 需要涉及到网络传输,数据量过大会造成网络传输过慢
-3. 网络传输慢,会造成服务地址感知的延迟变大,影响服务的正常响应
把属于服务治理的数据发布到注册中心,其他的配置数据统一发布到元数据中心。这样一来大大降低了注册中心的负载
元数据中心配置
元数据中心目前支持 redis 和 zookeeper。
在配置文件中添加元数据中心的地址
dubbo.metadata-report.address=zookeeper://192.168.13.106:2181
dubbo.registry.simplified=true //注册到注册中心的 URL 是否采用精简模式的
(与低版本兼容)