consul技术分享

2022年05月15日 阅读数:3
这篇文章主要向大家介绍consul技术分享,主要内容包括基础应用、实用技巧、原理机制等方面,希望对大家有所帮助。


开篇浅谈html

上一章《注册中心Eureka》咱们介绍了注册中心Eureka,相必你们都对注册中心都有了必定的认识了,在Eureka中止维护以后,Consul就成了其替换方案之一,让咱们一块儿来走进Consul的世界吧!java

1、Consul简介

在这里插入图片描述
Consul 是 HashiCorp 公司推出的开源工具,用于实现分布式系统的服务发现与配置。与其它分布式服务注册与发现的方案,Consul 的方案更“一站式”,内置了服务注册与发现框 架、分布一致性协议实现、健康检查、Key/Value 存储、多数据中心方案,再也不须要依赖其它工具(好比 ZooKeeper 等)。node

使用起来也较 为简单。Consul 使用 Go 语言编写,所以具备自然可移植性(支持Linux、windows和Mac OS X);安装包仅包含一个可执行文件,方便部署,与 Docker 等轻量级容器可无缝配合。mysql

Consul 的优点:linux

  • 使用 Raft 算法来保证一致性, 比复杂的 Paxos 算法更直接. 相比较而言, zookeeper 采用的是 Paxos, 而 etcd 使用的则是 Raft。
  • 支持多数据中心,内外网的服务采用不一样的端口进行监听。 多数据中心集群能够避免单数据中心 的单点故障,而其部署则须要考虑网络延迟, 分片等状况等。 zookeeper 和 etcd 均不提供多数据中 心功能的支持。
  • 支持健康检查。 etcd 不提供此功能。
  • 支持 http 和 dns 协议接口。 zookeeper 的集成较为复杂, etcd 只支持 http 协议。
  • 官方提供 web 管理界面, etcd 无此功能。
  • 综合比较, Consul 做为服务注册和配置管理的新星, 比较值得关注和研究。

特性:web

  • 服务发现
  • 健康检查
  • Key/Value 存储
  • 多数据中心

2、consul与Eureka的区别

(1)一致性
Consul强一致性(CP)算法

  • 服务注册相比Eureka会稍慢一些。由于Consul的raft协议要求必须过半数的节点都写入成功才认
    为注册成功
  • Leader挂掉时,从新选举期间整个consul不可用。保证了强一致性但牺牲了可用性。
    Eureka保证高可用和最终一致性(AP)
  • 服务注册相对要快,由于不须要等注册信息replicate到其余节点,也不保证注册信息是否
    replicate成功
  • 当数据出现不一致时,虽然A, B上的注册信息不彻底相同,但每一个Eureka节点依然可以正常对外提供服务,这会出现查询服务信息时若是请求A查不到,但请求B就能查到。如此保证了可用性但牺
    牲了一致性。
    (2)开发语言和使用
    eureka就是个servlet程序,跑在servlet容器中
    Consul则是go编写而成,安装启动便可

3、Consul的下载与安装

https://www.consul.io/downloadsspring

在这里插入图片描述
启动成功以后访问: http://IP:8500 ,能够看到 Consul 的管理界面sql

在这里插入图片描述

4、Consul基本使用

Consul 支持健康检查,并提供了 HTTP 和 DNS 调用的API接口完成服务注册,服务发现,以及K/V存储这些功能。接下来经过发送HTTP请求的形式来了解一下Consul。bootstrap

一、服务注册与发现

注册服务

经过postman发送put请求到http://192.168.74.101:8500/v1/catalog/register地址能够完成服务注册

{
   
   
 "Datacenter": "dc1", 
 "Node": "node01", 
 "Address": "192.168.74.102",
 "Service": {
   
   
 "ID":"mysql-01",
 "Service": "mysql", 
 "tags": ["master","v1"], 
 "Address": "192.168.74.102",
 "Port": 3306
 }
}

服务查询
经过postman发送get请求到http://192.168.74.101:8500/v1/catalog/services查看全部的服务列表
在这里插入图片描述
经过postman发送get请求到http://192.168.74.101:8500/v1/catalog/service/服务名查看具体的服务详情
在这里插入图片描述
服务删除
经过postman发送put请求到http://192.168.74.101:8500/v1/catalog/deregister删除服务

