微服务Nacos ⼀致性协议
Posted 卡布奇诺-海晨
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了微服务Nacos ⼀致性协议相关的知识，希望对你有一定的参考价值。
目录
二、为什么 Nacos 选择了 Raft 以及 Distro
一、为什么 Nacos 需要⼀致性协议
Nacos 在开源支持就定下了⼀个目标，尽可能的减少用户部署以及运维成本，做到用户只需要⼀个程序包，就可以快速以单机模式启动 Nacos 或者以集群模式启动 Nacos。而 Nacos 是⼀个需要存储数据的⼀个组件，因此，为了实现这个目标，就需要在 Nacos 内部实现数据存储。单机下其实问题不大，简单的内嵌关系型数据库即可；但是集群模式下，就需要考虑如何保障各个节点之间的数据⼀致性以及数据同步，而要解决这个问题，就不得不引入共识算法，通过算法来保障各个节点之间的数据的⼀致性。
二、为什么 Nacos 选择了 Raft 以及 Distro
为什么 Nacos 会在单个集群中同时运行 CP 协议以及 AP 协议呢？这其实要从 Nacos 的场景出发的：Nacos 是⼀个集服务注册发现以及配置管理于⼀体的组件，因此对于集群下，各个节点之间的数据⼀致性保障问题，需要拆分成两个方面
1、从服务注册发现来看
服务发现注册中心，在当前微服务体系下，是十分重要的组件，服务之间感知对方服务的当前可正常提供服务的实例信息，必须从服务发现注册中心进行获取，因此对于服务注册发现中心组件的可用性，提出了很高的要求，需要在任何场景下，尽最大可能保证服务注册发现能力可以对外提供服务；同时 Nacos 的服务注册发现设计，采取了心跳可自动完成服务数据补偿的机制。如果数据丢失的话，是可以通过该机制快速弥补数据丢失。因此，为了满足服务发现注册中心的可用性，强⼀致性的共识算法这里就不太合适了，因为强⼀致性共识算法能否对外提供服务是有要求的，如果当前集群可用的节点数没有过半的话，整个算法直接“罢工”，而最终⼀致共识算法的话，更多保障服务的可用性，并且能够保证在⼀定的时间内各个节点之间的数据能够达成⼀致。
上述的都是针对于 Nacos 服务发现注册中的非持久化服务而言（即需要客户端上报心跳进行服务实例续约）。而对于 Nacos 服务发现注册中的持久化服务，因为所有的数据都是直接使用调用 Nacos服务端直接创建，因此需要由 Nacos 保障数据在各个节点之间的强⼀致性，故而针对此类型的服务数据，选择了强⼀致性共识算法来保障数据的⼀致性。
2、从配置管理来看
配置数据，是直接在 Nacos 服务端进行创建并进行管理的，必须保证大部分的节点都保存了此配置数据才能认为配置被成功保存了，否则就会丢失配置的变更，如果出现这种情况，问题是很严重的，如果是发布重要配置变更出现了丢失变更动作的情况，那多半就要引起严重的现网故障了，因此对于配置数据的管理，是必须要求集群中大部分的节点是强⼀致的，而这里的话只能使用强⼀致性共识算法。
3、为什么是 Raft 和 Distro 呢
对于强⼀致性共识算法，当前工业生产中，最多使用的就是 Raft 协议，Raft 协议更容易让人理解，并且有很多成熟的工业算法实现，比如蚂蚁金服的 JRaft、Zookeeper 的 ZAB、Consul 的 Raft、百度的 braft、Apache Ratis；因为 Nacos 是 Java 技术栈，因此只能在 JRaft、ZAB、ApacheRatis 中选择，但是 ZAB 因为和 Zookeeper 强绑定，再加上希望可以和 Raft 算法库的支持团队随时沟通交流，因此选择了 JRaft，选择 JRaft 也是因为 JRaft 支持多 RaftGroup，为 Nacos 后面的多数据分片带来了可能。而 Distro 协议是阿里巴巴自研的⼀个最终⼀致性协议，而最终⼀致性协议有很多，比如 Gossip、Eureka 内的数据同步算法。而 Distro 算法是集 Gossip 以及 Eureka 协议的优点并加以优化而出来的，对于原生的 Gossip，由于随机选取发送消息的节点，也就不可避免的存在消息重复发送给同⼀节点的情况，增加了网络的传输的压力，也给消息节点带来额外的处理负载，而 Distro 算法引入了权威 Server 的概念，每个节点负责⼀部分数据以及将自己的数据同步给其他节点，有效的降低了消息冗余的问题。
三、早期的 Nacos ⼀致性协议
我们先来看看早起的 Naocs 版本的架构
在早期的 Nacos 架构中，服务注册和配置管理⼀致性协议是分开的，没有下沉到 Nacos 的内核模块作为通用能力演进，服务发现模块⼀致性协议的实现和服务注册发现模块的逻辑强耦合在⼀起，并且充斥着服务注册发现的⼀些概念。这使得 Nacos 的服务注册发现模块的逻辑变得复杂且难以维护，耦合了⼀致性协议层的数据状态，难以做到计算存储彻底分离，以及对计算层的无限水平扩容能力也有⼀定的影响。因此为了解决这个问题，必然需要对 Nacos 的⼀致性协议做抽象以及下沉，使其成为 Core 模块的能力，彻底让服务注册发现模块只充当计算能力，同时为配置模块去外部数据库存储打下了架构基础。
四、当前 Nacos 的⼀致性协议层
正如前面所说，在当前的 Nacos 内核中，我们已经做到了将⼀致性协议的能力，完全下沉到了内核模块作为 Nacos 的核心能力，很好的服务于服务注册发现模块以及配置管理模块，我们来看看当前 Nacos 的架构。
可以发现，在新的 Nacos 架构中，已经完成了将⼀致性协议从原先的服务注册发现模块下沉到了内核模块当中，并且尽可能的提供了统⼀的抽象接口，使得上层的服务注册发现模块以及配置管理模块，不再需要耦合任何⼀致性语义，解耦抽象分层后，每个模块能快速演进，并且性能和可用性都大幅提升。
💖 Spring家族及微服务系列文章
✨【微服务】SpringCloud中OpenFeign请求处理及负载均衡流程
✨【微服务】SpringCloud中Ribbon的WeightedResponseTimeRule策略
✨【微服务】SpringCloud中Ribbon的轮询(RoundRobinRule)与重试(RetryRule)策略
✨【微服务】SpringCloud中Ribbon集成Eureka实现负载均衡
✨【微服务】SpringCloud轮询拉取注册表及服务发现源码解析
✨【微服务】Nacos2.x服务发现？RPC调用？重试机制？
✨【微服务】SpringBoot监听器机制以及在Nacos中的应用
✨【微服务】SpringCloud中使用Ribbon实现负载均衡的原理
✨【微服务】SpringBoot启动流程注册FeignClient
nacos的一致性协议介绍
| 特性 | zookeeper | nacos |
|---|---|---|
| 一致性协议 | CP | CP+AP |
| 健康检查 | Keep Alive | TCP / HTTP / MySql / Client beat |
| 负载均衡 | 无 | 权重 / selector / metadata |
| 多数据中心 | 不支持 | 支持 |
| 跨注册中心同步 | 不支持 | 支持 |
| 雪崩保护 | 无 | 有 |
| 访问协议 | TCP | HTTP / DNS |
| K8s集成 | 不支持 | 支持 |
| dubbo集成 | – | 支持 |
一致性协议
在介绍一致性协议前先了解一下CAP理论
- Consistency 一致性，在分布式系统中的所有数据备份，在同一时刻是否同样的值；
- Availability 可用性，只要收到用户的请求，服务器就必须给出回应；
- Partition tolerance 分区容错性，以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择
分布式系统必须具有分区容错性，一致性与可用性只能选择其一，如果选择一致性，必须在某节点写入时，数据同步到其他节点完成后才可以响应下一个请求，这段时间内服务是不可用的；反之选择可用性，则一致性无法保证，这就是CAP理论
作为注册中心，P要保证，C和A需要权衡；常见的一致性协议有paxos、raft，他们都是强一致性协议（CP），然而今天要介绍的nacos的distro协议时弱一致协议（AP），即最终一致性协议。注册中心到底该是AP还是CP，推荐阅读阿里中间件的博客《阿里巴巴为什么不用 ZooKeeper 做服务发现？
》
为啥要保持一致性？
因为Nacos 是一个需要存储数据的中间件，因此就需要在 Nacos 内部实现数据存储。单机下其实问题不大，简单的内嵌关系型数据库即可；但是集群模式下，就需要考虑如何保障各个节点之间的数据一致性以及数据同步，而要解决这个问题，就不得不引入共识算法，通过算法来保障各个节点之间的数据的一致性。
以上是关于微服务Nacos ⼀致性协议的主要内容，如果未能解决你的问题，请参考以下文章