回声测试

检测服务是否可用，dubbo获取的所有服务代理对象都实现了EchoService接口，用于监控
在这里插入图片描述
代码实现

如果没问题返回OK字符串否则抛出异常在这里插入图片描述
输出结果
实际生产中可以部署这样一个接口进行测试service的可用性

泛化调用

当provider发布了某个接口A，但Consumer不知道这个接口A具体内容，但直到其中某个方法时，可采用泛化调用（但不推荐，影响透明化），跨越了消费端的代理对象

在消费端引用接口时开启

<!-- 声明需要暴露的服务接口 -->    
<dubbo:reference id="hystrixService" interface="com.sdcuike.dubbo.learning.service.HystrixService" generic="true" retries="0"/>

generic=”true”这个就是用来表示当前接口是泛化调用的

代码中调用时

//获取上下文
 ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext(new String[]{ "spring.xml"}); 
 //获取bean，强转成GenericService（这是一个代理对象，dubbo定义的） 
 GenericService hystrixService=(GenericService) context.getBean("hystrixService")
 //调用方法，这里第一个参数是方法名，第二个是参数类型，第三个是实际入参
 Object result = hystrixService.$invoke("testGenerRe", new String[]{ "java.lang.String"}, new Object[]{ "test"});

1、问题：若泛化调用服务消费端先启动，在服务提供端未启动之前，泛化调用服务消费端某接口(a)进行了一次调用，在后续即使服务提供端成功启动，泛化调用服务消费端依然不能正常访问某接口(a)
2、原因：因为ReferenceConfig实例很重，封装了与注册中心的连接以及与提供者的连接，需要缓存，否则重复生成ReferenceConfig可能造成性能问题并且会有内存和连接泄漏。所以在调用服务时，不论服务提供端接口服务是否存在，ReferenceConfigCache都会缓存ReferenceConfig实例(若调用服务提供端不存在，ReferenceConfig实例的ref参数为空，即不能生成GenericService对象)，再下次请求时，即使服务提供端正常提供服务，但因为ReferenceConfigCache已经缓存了ReferenceConfig实例，所以不会再重新创建链接，直接从ReferenceConfigCach缓存中获取GenericService对象，导致GenericService实例一直报空指针(因为ref参数为空)，最终导致一直调用不到真正的服务
3、处理方法：在GenericService对象调用方法($invoke)之前,先判断GenericService是否为空，若为空，则调用ReferenceConfigCache对象的destroy方法，下次调用时即会重新生成ReferenceConfig实例，不会再从缓存中取。