Nacos注册中心学习笔记

前言

英文全称Dynamic Naming and Configuration Service，Na为naming/nameServer即注册中心,co为configuration即注册中心，service是指该注册/配置中心都是以服务为核心。服务在nacos是一等公民。

在学习Nacos之前先来思考一个问题：注册中心应设计为AP还是CP系统？

参考《阿里巴巴为什么不用 ZooKeeper 做服务发现？》http://jm.taobao.org/2018/06/13/%E5%81%9A%E6%9C%8D%E5%8A%A1%E5%8F%91%E7%8E%B0%EF%BC%9F/

这篇文章的描述，阿里在很早就开始思考这个问题，对注册中心来说，AP和CP究竟哪种系统更加适合，在文中已经有详细的论证和阐述，简单来说，CP系统因为强一致性而只能放弃高可用性，但可用性对于注册中心来讲其实更为重要，注册中心不能因为自身的任何原因破坏服务之间本身的可连通性，这是注册中心设计应该遵循的铁律！一旦注册中心出现不可用，那服务的上线下线均受到影响，注册中心客户端虽然可以通过缓存等手段解决一部分可用性问题，但并无法完全避免可用性的缺失对服务间通信带来的影响。AP系统缺失了强一致性，文中提到会导致一定的流量不均衡，但随着最终一致性，流量不均衡的问题最终可以解决，但笔者认为，除了不均衡问题之外，服务下线信息如果没办法做到强一致性，还会导致增加服务失败的概率，这种服务失败的情况是否能够被业务场景所接受，也是需要考虑的因素，该如何解决和避免，是否应该在注册中心客户端层来对失败服务的ip做一定封锁，需要进一步思考。但总体来讲，比较认同AP系统更加适合作为注册中心这一结论。

下面就几个方面来介绍一下nacos注册中心的关键要点：

一、nacos如何进行服务注册、探活

服务注册方法：以Java nacos client v1.0.1 为例子，服务注册的策略的是每5秒向nacos server发送一次心跳，心跳带上了服务名，服务ip，服务端口等信息。同时 nacos server也会向client 主动发起健康检查，支持tcp/http检查。如果15秒内无心跳且健康检查失败则认为实例不健康，如果30秒内健康检查失败则剔除实例。

Zookeeper 和 Eureka 都实现了一种 TTL 的机制，就是如果客户端在一定时间内没有向注册中心发送心跳，则会将这个客户端摘除。Eureka 做的更好的一点在于它允许在注册服务的时候，自定义检查自身状态的健康检查方法。这在服务实例能够保持心跳上报的场景下，是一种比较好的体验，在 Dubbo 和 SpringCloud 这两大体系内，也被培养成用户心智上的默认行为。Nacos 也支持这种 TTL 机制，不过这与 ConfigServer 在阿里巴巴内部的机制又有一些区别。Nacos 目前支持临时实例使用心跳上报方式维持活性，发送心跳的周期默认是 5 秒，Nacos 服务端会在 15 秒没收到心跳后将实例设置为不健康，在 30 秒没收到心跳时将这个临时实例摘除。

不过正如前文所说，有一些服务无法上报心跳，但是可以提供一个检测接口，由外部去探测。这样的服务也是广泛存在的，而且以我们的经验，这些服务对服务发现和负载均衡的需求同样强烈。服务端健康检查最常见的方式是 TCP 端口探测和 HTTP 接口返回码探测，这两种探测方式因为其协议的通用性可以支持绝大多数的健康检查场景。在其他一些特殊的场景中，可能还需要执行特殊的接口才能判断服务是否可用。例如部署了数据库的主备，数据库的主备可能会在某些情况下切换，需要通过服务名对外提供访问，保证当前访问的库是主库。此时的健康检查接口，可能就是一个检查数据库是否是主库的 MYSQL 命令了。

客户端健康检查和服务端健康检查有一些不同的关注点。客户端健康检查主要关注客户端上报心跳的方式、服务端摘除不健康客户端的机制。而服务端健康检查，则关注探测客户端的方式、灵敏度及设置客户端健康状态的机制。从实现复杂性来说，服务端探测肯定是要更加复杂的，因为需要服务端根据注册服务配置的健康检查方式，去执行相应的接口，判断相应的返回结果，并做好重试机制和线程池的管理。这与客户端探测，只需要等待心跳，然后刷新 TTL 是不一样的。同时服务端健康检查无法摘除不健康实例，这意味着只要注册过的服务实例，如果不调用接口主动注销，这些服务实例都需要去维持健康检查的探测任务，而客户端则可以随时摘除不健康实例，减轻服务端的压力。

 

