Nacos高可用、可扩展集群部署实践

引言

Nacos支持三种部署模式(https://nacos.io/zh-cn/docs/deployment.html)：单机模式-用于测试和单机试用；集群模式：用于生产环境，确保高可用；多集群模式：用于多数据中心。在实践中，我们通常用单机模式快速构建一个 Nacos 开发/测试环境。而在生产环境中，一定要使用 Nacos 集群部署模式来保证系统的高可用、可扩展。

1.1 Nacos高可用特性

高可用性：可用性，通常指的是系统在面对各种异常时可以正确提供服务的能力。可用性是分布式系统的一项重要指标，衡量了系统的鲁棒性，是系统容错能力的体现。系统的可用性还可以用失败次数与总的请求次数之比来衡量，比如对网站请求 1000 次，其中有 10 次请求失败，那么可用性就是 99%。在分布式系统中，在服务端集群化部署多个节点，如果部分节点宕机，依旧不影响系统整体运行。

你可能经常在一个系统的可用性指标介绍时见到或听到 3 个 9、5 个 9。这些所说的 3 个 9、5 个 9，表明该系统可以在 99.9% 或 99.999% 的时间里能对外无故障地提供服务。

Nacos 的高可用不仅仅存在于服务端，同时也存在于客户端，以及一些与可用性相关的功能特性中，这些特性共同构成了 Nacos 的高可用。

例如：

address="172.29.68.77:8848,172.29.68.87:8848,172.29.68.139:8848"（我们开发的微服务分别部署在开发环境、测试环境、生产环境，因此Nacos服务器的地址不会直接配置在代码中。我们采用主机别名代替实际地址，如address=”nusp-nacos-server1:8848,nusp-nacos-server2:8848,nusp-nacos-server3:8848”，其中nusp-nacos-server1/2/3分别为Nacos三个节点的主机别名。）

图1：Nacos客户端轮询请求

Nacos客户端的逻辑是nacos-client获取地址列表，在请求成功之前逐个尝试，直到成功为止。

1.2 临时实例和持久化实例

在介绍一致性模型之前，需要先了解到 Nacos 中临时服务和持久化服务两个概念。

临时服务（Ephemeral）：临时服务健康检查失败后会从列表中删除，常用于服务注册发现场景。

持久化服务（Persistent）：持久化服务健康检查失败后会被标记成不健康，常用于 DNS 场景。

临时和持久化的区别主要在健康检查失败后的表现，持久化实例健康检查失败后会被标记成不健康，而临时实例会直接从列表中被删除。这个特性比较适合那些需要应对流量突增，而弹性扩容的服务，当流量降下来后这些实例自己销毁自己就可以了，不用再去Nacos里手动调用注销实例。持久化以后，可以实时看到健康状态，便于做后续的告警、扩容等一系列处理

（参考文章：Nacos临时实例和持久化实例https://blog.csdn.net/qq_38826019/article/details/109433231）。

图2：Nacos临时实例

1.3 一致性协议 distro介绍

CAP理论

（https://baike.baidu.com/item/CAP%E5%8E%9F%E5%88%99/5712863）表明：在分布式系统中，数据的一致性、服务的可用性和网络分区容忍性只能三者选二。一般来说分布式系统需要支持网络分区容忍性，那么就只能在C和A里选择一个作为系统支持的属性。C 的准确定义应该是所有节点在同一时间看到的数据是一致的，而A的定义是所有的请求都会收到响应。

临时服务使用的是服务注册发现场景定制化的私有协议 distro，distro为阿里巴巴的私有协议，distro协议被定位为临时数据的一致性协议（该类型协议要求不需要把数据存储到磁盘或者数据库，因为临时数据通常和服务器保持一个session会话，该会话只要存在，数据就不会丢失），其一致性模型是 AP（AP模式为了服务的可用性减弱了一致性，因此AP模式下只支持注册临时实例）；而持久化服务使用的是 raft 协议，其一致性模型是 CP（该模式下注册实例之前必须先注册服务，服务不存在，则返回错误）。

Distro协议特点请参考文章一致性算法 - Distro协议在Nacos的实践

（https://my.oschina.net/u/133079/blog/4562594）

distro 协议与高可用有什么关系呢？Nacos 这种有状态的应用和一般无状态的 Web 应用不同，并不是说只要存活一个节点就可以对外提供服务的，需要分场景讨论，这与其一致性协议的设计有关。

图3：Nacos distro协议工作流程示意图

如上图所示，每个节点服务一部分服务的写入，但每个节点都可以接收到写入请求，这时就存在两种写情况：

情况1：当该节点接收到属于该节点负责的服务时，直接写入。

情况2：当该节点接收到不属于该节点负责的服务时，将在集群内部路由，转发给对应的节点，从而完成写入。

图4：Nacos 集群中一个节点宕机工作示意图

1.4 本地缓存文件Failover机制

Nacos注册中心发生故障最坏的一个情况是整个 Server 端宕机，这时候 Nacos 依旧有高可用机制兜底。Nacos 存在本地文件缓存机制，nacos-client 在接收到 nacos-server 的服务推送之后，会在内存中保存一份，随后会落盘存储一份快照。snapshot 默认的存储路径为：{USER_HOME}/nacos/naming/ 中。这份文件有两种价值，一是用来排查服务端是否正常推送了服务；二是当客户端加载服务时，如果无法从服务端拉取到数据，会默认从本地文件中加载。

图5：Nacos 本地缓存文件

注意到 {USER_HOME}/nacos/naming/{namespace} 下除了缓存文件之外还有一个 failover 文件夹，里面存放着和 snapshot 一致的文件夹。这是 Nacos 的另一个 failover 机制，snapshot 是按照某个历史时刻的服务快照恢复恢复，而 failover 中的服务可以人为修改，以应对一些极端场景。（参考文章：一文详解 Nacos 高可用特性https://lexburner.github.io/nacos-high-available/）
2 Nacos部署模式

2.1 直连模式

我们在首次开发中采用该部署模式，如下图所示：

图6：Nacos 直连模式

采用直连模式后，典型的开发场景配置如下：

在SpringBoot微服务应用的application.properties中采用主机别名配置，如：

(1).nacos.config-server=nusp-nacos-server1:8848,nusp-nacos-server2:8848,nusp-nacos-server3:8848。

(2).应用在K8S对应的部署的deployment.yaml配置主机别名和Nacos真实服务器的地址，如：nusp-nacos-server1=172.29.68.77,nusp-nacos-server2=172.29.68.87,nusp-nacos-server3=172.29.68.139，如下图所示：

图7：K8S的deployment.yaml主机别名与实际Nacos地址映射关系

缺点1：如果Nacos 的 IP 变了，例如扩缩容，集群迁移等场景，所有的应用的application.properties对应address和应用对应的K8S的deployment.yaml都需要修改，这样的方式并不灵活。

缺点2：如果微服务数量超过100个，即便application.properties通过配置中心统一管控，deployment.yaml通过脚本批量修改，也需要付出巨大的代价。

缺点3：如果业务都在运行的状态，根本无法做到扩展Nacos节点，对应用状态的无感知。

鉴于以上缺点，直连的集群部署并不是生产推荐的模式。

2.2 VIP集群模式

Nacos服务端为Web应用，故在Nacos的前端加上Nginx做负载均衡器；然后对负载均衡使用虚拟IP，通过Keepalived实现虚拟IP的漂移；用户访问负载均衡器实现对Nacos服务的访问，若主Nginx挂掉，虚拟IP漂移到从Nginx提供服务。

2021·RECRUIT

2.2.1 部署架构

图8：Nacos VIP部署架构

表1：Nacos VIP部署名词解释

图9：Nacos VIP新增加一个节点示意图

VIP 帮助 Nacos Client 屏蔽了后端 RIP，相对于 RIP 而言，VIP 很少会发生变化。以扩容场景为例，只需要让 VIP 感知到即可，Nacos Client 只需要关注 VIP，避免了扩容引起的代码改造。

只要是具备负载均衡能力的组件，均可以实现 VIP 模式，例如开源的 Nginx ，本文使用keepalived+nginx实现VIP模式。开发，测试环境均为CentOS7.5，MySQL采用主备模式。以下组件均基于CentOS7.5环境部署。以开发环境为例，整体部署示意图如下:

图10：Nacos VIP高可用部署架构图

如上图所示，Nacos的部署架构，满足高可用、可扩展性。SpringBoot的application.properties中配置address=”nusp-nacos-server:8848”，K8S的deployment.yaml如下图所示。如果新扩展Nacos节点，应用启动文件和K8S的部署文件都不需要更改，仅仅修改Nginx的upstream节点，然后执行reload命令即可完成热更新。

图11：Nacos VIP部署K8S的deployment.ymal

2.2.2 Nacos节点数量

在生产集群中不能以单机模式运行 Nacos，那么第一个问题便是：我应该部署几台机器？前面提到 Nacos 有两个一致性协议：distro 和 raft，distro 协议不会有脑裂问题，所以理论来说，节点数大于等于 2 即可；raft 协议的投票选举机制则建议是 2N+1 个节点。因此，最小Nacos集群节点数为3，结合吞吐量和更高可用性，可以选择 5 个，7 个，甚至 9 个节点的集群。

2.2.3 Ngnix配置文件nginx.conf