Consul 是一个分布式，高可用的系统。 为了快速了解Consul的工作原理，本节只介绍基础知识，不会介绍详细的细节。
向Consul提供服务的每个节点都运行一个Consul代理。 发现其他服务或获取/设置键/值数据不需要运行代理。 代理负责健康检查节点上的服务以及节点本身。
代理与一个或多个Consul服务器通信。Consul 服务器是数据存储和复制的地方。 服务器自己选出一个 leader。 虽然Consul可以在一台服务器上运行，但推荐使用3到5台来避免数据丢失的情况。 每个数据中心都建议使用一组Consul服务器。
需要发现其他服务或节点的基础架构组件可以查询任何Consul服务器或任何Consul代理。 代理自动将查询转发到服务器。
每个数据中心都运行Consul服务器集群。 当跨数据中心服务发现或配置请求时，本地Consul服务器将请求转发到远程数据中心并返回结果。
Consul解决的问题是多种多样的，但是每个单独的特征已经被许多不同的系统解决了。 尽管没有单一的系统提供Consul的所有功能，但还有其他的选择可以解决这些问题。
ZooKeeper，doozerd和etcd在他们的架构中都是相似的。 所有这三个服务器节点都需要一定数量的节点才能运行（通常是简单多数）。 它们是高度一致的，并且公开了可以通过应用程序中的客户端库来构建复杂的分布式系统的各种基元。
Consul 还使用单个数据中心内的服务器节点。 在每个数据中心，Consul服务器都需要一个仲裁来 *** 作并提供强大的一致性。 不过，Consul拥有对多个数据中心的本地支持，以及连接服务型则器节点和客户端的功能丰富的系统。
所有这些系统在提供键/值存储时都具有大致相同的语义：读取具有强烈的一致性，为了在网络分区的情况下保持一致性，牺牲了可用性。 但是，当这些系统用于高级案例时，这些差异会变得更加明显。
这些系统提供的语义对于构建服务发现系统是有吸引力的，但重要的是要强调必须构建这些功能。 ZooKeeper等软件仅提供原始K / V存储，并要求应用程序开发人员构建自己的系统以提供服务发现。 相比之下，Consul为服务发现提供了一个可用的框架，并且消除了猜测工作和开发工作。 客户端只需注册服务，然后使用DNS或HTTP接口执行发现。 其他系统需要一个自己定制的解决方案。
一个引人注目的服务发现框架必须包含健康检查和失败的可能性。 知道如果节点A失败或服务崩溃，则节点A提供Foo服务是没有用的。 原生系统使用心跳检测，定期更新和TTL。 这些方案需要与节点数量成线性关系，并将需求放在固定数量的服务器上。 此外，故障检测窗口至少与TTL一样长。
ZooKeeper提供临时节点，这些节点是客户端断开连接时删除的K / V条目。 这些比心跳系统更复杂，但仍然存在固有的可扩展性问题，并增加了客户端的复杂性。 所有客户端必须保持与ZooKeeper服务器的活动连接并执行保持活动。 另外，这需要“厚厚的客户端”，这些客户端很难编写，经常导致调试难题。
Consul 使用非常不同的体系结构进行健康检查。 Consul客户端不是只有服务器节点，而是在集群中的每个节点上运行。 这些客户端是gossip pool的一部分，可以提供多种态租配功能，包括分布式健康检帆指查。 gossip协议实现了一个高效的故障检测器，可以扩展到任何规模的集群，而不用将任务集中在任何选定的服务器组上。 客户端还可以在本地运行更丰富的运行状况检查，而ZooKeeper临时节点对活跃性进行非常原始的检查。 通过Consul，客户端可以检查Web服务器是否返回200的状态码，内存使用情况，有足够的磁盘空间等。和ZooKeeper一样，Consul客户端公开一个简单的HTTP接口，避免将系统的复杂性暴露给客户端。
Consul为服务发现，运行状况检查，K / V存储和多个数据中心提供一流的支持。 为了支持比简单K / V存储更多的功能，所有这些其他系统都需要额外的工具和库。 通过使用客户端节点，Consul提供了一个简单的API，只需要瘦客户端。 另外，完全可以通过使用配置文件和DNS接口完全避免使用API，以获得完整的服务发现解决方案，而完全没有任何开发。
使用Chef，Puppet和其他配置管理工具的人来构建服务发现机制并不罕见。 这通常通过查询全局状态来在定期收敛运行期间在每个节点上构建配置文件来完成。
不幸的是，这种方法有一些陷阱。 配置信息是静态的，不能比收敛运行更频繁地更新。 一般这是在几分钟或几小时的间隔。 另外，没有机制将系统状态结合到配置中：不健康的节点可能进一步接收流量，进一步加剧问题。 使用这种方法还可以支持多个数据中心，因为中央服务器组必须管理所有数据中心。
Consul专门设计为服务发现工具。 因此，它对集群的状态更具有动态性和响应性。 节点可以注册和注销他们提供的服务，使得依赖的应用程序和服务能够快速发现所有提供者。 通过使用集成的健康检查，Consul可以将流量从不健康的节点发送出去，从而使系统和服务能够正常恢复。 可以通过配置管理工具提供的静态配置可以移动到动态键/值存储中。 这允许应用程序配置更新，而不会收敛缓慢。 最后，由于每个数据中心独立运行，支持多个数据中心与单个数据中心没有区别。
也就是说，Consul并不是配置管理工具的替代品。 这些工具对于设置应用程序（包括Consul本身）至关重要。 静态配置最好由现有工具管理，而动态状态和发现则由Consul更好地管理。 配置管理和集群管理的分离也有一些有利的副作用：Chef和Puppet在没有全局状态的情况下变得更简单，服务或配置更改不再需要定期运行，并且由于配置管理运行 不需要全局状态。
Nagios和Sensu都是用于监控的工具。 当问题发生时，它们用于快速通知 *** 作员。
Nagios使用一组配置为在远程主机上执行检查的中央服务器。 这种设计使Nagios难以规模化，因为大型船队迅速达到垂直尺度的限制，Nagios不容易水平缩放。 Nagios在现代DevOps和配置管理工具中也非常难以使用，因为在添加或删除远程服务器时必须更新本地配置。
Sensu有一个更现代化的设计，依靠当地的代理商运行支票，并推动结果AMQP经纪人。 许多服务器从代理获取并处理健康检查的结果。 这个模型比Nagios更具可扩展性，因为它允许更多的水平缩放和服务器和代理之间的较弱耦合。 但是，中央经纪人已经具有扩展限制，并且是系统中的单一故障点。
Consul提供与Nagios和Sensu相同的健康检查能力，对现代DevOps友好，并避免了其他系统固有的扩展问题。 Consul在本地运行所有检查，如Sensu，避免给中央服务器造成负担。 检查状态由Consul服务器维护，这是容错的，没有单点故障。 最后，Consul可以扩展到更多的检查，因为它依赖于边缘触发的更新。 这意味着更新仅在检查从“通过”转换为“失败”或反之亦然时才被触发。
在一个大型的船队里，大部分的支票都是通过的，连失败的少数人都是执着的。 通过仅捕获更改，Consul减少了运行状况检查所使用的网络和计算资源的数量，从而使系统具有更高的可扩展性。
一个精明的读者可能会注意到，如果一个Consul代理死亡，那么没有边缘触发更新将会发生。 从其他节点的角度来看，所有的检查都会显示为稳定状态。 不过，Consul也是这样的。 客户端和服务器之间使用的gossip协议集成了一个分布式故障检测器。 这意味着如果一个Consul代理失败，将会检测到失败，并且因此所有由该节点运行的检查都可以被假定为失败。 这个故障检测器将工作分配到整个集群中，而最重要的是使边缘触发结构能够工作。
Eureka是一个服务发现工具。 该体系结构主要是客户机/服务器，每个数据中心有一套Eureka服务器，通常每个可用性区域一个。 通常Eureka的客户端使用嵌入式SDK来注册和发现服务。 对于不是本地集成的客户端，使用Ribbon等来透明地发现通过Eureka的服务。
Eureka提供了一个弱一致的服务观点，使用尽力而为复制。 当客户端向服务器注册时，该服务器将尝试复制到其他服务器，但不提供保证。 服务注册有一个短的生存时间（TTL），要求客户端向服务器发送心跳。 不健康的服务或节点将停止心跳，使他们超时并从注册表中删除。 发现请求可以路由到任何服务，由于尽力而为的复制，服务可能会陈旧或丢失数据。 这个简化的模型允许简单的集群管理和高可扩展性。
Consul提供了一套超级功能，包括更丰富的健康检查，key/value存储以及多数据中心意识。 Consul在每个数据中心都需要一组服务器，每个客户端都有一个代理，类似于使用像Ribbon这样的。 Consul代理允许大多数应用程序成为Consul不知道的，通过配置文件执行服务注册，并通过DNS或负载平衡器sidecars发现。
Consul提供强大的一致性保证，因为服务器使用Raft协议复制状态。 Consul支持丰富的健康检查，包括TCP，HTTP，Nagios / Sensu兼容脚本或基于Eureka的TTL。 客户端节点参与基于gossip的健康检查，该检查分配健康检查的工作，而不像集中式心跳一样成为可扩展性挑战。 发现请求被路由到当选的Consul leader，这使得他们在默认情况下是非常一致的。 允许陈旧读取的客户端使得任何服务器能够处理他们的请求，从而允许像Eureka这样的线性可伸缩性。
Consul强烈的一致性意味着它可以作为领导选举和集群协调的锁定服务。 Eureka不提供类似的保证，并且通常需要运行ZooKeeper来获得需要执行协调或具有更强一致性需求的服务。
Consul提供了支持面向服务的体系结构所需的工具包。 这包括服务发现，还包括丰富的健康检查，锁定，key/value，多数据中心联合，事件系统和ACL。 Consul和consul-template和envconsul等工具的生态系统都尽量减少集成所需的应用程序更改，以避免需要通过SDK进行本地集成。 Eureka是一个更大的Netflix OSS套件的一部分，该套件预计应用程序相对均匀且紧密集成。 因此，Eureka只解决了一小部分问题，希望ZooKeeper等其他工具可以一起使用。
consul是google开源的一个使用go语言开发的服务发现、配置管理中心服务。内置了服务注册与发现闷宽框架（类似zookeeper）、分布一致性协议实现、健康检查、Key/Value存储、多数据中心方案。服务部署简单，只有一个可运行的二进制的包。每个节点都需要运行agent，他有两种运行模式server和client。每个节点为以下三种状态的一种：
上图蚂咐亮来源于 Consul 官网，很好的解释了 Consul 的工作原理。consul是一个服务管理软件，主要功能如下：
有些人可能对服务注册和发现还没有概念，有些人可能使用过其他服务发现的工具，比如 ZooKeeper，etcd，会有一些先入为主的经验。本文谈一下 Consul 做服务发现的实践和原理。
下面这张图描述了服务发现的完整流程，先大致看一下：
首先需要有一个正常的 Consul 集群，有 Server，有 Leader。这里在服务器 Server1、Server2、Server3 上分别部署了 Consul Server。
假设他们选举了 Server2 上的 Consul Server 节点为 Leader。这些服务器上最好只部署 Consul 程序，以尽量维护 Consul Server 的稳定。
然后在服务器 Server4 和 Server5 上通过 Consul Client 分别注册 Service A、B、C，这里每个 Service 分别部署在了两个服务器上，这样可以避免 Service 的单点问题。
服务注册到 Consul 可以通过 HTTP API（8500 端口）的方式，也可以通过 Consul 配置文件的方式。
Consul Client 可以认为是无状态的，它将注册信息通过 RPC 转发到 Consul Server，服务信息保存在 Server 的各个节点中，并且通过 Raft 实现了强一致性。
最后在服务器 Server6 中 Program D 需要访问 Service B，这时候 Program D 首先访问本机 Consul Client 提供的 HTTP API，本机 Client 会将请求转发到 Consul Server。
Consul Server 查询到 Service B 当前的信息返回，最终 Program D 拿到了 Service B 的所有部署的 IP 和端口，然后就可以选择 Service B 的其中一个部署并向其发起请求了。
如果服务发现采用的是 DNS 方式，则 Program D 中直接使用 Service B 的服务发现域名，域名解析请求首先到达本机 DNS 代理，然后转发到本机 Consul Client，本机 Client 会将请求转发到 Consul Server。
Consul Server 查询到 Service B 当前的信息返回，最终 Program D 拿到了 Service B 的某个部署的 IP 和端口。
图中描述的部署架构笔者认为是最普适最简单的方案，从某些默认配置或设计上看也是官方希望使用者采用的方案，比简隐如 8500 端口默认监听 127.0.0.1，当然有些同学不赞同，后边会提到其他方案。
consul必须启动agent才能使用，有两种启动模式server和client，还有一个官方自带的web ui。server用与持久化服务信息，集群官方建议3或5个节点。client只用与于server交互。ui可以查看集群情况的。
server模式启动如下：
参数解释：
client启动如下：
client节点可以有多个，自己根据服务指定即可。
ui启动如下:
参数解释：
集群创建完成后：
使用一些常用的命令检查集群的状态：
可以在raft：stat看到此节点的状态是Fllower或者leader
新加入一个节点有几种方式；
访问ui：
http://192.168.1.198:8500/ui
端口：
8300：consul agent服务relplaction、rpc（client-server）
8301：lan gossip
8302：wan gossip
8500：http api端口
8600：DNS服务端口
输入 consul agent -dev
在浏览器中输入 www.localhost:8500 就可以启动web查看
consul注册服务，有三种方式，
方式一：通过配置文件的方式静态注册
创建文件夹/etc/consul.d
.d代表有许多配置文件在里面
vim /etc/consul.d/jetty.json 内容如下：
重启consul，并将配置文件的路径给consul（指定参数：-config-dir /etc/consul.d）
方式二：通过HTTP API接口来动态注册
直接调用/v1/agent/service/register接口注册即可，需要注意的是：http method为PUT提交方式。如：
注意，这种方式，和上面的注册方式有一点不一样，body的参数，是上面service的值，这点需要注意
方式三：使用程序实现服务的注册和发现（Java）
首先加入consul client的依赖
服务发现
consul支持两种方式实现服务发现，一种是通过http API来查询有哪些服务，另外一种是通过consul agent 自带的DNS（8600端口），域名是以NAME.service.consul的形式给出，NAME即在定义的服务配置文件中，服务的名称。DNS方式可以通过check的方式检查服务。
服务间的通信协议
Consul使用gossip协议管理成员关系、广播消息到整个集群，他有两个gossip pool（LAN pool和WAN pool），LAN pool是同一个数据中心内部通信的，WAN pool是多个数据中心通信的，LAN pool有多个，WAN pool只有一个。
https://www.toutiao.com/a6639493728086000142/?tt_from=weixin&utm_campaign=client_share&wxshare_count=1×tamp=1546144777&app=news_article&utm_source=weixin&iid=55667270026&utm_medium=toutiao_android&group_id=6639493728086000142
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）