现在本地启动Starter，MgHeadCloudservice实现类加到了pom中，Setecloudservice没加入实现类pom
两者的接口都标记了CloudService，启动---------->调用
发现启动是成功的，说明 CloudReference = Autowired (required = false)
其实并不是，因为这里由CloudService产生了代理对象，被注入
这里可以看到两个对象，不管本地有没有，都会生成一个proxy代理对象用于注入，所以CloudService发挥作用，而不是像Autowired (required = false)一样，本地没有就注入一个null
实际调用，不管MgHeadCloudservice有没有显式指定gv，此时都可以执行成功，因为线上本地都有
那么Setecloudservice由于本地没有，所以进入远调策略，默认应当是寻找同gv的服务（没有），所以抛出异常也很合理
所以就有个逻辑：
线上：加了CloudService和CloudComponent会注册到线上
本地：starter.pom引入了会加入到本地容器
消费：本地线上都有会用本地，而不是本地有直接用
生产：先成为本地组件，再注册到远程
最终：（一体化包的前提下，大多不合理的情况会在分布式下出现）
autowired调Component = 合理
autowired调CloudService+CloudComponent = 合理 （复合注解）
CloudReference调Component = CloudReference退化成autowired理论合理，但实际上无法产生代理来处理这些逻辑，所以匹配上只有CloudService标记的接口，才有优先本地这种所谓的优先调用策略。
这里感觉可以改进，理论可实现。
CloudReference调CloudService+CloudComponent = 合理
结合之前一个QI：
之前出现一个问题CloudReference引用一个普通Component，按文档应当可以兼容注入，但是注入不了，对象也不是proxy的，而是null，所以很奇怪，掉的时候报了个-1
复现：尝试将某个远调组件降级，降成普通component，且启动pom且引该实现类，发现即使文档里说了如果存在本地服务，可以直接使用而忽略RPC调用，但是这种情况表述的应该是使用CloudComponent这一套注解且一体化包的形式（既有又有）的情况
这里的CloudService注解最直接的处理：直接导致的注入对象的Proxy对象的产生，最后远调的时候是proxy调用，如果找不到再抛RPC异常
当线上不存在时，仅有本地service时，这个时候还使用CloudReference
觉得理论上是可以直接退化成 Autowired (required = false)
但是这里开发上还是CloudReference的处理逻辑有难点，CloudReference发现标记接口没有CloudService注解，所以无法产生proxy对象，即使此时本地真的有普通Component，生成不了间接代理对象直接给了个null，直接退化成 Autowired的策略也无法实现了。所以所谓的优先逻辑是定义在代理对象中的
最终结论：日常开发中，建议规范上必须一致使用
这个时候调的时候报的异常就不是RpcException了，而是nullpointerException，但是都会报错
这就是为什么远调使用了三个注解
Reference：标记要调用谁
Service：标记接口，控制调用方法，生成统一的调用策略，路由规则等
Component：控制接口实现类服务的具体注册、上线
可以知道：
本地实现：两个注解满足
远调实现：好像也可以完全两个注解满足，类似Dubbo？三个可能是为扩展中间的AOP功能
如果您喜欢此博客或发现它对您有用，则欢迎对此发表评论。 也欢迎您共享此博客，以便更多人可以参与。 如果博客中使用的图像侵犯了您的版权，请与作者联系以将其删除。 谢谢 ！