.Net Core微服务——Consul（4）：主从、集群

延续上一篇的话题继续，顺便放上一篇的传送门：点这里。

集群的必要性

consul本身就是管理集群的，现在还需要给consul搞个集群，这是为啥？因为consul单点也容易挂啊！万一管理集群的consul挂掉了，那么相当于上下游应用都变成了瞎子，看不到也调不到。所以集群的必要性不用我说了吧？

Server & Client

生产环境下，可以选择上面两种模式，下面我就简称S端、C端。说说它俩有啥不一样：

S端：

1、数量不宜过多，一般推荐3、5个，要求是奇数。

2、持久化保存节点数据。

3、多个S端之间是主从关系（Leader/Follower），Leader要额外负责监控各节点的健康并且同步给Follower。

C端：

1、数量没限制。

2、不保存节点数据。

相同点就是S端、C端都可以注册、查询。

Leader & Follower

这模式我简称主从好了，它只针对S端。Leader是根据Raft算法自动选举得出的，不用手动指定，所有的Follower接到信息以后，都要提交给Leader，然后Leader同步给其他的Follower。并且Leader要一直发心跳给所有的Follower证明“我还活着”，否则其他的Follower之间就要再选举出一个新的Leader了。这就导致S端最好不要扩展太多，否则你会怀疑人生。至于为什么要求S端数量是奇数，其实很好理解，偶数容易影响选举结果导致效率变低，比如两票对两票，谁来当Leader？其实去了解一下Raft算法就知道这里的主从怎么运行的，什么原理。我上个神器：戳这里，不用谢我。

S端

老规矩，还是用docker。先跑三个起来：

docker run -d --restart=always --name=server1 -e 'CONSUL_LOCAL_CONFIG={"skip_leave_on_interrupt":true}' -p 8300:8300 -p 8301:8301 -p 8301:8301/udp -p 8302:8302/udp -p 8302:8302 -p 8400:8400 -p 8500:8500 -p 8600:8600 -h server1 consul agent -server -bind=0.0.0.0 -bootstrap-expect=3 -node=server1 -data-dir=/tmp/data-dir -client 0.0.0.0 -uidocker run -d --restart=always --name=server2 -e 'CONSUL_LOCAL_CONFIG={"skip_leave_on_interrupt":true}' -p 9300:8300 -p 9301:8301 -p 9301:8301/udp -p 9302:8302/udp -p 9302:8302 -p 9400:8400 -p 9500:8500 -p 9600:8600 -h server2 consul agent -server -bind=0.0.0.0 -join=你服务器的IP -node=server2 -data-dir=/tmp/data-dir -client 0.0.0.0 -uidocker run -d --restart=always --name=server3 -e 'CONSUL_LOCAL_CONFIG={"skip_leave_on_interrupt":true}' -p 10300:8300 -p 10301:8301 -p 10301:8301/udp -p 10302:8302/udp -p 10302:8302 -p 10400:8400 -p 10500:8500 -p 10600:8600 -h server3 consul agent -server -bind=0.0.0.0 -join=你服务器的IP -node=server3 -data-dir=/tmp/data-dir -client 0.0.0.0 -ui

bootstrap-expect：集群所需S端的最小数量，低于这个数量无法选举出leader。

join：加入到哪个集群，需要目标服务器放通tcp8301端口，否则会出现这种情况

可以语句查看主从关系：

docker exec -t server1 consul operator raft list-peers

也可以直接进入页面查看主从关系，结果一样：

把现在的leader干掉的话，会自动选举一个新的leader出来：

server3成为了新的leader，而且只要它不挂，leader身份是不会转移的。比如我把server1启动以后，leader没有转移过去：

OK，现在S端已经是集群了，而且它们之间的数据都是互通共存的。验证一下：

server1新增键值，key=shenzhenma，value=hellow：

server2查看：

server3修改value=hellow world以后，server1查看：

C端

现在再来启动客户端：

docker run -d --restart=always --name=client1 -e 'CONSUL_LOCAL_CONFIG={"skip_leave_on_interrupt":true}' -p 11300:8300 -p 11301:8301 -p 11301:8301/udp -p 11302:8302/udp -p 11302:8302 -p 11400:8400 -p 11500:8500 -p 11600:8600 -h client1 consul agent -bind=0.0.0.0 -retry-join=你服务器的IP -node=client1 -data-dir=/tmp/data-dir -client 0.0.0.0 -ui

想要多个客户端的话，改一下端口和名字就可以了，我这里跑了3个，如图：

