Dubbo的高级特性

Dubbo-admin管理平台

监控中心用来统计服务调用和消费的次数。

因为不完善，不去使用它，而是使用dubbo-admin

想知道有哪些生产者、消费者、服务

dubbo-admin需要去注册中心找相关信息，所以要在dubbo-admin中配置注册中心zookeeper，告诉dubbo-admin注册中心的位置。

• dubbo-admin管理平台，是图形化的服务管理页面

• 从注册中心中获取到所有的提供者/消费者进行配置管理

• 路由规则、动态配置、服务降级、访问控制、权重调整、负载均衡等管理功能

• dubbo admin是一个前后端分离的项目。 前端使用vue，后端使用springboot

下载安装node，以及dubbo-admin，修改里面的配置文件的zookeeper的地址

在电脑上安装了node.js和mvn之后，对项目进行打包

等待打包success。。。。

之后去启动jar包

启动好后端之后，去启动前端

Dubbo常用高级配置

序列化

• dubbo 内部已经将序列化和反序列化的过程内部封装了

• 我们只需要在定义pojo类时实现seriali zable接口即可

将pojo定义为一个模块，消费者和生产者进行依赖.

1,定一个模块,创建实体类

2,在接口的模块中依赖pojo模块,并且新创建一个方法来查询用户

3,在service模块里面进行方法的实现.

4,消费者进行controller方法的调用

interface依赖pojo,service和web又依赖interface,所以service和web间接的依赖pojo.

注意:

实体类在两个服务之间进行序列化传输的时候,实体类要实现Serializable

被依赖的模块进行改动后一定要重新进行install

地址缓存

注册中心挂了，服务是否可以正常访问?

• 可以，因为dubbo服务消费者在第一次调用时,会将服务提供方地址缓存到本地，以后在调用则不会访问注册中心。

• 当服务提供者地址发生变化时，注册中心会通知服务消费者。

面试问的话，回答：正常情况下，地址没变，缓存没清理就可以访问.zookeeper挂了之后,新的服务就不能用了,之前老的服务还是有缓存的.

超时

但是当用户很多的时候,流量比较大的时候,会创建很多线程去调用服务的提供者,如果每次都失败,那A消费者里面积压了很多线程,这时A机器得资源就被用光了,A机器就挂了,导致一些雪崩的效应.

• 在某个峰值时刻,大量的请求都在同时请求服务消费者,会造成线程的大量堆积,势必会造成雪崩。

• dubbo 利用超时机制来解决这个问题，设置一个超时时间， 在这个时间段内，无法完成服务访问，则自动断开连接。

• 使用timeout属性配置超时时间， 默认值1000,单位毫秒。

对于服务提供者在注解里面设置超时时间和重试次数

对于服务消费者模拟一秒打印一次的效果,打印三次后超时了,会报错.

超时时间可以在消费者的@Reference中配置,也可以在服务提供者的@Service注解中配置

超时时间建议配置在服务的提供方上,因为服务提供方知道提供什么样的服务,该服务大致花费的时间.

服务调用者(消费者)的配置可以覆盖服务提供方的配置,即当两者都配置了超时时间,这时会遵循消费者的配置.

重试

• 设置了超时时间，在这个时间段内，无法完成服务访问，则自动断开连接。

• 如果出现网络抖动，则这一次请求就会失败。

• Dubbo提供重试机制来避免类似问题的发生。

• 通过retries属性来设置重试次数。默认为2次。(算上第一次访问,那就是总共三次)

重试是超时了之后才会重试,正常是不会重试的.

多版本

灰度发布:当出现新功能时,会让一部分用户先使用新功能，用户反馈没问题时，再将所有用户迁移到新功能。

dubbo中使用version属性来设置和调用同一个接口的不同版本

负载均衡

修改权重,tomcat的端口号,以及dubbo的控制端口,qos的端口,模拟开启三台服务提供者

开启三个服务提供者之后,需要在消费者调用的时候指明请求的分配负载均衡的原则

不指明默认为随机

随机

在浏览器不断刷新,发现提供服务的机器不一样.

按照权重轮询

访问顺序为1,2,3,2

最少活跃调用数

消费者会分别问一下服务提供者最后一次处理请求花费了多长时间,选择时间最少的,如果时间都一样,那就随机选择.

最小活跃数量，访问加一，完成减一，本地记录就行

一致性Hash

集群容错

当消费者去调用提供者集群中的某一台机器时，发现出错了，Dubbo内部有容错机制

集群容错模式:

• Failover Cluster:失败重试。默认值。当出现失败,重试其它服务器，默认重试2次，使用retries配置。一般用于读操作。（因为读操作是幂等性的。）

• Failfast Cluster :快速失败，只发起- -次调用,失败立即报错。通常用于写操作。

• Failsafe Cluster:失败安全，出现异常时,直接忽略。返回一个空结果。

• Failback Cluster:失败自动恢复,后台记录失败请求,定时重发。（比较适合重要的事情，一定要执行的事情）

• Forking Cluster :并行调用多个服务器，只要一个成功即返回。（广撒网，比较消耗性能）

• Broadcast Cluster: 广播调用所有提供者,逐个调用，任意-台报错则报错。

要求同步性比较高，例如A要修改B，C，D里面的数据，要保证三个里面的数据一致，就是用广播

服务降级

为了保证核心的服务，关掉一些不太重要的服务。

服务降级方式:

• mock=force:return null表示消费方对该服务的方法调用都直接返回null值,不发起远程调用。用来屏蔽不重要服务不可用时对调用方的影响。
• mock= fail:return null表示消费方对该服务的方法调用在失败后，再返回null值,不抛异常。用来容忍不重要服务不稳定时对调用方的影响。

例如将广告服务和日志服务设置为mock=force:return null 都不会去远程调用相关服务，直接返回null。

服务的提供者

消费者采用服务降级