{
   
   
  "Datacenter": "dc1",
  "Node": "node01",
  "ServiceID": "mysql-01"
}

二、Consul的KV存储

能够参照Consul提供的KV存储的API完成基于Consul的数据存储
在这里插入图片描述

  • key值中能够带/, 能够看作是不一样的目录结构。
  • value的值通过了base64_encode,获取到数据后base64_decode才能获取到原始值。数据不能大
    于512Kb
  • 不一样数据中心的kv存储系统是独立的,使用dc=?参数指定。

5、基于consul的服务注册

一、pom文件

	    <!--SpringCloud提供的基于Consul的服务发现-->
		<dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-consul-discovery</artifactId>
        </dependency>
		<!--actuator用于心跳检查-->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-actuator</artifactId>
        </dependency>

其中 spring-cloud-starter-consul-discovery 是SpringCloud提供的对consul支持的相关依赖。

spring-boot-starter-actuator 适用于完成心跳检测响应的相关依赖。

二、配置服务注册

修改每一个微服务的application.yml配置文件,添加consul服务发现的相关配置信息

spring:
 ...省略
 cloud:
   consul: #consul相关配置
     host: 192.168.74.101 #ConsulServer请求地址
     port: 8500 #ConsulServer端口
     discovery:
        #是否注册
       register: true
        #实例ID
       instance-id: ${
   
   spring.application.name}-1
        #服务实例名称
       service-name: ${
   
   spring.application.name}
        #服务实例端口
       port: ${
   
   server.port}
        #健康检查路径
       healthCheckPath: /actuator/health
        #健康检查时间间隔
       healthCheckInterval: 15s
        #开启ip地址注册
       prefer-ip-address: true
        #实例的请求ip
       ip-address: ${
   
   spring.cloud.client.ip-address}

其中 spring.cloud.consul 中添加consul的相关配置

  • host:表示Consul的Server的请求地址
  • port:表示Consul的Server的端口
  • discovery:服务注册与发现的相关配置
    • instance-id : 实例的惟一id(推荐必填),spring cloud官网文档的推荐,为了保证生成一
      个惟一的id ,也能够换成${spring.application.name}: ${spring.cloud.client.ipAddress}
    • prefer-ip-address:开启ip地址注册
    • ip-address:当前微服务的请求ip

三、在控制台中查看服务列表

打开ConsulServer的管理控制台,能够发现三个微服务已经所有注册到Consul中了。
在这里插入图片描述

6、基于consul的服务发现

因为SpringCloud对Consul进行了封装。对于在消费者端获取服务提供者信息和Eureka是一致的。一样使用 DiscoveryClient 完成调用获取微服务实例信息。

7、consul高可用集群

在这里插入图片描述
此图是官网提供的一个事例系统图,图中的Server是consul服务端高可用集群,Client是consul客户
端。consul客户端不保存数据,客户端将接收到的请求转发给响应的Server端。Server之间经过局域网或广域网通讯实现数据一致性。每一个Server或Client都是一个consul agent。Consul集群间使用了
GOSSIP协议通讯和raft一致性算法。上面这张图涉及到了不少术语:

  • Agent——agent是一直运行在Consul集群中每一个成员上的守护进程。经过运行 consul agent来启
    动。
    agent能够运行在client或者server模式。指定节点做为client或者server是很是简单的,除非有其
    他agent实例。全部的agent都能运行DNS或者HTTP接口,并负责运行时检查和保持服务同步。

  • Client——一个Client是一个转发全部RPC到server的代理。这个client是相对无状态的。client惟
    一执行的后台活动是加入LAN

  • gossip池。这有一个最低的资源开销而且仅消耗少许的网络带宽。

  • Server——一个server是一个有一组扩展功能的代理,这些功能包括参与Raft选举,维护集群状
    态,响应RPC查询,与其余数据中心交互WANgossip和转发查询给leader或者远程数据中心。

  • DataCenter——虽然数据中心的定义是显而易见的,可是有一些细微的细节必须考虑。例如,在
    EC2中,多个可用区域被认为组成一个数据中心?咱们定义数据中心为一个私有的,低延迟和高带
    宽的一个网络环境。这不包括访问公共网络,可是对于咱们而言,同一个EC2中的多个可用区域可
    以被认为是一个数据中心的一部分。

  • Consensus——在咱们的文档中,咱们使用Consensus来代表就leader选举和事务的顺序达成一
    致。因为这些事务都被应用到有限状态机上,Consensus暗示复制状态机的一致性。

  • Gossip——Consul创建在Serf的基础之上,它提供了一个用于多播目的的完整的gossip协议。
    Serf提供成员关系,故障检测和事件广播。更多的信息在gossip文档中描述。这足以知道gossip使
    用基于UDP的随机的点到点通讯。

  • LAN Gossip——它包含全部位于同一个局域网或者数据中心的全部节点。

  • WANGossip——它只包含Server。这些server主要分布在不一样的数据中心而且一般经过因特网或者广域网通讯。

