说一下自己公司的服务注册中心怎么技术选型的

CAP 理论

C：一致性
A :可用性
P：分区一致性 (一定时间内完成一致性，避免造成分区数据不一致)
一般只能保持CP 或者AP

下面先来分析一下他们的优劣

eurake

缓存架构图

eurake本身有缓存策略，本地注册表更新了服务的地址后，需要先同步至ReadWriteCacheMap，然后在同步至ReadOnlyCacheMap，然后其他服务就从ReadOnlyCacheMap里面拉去最新的注册表信息。所以在同步和拉取的过程当中，会有很多时间延迟。

Eurake 采用的是peer to peer 的方式在每个节点间同步数据，是典型的AP模式，注册中心任意一个节点挂了，整体服务还是可以继续对外提供服务的，因为每个节点的信息都是一致的。

但是AP模式则舍弃了CAP中的C（数据一致性），因为同步的过程中，有可能收到新的注册信息的节点挂了，或者同步时延，都会造成数据不一致。

zookeeper

ZK 典型的master-salve主从架构。写只能从master写入，然后再同步到各个slave节点。而且ZK是典型的CP模式，保证了数据的强一致性。当master挂了以后，其他的salve会进行重新选举，选举期间，整体服务会处于不可用状态。

各种主流注册中心功能对比：

	Nacos	Eureka	Consul	CoreDNS	Zookeeper
一致性协议	CP+AP	AP	CP	—	CP
健康检查	TCP/HTTP/MYSQL/Client Beat	Client Beat	TCP/HTTP/gRPC/Cmd	—	Keep Alive
负载均衡策略	权重/ metadata/Selector	Ribbon	Fabio	RoundRobin	—
雪崩保护	有	有	无	无	无
自动注销实例	支持	支持	不支持	不支持	支持
访问协议	HTTP/DNS	HTTP	HTTP/DNS	DNS	TCP
监听支持	支持	支持	支持	不支持	支持
多数据中心	支持	支持	支持	不支持	不支持
跨注册中心同步	支持	不支持	支持	不支持	不支持
SpringCloud集成	支持	支持	支持	不支持	不支持
Dubbo集成	支持	不支持	不支持	不支持	支持
K8S集成	支持	不支持	支持	支持	不支持

容量：
eurake和zk均不适合进行大规模的集群部署。因为无论是peer to peer 或者zk的master-slave模式，均需要向其他节点进行数据一致性同步，会造成大量的网络开销，容易引起羊群效应。

所以 nacos只目前比较不错的选择，而且nacos 还自带配置中心功能，相当于eurake + spring cloud config，还有控制台进行服务管理和分布式配置中心管理。