配置中心
长轮询，客户端启动后连接nacos 获取配置，同时发起长轮询请求，server 挂起请求，直到有配置更新或超时。
有配置更新时，server 响应，客户端重新拉配置并触发监听器刷新
本地有缓存配置，保证可用。
服务中心
Nacos 不是纯粹的最终一致性，而是"AP + CP"。
● 临时实例 ➡️ AP模式（Distro协议）➡️ 要可用性
● 持久化实例/配置 ➡️ CP模式（Raft协议）➡️ 要强一致
"Nacos 2.x 节点间通过 gRPC 保持长连接。如果是 CP 模式，底层走 JRaft 协议进行 Leader-Follower 的数据复制和选举；如果是 AP 模式，底层走 Distro 协议，各节点对等，通过异步广播和定时校验保证数据最终一致。"
新服务注册
AP模式不能立马感知，distro 协议是异步同步，新注册的服务会写入当前节点内存中，后面通过广播方式进行同步，其他节点获取服务列表会很有短暂延迟，但最终一致。
CP模式，raft协议要求写操作必须同步过半节点才响应客户端，集群内大部分节点都有该服务实例，实现强一致性
主节点挂了怎么办
AP模式，节点是平等的，所以挂了一个，其他的节点继续提供服务。
CP模式，基于raft算法自动触发选主，选主期间集群短暂不可写，但是是秒级。读请求可以通过本地缓存响应。
● 服务注册中心：绝大多数场景下是 AP 模式（Distro 协议），优先保障服务发现的高可用。
● 配置中心：纯 Nacos 集群模式下是 CP 模式（Raft 协议），优先保障配置数据的绝对安全与一致；接入外部 DB 后则偏向 AP 模式
在绝大多数微服务场景中，Nacos 扮演的是一个 AP 的角色，以保障服务发现的高可用；只有在特定需求下，才会将其作为 CP 使用。
为什么需要服务注册
微服务架构中，服务实例的IP地址和端口是动态变化的，用于解决服务地址不固定的问题。
服务器启动时向注册中心注册自己的地址和健康状态，注册中心通过心跳机制维护服务实例列表。
Nacos心跳检测
维护服务实例的健康状态，根据实例类型分为两种模式：
临时实例
由客户端自主上报心跳，默认是5s，超过15s没收到，则把实例标记为不健康。超过30s，则剔除该实例。
持久化实例
nacos服务器主动向实例发起健康检查。TCP端口探测或http请求，检查失败，标记为不健康，但不会删除
Nacos路由发现
分为服务注册和服务发现两部分。
服务注册阶段
服务启动时向nacos server发送注册请求，服务端将实例信息存入内存注册表，并在集群之间同步。
服务发现阶段
nacos1.x依赖客户端定时拉取，2.x优化为服务端主动推送变更，结合客户端定时拉取的方式，保证数据实时性。
客户端获取到实例列表，结合权重、元数据、集群信息等策略进行负载均衡，选择合适的实例进行调用。