记一次RPC服务发布过程（系统提供和消费同一个服务）

记一次RPC服务发布过程

公司框架基本既定，没有再改的欲望，当然，最重要的是没有源码。需求很简单，只是刷新核心服务器缓存中的预加载的配置参数Map的值，但是目前对应的系统已经完善，分别有批处理管理系统、核心系统，服务流程是由管理系统发起服务调用调起核心系统暴露的批处理管理接口进行业务处理，最简单的处理当然是在核心提供服务，在管理系统消费服务，但是苦于没有管理系统源码，只能在核心系统处理，也就是说只能在当前系统提供和消费同一个服务，这个和单独提供或消费某个服务有点轻微区别，话不多说，上代码！

提供者配置

<dcits:service ref="cacheUtil" interface="com.***.test.nl.business.api.util.ICacheUtil" cluster="broadcast"/>

消费者配置

<dcits:reference id="iCacheUtil"
interface="com.***.test.nl.business.api.util.ICacheUtil" scope="remote" check="false" cluster="broadcast" >
</dcits:reference>

其中scope=“remote” 表示远程调用，cluster="broadcast"表示集群容错模式为广播（适用于缓存刷新或日志服务），最重要的是你会发现消费者id和提供者ref并不一致，这也是此文的核心所在！
1.提供者ref需要与系统注册到Spring容器的对象保持一致，否则将导致服务启动报错，同时其也是远程服务具体实现；
2.消费者id则需要与Spring容器中注册的对象有所区分，否则启动会报对象重复；
3.调用服务时，与Spring注入方式一致，但是要注意的是，此时引用的是消费者配置中的id,而不是提供者的注册id,如下

@Resource
private ICacheUtil iCacheUtil;

至此，配置完成，按照自己的需求进行业务开发就好了，要注意的是，避免循环调用服务就好了。

需要了解基础搭建的移步百度一大堆，这里推荐一个看起来简单易懂的：
https://blog.csdn.net/jingyangV587/article/details/84990837

需要了解dubbo底层原理的，我推荐下面这个链接，层次分明且简单易懂，适合新手研读：
https://blog.csdn.net/jingyangV587/article/details/84983770