盘点常用的注册中心上图基本表达了注册中心的交互过程，体现了三个角色的关系：并定期向RegistryCenter发送心跳（heartbeat），以证明在服务关闭时可以等待一段时间向RegistryCenter发起注销服务消费者。服务消费者（Client）：服务启动后，RegistryCenter订阅需要使用的服务（Server），缓存在实例列表中到对应的服务（Server）发起调用时，从实例中选择一个内存中要进行远程调用的服务列表。当服务关闭时，取消订阅RegistryCenter。除了。当服务的实例列表发生变化（新增或移除）时，会通知订阅该服务的Consumer，以便Consumer刷新本地缓存。有的注册中心不提供这个功能，比如Eureka，二手Client定期轮询更新本地缓存大多数情况下，一个服务可能既是Client又是ConsumerCAP理论是分布式架构中的一个重要理论一致性（Allnodes同时拥有相同的数据)可用性(保证每次请求成功或失败都有响应)分区容忍度(系统中任何信息的丢失或失效都不会影响系统的继续运行)到期根据C和A的特性，它们不能共存。不可能两个CAP都拿，只能拿两个，或者AP或者CP注册中心的牌子说到这里先说服务发现。当我们的服务从单机走向社会时，服务发现就发生了。一开始，服务发现是通过DNS协议实现的，也就是网络IP协议，http形式的服务发现基本都是通过DNS+LVS实现的。这个时候IP一般是在LVS中配置的。之后大家开始玩RPC服务，服务的部署开始频繁起来。为了实现动态上下线，注册中心的目的就是推送IP栏。ZookeeperZookeeper一直是国内注册中心的一哥。多半是因为Dubbo在国能的盛行。EurekaEureka是在线视频租赁提供商NetfLix是开源的，公司的理念还是挺超前的。Netflix是一种流媒体服务。爱情、死亡与机器人、怪奇物语、纸牌屋、黑镜……这些耳熟能详的美剧，都是它的作品。Netflix长久以来的商业模式其实就是众筹，用户用更低的价格看电视剧。现在已经进入原创剧集时代，这也是Netflix从众多电视巨头中突围的原因。这是非常顶级的。SpringCloud的很多组件都是Netflix做的，也就是Netflix的微服务生态。方便Spring开发者搭建微服务基础框架。Eureka也凭借着微服务概念的流行，以及与SpringCloud生态的深度融合，收获了一大批粉丝。NacosNacos是阿里开源的，它其实有很多功能，比如服务注册、配置管理、动态DNS服务、元数据管理注册中心等。数据一致性一直是分布式系统中的热点。目前基本分为两派：AP：对等部署的多写一致性CP：基于leader的非对等部署的单点写一致性，可以通过心跳检测。注册的时候要保证数据不会丢失，如果服务节点可以发送心跳，第一次注册成功就没有那么重要了（当然也很重要，这里指的是允许失败).这就是为什么Eureka使用自定义的Renew机制而不是Paxos协议的原因（据说获得了图灵奖）。对于dubbo来说，其实还是用Renew机制比较好，主要是它是注册在zookeeper上的一个临时节点，也允许服务下线。将心跳发送给zookeeper，更新服务节点。Zookeeper保证了一致性，保证了服务的高可用和机房容灾能力的可靠性。Nacos支持AP和CP两种协议，如图。在这个设计中，有一个show操作，就是将业务相关逻辑和底层同步逻辑进行分层，将业务读写抽象为Nacos定义的[datamodel]（#datamodel）。通过代理，按照一定的规则转发。数据模型注册中心核心数据是服务名称和IP地址。Zookeeper是一个树状的k-v数据结构，理论上满足各种上下文的数据。Eureka和Consul实现了实例级的数据扩展，满足最基本的需求。Nacos的数据模型比较复杂。如图：Nacos考虑了数据隔离模型，提供了四种。作为共享服务组件，需要能够保证各种环境下的数据隔离这在庞大的业务场景中很常见。上面说的业务逻辑和同步逻辑，其实指的是临时实例和持久实例。从定义上区分临时实例和持久实例的关键是健康检查临时实例使用客户端报告模式，而持久实例使用服务器端反向检测模式。临时实例需要能够自动剔除不健康的实例，不需要持久化存储实例。持久化实例使用服务端检测的健康检查方式。因为客户端不上报心跳，自然不可能自动移除掉线的实例。一些基础组件，如数据库、缓存等，往往无法上报心跳。在注册此类服务时，需要将其作为持久化Instance注册。大多数上层业务服务健康检查都是通过心跳检测来实现的。如果客户端在一定时间内没有发送心跳，服务节点将被注销。这种机制称为TTL（生存时间）。Eureka（自我保护机制：默认为90s）允许自定义检查服务自身的方法。不同的注册中心有不同的审核机制。Nacos有一个5秒的周期。如果15秒内未收到心跳，则该服务被标记为不健康。如果30秒没有收到心跳，该服务将被注销。另外，clientServices和serverservices不同：clienthealthcheck关注的是心跳的上报方式和服务不健康的机制。服务器健康检查主要关注检测服务器的方式、敏感性以及设置服务器服务健康状态的机制。一般来说，注册服务实例如果不调用该结构体主动注销，意味着维持健康检查的检测任务，而客户端服务实例可以随时注销不健康的实例，减轻客户端的压力服务器。负载均衡是合理的，负载均衡不是注册中心的传统艺术。是的。一般来说，服务发现的过程就是从注册中心获取实例列表，然后选择符合规则的服务提供者进行分配。注册中心不会限制消费者的访问策略。Eureka、zookeeper、Consul基本上都是这样。*Eureka的负载均衡由Ribbon负责；*Consul的负载均衡由Fabio完成。目前的负载均衡有基于权重、服务提供者负载、响应时间、标签等策略，Ribbon设计的客户端负载均衡机制主要是选择合适的现有IRule、ServerListFilter等接口分两步实现负载均衡：过滤掉不会被使用的服务提供者实例，在过滤后的服务列表中进行负载均衡。fabio是基于tags做loadBalance，和kubernetes类似，就是把tags传输给资源过滤，实现tagratio和weight的负载均衡.Nacos不仅提供加权负载均衡，还提供CMDB标签负载均衡。实现了同一标签优先接入的流量调度策略。如果服务部署在多个不同的地域，CMDB的负载会起到很好的效果充分均匀的分配流量。集群可扩展性Zookeeper基于leader非对等部署的单点写入一致性，无法实现自动多机房容灾；Eureka的部署方式天然支持多机房容灾。Nacos支持两种模式。部署，一种是部署和Eureka一样的AP协议。该模式只支持临时实例，可以完美替代目前的Zookeeper和Eureka，支持机房容灾。另一种是支持持久化实例的CP模式。此时不支持双机房容灾。机房容灾是异地多活的一部分，允许业务在访问服务注册中心时动态调整访问的集群节点，需要第三方做路由。多数据中心其实是远程比较活跃的部分。Zookeeper和Eureka没有官方的数据中心解决方案。Nacos有Nacos-Sync组件来做数据中心之间的数据同步。不仅可以实现Nacos之间的同步，还可以实现Nacos在zookeeper、k8s.Consul和Eureka的数据同步，实现生态大和谐。总结一下本文注册中心的特点，Nacos大而全，Eureka小而美，Consul其实和Nacos差不多。Zookeeper性能难以扩展
