consul 简介
做服务发现的框架常用的有
zookeeper
eureka
etcd
consul
consul是分布式的、高可用、横向扩展的。consul提供的一些关键特性：
service discovery：consul通过DNS或者HTTP接口使服务注册和服务发现变的很容易，一些外部服务，例如saas提供的也可以一样注册。
health checking：健康检测使consul可以快速的告警在集群中的操作。和服务发现的集成，可以防止服务转发到故障的服务上面。
key/value storage：一个用来存储动态配置的系统。提供简单的HTTP接口，可以在任何地方操作。
multi-datacenter：无需复杂的配置，即可支持任意数量的区域。
架构图及解析
让我们把这幅图分解描述。首先，我们可以看到有两个数据中心，分别标记为“1”和“2”。Consul拥有对多个数据中心的一流支持，这是比较常见的情况。
在每个数据中心中，我们都有客户机和服务器。预计将有三到五台服务器。这在故障情况下的可用性和性能之间取得了平衡，因为随着添加更多的机器，一致性会逐渐变慢。但是，客户端的数量没有限制，可以很容易地扩展到数千或数万。
Consul 实现多个数据中心都依赖于gossip protocol协议。这样做有几个目的:首先，不需要使用服务器的地址来配置客户端;服务发现是自动完成的。其次，健康检查故障的工作不是放在服务器上，而是分布式的。这使得故障检测比单纯的心跳模式更具可伸缩性。为节点提供故障检测;如果无法访问代理，则节点可能经历了故障。
每个数据中心中的服务器都是一个筏对等集的一部分。这意味着它们一起工作来选举单个leader，一个被选中的服务器有额外的职责。领导负责处理所有的查询和事务。事务还必须作为协商一致协议的一部分复制到所有对等方。由于这个需求，当非leader服务器接收到RPC请求时，它会将其转发给集群leader。
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服务。
docker安装
第一个server启动
docker run -d --name=consul-server1 --net=host -e CONSUL_BIND_INTERFACE=ens33 -v /consul/config:/consul/config -v /consul/data:/consul/data consul:latest agent -server -node=agent128 -bootstrap-expect=3 -client=0.0.0.0 -ui
剩下两个Server启动并加入集群
docker run -d --name=consul-server2 --net=host -e CONSUL_BIND_INTERFACE=ens33 consul agent -server -node=agent129 -client=0.0.0.0 -join 192.168.30.128
docker run -d --name=consul-server3 --net=host -e CONSUL_BIND_INTERFACE=ens33 consul agent -server -node=agent130 -client=0.0.0.0 -join 192.168.30.128
Client启动并加入集群
docker run -d --name=consul-client1 --net=host -e CONSUL_BIND_INTERFACE=ens33 consul agent -node=agent131 -client=0.0.0.0 -join 192.168.30.128
查看集群：
docker exec consul-server1 consul members Node Address Status Type Build Protocol DC Segment agent128 192.168.30.128:8301 alive server 1.8.3 2 dc1 <all> agent129 192.168.30.129:8301 alive server 1.8.3 2 dc1 <all> agent130 192.168.30.130:8301 alive server 1.8.3 2 dc1 <all> agent131 192.168.30.131:8301 alive client 1.8.3 2 dc1 <default>
访问ui：
访问192.168.30.128:8500/ui，
参考：https://www.imooc.com/article/296209/
https://www.imooc.com/article/284030/
https://blog.csdn.net/a312586670/article/details/105337943/
首先Consul支持多数据中心，在上图中有两个DataCenter，他们通过Internet互联，同时请注意为了提高通信效率，只有Server节点才加入跨数据中心的通信。
作者：KaliArch
链接：https://www.imooc.com/article/296209/
来源：慕课网
本文首次发布于慕课网 ，转载请注明出处，谢谢合作
首先Consul支持多数据中心，在上图中有两个DataCenter，他们通过Internet互联，同时请注意为了提高通信效率，只有Server节点才加入跨数据中心的通信。
在单个数据中心中，Consul分为Client和Server两种节点（所有的节点也被称为Agent），Server节点保存数据，Client负责健康检查及转发数据请求到Server；Server节点有一个Leader和多个Follower，Leader节点会将数据同步到Follower，Server的数量推荐是3个或者5个，在Leader挂掉的时候会启动选举机制产生一个新的Leader。
集群内的Consul节点通过gossip协议（流言协议）维护成员关系，也就是说某个节点了解集群内现在还有哪些节点，这些节点是Client还是Server。单个数据中心的流言协议同时使用TCP和UDP通信，并且都使用8301端口。跨数据中心的流言协议也同时使用TCP和UDP通信，端口使用8302。
集群内数据的读写请求既可以直接发到Server，也可以通过Client使用RPC转发到Server，请求最终会到达Leader节点，在允许数据轻微陈旧的情况下，读请求也可以在普通的Server节点完成，集群内数据的读写和复制都是通过TCP的8300端口完成。
作者：KaliArch
链接：https://www.imooc.com/article/296209/
来源：慕课网
本文首次发布于慕课网 ，转载请注明出处，谢谢合作
首先Consul支持多数据中心，在上图中有两个DataCenter，他们通过Internet互联，同时请注意为了提高通信效率，只有Server节点才加入跨数据中心的通信。
在单个数据中心中，Consul分为Client和Server两种节点（所有的节点也被称为Agent），Server节点保存数据，Client负责健康检查及转发数据请求到Server；Server节点有一个Leader和多个Follower，Leader节点会将数据同步到Follower，Server的数量推荐是3个或者5个，在Leader挂掉的时候会启动选举机制产生一个新的Leader。
集群内的Consul节点通过gossip协议（流言协议）维护成员关系，也就是说某个节点了解集群内现在还有哪些节点，这些节点是Client还是Server。单个数据中心的流言协议同时使用TCP和UDP通信，并且都使用8301端口。跨数据中心的流言协议也同时使用TCP和UDP通信，端口使用8302。
集群内数据的读写请求既可以直接发到Server，也可以通过Client使用RPC转发到Server，请求最终会到达Leader节点，在允许数据轻微陈旧的情况下，读请求也可以在普通的Server节点完成，集群内数据的读写和复制都是通过TCP的8300端口完成。
Consul 集群间使用了 Gossip 协议通信和 raft 一致性算法
Gossip —— Gossip protocol 也叫 Epidemic Protocol （流行病协议），实际上它还有很多别名，比如：“流言算法”、“疫情传播算法”等。 这个协议的作用就像其名字表示的意思一样，非常容易理解，它的方式其实在我们日常生活中也很常见，比如电脑病毒的传播，森林大火，细胞扩散等等。
Client —— 一个 Client 是一个转发所有 RPC 到 server 的代理。这个 client 是相对无状态的。client 唯一执行的后台活动是加入 LAN gossip 池。这有一个最低的资源开销并且仅消耗少量的网络带宽。
Server —— 一个 server 是一个有一组扩展功能的代理，这些功能包括参与 Raft 选举，维护集群状态，响应 RPC 查询，与其他数据中心交互 WAN gossip 和转发查询给 leader 或者远程数据中心。
DataCenter —— 虽然数据中心的定义是显而易见的，但是有一些细微的细节必须考虑。例如，在 EC2 中，多个可用区域被认为组成一个数据中心。我们定义数据中心为一个私有的，低延迟和高带宽的一个网络环境。这不包括访问公共网络，但是对于我们而言，同一个 EC2 中的多个可用区域可以被认为是一个数据中心的一部分。
Consensus —— 一致性，使用 Consensus 来表明就 leader 选举和事务的顺序达成一致。为了以容错方式达成一致，一般有超过半数一致则可以认为整体一致。Consul 使用 Raft 实现一致性，进行 leader 选举，在 consul 中的使用 bootstrap 时，可以进行自选，其他 server 加入进来后 bootstrap 就可以取消。
LAN Gossip —— 它包含所有位于同一个局域网或者数据中心的所有节点。
WAN Gossip —— 它只包含 Server。这些 server 主要分布在不同的数据中心并且通常通过因特网或者广域网通信。
RPC——远程过程调用。这是一个允许 client 请求 server 的请求/响应机制。
1.3.2 Consul服务发现原理
1.3.2.1 原理图
作者：KaliArch
链接：https://www.imooc.com/article/296209/
来源：慕课网
本文首次发布于慕课网 ，转载请注明出处，谢谢合作
架构图及解析
作者：KaliArch
链接：https://www.imooc.com/article/296209/
来源：慕课网
本文首次发布于慕课网 ，转载请注明出处，谢谢合作
架构图及解析
作者：KaliArch
链接：https://www.imooc.com/article/296209/
来源：慕课网
本文首次发布于慕课网 ，转载请注明出处，谢谢合作