在每一个数据中心,client和server是混合的。通常建议有3-5台server。这是基于有故障状况下的可用性和性能之间的权衡结果,由于越多的机器加入达成共识越慢。然而,并不限制client的数量,它们能够很容易的扩展到数千或者数万台。

同一个数据中心的全部节点都必须加入gossip协议。这意味着gossip协议包含一个给定数据中心的全部节点。这服务于几个目的:第一,不须要在client上配置server地址。发现都是自动完成的。第二,检测节点故障的工做不是放在server上,而是分布式的。这是的故障检测相比心跳机制有更高的可扩展性。第三:它用来做为一个消息层来通知事件,好比leader选举发生时。

每一个数据中心的server都是Raft节点集合的一部分。这意味着它们一块儿工做并选出一个leader,一个有额外工做的server。leader负责处理全部的查询和事务。做为一致性协议的一部分,事务也必须被复制到全部其余的节点。由于这一要求,当一个非leader得server收到一个RPC请求时,它将请求转发给集群leader。

server节点也做为WAN gossip Pool的一部分。这个Pool不一样于LAN Pool,由于它是为了优化互联网更高的延迟,而且它只包含其余Consul server节点。这个Pool的目的是为了容许数据中心可以以lowtouch的方式发现彼此。这使得一个新的数据中心能够很容易的加入现存的WAN gossip。由于server都运行在这个pool中,它也支持跨数据中心请求。当一个server收到来自另外一个数据中心的请求时,它随即转发给正确数据中想一个server。该server再转发给本地leader。

这使得数据中心之间只有一个很低的耦合,可是因为故障检测,链接缓存和复用,跨数据中心的请求都是相对快速和可靠的。

8、 Consul的核心知识

Gossip协议
传统的监控,如ceilometer,因为每一个节点都会向server报告状态,随着节点数量的增长server的压力随之增大。在全部的Agent之间(包括服务器模式和普通模式)运行着Gossip协议。服务器节点和普通Agent都会加入这个Gossip集群,收发Gossip消息。每隔一段时间,每一个节点都会随机选择几个节点发送Gossip消息,其余节点会再次随机选择其余几个节点接力发送消息。这样一段时间事后,整个集群都能收到这条消息。示意图以下。
在这里插入图片描述
RAFT一致性算法
在这里插入图片描述
为了实现集群中多个ConsulServer中的数据保持一致性,consul使用了基于强一致性的RAFT算法。
在Raft中,任什么时候候一个服务器能够扮演下面角色之一:

  1. Leader: 处理全部客户端交互,日志复制等,通常一次只有一个Leader.
  2. Follower: 相似选民,彻底被动
  3. Candidate(候选人): 能够被选为一个新的领导人。

Leader全权负责全部客户端的请求,以及将数据同步到Follower中(同一时刻系统中只存在一个 Leader)。Follower被动响应请求RPC,从不主动发起请求RPC。Candidate由Follower向Leader转换的中间状态

关于RAFT一致性算法有一个经典的动画http://thesecretlivesofdata.com/raft/,其中详细介绍了选
举,数据同步的步骤。

9、Consul 集群搭建

