如何基于Nacos集群部署方案? | 带你读《Spring Cloud Alibaba(2019)》之八-阿里云开发者社区

开发者社区> 开发者学习资源库> 正文

如何基于Nacos集群部署方案? | 带你读《Spring Cloud Alibaba(2019)》之八

简介: 本节介绍Nacos的集群部署,Nacos对比Zookeeper、Eureka之间的区别,以及什么是分布式系统一致性算法。

上一篇:如何基于Nacos实现分布式配置中心? | 带你读《Spring Cloud Alibaba(2019)》之七
下一篇:什么是微服务网关? | 带你读《Spring Cloud Alibaba(2019)》之九

本文来自于《精通Spring Cloud Alibaba》课程的整理,讲师为余胜军,点击查看视频内容
本文系志愿者整理,供配合学习中心课程使用,不做商业用途。

基于Nacos集群部署方案

Nacos 核心帮助我们做的事情注册中心、分布式配置中心

注册中心:没有必要将数据持久化到数据库中,可以持久化到本地的硬盘。
分布式配置中心: 默认是将数据持久化到本地嵌入式的数据库改为持久化到myql中

相关集群配置

创建cluster文件夹
---nacos-server-8848
---nacos-server-8849
---nacos-server-8850

cluster.conf
###ip和端口号
127.0.0.1:8848
127.0.0.1:8849
127.0.0.1:8850

1.png
Nginx相关配置
客户端连接

spring:
  application:
    ###服务的名称
    name: meitemayikt-nacos-client
  cloud:
    nacos:
      discovery:
        ###nacos注册地址
        server-addr: 127.0.0.1:8848,127.0.0.1:8849,127.0.0.1:8850
        enabled: true
      config:
        ###配置中心连接地址
        server-addr: 127.0.0.1:8848,127.0.0.1:8849,127.0.0.1:8850
        ###分组
        group: DEFAULT_GROUP
        ###类型
        file-extension: yaml

注意:
1、Nacos在不同的版本下运行集群是不一样的。
nacos在windows版本下运行默认是单机版本 需要指定startup.cmd -m cluster
2、nacos在linux版本下运行默认是集群版本 如果想连接单机版本 startup.cmd –m standalone

2.png

注意事项:集群的ip地址不能采用127.0.0.1,我们需要修改为192.168.18.218。
3.png

分布式情况下 集群保证数据的一致性集群的算法
ZAB(Zookeeper)核心原理两阶段是提交协议2PC、Paxos、nacos数九一致性协议raft协议采用心跳形式

Nacos对比Zookeeper、Eureka之间的区别

Nacos与Eureka区别
最大区别:Nacos支持两种模式CP/Ap模式,从Nacos1.0版本开始,注意模式就是Ap模式

注册有哪些?
Eueeka、Nacos、consul、Zookepper

核心:
1、Eureka与Zookeeper实现注册的区别
2、Eureka与Nacos实现注册区别

CAP定律概念:
这个定理的内容是指的是在一个分布式系统中、Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性),三者不可得兼。

一致性(C):在分布式系统中,如果服务器集群,每个节点在同时刻访问必须要保持数据的一致性。
可用性(A):集群节点中,部分节点出现故障后仍然可以使用 (高可用)
分区容错性(P):在分布式系统中网络会存在脑裂的问题,部分Server与整个集群失去节点联系,无法组成一个群体。

取舍:只有在CP和AP选择一个平衡点

采用:
Cp情况下 虽然我们服务不能用,但是必须要保证数据的一致性
Ap情况下 可以短暂保证数据不一致性,但是最终可以一致性,不管怎么样,要能够保证我们的服务可用

大多的注册中心都是Ap

Nacos对比Zookeeper、Eureka之间的区别
从相同点、不同点、中心化思想三方面来
三者都可以实现分布式注册中心框架.
不同点:
Zookeeper采用CP保证数据的一致性的问题, 原理采用(ZAP原子广播协议) , 当我们ZK领导者因为某种情况下部分节点出现了故障,会自动重新实现选举新的领导角色,整个选举的过程中为了保证数据一致性的问题, 客户端暂时无法使用我们的Zookeeper, 那么这意味着整个微服务无法实现通讯(本地有缓存除外)。
注意:可运行的节点必须满足过半机制,整个zk采用使用。

Eureka采用AP设计思想实现分布式注册中心, 完全去中心化、每个节点都是相等, 采用你中有我、我中有你相互注册设计思想,只要最后有一台Eureka节点存在整个微服务就可以实现通讯。

中心化:必须围绕一个领导角色作为核心,选举领导和跟随者角色。
去中心化:每个角色都是均等。

我们在使用注册中心,可用性优先级最高,可以读取数据短暂不一致性,但是至少要能够保证注册中心可用性。

Nacos从1.0版本选择Ap和CP混合形式实现注册中心, 默认情况下采用Ap, CP则采用Raft协议实现保持数据的一致性。
如果选择为Ap模式,注册服务的实例仅支持临时模式,在网络分区的的情况允许注册服务实例,选择CP模式可以支持注册服务的实例为持久模式,在网络分区的产生了抖动情况下不允许注册服务实例。

