监控中心用来统计服务调用和消费的次数。
因为不完善，不去使用它，而是使用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。
服务的提供者
消费者采用服务降级