二、nacos的数据模型

注册中心的核心数据是服务的名字和它对应的网络地址，当服务注册了多个实例时，我们需要对不健康的实例进行过滤或者针对实例的一些特征进行流量的分配，那么就需要在实例上存储一些例如健康状态、权重等属性。随着服务规模的扩大，渐渐的又需要在整个服务级别设定一些权限规则、以及对所有实例都生效的一些开关，于是在服务级别又会设立一些属性。再往后，我们又发现单个服务的实例又会有划分为多个子集的需求，例如一个服务是多机房部署的，那么可能需要对每个机房的实例做不同的配置，这样又需要在服务和实例之间再设定一个数据级别。

服务分级模型

服务逻辑隔离模型

Nacos 提供了四层的数据逻辑隔离模型，用户账号对应的可能是一个企业或者独立的个体，这个数据一般情况下不会透传到服务注册中心。一个用户账号可以新建多个命名空间，每个命名空间对应一个客户端实例，这个命名空间对应的注册中心物理集群是可以根据规则进行路由的，这样可以让注册中心内部的升级和迁移对用户是无感知的，同时可以根据用户的级别，为用户提供不同服务级别的物理集群。再往下是服务分组和服务名组成的二维服务标识，可以满足接口级别的服务隔离。

 

三、nacos如何保证一致性

数据一致性是分布式系统永恒的话题，Paxos 协议的艰深更让数据一致性成为程序员大牛们吹水的常见话题。不过从协议层面上看，一致性的选型已经很长时间没有新的成员加入了。目前来看基本可以归为两家：一种是基于 Leader 的非对等部署的单点写一致性，一种是对等部署的多写一致性。当我们选用服务注册中心的时候，并没有一种协议能够覆盖所有场景，例如当注册的服务节点不会定时发送心跳到注册中心时，强一致协议看起来是唯一的选择，因为无法通过心跳来进行数据的补偿注册，第一次注册就必须保证数据不会丢失。而当客户端会定时发送心跳来汇报健康状态时，第一次的注册的成功率并不是非常关键（当然也很关键，只是相对来说我们容忍数据的少量写失败），因为后续还可以通过心跳再把数据补偿上来，此时 Paxos 协议的单点瓶颈就会不太划算了，这也是 Eureka 为什么不采用 Paxos 协议而采用自定义的 Renew 机制的原因。

这两种数据一致性协议有各自的使用场景，对服务注册的需求不同，就会导致使用不同的协议。Nacos 因为要支持多种服务类型的注册，并能够具有机房容灾、集群扩展等必不可少的能力，在 1.0.0 正式支持 AP 和 CP 两种一致性协议并存。1.0.0 重构了数据的读写和同步逻辑，将与业务相关的 CRUD 与底层的一致性同步逻辑进行了分层隔离。然后将业务的读写（主要是写，因为读会直接使用业务层的缓存）抽象为 Nacos 定义的数据类型，调用一致性服务进行数据同步。在决定使用 CP 还是 AP 一致性时，使用一个代理，通过可控制的规则进行转发。

目前的一致性协议实现，一个是基于简化的 Raft 的 CP 一致性，一个是基于自研协议 Distro 的 AP 一致性。Raft 协议不必多言，基于 Leader 进行写入，其 CP 也并不是严格的，只是能保证一半所见一致，以及数据的丢失概率较小。Distro 协议则是参考了内部 ConfigServer 和开源 Eureka，在不借助第三方存储的情况下，实现基本大同小异。Distro 重点是做了一些逻辑的优化和性能的调优。

四、nacos的负载均衡策略

负载均衡严格的来说，并不算是传统注册中心的功能。一般来说服务发现的完整流程应该是先从注册中心获取到服务的实例列表，然后再根据自身的需求，来选择其中的部分实例或者按照一定的流量分配机制来访问不同的服务提供者，因此注册中心本身一般不限定服务消费者的访问策略。

