Dubbo高级特性
dubbo-admin管理平台
Monitor就是管理中心，但是官方宣布此组件并不完整正在维护中，所以一般采用dubbo-admin组件来进行服务的监控和管理。
- dubbo-admin管理平台，是图形化的服务管理页面。
- 可以从注册中心最终获取到所有服务提供者和服务消费者进行配置管理。也就是说要先启动dubbo和zk后才能使用dubbo-admin
- 可以做路由配置、动态配置、服务降级、访问控制、权重调整、负载均衡等管理功能。
- dubbo-admin是一个前后端分离项目，前端采用Vue，后端采用spring boot。
安装
-
首先需要安装node，然后在github中搜索dubbo-admin，此项目来自apache。
-
在./dubbo-admin-server/src/main/resources/application.properties中修改zk的地址：
admin.registry.address=zookeeper://127.0.0.1:2101
admin.config-center=zookeeper://127.0.0.1:2101
admin.metadata-report.address=zookeeper://127.0.0.1:2101
-
在项目根目录中通过Maven进行打包：
mvn clean package；然后启动jar包java -jar ./dubbo-admin-distribution/target/dubbo-admin-0.1.jar。 -
在dubbo-admin-ui中，通过
npm run dev进行前端项目的启动。 -
通过npm启动后指定的地址，就可以进入admin的首页，默认的用户名和密码都为root：
使用
-
在服务列表中可以通过服务名称进行查询，
*表示所有服务：
-
可以点击服务进行详细信息的查查询，服务信息表示当前服务和使用此服务的消费者服务；元数据表示当前服务所提供的方法的集合和详细信息。服务提供者就是一个dubbo服务，服务消费者需要在一次请求之后才会展示出来。
默认情况下，服务的元数据是看不到的，需要在生产服务的配置上添加：
<dubbo:metadata-report address="zookeeper://127.0.0.1:2181"来将元数据推送到注册中心。其中端口号表示服务在Tomcat之外，dubbo自动占用的一个端口：
如果想修改这个端口号，可以通过修改服务配置文件的方式：
<dubbo:protocol port="20880"/>如果在同一个服务器上启动多个dubbo服务，就需要更改此端口以避免端口冲突。
-
可以针对某个远程方法在控制台中直接模拟数据进行调用，以检测接口是否可达，以及数据准确性。
序列化
在进行远程方法调用的时候，难免会出现对象传输的情况。消费者发出请求的参数可能是一个对象，生产者返回的数据也可能是一个对象，那这个对象要经历序列化才能完成传输。Dubbo已经自动完成了序列化的工作，开发过程中要协助便捷的完成序列化工作。
因为类需要进行序列化，所以都要实现Serializable接口，并且因为多个服务使用的类都是相同的，所以所有的实体类都要抽离到一个独立的模块中，被多个服务依赖共用。
之前已经抽离了一个模块，用来存储所有的service接口，新的模块用于存储所有实体类，包括POJO、VO、DTO和DAO。一般情况下可以让接口模块依赖实体类模块，然后其他服务直接依赖接口模块，间接依赖实体类模块即可。
如果在进行方法调用时候所传输的对象没有实现Serializable接口，会在控制台报错。
地址缓存
如果注册中心出现异常而无法使用，也不会再短期内导致服务调用异常。因为dubbo服务的消费者会在第一次调用的时候缓存服务列表到本地，在未来进行远程调用的时候不会访问注册中心了。
如果服务提供者出现异常或者地址发生改变，注册中心会通知服务消费者更新服务列表。
超时与重试
超时
服务消费者在进行远程调用服务提供者时，如果发生了阻塞、等待的情况，服务消费者就会一直等待服务的返回。
在大量请求服务消费者的时候，就会出现大量无法释放的线程，从而导致服务的异常。
dubbo为了避免服务宕机的情况，采用超时的方式来自动断开与服务提供者的连接，默认1000（毫秒），具体配置在服务提供者的@Service注解上：
@Service(timeout = 3000)
public class ServiceImpl implements IService{
//...
}
服务超时也会在控制台上显示超时错误日志。
实际上在服务消费者的@Reference注解上也可以配置timeout参数：
@Reference(timeout = 3000)
private UserService service;
如果@Reference注解和@Service注解都配置了超时时间，则Reference会覆盖Service的配置。
通常超时时间按根据服务提供者业务代码的运行时间做预判，从而配置到服务提供方。
重试
如果出现网络抖动（网速不稳定）的情况下出现了超时的情况，就会导致远程调用失败，但是网络会立即恢复，需要重新让服务消费方发送消息。
重试的配置也是在@Services上配置，通过retries属性配置重试次数，默认2次重试，也就是第一次请求之后再发出两次重试请求，一共三次请求。
多版本
当服务提供者出现新的功能的时候，需要让服务调用方进行兼容，但是并不是所有服务消费者都一次性的进行版本的切换，而是部分消费者切换并测试没有问题后慢慢的再将旧版本的份额逐渐减小，这被称为灰度发布。
dubbo中使用version属性来设置同一个接口的版本。
首先在服务提供者的@Service接口上进行version属性配置：
@Service(version = "v2.0")
然后在服务调用方的@Reference注解上同样配置version属性：
@Reference(version = "v2.0")
private UserService service;
负载均衡
如果一个服务提供者是集群部署的，那一个服务消费者在多个服务中如何选择一个就是负载均衡。
Random随机策略
给每个服务提供者添加一个权重值，当服务消费者进行调用的时候会通过权重值进行随机的选择。如果想让其中一个服务大一点压力，就可以将服务的权重调高一些。
服务提供者：
权重的设置就是在@Service注解上添加weight属性，值选择为100则表示此类中的方法权重为100。
@Service(weight=100)
服务消费者：
在@Reference注解上，使用loadbalance属性指定负载均衡的方案，随机策略值为random。
@Regerence(loadbalance="random")
服务提供方权重的设置是相同的，服务消费方只需要更改loadbalance属性值。
RoundRobin按权重轮询
进行轮询的时候，权重越高被轮询到的次数越多。第一轮轮询将轮询全部的服务，第二轮将轮询所有服务中权重较高的服务，而忽略权重最低的服务，以此类推。
LeastActive最少活跃调用数
根据每个服务最后一次处理请求的时间进行排序，优先选择最快响应的服务，相同速度响应的服务采用随机的方式。
ConsistentHash一致性Hash
相同参数的请求将发送到同一个服务提供者。
集群容错
容错也就是当服务的调用出现报错之后，如何去做下一步操作。
容错的设置要在服务消费方的@Reference注解的cluster属性上进行设置。
Failover Cluster：失败重试，也就是此前在超时重试一章中讲到的。重试是默认的容错机制，当出现失败的时候会重试其他服务器，默认重试两次，或者通过@Sertice注解的retries属性进行配置。
重试操作通常用于查询操作，因为重复的查询不会造成数据的更改，但是重复的增删改却极有可能导致数据错误。
重试机制的cluster属性值为failover。
Failfast Cluster：快速失败，也就是在失败后不做任何操作，此请求只允许执行一次。通常用于写操作。
Failsafe Cluster：失败安全，也就是在调用导致报错了以后直接忽略报错，返回一个空结果。通常用于日志或者其他价值不高的操作。
Failback Cluster：失败自动恢复，当服务发送失败以后会自动恢复，直到请求正常返回。
Forking Cluster：并行的调用多个服务器，只要一个服务器成功就返回成功结果。这种操作比较消耗性能。
Broadcast Cluster：广播调用所有服务提供者进行逐个调用，任何一个服务报错都将导致报错。
具体关于容错的细节可参见dubbo官方文档。
服务降级
服务降级也就是表示将次要的服务进行停用或者屏蔽掉次要服务的异常。
所有关于服务降级的设置都在服务消费者的@Reference注解上进行设置：
-
@Reference(moke = "force:return null")：停止对此注解注入的服务的调用，所有调用直接返回null值。用来屏蔽不可用的服务。 -
@Reference(moke = "fail:return null")：如果消费方在调用此注解注入的服务的方法的时候，方法内抛出了异常则返回null，并且不会抛出异常到消费方。用来容忍不重要的服务在不稳定时期的调用结果。