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。
服务的提供者
消费者采用服务降级
