Nacos

Nacos架构图P116

　　Nacos Server服务端关键组件：

　　　　1.Naming Service用于服务注册

　　　　2.Config Service用于配置管理

　　　　3.OpenAPI提供服务注册及服务查询接口

　　Nacos Console客户端:

　　　　通过调用服务端OpenAPI接口查询服务信息、配置信息

Naming Service注册中心

　　客户端注册时客户端流程：

　　    NacosServiceRegistry调用NacosNamingService的注册方法注册到Naming Service，

　　　并同时开启一个一次性的延时调度的心跳任务，这个心跳任务是利用ScheduledThreadPoolExecutor.schedule来延时调度一个BeatTask，

　　　这个BeatTask实现runnable接口，在run方法内部又利用同一个ScheduledThreadPoolExecutor来递归调用BeatTask，默认是5s调一次

　　客户端注册时服务端流程：

　　　　服务端维护一个所有服务实例的 HashMap< NameSpace, ConcurrentHashMap<ServiceName, Service实例> >，每个命名空间都有各自的ConcurrentHashMap

　　　　Nacos Client调用OpenAPI注册到Naming Service时，会将服务实例添加到对应命名空间的ConcurrentHashMap中

　　　　服务端定时任务检测当前服务下的所有实例最后发送心跳包的时间，超时后标记实例状态，并发布服务实例变更事件

Config Service配置中心

　　SpringCloudConfig没有UI界面，修改配置繁琐

　　Nacos多环境配置切换实现步骤：

　　　　1. 在服务的 booststrap.properties 文件中配置服务名service-demo、Nacos服务地址、配置的DataId前缀(非必须)【P138】

　　　　2. 在Nacos中配置两个配置

　　　　　　2.1生产环境文件：[Data ID:service-demo-prod，配置格式:properties]

　　　　　　2.2测试环境文件：[Data ID:service-demo-test，配置格式:properties]

　　　　3. 启动jar包时指定 -spring.profiles.active=prod/test 即可使用不同环境配置

　　配置动态更新原理：P146　

　　　　push和pull模式的优劣对比：push实时性高，但须维护长连接；pull不能保证实时性，定时拉取时可能会做无用功

　　　　Nacos采用客户端主动pull的模式+服务端长轮询机制

　　　　1. 客户端主动发起PULL请求，若服务端配置发生变化，服务端直接返回变更的配置

　　　　2. 若服务端配置未发生变化，服务端将hold住客户端的pull request，创建一个延时29.5s(长连接保持的时间)后执行的定时任务，

　　　　　并将当前客户端的长轮询连接加入到allSubs队列

　　　　3. 若在29.5s内服务端配置被用户修改了，服务端触发配置修改事件通知，服务端监听该事件的任务将遍历allSubs队列，

　　　　　找到发生修改的配置对应的客户端连接，将最新配置PUSH给客户端

　　　　4. 若在29.5s内服务端配置未被修改，释放长连接，返回客户端