当前位置：首页 > news >正文

【服务治理中间件】consul介绍和基本原理

news 来源：原创 2025/9/11 12:17:50

一、CAP定理

二、服务注册中心产品比较

三、Consul概述

3.1 什么是Consul

3.2 Consul架构

3.3 Consul的使用场景

3.4 Consul健康检查

四、部署consul集群

4.1 服务器部署规划

4.2 下载解压

4.3 启动consul

五、服务注册到consul

一、CAP定理

CAP定理，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可兼得。

一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
分区容忍性（P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

CAP原则的精髓就是要么AP，要么CP，要么AC，但是不存在CAP。如果在某个分布式系统中数据无副本，那么系统必然满足强一致性条件，因为只有独一数据，不会出现数据不一致的情况，此时C和P两要素具备，但是如果系统发生了网络分区状况或者宕机，必然导致某些数据不可以访问，此时可用性条件就不能被满足，即在此情况下获得了CP系统，但是CAP不可同时满足。因此在进行分布式架构设计时，必须做出取舍。

二、服务注册中心产品比较

服务注册中心主流产品如下：

Zookeeper和Consul保证的是CP，而Eureka则是AP，Nacos不仅支持CP也支持AP。

当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但是Zookeeper会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s，且选举期间整个Zookeeper集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得Zookeeper集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。

所以Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：

Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)
当网络稳定时，当前实例新的注册信息会被同步到其它节点中

因此， Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪。

三、Consul概述

3.1 什么是Consul

Consul是一个服务网格解决方案，提供了一个功能齐全的控制平面，具有服务发现、配置和分段功能。这些功能中的每一项都可以根据需要单独使用，也可以一起使用来构建一个完整的服务网格。Consul需要一个数据平面，并支持代理和原生集成模型。Consul提供了一个简单的内置代理，因此一切都可以开箱即用，但也支持第三方代理集成，如Envoy。

Consul的主要功能有:

服务发现 : Consul的客户端可以注册一个服务，比如api或mysql，其他客户端可以使用Consul来发现特定服务的提供者。使用DNS或HTTP，应用程序可以很容易地找到他们所依赖的服务。
健康检查 : Consul客户端可以提供任何数量的健康检查，要么与给定的服务相关联（如： “webserver是否返回200 OK”），要么与本地节点相关联（如： “内存利用率是否低于90%”）。这些信息提供给运维人员用来监控集群的健康状况，并被服务发现组件来路由流量（比如：仅路由到健康节点）
KV存储 ：应用程序可以利用Consul的层级K/V存储来实现任何目的，包括动态配置、功能标记、协调、领导者选举等。Consul提供了HTTP API，使其非常简单以用。
安全服务通信：Consul可以为服务生成和分发TLS（传输层安全性协议）证书，以建立相互的TLS连接。可以使用Intention来定义哪些服务被允许进行通信。服务隔离可以通过可以实时更改Intention策略轻松管理，而不是使用复杂的网络拓扑结构和静态防火墙规则。
多数据中心:Consul支持开箱即用的多数据中心。这意味着Consul的用户不必担心建立额外的抽象层来发展到多个区域。

Consul的设计对DevOps社区和应用开发人员都很友好，使其成为现代弹性基础架构的完美选择。

3.2 Consul架构

Consul是一个分布式、高可用的系统。每个为Consul提供服务的节点都会运行一个_Consul Agent_。运行代理不需要发现其他服务或获取/设置密钥/值数据。Agent负责对节点上的服务以及节点本身进行健康检查。

Consul Agent 分为两种模式， Server 和 Client模式，一般我们得部署模型是 Server + Client的模式（当然也可以纯Server）, Server 具有Client的全部功能，但是由于Server负责存储数据，并且强一致性模型的缘故， Server数是有限的（3-5个Server节点，Client可以无限扩展的）更多信息可参考架构概述。

Agent与一个或多个Consul Server对话。Consul Server是存储和复制数据的地方。Server本身会选出一个Leader。虽然Consul可以用一台Server来运作，但建议使用3到5台，以避免故障情况导致数据丢失。建议每个数据中心采用Consul服务器集群。

