注册中心的核心数据是服务的名字和它对应的网络地址，当服务注册了多个实例时，我们需要对不 健康的实例进行过滤或者针对实例的⼀些特征进行流量的分配，那么就需要在实例上存储⼀些例如 健康状态、权重等属性。随着服务规模的扩大，渐渐的又需要在整个服务级别设定⼀些权限规则、 以及对所有实例都生效的⼀些开关，于是在服务级别又会设立⼀些属性。再往后，我们又发现单个 服务的实例又会有划分为多个子集的需求，例如⼀个服务是多机房部署的，那么可能需要对每个机 房的实例做不同的配置，这样又需要在服务和实例之间再设定⼀个数据级别。
Zookeeper 没有针对服务发现设计数据模型，它的数据是以⼀种更加抽象的树形 K-V 组织的，因 此理论上可以存储任何语义的数据。而 Eureka 或者 Consul 都是做到了实例级别的数据扩展，这 可以满足大部分的场景，不过无法满足大规模和多环境的服务数据存储。Nacos 在经过内部多年生 产经验后提炼出的数据模型，则是⼀种服务-集群-实例的三层模型。如上文所说，这样基本可以满足 服务在所有场景下的数据存储和管理。
Nacos 的数据模型虽然相对复杂，但是它并不强制你使用它里面的所有数据，在大多数场景下，你 可以选择忽略这些数据属性，此时可以降维成和 Eureka 和 Consul ⼀样的数据模型。
目前的⼀致性协议实现，⼀个是基于简化的 Raft 的 CP ⼀致性，⼀个是基于自研协议 Distro 的 AP ⼀致性。Raft 协议不必多言，基于 Leader 进行写入，其 CP 也并不是严格的，只是能保证⼀ 半所见⼀致，以及数据的丢失概率较小。Distro 协议则是参考了内部 ConfigServer 和开源 Eureka， 在不借助第三方存储的情况下，实现基本大同小异。Distro 重点是做了⼀些逻辑的优化和性能的调优。
负载均衡严格的来说，并不算是传统注册中心的功能。⼀般来说服务发现的完整流程应该是先从注 册中心获取到服务的实例列表，然后再根据自身的需求，来选择其中的部分实例或者按照⼀定的流 量分配机制来访问不同的服务提供者，因此注册中心本身⼀般不限定服务消费者的访问策略。 Eureka、Zookeeper 包括 Consul，本身都没有去实现可配置及可扩展的负载均衡机制，Eureka 的 负载均衡是由 ribbon 来完成的，而 Consul 则是由 Fabio 做负载均衡。
服务端的负载均衡，给服务提供者更强的流量控制权，但是无法满足不同的消费者希望使用不同负 载均衡策略的需求。而不同负载均衡策略的场景，确实是存在的。而客户端的负载均衡则提供了这 种灵活性，并对用户扩展提供更加友好的支持。但是客户端负载均衡策略如果配置不当，可能会导 致服务提供者出现热点，或者压根就拿不到任何服务提供者。
抛开负载均衡到底是在服务提供者实现还是在服务消费者实现，我们看到目前的负载均衡有基于权 重、服务提供者负载、响应时间、标签等策略。其中 Ribbon 设计的客户端负载均衡机制，主要是 选择合适现有的 IRule、ServerListFilter 等接口实现，或者自己继承这些接口，实现自己的过滤逻 辑。这里 Ribbon 采用的是两步负载均衡，第⼀步是先过滤掉不会采用的服务提供者实例，第二步 是在过滤后的服务提供者实例里，实施负载均衡策略。Ribbon 内置的几种负载均衡策略功能还是比 较强大的，同时又因为允许用户去扩展，这可以说是⼀种比较好的设计
5.4健康检查Zookeeper 和 Eureka 都实现了⼀种 TTL 的机制，就是如果客户端在⼀定时间内没有向注册中心发 送心跳，则会将这个客户端摘除。Eureka 做的更好的⼀点在于它允许在注册服务的时候，自定义检 查自身状态的健康检查方法。这在服务实例能够保持心跳上报的场景下，是⼀种比较好的体验，在 Dubbo 和 SpringCloud 这两大体系内，也被培养成用户心智上的默认行为。Nacos 也支持这种 TTL 机制，不过这与 ConfigServer 在阿里巴巴内部的机制又有⼀些区别。Nacos 目前支持临时实 例使用心跳上报方式维持活性，发送心跳的周期默认是 5 秒，Nacos 服务端会在 15 秒没收到心 跳后将实例设置为不健康，在 30 秒没收到心跳时将这个临时实例摘除。
不过正如前文所说，有⼀些服务无法上报心跳，但是可以提供⼀个检测接口，由外部去探测。这样 的服务也是广泛存在的，而且以我们的经验，这些服务对服务发现和负载均衡的需求同样强烈。服 务端健康检查最常见的方式是 TCP 端口探测和 HTTP 接口返回码探测，这两种探测方式因为其协 议的通用性可以支持绝大多数的健康检查场景。在其他⼀些特殊的场景中，可能还需要执行特殊的 接口才能判断服务是否可用。例如部署了数据库的主备，数据库的主备可能会在某些情况下切换，需要通过服务名对外提供访问，保证当前访问的库是主库。此时的健康检查接口，可能就是⼀个检 查数据库是否是主库的 MYSQL 命令了。
客户端健康检查和服务端健康检查有⼀些不同的关注点。客户端健康检查主要关注客户端上报心跳 的方式、服务端摘除不健康客户端的机制。而服务端健康检查，则关注探测客户端的方式、灵敏度 及设置客户端健康状态的机制。从实现复杂性来说，服务端探测肯定是要更加复杂的，因为需要服 务端根据注册服务配置的健康检查方式，去执行相应的接口，判断相应的返回结果，并做好重试机 制和线程池的管理。这与客户端探测，只需要等待心跳，然后刷新 TTL 是不⼀样的。同时服务端健 康检查无法摘除不健康实例，这意味着只要注册过的服务实例，如果不调用接口主动注销，这些服 务实例都需要去维持健康检查的探测任务，而客户端则可以随时摘除不健康实例，减轻服务端的压 力。
Nacos 既支持客户端的健康检查，也支持服务端的健康检查，同⼀个服务可以切换健康检查模式。 这种健康检查方式的多样性非常重要，这样可以支持各种类型的服务，让这些服务都可以 使用到 Nacos 的负载均衡能力。Nacos 下⼀步要做的是实现健康检查方式的用户扩展机制，不管是服务端探测还是客户端探测。这样可以支持用户传入⼀条业务语义的请求，然后由 Nacos 去执 行，做到健康检查的定制。
虽然大部分用户用到的性能不高，但是他们仍然希望选用的产品的性能越高越好。影响读写性能的 因素很多：⼀致性协议、机器的配置、集群的规模、存量数据的规模、数据结构及读写逻辑的设计 等等。在服务发现的场景中，我们认为读写性能都是非常关键的，但是并非性能越高就越好，因为 追求性能往往需要其他方面做出牺牲。Zookeeper 在写性能上似乎能达到上万的 TPS，这得益于 Zookeeper 精巧的设计，不过这显然是因为有⼀系列的前提存在。首先 Zookeeper 的写逻辑就是 进行 K-V 的写入，内部没有聚合；其次 Zookeeper 舍弃了服务发现的基本功能如健康检查、友好 的查询接口，它在支持这些功能的时候，显然需要增加⼀些逻辑，甚至弃用现有的数据结构；最后， Paxos 协议本身就限制了 Zookeeper 集群的规模，3、5 个节点是不能应对大规模的服务订阅和查 询的。
在对容量的评估时，不仅要针对企业现有的服务规模进行评估，也要对未来 3 到 5 年的扩展规模 进行预测。阿里巴巴的中间件在内部支撑着集团百万级别服务实例，在容量上遇到的挑战可以说不 会小于任何互联网公司。这个容量不仅仅意味着整体注册的实例数，也同时包含单个服务的实例数、 整体的订阅者的数目以及查询的 QPS 等。Nacos 在内部淘汰 Zookeeper 和 Eureka 的过程中， 容量是⼀个非常重要的因素。
Zookeeper 的容量，从存储节点数来说，可以达到百万级别。不过如上面所说，这并不代表容量的 全部，当大量的实例上下线时，Zookeeper 的表现并不稳定，同时在推送机制上的缺陷，会引起客 户端的资源占用上升，从而性能急剧下降。
Eureka 在服务实例规模在 5000 左右的时候，就已经出现服务不可用的问题，甚至在压测的过程中， 如果并发的线程数过高，就会造成 Eureka crash。不过如果服务规模在 1000 上下，几乎目前所有 的注册中心都可以满足。毕竟我们看到 Eureka 作为 SpringCloud 的注册中心，在国内也没有看到 很广泛的对于容量或者性能的问题报告。
Nacos 在开源版本中，服务实例注册的支撑量约为 100 万，服务的数量可以达到 10 万以上。在 实际的部署环境中，这个数字还会因为机器、网络的配置与 JVM 参数的不同，可能会有所差别。
测试报告地址
https://nacos.io/en-us/docs/nacos-naming-benchmark.html https://nacos.io/en-us/docs/nacos-config-benchmark.html