nacos支持服务端的负载均衡，服务端的负载均衡，给服务提供者更强的流量控制权，但是无法满足不同的消费者希望使用不同负载均衡策略的需求。而不同负载均衡策略的场景，确实是存在的。而客户端的负载均衡则提供了这种灵活性，并对用户扩展提供更加友好的支持。但是客户端负载均衡策略如果配置不当，可能会导致服务提供者出现热点，或者压根就拿不到任何服务提供者。

同时，nacos支持基于标签的负载均衡，新提供了基于第三方 CMDB 的标签负载均衡器，具体可以参考CMDB 功能介绍文章。使用基于标签的负载均衡器，目前可以实现同标签优先访问的流量调度策略，实际的应用场景中，可以用来实现服务的就近访问，当您的服务部署在多个地域时，这非常有用。使用这个标签负载均衡器，可以支持非常多的场景。

理想的负载均衡实现应该是什么样的呢？不同的人会有不同的答案。Nacos 试图做的是将服务端负载均衡与客户端负载均衡通过某种机制结合起来，提供用户扩展性，并给予用户充分的自主选择权和轻便的使用方式。负载均衡是一个很大的话题，当我们在关注注册中心提供的负载均衡策略时，需要注意该注册中心是否有我需要的负载均衡方式，使用方式是否复杂。如果没有，那么是否允许我方便的扩展来实现我需求的负载均衡策略。

Nacos 既支持客户端的健康检查，也支持服务端的健康检查，同一个服务可以切换健康检查模式。我们认为这种健康检查方式的多样性非常重要，这样可以支持各种类型的服务，让这些服务都可以使用到 Nacos 的负载均衡能力。Nacos 下一步要做的是实现健康检查方式的用户扩展机制，不管是服务端探测还是客户端探测。这样可以支持用户传入一条业务语义的请求，然后由 Nacos 去执行，做到健康检查的定制。

五、nacos的多活策略

集群扩展性和集群容量以及读写性能关系紧密。当使用一个比较小的集群规模就可以支撑远高于现有数量的服务注册及访问时，集群的扩展能力暂时就不会那么重要。

集群扩展性的另一个方面是多地域部署和容灾的支持。当讲究集群的高可用和稳定性以及网络上的跨地域延迟要求能够在每个地域都部署集群的时候，我们现有的方案有多机房容灾、异地多活、多数据中心等。

Nacos 的多机房部署和容灾

Nacos 支持两种模式的部署，一种是和 Eureka 一样的 AP 协议的部署，这种模式只支持临时实例，并支持机房容灾。另一种是支持持久化实例的 CP 模式，这种情况下不支持双机房容灾。

在谈到异地多活时，很巧的是，很多业务组件的异地多活正是依靠服务注册中心和配置中心来实现的，这其中包含流量的调度和集群的访问规则的修改等。机房容灾是异地多活的一部分，但是要让业务能够在访问服务注册中心时，动态调整访问的集群节点，这需要第三方的组件来做路由。异地多活往往是一个包含所有产品线的总体方案，很难说单个产品是否支持异地多活。

多数据中心其实也算是异地多活的一部分。Nacos 基于阿里巴巴内部的使用经验，提供的解决方案是才有 Nacos-Sync 组件来做数据中心之间的数据同步，这意味着每个数据中心的 Nacos 集群都会有多个数据中心的全量数据。Nacos-Sync 是 Nacos 生态组件里的重要一环，不仅会承担 Nacos 集群与 Nacos 集群之间的数据同步，也会承担 Nacos 集群与 Eureka、Zookeeper、Kubernetes 及 Consul 之间的数据同步。

Nacos 的多数据中心方案

参考文章：

1、服务注册中心架构演进 https://www.jianshu.com/p/5014bb302c7d

2、什么是Nacos？Nacos注册配置中心介绍 https://www.jianshu.com/p/39ade28c150d

3、阿里巴巴为什么不用 ZooKeeper 做服务发现？ http://jm.taobao.org/2018/06/13/%E5%81%9A%E6%9C%8D%E5%8A%A1%E5%8F%91%E7%8E%B0%EF%BC%9F/

4、Nacos 注册中心的设计原理详解  https://www.infoq.cn/article/B*6vyMIKao9vAKIsJYpE?utm_source=tuicool&utm_medium=referral