注册中心
为什么？
第一个阶段：consume ->(invoke) -> provider
单节点，消费者和生产者的RPC调用。
第二阶段： consume ->(invoke) -> 多个 provider
消费者需要调用生产者集群。产生的问题：1. 生产者节点信息的存储 2.服务上下线的变更通知及服务健康检查
-
服务信息存储 主要任务。 服务注册 服务信息的写；服务发现 服务信息的读。（高并发、读多写少，基于内存）像 CopyOnWrite 写时复制，读时共享一份资源，写时复制一份数据并更新。
-
健康检测。防止服务进程假死和停止，减少错误调用。下游主动上报，上游主动请求。
-
上下游变更通知。需要即时性，保证可用性。通过什么方式？客户端轮询 pull 拉 ；服务端推送 push 推；
第一是服务的健康检测，通过连接敏感的特性，对服务宕机做到秒级发现，但为此也带来“网络不稳定导致服务频繁上下线”的负面影响；第二是内部角色之间的“推”和“拉”的机制，整个服务上下线流程都以实时的“推”为主。
推拉结合： nacos apollo zk的watch机制：zk只会发送事件类型和节点信息到客户端；收到变更通知的服务器自己去拉取更多的数据 (如果仅仅是推，把所有数据推过去，会出现推不过来；如果是拉，会出现拉不及时)
第三阶段：单节点故障问题，需要分布式的注册中心。
分布式会出现可用性和一致性问题。
CAP原则：
CAP是在一个分布式系统中，Consitency（一致性）、Availability（可用性）、Partition tolerance（分区容错性）。
-
AP 无主+数据同步 满足可用性，在网络出现异常的情况，系统仍可工作，但会出现节点数据不一致但情况。如eureka，允许短暂数据不一致。用户体验（舍弃一致性）。数据同步 P 节点之前对称，节点角色均等，对称式架构，各个节点需要互相通信，保证数据一致性，节点通信会指数型增长。
-
CP raft协议 选主+数据同步，保证钱财安全。数据同步 P 非对称，有专门的leader维护元数据。如zk
服务发起注册 通知 健康检查
一致性协议（选主 读写控制）
存储
