作者回复: 往静态方法中注入一个可被刷新的属性吗?这可以间接曲线救国,把属性注入到一个受托管的对象里,静态类调用spring原生方法从上下文中拿这个对象的实例
作者回复: Nacos在国内用Spring Cloud架构的公司里应用程度还不错,而且国内nacos+dubbo生态也还可以,但在国外Nacos用的确实不多
作者回复: 我提示一下研究注解的一个方向,同学可以顺着去验证一下自己的想法。 一个注解除了自身的解释器以外,点击进到该注解源码你会发现有一些子注解,比如@RestController里就会有额外的子注解:Controller+ResponseBody注解。所以同学可以1)查看注解当前的解释器 2)查看子注解的解释器 来了解一个注解完整的功能
作者回复: 1. 获取的配置项加载到spring上下文中,可以认为是内存中。 2. 这样做没问题,controller这一层是mvc时代的产物,实际开发中并没有太多用处,只是用来安置spring mvc注解。所以去掉controller,对外直接暴露service是可以的,这也是dubbo、grpc这类RPC框架所使用的规范,
作者回复: 是通过HttpPost长轮询做的,可以理解为Pull模式和Push模式的折中方案,客户端在此期间是等待
作者回复: 无论value有没有在上下文中使用到,只要触发了动态推送,同学都可以在日志里找到一行消费了nacos event的推送通知。但如果需要刷新上下文context,就要@RefreshScope (本质是scopeName="refresh"的 @Scope注解)
作者回复: 几十台这种并发量不会产生性能问题,不然这个配置系统A可承担不起配置系统的重任哦。 不过从设计角度来看,我可以提供一个新的思路。同学使用的是push方式,即B收到通知后主动push消息到A,这种方式是一种常用的思路,但要注意错误处理,即push消息丢失或者网络超时的时候如何处理。我建议可以结合pull方式,即配置系统A同时也主动pull各个机器上的配置信息,大大提高容错。至于通知的内容,我建议可以采用类似version control的方式,即配置副本的版本控制号,这样可以很容易知道目标机器上的配置是哪一版,进而知道推送是否成功
作者回复: 这部分文件没有上传到github哈,同学只能看下课程里图片中的配置截图,里面的内容比如DB配置这些都是从项目yml里copy过去的
作者回复: 同学把本地项目运行环境提供一下,比如是否使用了docker,然后报错的时间节点是在属性刷新refresh的时候,还是在启动项目获取配置阶段
作者回复: spring cloud config正规军出品保质保量,不过它和Nacos注册中心不怎么对付,有些功能存在兼容性问题