go语言 微服务管理--单点故障与分布式_go语言 处理管理节点和子节点(1)

32 阅读5分钟

在终端中输入consul指令,出现如上指令用法及参数提示,即表示consul安装成功。 如果得到的是**-bash: consul: command not found的错误,则表示path**没有正确设置,需要重新检查consul可执行文件所在路径是否添加到了环境变量PATH中。

主从模式分布式系统

分布式系统中,一遍采用主从模式进行部署,如下图所示:

单点故障

通常分布式系统采用主从模式,就是一个主控机连接多个处理节点。主节点负责分发任务,从节点负责处理任务,当我们的主节点发生故障时,整个系统就瘫痪了。这就是单点故障。

单点故障(single point of failure),从英文字面上可以看到是单个点发生的故障,通常应用于计算机系统及网络。实际指的是单个点发生故障的时候会波及到整个系统或者网络,从而导致整个系统或者网络的瘫痪。这也是在设计IT基础设施时应避免的。

对应到上文,我们所说的服务注册与发现组件,如果我们引入的服务注册与发现组件出现了问题,则会导致系统乃至整个链路瘫痪,这是不可容忍的。需要采用新的方案解决此问题。

传统解决方案

传统的解决方案是采用一个备用节点,这个备用节点定期给当前主节点发送ping包,主节点收到ping包以后向备用节点发送回复ACK,当备用节点收到回复时就会认为当前主节点还活着,让他继续提供服务。

当主节点停止服务以后,这个时候备用节点收不到回复了,备用主节点认为主节点就宕机了,备用节点会代替主节点成为主节点,如下图:

但是这种方案有个问题,如果仅仅是网络故障引起的ACK返回延时,这种方案就会面临着同时存在两个主节点的问题。

Consul中的Raft

Raft是一种基于Paxos的一致性算法。和Paxos相比,Raft的状态更少,算法更简单易懂。

Raft中的节点总是处于以下三种状态之一: follower、candidate或leader。所有的节点最初都是follower。在这种状态下,节点可以接受来自leader的日志条目并进行投票。如果在一段时间内没有收到条目,节点将自动提升到候选状态。在候选状态中,节点请求同级的选票。如果一个候选人获得了法定人数的选票,那么他就被提升为领袖。领导者必须接受新的日志条目,并将其复制给所有其他的追随者。此外,如果不能接受过时的读取,则还必须对leader执行所有查询。

Consul内部原理

我们可以通过如下的原理图来理解Consul的原理:

首先Consul支持多数据中心,在上图中有两个DataCenter,他们通过Internet互联,同时请注意为了提高通信效率,只有Server节点才加入跨数据中心的通信。

在单个数据中心中,Consul分为Client和Server两种节点(所有的节点也被称为Agent),Server节点保存数据,Client负责健康检查及转发数据请求到Server。

Server节点有一个Leader和多个Follower,Leader节点会将数据同步到Follower,Server的数量推荐是3个或者 5个,在Leader挂掉的时候会启动选举机制产生一个新的 Leader。

集群内的Consul节点通过gossip协议(流言协议)维护成员关系,也就是说某个节点了解集群内现在还有哪些节点,这些节点是Client还是Server。

单个数据中心的流言协议同时使用TCP和UDP通信,并且都使用8301端口。跨数据中心的流言协议也同时使用TCP和UDP 通信,端口使用8302。

img img

网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。

需要这份系统化的资料的朋友,可以添加戳这里获取

一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!