赞
踩
目录
CAP定理,指的是在一个分布式系统中, Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性),三者不可兼得。
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可以很好的应对因网络故障导致部分节点失去联系的情况,而不会像zookeeper那样使整个注册服务瘫痪。
Consul是一个服务网格解决方案,提供了一个功能齐全的控制平面,具有服务发现、配置和分段功能。这些功能中的每一项都可以根据需要单独使用,也可以一起使用来构建一个完整的服务网格。Consul需要一个数据平面,并支持代理和原生集成模型。Consul提供了一个简单的内置代理,因此一切都可以开箱即用,但也支持第三方代理集成,如Envoy。
Consul的主要功能有:
Consul的设计对DevOps社区和应用开发人员都很友好,使其成为现代弹性基础架构的完美选择。
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都是单一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的应用场景包括服务发现、服务隔离、服务配置:
比如:docker实例的注册与配置共享、coreos实例的注册与配置共享、vitess集群、SaaS应用的配置共享、Consul与confd服务集成,动态生成nginx和haproxy配置文件或者Consul结合nginx构建高可用可扩展的Web服务。
Consul的一个基本功能是提供系统级和应用级健康检查。如果健康检查与某个服务关联,则称为是应用级的;如果不予服务关联,则监控整个节点的健康。
check定义在配置文件中,或运行时通过HTTP接口添加。Check是通过HTTP与节点保持一致。
有五种check方法:
参考文章:【Consul】实践指导-健康检查(Checks)_consul health check-CSDN博客
主机名 | IP | 角色 |
master1 | 192.168.2.139 | server |
node1 | 192.168.2.140 | client |
node2 | 192.168.2.210 | client |
-
- # 下载安装包
- https://releases.hashicorp.com/consul/1.18.1/consul_1.18.1_linux_amd64.zip
- # 解压
- unzip consul_1.18.1_linux_amd64.zip
- 在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 管理界面有一些菜单,我们这里做一下简单的介绍:
如下示例将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博客
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。