nacos config 工作原理
目前任务调度在项目中的问题
- 配置不能实时刷新，一些业务配置属性及开关需要重新启动
- spring cloud config 支持实时刷新需要引入 spring cloud bus，但是bus 又依赖mq，针对于渠道微服务，依赖较多，不够简单
- spring cloud config 基于git ，目前目前在gitlab 上管理，管理台不够好用
调研及横向对比
- spring cloud config
- apollo 携程
- Disconf 百度开源项目，目前不维护
- nacos 阿里开源项目，配置及注册中心
- consul(go 语言开发) 注册及配置中心
调研结果
选型nacos，原因：
- 简单、配置准实时刷新
- 社区目前较为活跃
- spring cloud config 可以平滑迁移至nacos
- apollo 功能相对完善，但是基于zookeeper，结构较为复杂，nacos 集群 + 域名 + nginx 可以解决可用性、横向扩容
- consul 相对简单
- 没有权限控制-
- 配置支持刷新，但是时效性差，客户端定时轮询获取配置默认1s，性能差
- 没有fail over 策略，如果服务重启，consul挂掉，启动会失败（nacos 会有failover 文件保存到本地）官方文档翻译
分析nacos
- 可用性
- 准确定
- 性能
client config 端
- 可用性
nacos client 启动服务时会先从failOver获取缓存文件，不存在从server端获取，server 端获取异常从本地snapshot 获取
nacos client 挂掉，nacos server 同时挂掉，服务可以启动（前提是不删除snapshot版本）
- 准确定
- nacos client 使用long-polling 保证数据变更准准实时刷新
- 性能
- 客户端使用Long-polling的方刷新配置，拉-推的组合模式。相比polling 更节省网络资源和cpu
- 优先从本地缓存读取配置文件
server config 端
- 可用性
- 支持集群cluster
- 满足CAP中的A(avaliable)和P(partion tolerance) ，server name 满足 CP 理论。所有的请求都会到leader节点处理。
- raft算法leader 挂后、只要存在一个节点也可以提供服务
- 准确性
- 所有节点是对等节点，publishConfig 数据修改后，会触发事件，通知集群其他节点dataChange接口
- 性能
- servlet 3.0 请求异步处理，LongPolling+ AsyncContext + 事件监听模式，
- 数据变化实时返回，请求超时时间内有保证数据的实施性
- 数据无变化添加监听，有变化，监听实时处理返回结果
- 超过一定时间无变化，返回结果 无变化
- 本地缓存文件，获取配置文件都从本地获取返回而不是数据库
- 大量基于事件处理方式，保证实时性
nacos 涉及知识
- spring 自定义配置源 NacosPropertySourceLocator 实现 PropertySourceLocator 将端配置交给spring 管理（参考 spring 自定义数据源：https://www.cnblogs.com/lizo/p/7683300.html）NacosPropertySourceLocator
- spring 事件监听
- servlet 3.0 asyncContext 异步处理
- raft 算法
- spring @RefreshScope 动态刷新bean
- spring boot acutor nacos 接入了endPoint（NacosConfigEndpoint extends AbstractEndpoint> http://localhost:8080/nacos_config 查看endPoint数据）
- spring boot health nacos 接入 healthIndicator （NacosConfigHealthIndicator extends AbstractHealthIndicator）http://localhost:8080/health 健康检查，通过查询接口来处理。不太理解为啥是以dataId为维度健康检查
最后附上自己精心制作的nacos工作原理图
