Nacos高可用、可扩展集群部署实践
引言
1.1 Nacos高可用特性
高可用性：可用性，通常指的是系统在面对各种异常时可以正确提供服务的能力。可用性是分布式系统的一项重要指标，衡量了系统的鲁棒性，是系统容错能力的体现。系统的可用性还可以用失败次数与总的请求次数之比来衡量，比如对网站请求 1000 次，其中有 10 次请求失败，那么可用性就是 99%。在分布式系统中，在服务端集群化部署多个节点，如果部分节点宕机，依旧不影响系统整体运行。
你可能经常在一个系统的可用性指标介绍时见到或听到 3 个 9、5 个 9。这些所说的 3 个 9、5 个 9，表明该系统可以在 99.9% 或 99.999% 的时间里能对外无故障地提供服务。
Nacos 的高可用不仅仅存在于服务端，同时也存在于客户端，以及一些与可用性相关的功能特性中，这些特性共同构成了 Nacos 的高可用。
例如：
图1：Nacos客户端轮询请求
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 本地缓存文件
2.1 直连模式
我们在首次开发中采用该部署模式，如下图所示：
图6：Nacos 直连模式
采用直连模式后，典型的开发场景配置如下：
在SpringBoot微服务应用的application.properties中采用主机别名配置，如：
(1).nacos.config-server=nusp-nacos-server1:8848,nusp-nacos-server2:8848,nusp-nacos-server3:8848。
缺点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
2.2.4 Keepalived配置
配置文件位置：
/etc/keepalived/keepalived.conf
重启keepalived服务，使用命令: ip addr 查看是否在网卡接口eth0绑定了VIP 172.29.68.250
2.2.5 Keepalived测试
1表示启用服务，即正常工作的状态；0表示禁用服务，即停止服务的状态。
√表示可通过VIP访问nacos页面，×表示通过VIP无法访问nacos页面。
http:172.29.68.250:8848/nacos，
默认用户名密码：nacos/nacos
表2：Keepalived高可用场景测试
2.3 多集群模式
多集群模式 用于多数据中心场景，由于我们目前没有多数据中心的需求，因此未进行进一步探索。
撰稿人：魏春雷
审核人：综合管理部