不知此网站枉做男人的网站,公众号运营思路,丹灶网站建设,网站开发与app开发的区别目录
一、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定理#xff…
目录
一、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则是APNacos不仅支持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 IntervalHTTP IntervalTCP IntervalTimeto LiveTTLDocker 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 -bind192.168.2.139 -client192.168.2.139 -data-dirdata -ui -node192.168.2.139 这样就启动了master1上的consul在node1上
cd /opt/
nohup ./consul agent -bind192.168.2.140 -client192.168.2.140 -data-dirdata -node192.168.2.140 -join192.168.2.139 在node2上
cd /opt/
nohup ./consul agent -bind192.168.2.141 -client192.168.2.141 -data-dirdata -node192.168.2.141 -join192.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博客