Server Agent维护着一个目录（Catalog），这个目录（Catalog）是由Agent提交的信息汇总形成的。目录维护着集群的高层视图，包括哪些服务可用，哪些节点运行这些服务，健康信息等。

需要发现其他服务或节点的基础结构组件可以查询任何Consul Server或任何Consul Agent。Agent将查询自动转发到Server。每个数据中心都运行一个Consul Server集群。当有跨数据中心的服务发现或配置请求时，本地Consul Server将请求转发到远程数据中心并返回结果。

从宏观角度看, Consul架构是这样的。

我们来分析一下这张图，并描述一下每一个部分。首先，我们可以看到有两个数据中心，分别标注为 "DATACENTER1"和 “DATACENTER2”。Consul对多个数据中心有天然非常好的支持，并希望这是常见的情况。

在每个数据中心内，我们有Client和Server的混合。预计会有3到5台Server。这是在权衡故障场景下可用性和性能之间取得平衡的结果，因为随着机器的增加，共识的速度会逐渐变慢。然而，Client的数量没有限制，它们可以轻松地扩展到数千或数万。

所有在数据中心的代理都会参与一个Gossip协议。这意味着有一个Gossip池，其中包含了某个数据中心的所有Agent。这有几个目的：

第一，客户端不需要配置Server的地址，发现工作是自动完成的。
第二，检测代理故障的工作不放在Server上，而是分布式的。这使得故障检测的扩展性比原生的心跳方案要强得多。同时，它还为节点提供了故障检测，如果代理无法到达，那么该节点可能已经发生了故障。
第三，它被用作消息层，当发生重要事件（如Leader 选举）时进行通知。

每个数据中心的Server都是单一Raft对等集的一部分。这意味着它们共同选出一个单一的Leader，一个被选中的Server，它有额外的职责。Leader负责处理所有查询和事务。事务也必须复制到所有参与共识协议的分片。由于这一要求，当None-Leader Server收到RPC请求时，它会将其转发给集群Leader。

Server Agent还作为WAN（广域网） Gossip Pool的一部分进行操作。这个池子与**LAN（局域网）**池不同，因为它是针对互联网的较高延迟进行优化的，WAN池只包含其他Consul 数据中心的Sever Agent。这个池的目的是让数据中心以低接触的方式发现彼此。让一个新的数据中心上线就像加入现有的WAN Gossip 池一样简单。因为服务器都在这个池中运行，所以还可以实现跨数据中心的请求。当一台Server收到一个不同数据中心的请求时，它会将其转发到正确数据中心的随机Server。然后该Servevr可能会转发到本地Leader。

这导致数据中心之间的耦合度很低，但由于故障检测、连接缓存和多路复用，跨数据中心的请求相对快速可靠。

一般情况下，不同的Consul数据中心之间不会复制数据。当对另一个数据中心的资源进行请求时，本地Consul服务器会将该资源的RPC请求转发给远程Consul服务器，并返回结果。如果远程数据中心不可用，那么这些资源也将不可用，但这不会以其他方式影响本地数据中心。

在一些特殊情况下，可以复制有限的数据子集，比如使用Consul内置的ACL复制功能，或者使用consul-replicate等外部工具。在某些地方，Client Agent可能会从Server上缓存数据，使其在本地可用，以提高性能和可靠性。例如，包括连接证书和它允许Client代理对入站连接请求做出本地决定，而无需往返Server的场景。一些API端点还支持可选的结果缓存。这有助于可靠性，因为即使与服务器的连接中断或服务器暂时不可用，本地Agent仍然可以继续从缓存中响应一些查询，如服务发现或Connect授权。

官网： Consul by HashiCorp

3.3 Consul的使用场景

Consul的应用场景包括服务发现、服务隔离、服务配置：

服务发现场景中consul作为注册中心，服务地址被注册到consul中以后，可以使用consul提供的dns、http接口查询，consul支持health check。
服务隔离场景中consul支持以服务为单位设置访问策略，能同时支持经典的平台和新兴的平台，支持tls证书分发，service-to-service加密。
服务配置场景中consul提供key-value数据存储功能，并且能将变动迅速地通知出去，借助Consul可以实现配置共享，需要读取配置的服务可以从Consul中读取到准确的配置信息。
Consul可以帮助系统管理者更清晰的了解复杂系统内部的系统架构，运维人员可以将Consul看成一种监控软件，也可以看成一种资产（资源）管理系统。

