作者回复: 你好,javaxu:找寻通过 NacosService 拉取数据的核心关键口子,然后研究一番是怎么读取 nacos 配置的,相信你一下就能找到突破口的。
作者回复: 你好,飞飞:服务端配置了我timeout 后,最后会被消费者订阅,这样对于消费者而言,就天然有了两套,一套啥消费者本身设置的,一套是提供方订阅回来的,把握消费方优先,颗粒度越小越优先原则就好啦~
作者回复: 你好,张三丰:不是不识别 api 的配置,而是在新老版本兼容的情况下,其实在消费方是有 api 的 invoke 对象的,只是因为消费方的订阅策略,所以选择了注解上的配置。对于这种新老版本兼容的情况,一定要周全的将一些重要的配置,该默认的都显示的默认好,并且做好策略的精准对应,方能很好的进行过度。
作者回复: 你好,夏帆:可以参考下【org.apache.dubbo.common.URL#getMethodParameter(java.lang.String, java.lang.String, int)】这个方法,然后想办法替换其中对应属性的值。
作者回复: 你好,徐有鱼:因为提供方要注册,假设当作一个很普通的提供方服务方,那么这个提供服务方有哪些参数设置的能力,是不是得告诉别人,这样别人才能根据参数因地制宜的做出相应的对策,所以这也就是为什么提供方的一些参数需要通过注册的方式向别人宣告提供方的能力限制范围。 但是恰巧这个场景是因为有接口级消费、应用级消费,混在一起,造成了这样的现象。
作者回复: 你好,杨老师:我在文中有这样一段描述〖因为提供方走进了默认的注册服务策略,消费方那边又恰好采用的是智能决策策略,就变成使用新版本服务发现类进行远程调用了。〗 对于消费方而言,提供方通过API形式、注解形式的数据其实都在消费方的invokers中,只不过消费方总是有使用订阅策略的,恰巧使用到了新版的策略。
作者回复: 你好,Geek_5a425f:你理解是对的,可以从 DefaultFuture 源码类的构造方法可以看出来的。
作者回复: 你好,Geek_5a425f:所谓的粒度越细,比如一个类有N个方法,那么方法就比类的粒度越细。也可以理解为越精确的地方粒度就越细。
作者回复: 你好,阿昕:你理解的很到位,确实是的,同一个namespace下的group+dataId不能重复。
作者回复: 你好,y:消费方能感知到提供方API设置的参数,主要是提供方将这些信息写到了注册中心,消费方一旦订阅提供方的接口,然后就能感知提供方在API设置的这些参数了。如果想再找找感觉认识一下的话,可以留意后续的“第 25 章节,注册扩展”。