【服务治理中央件】consul先容和根本原理

目次
一、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 下载解压

---

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

复制代码

4.3 启动consul

---

1. 在master1上：
2. cd /opt/
3. nohup ./consul agent -server -bootstrap  -bind=192.168.2.139   -client=192.168.2.139 -data-dir=data -ui -node=192.168.2.139 &
5. 这样就启动了master1上的consul
7. 在node1上：
8. cd /opt/
9. 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 &
11. 在node2上：
12. cd /opt/
13. 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

1. curl -X PUT -d '                                      
2. {                                                   
3.     "id": "ambari-server",                                   
4.     "name": "ambari-server",                                 
5.     "address": "192.168.2.152",                     
6.     "port": 8080,                                    
7.     "tags": ["ambari-server-service"],                       
8.     "checks": [{                                    
9.             "http": "http://192.168.2.152:8080/",        
10.             "interval": "5s"                             
11.     }]                                               
12. }' http://192.168.2.139:8500/v1/agent/service/register

复制代码

注册成功 且状态康健

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

1. 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博客

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。