共计 5023 个字符，预计需要花费 13 分钟才能阅读完成。
简介： 我明天介绍的 Nacos 高可用，是 Nacos 为了晋升零碎稳定性而采取的一系列伎俩。Nacos 的高可用不仅仅存在于服务端，同时也存在于客户端，以及一些与可用性相干的性能个性中，这些点组装起来，独特形成了 Nacos 的高可用。
前言
服务注册发现是一个经久不衰的话题，Dubbo 晚期开源时默认的注册核心 ZooKeeper 最早进入人们的眼帘，并且在很长一段时间里，人们将注册核心和 ZooKeeper 划上了等号，可能 ZooKeeper 的设计者都没有想到这款产品对微服务畛域造成了如此深厚的影响，直到 Spring Cloud 开始风行，其自带的 Eureka 进入了人们的视线，人们这才意识到原来注册核心还能够有其余的抉择。再到起初，热衷于开源的阿里把眼光也聚焦在了注册核心这个畛域，Nacos 横空出世。
Kirito 在做注册核心选型时的思考：已经我没得选，当初我只想抉择一个好的注册核心，它最好是开源的，这样凋谢通明，有自我的掌控力。不仅要开源，它还要有沉闷的社区，以确保个性演进可能满足日益增长的业务需要，呈现问题也能即便修复，性能还要很弱小。除了满足注册服务、推送服务外，还要有欠缺的微服务体系中所需的性能。最重要的，它还要稳固，最好有大厂的理论应用场景背书，证实这是一个经得起实战考验的产品。当然，云原生个性，平安个性也是很重要的······
仿佛 Kirito 对注册核心的要求切实是太高了，但这些形形色色的注册核心出现在用户眼前，总是免不了一番比拟。正如下面所言，性能个性、成熟度、可用性、用户体验度、云原生个性、平安都是能够拿进去做比拟的话题。明天这篇文章重点介绍的是 Nacos 在可用性上的体现，心愿借助于这篇文章，可能让你对 Nacos 有一个更加粗浅的意识。
高可用介绍
当咱们在聊高可用时，咱们在聊什么？
- 零碎可用性达到 99.99%
- 在分布式系统中，局部节点宕机，仍旧不影响零碎整体运行
- 服务端集群化部署多个节点
这些都能够认为是高可用，而我明天介绍的 Nacos 高可用，则是 Nacos 为了晋升零碎稳定性而采取的一系列伎俩。Nacos 的高可用不仅仅存在于服务端，同时也存在于客户端，以及一些与可用性相干的性能个性中，这些点组装起来，独特形成了 Nacos 的高可用。
客户端重试
先对立一下语义，在微服务架构中个别会有三个角色：Consumer、Provider 和 Registry，在明天注册核心的主题中，Registry 是 nacos-server，而 Consumer 和 Provider 都是 nacos-client。
在生产环境，咱们往往须要搭建 Nacos 集群，在 Dubbo 也须要显式地配置上集群地址：
<dubbo:registry protocol="nacos" address="192.168.0.1:8848,192.168.0.2:8848,192.168.0.3:8848"/>当其中一台机器宕机时，为了不影响整体运行，客户端会存在重试机制。
逻辑非常简单，拿到地址列表，在申请胜利之前一一尝试，直到胜利为止。
该可用性保障存在于 nacos-client 端。
一致性协定 distro
首先给各位读者打个强心剂，不必看到”一致性协定“这几个字就被劝退，本节不会探讨一致性协定的实现过程，而是重点介绍其与高可用相干的个性。有的文章介绍 Nacos 的一致性模型是 AP + CP，这么说很容易让人误会，其实 Nacos 并不是反对两种一致性模型，也并不是反对两种模型的切换，介绍一致性模型之前，须要先理解到 Nacos 中的两个概念：长期服务和长久化服务。
- 长期服务（Ephemeral）：长期服务健康检查失败后会从列表中删除，罕用于服务注册发现场景。
- 长久化服务（Persistent）：长久化服务健康检查失败后会被标记成不衰弱，罕用于 DNS 场景。
长期服务应用的是 Nacos 为服务注册发现场景定制化的公有协定 distro，其一致性模型是 AP；而长久化服务应用的是 raft 协定，其一致性模型是 CP。所以当前不要再说 Nacos 是 AP + CP 了，更倡议加上服务节点状态或者应用场景的束缚。
distro 协定与高可用有什么关系呢？上一节咱们提到 nacos-server 节点宕机后，客户端会重试，但少了一个前提，即 nacos-server 少了一个节点后仍旧能够失常工作。Nacos 这种有状态的利用和个别无状态的 Web 利用不同，并不是说只有存活一个节点就能够对外提供服务的，须要分 case 探讨，这与其一致性协定的设计无关。distro 协定的工作流程如下：
- Nacos 启动时首先从其余近程节点同步全副数据。
- Nacos 每个节点是平等的都能够解决写入申请，同时把新数据同步到其余节点。
- 每个节点只负责局部数据，定时发送本人负责数据的校验值到其余节点来保持数据一致性。
如上图所示，每个节点负责一部分服务的写入，但每个节点都能够接管到写入申请，这时就存在两种状况：
- 当该节点接管到属于该节点负责的服务时，间接写入。
- 当该节点接管到不属于该节点负责的服务时，将在集群外部路由，转发给对应的节点，从而实现写入。
读取操作则不须要路由，因为集群中的各个节点会同步服务状态，每个节点都会有一份最新的服务数据。
而当节点产生宕机后，本来该节点负责的一部分服务的写入工作会转移到其余节点，从而保障 Nacos 集群整体的可用性。
一个比较复杂的状况是，节点没有宕机，然而呈现了网络分区，即下图所示：
这个状况会侵害可用性，客户端会体现为有时候服务存在有时候服务不存在。
综上，Nacos 的 distro 一致性协定能够保障在大多数状况下，集群中的机器宕机后仍旧不侵害整体的可用性。该可用性保障存在于 nacos-server 端。
本地缓存文件 Failover 机制
注册核心产生故障最坏的一个状况是整个 Server 端宕机，这时候 Nacos 仍旧有高可用机制做兜底。
一道经典的 Dubbo 面试题：当 Dubbo 利用运行时，Nacos 注册核心宕机，会不会影响 RPC 调用。这个题目大多数应该都能答复进去，因为 Dubbo 内存外面是存了一份地址的，一方面这样的设计是为了性能，因为不可能每次 RPC 调用时都读取一次注册核心，另一面，注册核心宕机后内存会有一份数据，这也起到了可用性的保障（只管可能 Dubbo 设计者并没有思考这个因素）。
那如果，我在此基础上再抛出一个问题：Nacos 注册核心宕机，Dubbo 利用产生重启，会不会影响 RPC 调用。如果理解了 Nacos 的 Failover 机制，该当失去和上一题同样的答复：不会。
Nacos 存在本地文件缓存机制，nacos-client 在接管到 nacos-server 的服务推送之后，会在内存中保留一份，随后会落盘存储一份快照。snapshot 默认的存储门路为：{USER_HOME}/nacos/naming/ 中：
这份文件有两种价值，一是用来排查服务端是否失常推送了服务；二是当客户端加载服务时，如果无奈从服务端拉取到数据，会默认从本地文件中加载。
前提是构建 NacosNaming 时传入了该参数：namingLoadCacheAtStart=true
Dubbo 2.7.4 及以上版本反对该 Nacos 参数；开启该参数的形式：dubbo.registry.address=nacos://127.0.0.1:8848?namingLoadCacheAtStart=true
在生产环境，举荐开启该参数，以防止注册核心宕机后，导致服务不可用，在服务注册发现场景，可用性和一致性 trade off 时，咱们大多数时候会优先思考可用性。
仔细的读者还留神到
{USER_HOME}/nacos/naming/{namespace} 下除了缓存文件之外还有一个 failover 文件夹，外面寄存着和 snapshot 统一的文件夹。这是 Nacos 的另一个 failover 机制，snapshot 是依照某个历史时刻的服务快照复原复原，而 failover 中的服务能够人为批改，以应答一些极其场景。
该可用性保障存在于 nacos-client 端。
心跳同步服务
心跳机制个别宽泛存在于分布式通信畛域，用于确认存活状态。个别心跳申请和一般申请的设计是有差别的，心跳申请个别被设计的足够精简，这样在定时探测时能够尽可能防止性能降落。而在 Nacos 中，出于可用性的思考，一个心跳报文蕴含了全副的服务信息，这样相比仅仅发送探测信息升高了吞吐量，而晋升了可用性，怎么了解呢？思考以下的两种场景：
- nacos-server 节点全副宕机，服务数据全副失落。nacos-server 即便复原运作，也无奈复原出服务，而心跳蕴含全部内容能够在心跳期间就复原出服务，保障可用性。
- nacos-server 呈现网络分区。因为心跳能够创立服务，从而在极其网络故障下，仍旧保障根底的可用性。
以下是对心跳同步服务的测试，应用阿里云 MSE 提供 Nacos 集群进行测试：
调用 OpenApi 顺次删除各个服务：
curl -X "DELETE mse-xxx-p.nacos-ans.mse.aliyuncs.com:8848/nacos/v1/ns/service?serviceName=providers:com.alibaba.edas.boot.EchoService:1.0.0:DUBBO&groupName=DEFAULT_GROUP"
过 5s 后刷新，服务又再次被注册了上来，合乎咱们对心跳注册服务的预期。
集群部署模式高可用
最初给大家分享的 Nacos 高可用个性来自于其部署架构。
节点数量
咱们晓得在生产集群中必定不能以单机模式运行 Nacos，那么第一个问题便是：我应该部署几台机器？后面咱们提到 Nacos 有两个一致性协定：distro 和 raft，distro 协定不会有脑裂问题，所以实践来说，节点数大于等于 2 即可；raft 协定的投票选举机制则倡议是 2n+1 个节点。综合来看，抉择 3 个节点是起码的，其次处于吞吐量和更高可用性的考量，能够抉择 5 个，7 个，甚至 9 个节点的集群。
多可用区部署
组成集群的 Nacos 节点，应该尽可能思考两个因素：
- 各个节点之间的网络时延不能很高，否则会影响数据同步。
- 各个节点所处机房、可用区该当尽可能扩散，以防止单点故障。
以阿里云的 ECS 为例，抉择同一个 Region 的不同可用区就是一个很好的实际。
部署模式
次要分为 K8s 部署和 ECS 部署两种模式。
ECS 部署的长处在于简略，购买三台机器即可搭建集群，如果你纯熟 Nacos 集群部署的话，这不是难事，但无奈解决运维问题，如果 Nacos 某个节点呈现 OOM 或者磁盘问题，很难迅速摘除，无奈实现自运维。
K8s 部署的有点在于云原生运维能力强，能够在节点宕机后实现自复原，保障 Nacos 的安稳运行。后面提到过，Nacos 和无状态的 Web 利用不同，它是一个有状态的利用，所以在 K8s 中部署，往往要借助于 StatefulSet 和 Operator 等组件能力实现 Nacos 集群的部署和运维。
MSE Nacos 的高可用最佳实际
阿里云微服务引擎 MSE 提供了 Nacos 集群的托管能力，实现了集群部署模式的高可用。
- 当创立多个节点的集群时，零碎会默认调配在不同可用区。同时，这对于用户来说又是通明的，用户只须要关怀 Nacos 的性能即可，MSE 替用户兜底可用性。
- MSE 底层应用 K8s 运维模式部署 Nacos。历史上呈现过用户误用 Nacos 导致局部节点宕机的问题，但借助于 K8s 的自运维模式，宕机节点迅速被拉起，以至于用户可能都没有意识到本人产生宕机。
上面模仿一个节点宕机的场景，来看看 K8s 如何实现自复原。
一个三节点的 Nacos 集群：
执行 kubectl delete pod mse-7654c960-1605278296312-reg-center-0-2 以模仿局部节点宕机的场景。
大略 2 分钟后，节点复原，并且角色产生了转换，Leader 从杀死的 2 号节点转给 1 号节点。
总结
本文从多个角度登程，总结了一下 Nacos 是如何保障高可用的。高可用个性绝不是靠服务端多部署几个节点就能够取得的，而是要联合客户端应用形式、服务端部署模式、应用场景综合来思考的一件事。
特地是在服务注册发现场景，Nacos 为可用性做了十分多的致力，而这些保障，ZooKeeper 是不肯定有的。在做注册核心选型时，可用性保障上，Nacos 相对是优良的。
原文链接
[](https://developer.aliyun.com/…，未经容许不得转载。
