标签：err   通信   初始   exce   平台   配置   功能   过多   地址   

一、介绍

? 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 是否采用精简模式的
（与低版本兼容）  

一、dubbo基本知识整理

标签：err   通信   初始   exce   平台   配置   功能   过多   地址   

原文地址：https://www.cnblogs.com/chz-blogs/p/13288689.html