和刚才的3个S端一起，这6个都是一体的，数据都会自动同步，任意节点注册修改数据都会在其他节点看到。

入口统一

我把集群弄好了，但是现在的集群还没有发挥作用。前几篇文章有讲服务注册，consul注册的时候需要一个固定的地址。集群有很多节点，每一个IP端口都不一样，如果下端只和其中一个节点产生联系，万一这个节点挂了，下端就失去consul的支持了，集群的作用也没发挥出来。所以给下端一个统一的入口是必要的，这里用Nginx的Upstream模式实现，修改下配置文件就行了：

upstream myconsul {server 42.XX.XX.64:8500;server 42.XX.XX.64:9500; server 42.XX.XX.64:10500;server 42.XX.XX.64:11500;server 42.XX.XX.64:12500;server 42.XX.XX.64:13500;
} server{listen       88;server_name  localhost;location / {proxy_pass http://myconsul;
    }
}

配置文件修改好重启一下，进去看看能不能访问：

OK，下端注册服务时，统一用这个地址就可以了。跑两个试试（下端代码就不发了，前面几篇文章有）：

成功了！切换到其他consul节点看下能否正确展示：

很显然是OK的。基于我之前为服务配置的健康检查，最后来看下服务状态变化会不会同步给其他节点，比如我停掉其中一个：

变更的状态也很快同步到了其他节点。到这里为止，consul的集群就已经实现了，东西还是有点多的，如果实践遇到麻烦，欢迎讨论。

.Net Core微服务——Consul（4）：主从、集群相关推荐

从单机架构------》到现在复杂的微服务，分布式，集群，云平台途中是遇到了什么问题，又如何解决的？
本文转载地址服务端高并发分布式架构演进之路写的很清楚,全面,顺序的话,肯定不是完全正确,如Docker,redis 等但不重要,过程就是这莫个过程,根据公司业务不同,架构演变自然不同.转载记录一 ...
dubbo k8s 服务发现_将Dubbo微服务迁移到k8s集群环境中前的思考与落地
将Dubbo微服务迁移到k8s中的思考与落地说到容器化,不得不提kubernetes这个集群编排系统,它是一个开源系统,用于容器化应用的自动部署.扩缩和管理. Kubernetes 将构成应用的容器 ...
什么是微服务？分布式和集群又是什么？
什么是微服务? 微服务(Microservice Architecture)是架构设计方式的一种. 简单来说就是将传统的一站式应用,根据业务拆分成一个一个的服务, 每一个微服务提供单个业务功能的服务, ...
nginx工作笔记005---nginx配置负载均衡_在微服务中实现网关集群_实现TCP传输层协议__http协议的负载均衡
技术交流QQ群[JAVA,C++,Python,.NET,BigData,AI]:170933152 我们在微服务中,由于网关的存在,后来,在nginx中都不需要在配置其他服务的地址了,只需要,配置一 ...
.NET Core微服务之路：基于Consul最少集群实现服务的注册与发现（一）
原文:.NET Core微服务之路:基于Consul最少集群实现服务的注册与发现(一) Consul介绍 Consul是HashiCorp公司推出的开源工具[开源地址:https://github.c ...
.Net Core微服务入门——Ocelot和Consul集群高可用
.Net Core微服务入门--Ocelot和Consul集群高可用上一章我们ocelot网关顺利的接入了consul集群,并且访问成功. 但是,我们也遇到了问题,把 192.168.8.25 上 ...
.NET Core微服务之基于Consul实现服务治理
一.Consul基础介绍 Consul是HashiCorp公司推出的开源工具,用于实现分布式系统的服务发现与配置.与其他分布式服务注册与发现的方案,比如 Airbnb的SmartStack等相比,Co ...
.NET Core微服务之基于Consul实现服务治理（续）
Tip: 此篇已加入.NET Core微服务基础系列文章索引上一篇发布之后,很多人点赞和评论,不胜惶恐,这一篇把上一篇没有弄到的东西补一下,也算是给各位前来询问的朋友的一些回复吧. 一.Consul ...
ASP.NET Core 微服务初探[1]：服务发现之Consul
ASP.NET Core 微服务初探[1]:服务发现之Consul 在传统单体架构中,由于应用动态性不强,不会频繁的更新和发布,也不会进行自动伸缩,我们通常将所有的服务地址都直接写在项目的配置文件中, ...

.Net Core微服务——Consul（4）：主从、集群

.Net Core微服务——Consul（4）：主从、集群相关推荐

最新文章

热门文章