在这里插入图片描述
首先须要有一个正常的Consul集群,有Server,有Leader。这里在服务器Server一、Server二、Server3上分别部署了Consul Server。(这些服务器上最好只部署Consul程序,以尽可能维护Consul Server的稳定)

服务器Server4和Server5上经过Consul Client分别注册Service A、B、C,这里每一个Service分别部署在了两个服务器上,这样能够避免Service的单点问题。(通常微服务和Client绑定)

在服务器Server6中Program D须要访问Service B,这时候Program D首先访问本机Consul Client提供的HTTP API,本机Client会将请求转发到Consul Server,Consul Server查询到Service B当前的信息返回。

一、准备环境

在这里插入图片描述
Agent 以 client 模式启动的节点。在该模式下,该节点会采集相关信息,经过 RPC 的方式向
server 发送。Client模式节点有无数个,官方建议搭配微服务配置

Agent 以 server 模式启动的节点。一个数据中心中至少包含 1 个 server 节点。不过官方建议使用
3 或 5 个 server 节点组建成集群,以保证高可用且不失效率。server 节点参与 Raft、维护会员信
息、注册服务、健康检查等功能。

二、安装consul并启动

在每一个consul节点上安装consul服务,下载安装过程和单节点一致。

##从官网下载最新版本的Consul服务
wget https://releases.hashicorp.com/consul/1.5.3/consul_1.5.3_linux_amd64.zip
##使用unzip命令解压
unzip consul_1.5.3_linux_amd64.zip
##将解压好的consul可执行命令拷贝到/usr/local/bin目录下
cp consul /usr/local/bin
##测试一下
consul

启动每一个consul server节点

##登陆s1虚拟机,以server形式运行
consul agent -server -bootstrap-expect 3 -data-dir /etc/consul.d -node=server-1 
-bind=192.168.74.101 -ui -client 0.0.0.0 &
##登陆s2 虚拟机,以server形式运行
consul agent -server -bootstrap-expect 2 -data-dir /etc/consul.d -node=server-2 
-bind=192.168.74.102 -ui -client 0.0.0.0 & 
##登陆s3 虚拟机,以server形式运行
consul agent -server -bootstrap-expect 2 -data-dir /etc/consul.d -node=server-3 
-bind=192.168.74.103 -ui -client 0.0.0.0 &

-server: 以server身份启动。
-bootstrap-expect:集群要求的最少server数量,当低于这个数量,集群即失效。
-data-dir:data存放的目录,更多信息请参阅consul数据同步机制
-node:节点id,在同一集群不能重复。
-bind:监听的ip地址。
-client:客户端的ip地址(0.0.0.0表示不限制) & :在后台运行,此为linux脚本语法

至此三个Consul Server模式服务所有启动成功

##在本地电脑中使用client形式启动consul
consul agent -client=0.0.0.0  -data-dir /etc/consul.d -node=client-1

三、每一个节点加入集群

在s2,s3,s4 服务其上经过consul join 命令加入 s1中的consul集群中

##加入consul集群
consul join 192.168.74.101

四、 测试

在任意一台服务器中输入 consul members查看集群中的全部节点信息

##查看consul集群节点信息
consul members

在这里插入图片描述

10、Consul 常见问题

(1)节点和服务注销
当服务或者节点失效,Consul不会对注册的信息进行剔除处理,仅仅标记已状态进行标记(而且不可以使用)。若是担忧失效节点和失效服务过多影响监控。能够经过调用HTTP API的形式进行处理节点和服务的注销可使用HTTP API:

  • 注销任意节点和服务:/catalog/deregister
  • 注销当前节点的服务:/agent/service/deregister/:service_id

若是某个节点不继续使用了,也能够在本机使用consul leave命令,或者在其它节点使用consul forceleave 节点Id。
(2)健康检查与故障转移

在集群环境下,健康检查是由服务注册到的Agent来处理的,那么若是这个Agent挂掉了,那么此节点的健康检查就处于无人管理的状态。

从实际应用看,节点上的服务可能既要被发现,又要发现别的服务,若是节点挂掉了,仅提供被发现的功能实际上服务仍是不可用的。固然发现别的服务也能够不使用本机节点,能够经过访问一个Nginx实现的若干Consul节点的负载均衡来实现。