Nacos的版本更新:
https://github.com/alibaba/nacos/releases

Eureka与Nacos有哪些区别:
1、Eureka采用Ap模式实现注册中心
2、Nacos默认采用AP模式,在1.0版本之后采用ap+cp模式混合实现注册中心。

Eureka与Nacos底层实现集群协议哪些区别
1、去中心化对等。
2、Raft协议实现集群产生领导角色。

分布式系统一致性算法

Raft到底是什么问题即什么是分布式一致性协议的算法

分布式系统一致性算法:应用于系统软件实现集群保持每个节点数据的同步性
保持我们的集群中每个节点的数据的一致性的问题。
专业的术语:分布式一致性的算法。

场景:Redis集群、nacos集群、mongdb集群等

分布式事务一致性框架与分布式系统一致性算法有哪些?

分布式事务一致性框架:核心解决我们在实际系统中产生夸事物导致分布式事务问题。
核心靠的是最终一致性。rocketmq事务消息、rabbitmq补单、lcn、SeaTac等。
分布式系统一致性算法:解决我们系统之间集群之后每个节点保持数据的一致性
有哪些:raft(nacos)、zab(zookeeper)、paxos等。

Zab协议集群原理

我们在分布式系统,存在多个系统之间的集群保持数据一致性,采用CP一致性算法保持数据的一致性问题。
Zookeeper基于ZAP协议实现保持每个节点的数据同步的问题,中心化思想集群模式;
分为领导和跟随者角色。

在程序中如何成为某个节点能力比较强:
对每个节点配置一个myid或者serverid,数值越大表示能力越强;或者根据随机时间判断,随机时间越短,能力越强。

5.png

整个集群中为了保持数据的一致性的问题,必须满足大多数情况>n/2+1 可运行的节点环境下才可以使用

ZAP的协议实现原理事通过比较myid myid谁最大谁就是为可能是领导角色,只要满足过半的机制就可以成为领导角色,后来启动的节点不会参与选举的。

6.png

Zab协议如何保持数据的一致性问题
所有写的请求统一交给我们的领导角色实现,领导角色写完数据之后,领导角色再将 数据同步给每个节点。

注意:数据之间同步采用2pc两个阶段提交协议。

选举过程:

先去比较zxid,zxid谁最大谁就是为领导角色;
如果zxid相等的情况下,myid谁最大谁就为领导角色;

7.png

Ratf整个底层实现原理:

在Raft协议算法中分为角色|名词:
1、状态:分为三种,跟随者、竞选者(候选人)、领导角色。
跟随者:只有投票权限,不能参与竞选。
竞选者(候选人):被投票,有可能成为领导者的角色。
领导角色:只有唯一的一个。
2、大多数: >n/2+1,n表示集群总数的节点。
3、任期:每次选举一个新的领导角色,任期都会增加。
注意:任何的算法都是来源于生活。
4、竞选者谁的票数最多,谁就成为领导角色。

存在的疑问:
多个竞选者,产生的票数都完全一样,这到底谁是领导角色?
注意当我们的集群节点总数,如果是奇数情况下,就算遇到了该问题也不用担心。
当我们的节点是偶数的情况下,可能会存在该问题,如果两个竞选者获取的票数相等的情况下,开始重置竞选的超时时间,一直到谁的票数最多谁就为领导。

9.png

10.png

默认情况下选举的过程:
1、默认的情况下每个节点都是跟随者角色
2、每个节点会随机生成一个选举的超时时间,例如大概是100-300ms,在这个超时时间范围内必须要等待。
3、超时时间过后,当前节点的状态由跟随者变为竞选者状态,会给其他的节点发出选举的投票通知,只要该竞选者有超过半数以上即可选为领导角色。

核心的设计原理:谁超时时间最短,谁就有非常大的概率为领导角色。

那么在随机数有可能一样的情况下,如何选举呢?
11.png
1、如果所有的节点的超时随机数都是一样的情况下,当前投票全部作废,重新进入随机生成超时时间。
12.png
2、如果有多个节点生成的随机数都是一样的情况下,比较谁的票数最多,谁就是领导。如果票数完全一样的情况,直接作废,重新进入随机生成超时时间。
注意:建议集群节点为奇数。偶数节点容易造成死循环。

故障重新实现选举:
1、如果我们跟随者节点不能够及时的收到领导角色消息,那么这时候跟随者就会将当前自己的状态由跟随者变为竞选者状态,会给其他的节点发出选举投票的通知,只要该竞选者有超过半数以上即可选举为领导角色。

数据是如何保持一致性的,类似于ZAP两阶段提交协议。

如何实现日志的复制
1、所有的写的请求都是统一的交给我们的领导角色完成,写入该对应的日志,标记该日志为被提交状态。
2、为了提交该日志,领导角色就会将该日志以心跳的形式发送给其他的跟随者节点,只要满足过半的跟随者节点写入该目志,则直接通知其他的跟随者节点同步该数据,这个过程称为日志复制的过程。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:

开发者免费资源中心,技术电子书、会议PPT、论文资料持续供应中

官方博客
官网链接