目录
一、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 服务器部署规划
主机名 | IP | 角色 |
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博客