1、微服务CAP
一致性C：所有节点在同一时间，数据完全一致；
可用性A：服务可用，且能正常响应；
容错性P：某节点有故障，仍能对外提供可用性和一致性的服务；
分析：提高容错，需要多节点；节点增多，难保一致性，需要更多时间同步；确保多节点一致性同步耗时增多，节点可用性下降
我们的希望：注册中心的注册信息可以是几分钟前的旧数据，而不是注册中心直接挂掉，即：可用性>一致性
2、zk、nacos、Eureka
ZK：强调CP(一致性和容错性)，可用性低；当master发生故障时，剩余节点会重新选举leader，选举耗时30-120s，期间服务不可用；
Eureka：强调AP(可用性和容错性)，一致性低；各个节点平等；
nacos：AP+CP混合制，默认是AP，但可以设置成CP；
ZK：zab协议：分布式一致性算法，崩溃恢复和消息广播；发现、同步、广播；选举leader并维护follower列表，同步数据到follower，新的数据广播到follower；
Raft协议：日志复制，记录命令为日志，强调leader和follower的执行日志保持一致，从而达到一致性；
选举流程：初始轮次+投票，接收投票 轮次和pk票，变更投票 统计，更改状态； Observer不参与投票和事务提交，提高读性能；新节点/宕机不影响，leader挂了才影响会重选；非观察者全转LOOKING状态；
初始流程-服务器LOOKING状态下，每个服务投票vote(sid服务器ID/服务器编号, ZID事件发生时间戳/节点创建最新修改时间戳)和自己的self（）比较，先value后key取大发出去；Leader变Leading，Follower变Following状态；
选举代码详解：选举类quorumPeer.start()磁盘读数据+上下文+选举；run方法有makeLeader()/makeFollower()创建；leader.lead()创建StateSummary标记最新事务和提交次数+与Learner单线程长连接+LearnerHander监控新节点；
followLeader方法-Follower.registerWithLeader()建立长链接5次+syncWithLeader()去同步数据-清空/删除无效；
Eureka：Client向Server注册服务ip端口url，消费者向注册中心获取提供者地址缓存到本地，从缓存读取调用；注册中心向订阅者提供宕机信息；节点每30s向注册中心发送心跳续约服务；90S无心跳剔除注册列表；
自我保护：统计15分钟内的失败比例，大于85%则不剔除防误杀，等待恢复心跳；
工作流程：等待注册或集群复制；注册/心跳续约/自我保护；获取服务到本地缓存；缓存无服务去注册中心刷新再缓存；缓存获取地址调用；
Nacos和Eureka：负载均衡Feign：
Nacos = Spring Cloud注册中心 + Spring Cloud配置中心
3、Dubbo