dubbo——回声测试、泛化调用、RPC调用原理

回声测试

检测服务是否可用，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实例，不会再从缓存中取。

RPC调用原理

rpc是一种协议，客户端生成代理对象，服务端暴露中转对象，网络中使用rmi或者socket等协议都可以

服务方创建中转对象（源码）

主动暴露（手写）


消费端创建代理对象