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内服务端配置未被修改，释放长连接，返回客户端