SpringCloud 微服务注册中心 - Nacos高可用
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了SpringCloud 微服务注册中心 - Nacos高可用，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含6026字，纯文字阅读大概需要9分钟。
内容图文
SpringCloud 微服务注册中心 - Nacos高可用
文章目录
前言
在生产环境中，我们的nacos-server一定是集群的环境，当其中一台机器宕机时，依旧需要保证服务的可用性。Nacos 的高可用不仅仅存在于服务端，同时也存在于客户端，以及一些与可用性相关的功能特性中，这些点组装起来，共同构成了 Nacos 的高可用。Nacos会从以下几个方面去保证高可用。
- 重试机制
- 一致性协议
- 本地缓存文件 Failover 机制
- 心跳同步服务
最后我们还会介绍Nacos的集群部署配置及持久化配置。
一、重试机制
我们先说一个场景，当provider注册了两台机器 192.168.0.10和192.168.0.20 ，当某一时刻，其中10机器宕机下线，但是此时cosumer发起请求，正好请求到10机器，应该如何处理。
从处理中可用看到，逻辑非常简单，拿到地址列表，在请求成功之前逐个尝试，直到成功为止。 这个处理时在 nacos-client上处理的。
二、一致性协议
分布式一致性协议有很多，而Nacos采用的是Distro协议和Raft协议。
介绍一致性模型之前，需要先了解到 Nacos 中的两个概念：临时服务和持久化服务。
-
临时服务（
Ephemeral）：临时服务健康检查失败后会从列表中删除，常用于服务注册发现场景。 -
持久化服务（
Persistent）：持久化服务健康检查失败后会被标记成不健康，常用于 DNS 场景。
临时服务使用的是 Nacos 为服务注册发现场景定制化的私有协议 distro，其一致性模型是 AP；而持久化服务使用的是 raft 协议，其一致性模型是 CP。
下面我们逐个了解一下这两个协议。
Distro协议
Distro是阿里巴巴的私有协议，目前流行的Nacos服务管理框架就采用了Distro协议。Distro 协议被定位为 临时数据的一致性协议 ：该类型协议， 不需要把数据存储到磁盘或者数据库 ，因为临时数据通常和服务器保持一个session会话， 该会话只要存在，数据就不会丢失 。
distro协议的关键点
-
distro协议是为了注册中心而创造出的协议； -
客户端与服务端有两个重要的交互，服务注册与心跳发送；
-
客户端以服务为维度向服务端注册，注册后每隔一段时间向服务端发送一次心跳，心跳包需要带上注册服务的全部信息，在客户端看来，服务端节点对等，所以请求的节点是随机的；
-
客户端请求失败则换一个节点重新发送请求；
-
服务端节点都存储所有数据，但每个节点只负责其中一部分服务，在接收到客户端的“写“（注册、心跳、下线等）请求后，服务端节点判断请求的服务是否为自己负责，如果是，则处理，否则交由负责的节点处理；
-
每个服务端节点主动发送健康检查到其他节点，响应的节点被该节点视为健康节点；
-
服务端在接收到客户端的服务心跳后，如果该服务不存在，则将该心跳请求当做注册请求来处理；
-
服务端如果长时间未收到客户端心跳，则下线该服务；
-
负责的节点在接收到服务注册、服务心跳等写请求后将数据写入后即返回，后台异步地将数据同步给其他节点；
-
节点在收到读请求后直接从本机获取后返回，无论数据是否为最新。
distro 协议的工作流程如下
-
Nacos 启动时首先从其他远程节点同步全部数据。
-
Nacos 每个节点是平等的都可以处理写入请求，同时把新数据同步到其他节点。
-
每个节点只负责部分数据，定时发送自己负责数据的校验值到其他节点来保持数据一致性。
-
当该节点接收到属于该节点负责的服务时，直接写入。
-
当该节点接收到不属于该节点负责的服务时，将在集群内部路由，转发给对应的节点，从而完成写入。
Raft协议
Raft协议是一种强一致性、去中心化、高可用的分布式协议，它是用来解决分布式一致性问题的，Nacos在CP的模型下，采用的就是Raft协议.
节点角色
- Leader：负责接收客户端的请求
- Candidate：用于选举Leader的一种角色
- Follower：负责响应来自Leader或者Candidate的请求
选举时间点:
- 服务启动的时候
- leader挂了的时候
所有节点启动的时候，都是follower状态。 如果在一段时间内如果没有收到leader的心跳（可能是没有 leader，也可能是leader挂了），那么follower会变成Candidate。然后发起选举。
follower会投自己一票，并且给其他节点发送票据vote，等到其他节点回复
在这个过程中，可能出现几种情况
- 收到过半的票数通过，则成为leader
- 被告知其他节点已经成为leader，则自己切换为follower
- 一段时间内没有收到过半的投票，则重新发起选举
三、本地缓存文件 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.
cloud:
nacos:
discovery:
naming-load-cache-at-start: true
{USER_HOME}/nacos/naming/{namespace} 下除了缓存文件之外还有一个 failover 文件夹，里面存放着和 snapshot 一致的文件夹。这是 Nacos 的另一个 failover 机制，snapshot 是按照某个历史时刻的服务快照恢复恢复，而 failover 中的服务可以人为修改，以应对一些极端场景。
四、心跳同步服务
心跳机制一般广泛存在于分布式通信领域，用于确认存活状态。一般心跳请求和普通请求的设计是有差异的，心跳请求一般被设计的足够精简，这样在定时探测时可以尽可能避免性能下降。而在 Nacos 中，出于可用性的考虑，一个心跳报文包含了全部的服务信息，这样相比仅仅发送探测信息降低了吞吐量，而提升了可用性，怎么理解呢？考虑以下的两种场景：
- nacos-server 节点全部宕机，服务数据全部丢失。nacos-server 即使恢复运作，也无法恢复出服务，而心跳包含全部内容可以在心跳期间就恢复出服务，保证可用性。
- nacos-server 出现网络分区。由于心跳可以创建服务，从而在极端网络故障下，依旧保证基础的可用性。
总结
作为注册中心，Nacos又两种节点 临时节点和持久化节点，分别使用了Distro和Raft协议，而对应的一致性模型是AP和CP.
Nacos在服务端和客户端采用了不同的机制保证高可用。对于我们正式环境搭建Nacos高可用架构时，我们一般会考虑部署几台机器，一般在分布式环境我们一定部署的是基数机器数量。所以结合之前的内容，distro 协议不会有脑裂问题，所以理论来说，节点数大于等于 2 即可；raft 协议的投票选举机制则建议是 2n+1 个节点。综合来看，选择 3 个节点是起码的，其次处于吞吐量和更高可用性的考量，可以选择 5 个，7 个，甚至 9 个节点的集群。
内容总结
以上是互联网集市为您收集整理的SpringCloud 微服务注册中心 - Nacos高可用全部内容，希望文章能够帮你解决SpringCloud 微服务注册中心 - Nacos高可用所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。