比如：docker实例的注册与配置共享、coreos实例的注册与配置共享、vitess集群、SaaS应用的配置共享、Consul与confd服务集成，动态生成nginx和haproxy配置文件或者Consul结合nginx构建高可用可扩展的Web服务。

3.4 Consul健康检查

Consul的一个基本功能是提供系统级和应用级健康检查。如果健康检查与某个服务关联，则称为是应用级的；如果不予服务关联，则监控整个节点的健康。

check定义在配置文件中，或运行时通过HTTP接口添加。Check是通过HTTP与节点保持一致。

有五种check方法：

Script+ Interval
HTTP+ Interval
TCP+ Interval
Timeto Live（TTL）
Docker+ interval

参考文章：【Consul】实践指导-健康检查（Checks）_consul health check-CSDN博客

四、部署consul集群

4.1 服务器部署规划

主机名

角色

master1

192.168.2.139

server

node1

192.168.2.140

client

node2

192.168.2.210

client

4.2 下载解压

# 下载安装包
https://releases.hashicorp.com/consul/1.18.1/consul_1.18.1_linux_amd64.zip
# 解压
unzip   consul_1.18.1_linux_amd64.zip

4.3 启动consul

在master1上：
cd /opt/
nohup ./consul agent -server -bootstrap  -bind=192.168.2.139   -client=192.168.2.139 -data-dir=data -ui -node=192.168.2.139 &这样就启动了master1上的consul在node1上：
cd /opt/
nohup ./consul agent -bind=192.168.2.140 -client=192.168.2.140 -data-dir=data -node=192.168.2.140 -join=192.168.2.139 &在node2上：
cd /opt/
nohup ./consul agent -bind=192.168.2.141 -client=192.168.2.141 -data-dir=data -node=192.168.2.141 -join=192.168.2.139 &

各个节点都启动完之后

在浏览器访问http://192.168.2.139:8500/

可看到consul的管理界面

192.1682.139 为Leader

Consul 的 Web 管理界面有一些菜单，我们这里做一下简单的介绍：

Services，管理界面的默认页面，用来展示注册到 Consul 的服务，启动后默认会有一个 consul 服务，也就是它本身。
Nodes，在 Services 界面双击服务名就会来到 Services 对于的 Nodes 界面，Services 是按照服务的抽象来展示的，Nodes 展示的是此服务的具体节点信息。比如启动了两个订单服务实例，Services 界面会出现一个订单服务，Nodes 界面会展示两个订单服务的节点。
Key/Value ，如果有用到 Key/Value 存储，可以在界面进行配置、查询。
ACL，全称 Access Control List，为访问控制列表的展示信息。
Intentions，可以在页面配置请求权限。

五、服务注册到consul

如下示例将ambariServer服务注册奥consul

curl -X PUT -d '                                      
{                                                    "id": "ambari-server",                                   "name": "ambari-server",                                 "address": "192.168.2.152",                      "port": 8080,                                    "tags": ["ambari-server-service"],                       "checks": [{                                     "http": "http://192.168.2.152:8080/",        "interval": "5s"                             }]                                               
}' http://192.168.2.139:8500/v1/agent/service/register

注册成功且状态健康

把consul中注册的ambari-server服务移除

curl --request PUT http://192.168.2.139:8500/v1/agent/service/deregister/ambari-server

参考引用文章：Consul 架构 | Consul

Nacos和Consul的区别 - yifanSJ - 博客园
【Hadoop】HA简介&CAP理论的关系_hadoop cap-CSDN博客

原文链接：【超详细】Consul的安装的使用附多环境配置（傻瓜式教程）_consul安装与配置-CSDN博客

一、CAP定理

二、服务注册中心产品比较

三、Consul概述

3.1 什么是Consul

3.2 Consul架构

3.3 Consul的使用场景

3.4 Consul健康检查

四、部署consul集群

4.1 服务器部署规划

4.2 下载解压

4.3 启动consul

五、服务注册到consul

相关文章：