Consul
在 Spring Cloud 体系中,几乎每个角色都会有两个以上的产品提供选择,比如在注册中心有:Eureka、Consul、zookeeper、etcd 等;网关的产品有 Zuul、Spring Cloud Gateway 等。在注册中心产品中,最常使用的是 Eureka 和 Consul,两者各有特点,企业可以根据自述项目情况来选择。
Consul简介
Consul 是 HashiCorp 公司推出的开源产品,用于实现分布式系统的服务发现、服务隔离、服务配置,这些功能中的每一个都可以根据需要单独使用,也可以同时使用所有功能。Consul 官网目前主要推 Consul 在服务网格中的使用。
与其它分布式服务注册与发现的方案相比,Consul 的方案更“一站式”——内置了服务注册与发现框架、分布一致性协议实现、健康检查、Key/Value 存储、多数据中心方案,不再需要依赖其它工具。Consul 本身使用 go 语言开发,具有跨平台、运行高效等特点,也非常方便和 Docker 配合使用。
Consul 的主要特点有:
Service Discovery : 服务注册与发现,Consul 的客户端可以做为一个服务注册到 Consul,也可以通过 Consul 来查找特定的服务提供者,并且根据提供的信息进行调用。
Health Checking: Consul 客户端会定期发送一些健康检查数据和服务端进行通讯,判断客户端的状态、内存使用情况是否正常,用来监控整个集群的状态,防止服务转发到故障的服务上面。
KV Store: Consul 还提供了一个容易使用的键值存储。这可以用来保持动态配置,协助服务协调、建立 Leader 选举,以及开发者想构造的其它一些事务。
Secure Service Communication: Consul 可以为服务生成分布式的 TLS 证书,以建立相互的 TLS 连接。 可以使用 intentions 定义允许哪些服务进行通信。 可以使用 intentions 轻松管理服务隔离,而不是使用复杂的网络拓扑和静态防火墙规则。
Multi Datacenter: Consul 支持开箱即用的多数据中心,这意味着用户不需要担心需要建立额外的抽象层让业务扩展到多个区域。
Consul 角色
Server: 服务端, 保存配置信息, 高可用集群, 在局域网内与本地客户端通讯, 通过广域网与其它数据中心通讯。 每个数据中心的 Server 数量推荐为 3 个或是 5 个。
Client: 客户端, 无状态, 将 HTTP 和 DNS 接口请求转发给局域网内的服务端集群。
Consul 旨在对 DevOps 社区和应用程序开发人员友好,使其成为现代、弹性基础架构的理想选择。
Consul 的优势
使用 Raft 算法来保证一致性, 比复杂的 Paxos 算法更直接。相比较而言, zookeeper 采用的是 Paxos, 而 etcd 使用的则是 Raft。
支持多数据中心,内外网的服务采用不同的端口进行监听。多数据中心集群可以避免单数据中心的单点故障,而其部署则需要考虑网络延迟, 分片等情况等。 zookeeper 和 etcd 均不提供多数据中心功能的支持。
支持健康检查。 etcd 不提供此功能。
支持 http 和 dns 协议接口。 zookeeper 的集成较为复杂, etcd 只支持 http 协议。
官方提供 Web 管理界面, etcd 无此功能。
Consul 保持了 CAP 中的 CP,保持了强一致性和分区容错性。
Consul 支持 Http\gRPC\DNS 多种访问方式。
Spring Cloud 中注册中心组件对比
![](https://img.laitimes.com/img/9ZDMuAjOiMmIsIjOiQnIsIyZuBnLxQzN5UjNxUTMzADOwAjMwIzLc52YucWbp5GZzNmLn9Gbi1yZtl2Lc9CX6MHc0RHaiojIsJye.png)
CAP解释: 分布式系统的CAP理论
CAP理论:一个分布式系统最多只能同时满足一致性(Consistency)、可用性(Availability)和分区容错性(Partition tolerance)这三项中的两项。
一致性(Consistency),即更新操作成功并返回客户端完成后,所有节点在同一时间的数据完全一致,所以,一致性,说的就是数据一致性。
可用性(Availability), 即服务一直可用,而且是正常相应时间。
分区容错性(Partition Tolerance),即分布式系统在遇到某节点或网络分区故障的时候,仍然能够对外提供满足一致性和可用性的服务。
Consul–VS–Eureka
Consul和Eureka最大区别在于:Consul保证CA,而Eureka保证了AP;
Consul强一致性带来的是:
服务注册相比Eureka会稍慢一些。因为Consul的raft协议要求必须过半数的节点都写入成功才认为注册成功
Leader挂掉时,重新选举期间整个consul不可用。保证了强一致性但牺牲了可用性。
Eureka保证高可用(A)和最终一致性:
服务注册相对要快,因为不需要等注册信息replicate到其他节点,也不保证注册信息是否replicate成功
当数据出现不一致时,虽然A, B上的注册信息不完全相同,但每个Eureka节点依然能够正常对外提供服务,这会出现查询服务信息时如果请求A查不到,但请求B就能查到。如此保证了可用性但牺牲了一致性。
Consul 的调用过程
1、当 Producer 启动的时候,会向 Consul 发送一个 post 请求,告诉 Consul 自己的 IP 和 Port;
2、Consul 接收到 Producer 的注册后,每隔 10s(默认)会向 Producer 发送一个健康检查的请求,检验 Producer 是否健康;
3、当 Consumer 发送 GET 方式请求 /api/address 到 Producer 时,会先从 Consul 中拿到一个存储服务 IP 和 Port 的临时表,从表中拿到 Producer 的 IP 和 Port 后再发送 GET 方式请求 /api/address;
4、该临时表每隔 10s 会更新,只包含有通过了健康检查的 Producer。
Spring Cloud Consul 项目是针对 Consul 的服务治理实现。Consul 是一个分布式高可用的系统,它包含多个组件,但是作为一个整体,在微服务架构中,为我们的基础设施提供服务发现和服务配置的工具。
consul集成部署
官网地址链接:可参考相关官方文档
基础环境
基础环境是在Linux centos7.7的基础环境中进行集群部署,基础系统架构为x86_64
[[email protected] ~]# hostname -I
10.252.68.158
[[email protected] ~]# uname -m
x86_64
[[email protected] ~]# cat /etc/redhat-release
CentOS Linux release 7.7.1908 (Core)
IP地址规划
IP | 部署节点规划 | 主机名称 |
---|---|---|
10.252.68.156 | devops-consul-server01 | hmsc-dev-1-nginx-web |
10.252.68.157 | devops-consul-server02 | hmsc-dev-1-db |
10.252.68.158 | devops-consul-server03 | hmsc-dev-1-fdfs |
部署安装
下载源码
官网下载链接
consul_1.8.0_linux_amd64.zip下载
这里可以在需要部署的三台机器都下载最新版本的源码压缩包consul_1.8.0_linux_amd64.zip
这里以10.252.68.156机器为例。其他2台机器都一样的操作
[[email protected] ~]# cd /usr/local/src/
[[email protected] src]# wget https://releases.hashicorp.com/consul/1.8.0/consul_1.8.0_linux_amd64.zip
[[email protected] src]# unzip consul_1.8.0_linux_amd64.zip -d /usr/local/consul
Archive: consul_1.8.0_linux_amd64.zip
inflating: /usr/local/consul/consul
[[email protected] src]# cd /usr/local/consul/
[[email protected] consul]# ll
total 111004
-rwxr-xr-x 1 root root 113666152 Jun 19 02:29 consul
配置环境变量
[[email protected] consul]# echo "export PATH=$PATH:/usr/local/consul" >> /etc/profile
[[email protected] consul]# . /etc/profile
上述的操作需要在部署集群的机器中全部执行一次
启动集群节点
consul agent有两种运行模式:server和client。这里的server和client只是consul集群层面的区分,与搭建在cluster之上的应用服务无关。
以server模式运行的consul agent节点用于维护consul集群的状态,
官方建议每个consul cluster至少有3个或以上的运行在server mode的agent,client节点不限。
我们这里以安装三个节点为例
[[email protected] ~]# consul agent -server -data-dir=/tmp/consul -node=server-1 -bind=10.252.68.156 -bootstrap-expect 3 -client=0.0.0.0 -ui &
[[email protected] ~]# consul agent -server -data-dir=/tmp/consul -node=server-2 -bind=10.252.68.157 -join=10.252.68.156 -client=0.0.0.0 -ui &
[[email protected] ~]# consul agent -server -data-dir=/tmp/consul -node=server-3 -bind=10.252.68.158 -join=10.252.68.156 -client=0.0.0.0 -ui &
选项详解
consul配置参数大全、详解、总结
选项 | 说明 |
---|---|
consul anent | 该命令会启动一个consulAnent |
-server | 表示该 agent是一个 serverAgent,不添加这个选项则表示是一个 clientAgent |
-data-dir | 表示相关数据存储的目录位置,在 serverAgent上该命令所指示的目录下会存储一些集群的状态信息 |
-node | 指定该 agent 节点的名称,该名称在集群众必须是唯一的 |
-bind | 指定 agent 的 Ip |
-bootstrap-expect | 该命令通知 consul 准备加入集群的节点个数 |
-client 0.0.0.0 -ui | 启动 consulUI,如不添加该指令,则 UI 只能在当前机器上访问 |
-join | 将该节点加入集群中 |
验证
验证集群是否搭建成功,执行consul members,在任意的一台机器上:
[[email protected] ~]# consul members
Node Address Status Type Build Protocol DC Segment
server-1 10.252.68.156:8301 alive server 1.8.0 2 dc1 <all>
server-2 10.252.68.157:8301 alive server 1.8.0 2 dc1 <all>
server-3 10.252.68.158:8301 alive server 1.8.0 2 dc1 <all>