一、dubbo基本知识整理

￡神魔★判官ぃ 2023-02-25 10:22 125阅读 0赞

# 一、介绍 #

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 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. 网络传输慢，会造成服务地址感知的延迟变大，影响服务的正常响应

把属于服务治理的数据发布到注册中心，其他的配置数据统一发布到元数据中心。这样一来大大降低了注册中心的负载