2-Consul简介
Consul 是什么
Consul 是一个支持多数据中心分布式高可用的服务发现和配置共享的服务软件,由 HashiCorp 公司用 Go 语言开发, 基于 Mozilla Public License 2.0 的协议进行开源. Consul 支持健康检查,并允许 HTTP 和 DNS 协议调用 API 存储键值对.
命令行超级好用的虚拟机管理软件 vgrant 也是 HashiCorp 公司开发的产品.
一致性协议采用 Raft 算法,用来保证服务的高可用. 使用 GOSSIP 协议管理成员和广播消息, 并且支持 ACL 访问控制.
Consul 的使用场景
- docker 实例的注册与配置共享
- coreos 实例的注册与配置共享
- vitess 集群
- SaaS 应用的配置共享
- 与 confd 服务集成，动态生成 nginx 和 haproxy 配置文件
Consul 的优势
- 使用 Raft 算法来保证一致性, 比复杂的 Paxos 算法更直接. 相比较而言, zookeeper 采用的是 Paxos, 而 etcd 使用的则是 Raft.
- 支持多数据中心，内外网的服务采用不同的端口进行监听。 多数据中心集群可以避免单数据中心的单点故障,而其部署则需要考虑网络延迟, 分片等情况等. zookeeper 和 etcd 均不提供多数据中心功能的支持.
- 支持健康检查. etcd 不提供此功能.
- 支持 http 和 dns 协议接口. zookeeper 的集成较为复杂, etcd 只支持 http 协议.
- 官方提供web管理界面, etcd 无此功能.
综合比较, Consul 作为服务注册和配置管理的新星, 比较值得关注和研究.
Consul 的角色
client: 客户端, 无状态, 将 HTTP 和 DNS 接口请求转发给局域网内的服务端集群.
server: 服务端, 保存配置信息, 高可用集群, 在局域网内与本地客户端通讯, 通过广域网与其他数据中心通讯. 每个数据中心的 server 数量推荐为 3 个或是 5 个.
什么是服务发现
相关源码： spring cloud demo
微服务的框架体系中，服务发现是不能不提的一个模块。我相信了解或者熟悉微服务的童鞋应该都知道它的重要性。这里我只是简单的提一下，毕竟这不是我们的重点。我们看下面的一幅图片：
图中，客户端的一个接口，需要调用服务A-N。客户端必须要知道所有服务的网络位置的，以往的做法是配置是配置文件中，或者有些配置在数据库中。这里就带出几个问题：
需要配置N个服务的网络位置，加大配置的复杂性
服务的网络位置变化，都需要改变每个调用者的配置
集群的情况下，难以做负载（反向代理的方式除外）
总结起来一句话：服务多了，配置很麻烦，问题多多
既然有这些问题，那么服务发现就是解决这些问题的。话说，怎么解决呢？我们再看一张图
与之前一张不同的是，加了个服务发现模块。图比较简单，这边文字描述下。服务A-N把当前自己的网络位置注册到服务发现模块（这里注册的意思就是告诉），服务发现就以K-V的方式记录下，K一般是服务名，V就是IP:PORT。服务发现模块定时的轮询查看这些服务能不能访问的了（这就是健康检查）。客户端在调用服务A-N的时候，就跑去服务发现模块问下它们的网络位置，然后再调用它们的服务。这样的方式是不是就可以解决上面的问题了呢？客户端完全不需要记录这些服务网络位置，客户端和服务端完全解耦！
这个过程大体是这样，当然服务发现模块没这么简单。里面包含的东西还很多。这样表述只是方便理解。
图中的服务发现模块基本上就是微服务架构中服务发现的作用了。
consul 简介
做服务发现的框架常用的有
zookeeper
eureka
etcd
consul
这里就不比较哪个好哪个差了，需要的童鞋自己谷歌百度。
那么consul是啥？consul就是提供服务发现的工具。然后下面是简单的介绍：
consul是分布式的、高可用、横向扩展的。consul提供的一些关键特性：
service discovery：consul通过DNS或者HTTP接口使服务注册和服务发现变的很容易，一些外部服务，例如saas提供的也可以一样注册。
health checking：健康检测使consul可以快速的告警在集群中的操作。和服务发现的集成，可以防止服务转发到故障的服务上面。
key/value storage：一个用来存储动态配置的系统。提供简单的HTTP接口，可以在任何地方操作。
multi-datacenter：无需复杂的配置，即可支持任意数量的区域。
我们这里会介绍服务发现，健康检查，还有一些基本KV存储。多数据中心有机会另一篇文章再说。
总结：只要知道它是解决我上一部分提出的问题就行，其它的东西慢慢理解
consul的几个概念
每个数据中心可以视为一个地区（北上广），每个数据中心内存在一个LAN Gossip池，它包含数据中心的所有成员——client和server。
LAN池用于以下几个目的：
1、 成员关系运行，client自动发现server，减少配置量
2、 分布式的故障检测，允许故障检测的工作由整个集群承担，而不是集中在少数server上
3、 Gossip池允许可靠和快速的事件广播，比如leader选举。
多个数据中心根据consul keygen构成一个集群，一个集群存在唯一一个WAN Gossip池，所有的server都（应）加入 WAN Gossip池，不论是哪个数据中心的。WAN池提供的成员关系，允许server执行跨数据中心请求。
上图是我从consul官方文档抠出来的。
我们只看数据中心1，可以看出consul的集群是由N个SERVER，加上M个CLIENT组成的。而不管是SERVER还是CLIENT，都是consul的一个节点，所有的服务都可以注册到这些节点上，正是通过这些节点实现服务注册信息的共享。除了这两个，还有一些小细节，一一简单介绍。
CLIENT
CLIENT表示consul的client模式，就是客户端模式。是consul节点的一种模式，这种模式下，所有注册到当前节点的服务会被转发到SERVER，本身是不持久化这些信息。
SERVER
SERVER表示consul的server模式，表明这个consul是个server，这种模式下，功能和CLIENT都一样，唯一不同的是，它会把所有的信息持久化的本地，这样遇到故障，信息是可以被保留的。
SERVER-LEADER
中间那个SERVER下面有LEADER的字眼，表明这个SERVER是它们的老大，它和其它SERVER不一样的一点是，它需要负责同步注册的信息给其它的SERVER，同时也要负责各个节点的健康监测。
raft: Server 节点之间的数据一致性保证协议使用的是 raft，而 zookeeper 用的 paxos，etcd采用的也是raft
服务发现协议: Consul 采用 http 和 DNS 协议，etcd 只支持 http 。
服务注册: Consul 支持两种方式实现服务注册，一种是通过 Consul 的服务注册 Http API，由服务自己调用 API 实现注册，另一种方式是通过json 格式的配置文件实现注册，将需要注册的服务以 json 格式的配置文件给出。Consul 官方建议使用第二种方式。
其它信息
其它信息包括它们之间的通信方式，还有一些协议信息，算法。它们是用于保证节点之间的数据同步，实时性要求等等一系列集群问题的解决。这些有兴趣的自己看看官方文档。
consul 基本使用
Consul集群Server+Client模式
Consul 作为一种分布式服务工具，为了避免单点故障常常以集群的方式进行部署，在 Consul 集群的节点中分为 Server 和 Client 两种节点（所有的节点也被称为Agent），Server 节点保存数据，Client 节点负责健康检查及转发数据请求到 Server；Server 节点有一个 Leader 节点和多个 Follower 节点，Leader 节点会将数据同步到 Follower 节点，在 Leader 节点挂掉的时候会启动选举机制产生一个新的 Leader。
Client 节点很轻量且无状态，它以 RPC 的方式向 Server 节点做读写请求的转发，此外也可以直接向 Server 节点发送读写请求。
架构示意图
只使用Consul的Server模式有以下2个问题：
- 因为Consul Server数量受到控制所以压力承载（扩展性）是个问题。
- Server很少导致一个Server下会注册很多微服务，当Server挂掉，这个Server节点下注册的微服务都会视为无效。
基于上述问题我们在架构中加入Consul Client模式，Client因为加入了LAN gossip协议组成网络中（高速局域网），可以识别故障的Server节点并找到可用的Server节点继续工作，其实Server模式负责的是用WAN gossip协议组成的网络进行跨广域网的数据同步（多个数据中心），这点Client模式是做不到的，Client模式也提供服务的注册和查询，但Client模式不存储节点数据，Client将请求转发给Server进行处理，节点注册数据在Server端是持久化保存的，Client的数量可以无限多，Server的数量是受控制的。总之：Client模式+LAN gossip协议组成了一个数据中心中的各个节点，Server负责投票选出Leader进行数据中心内的数据同步，这个Leader还负责利用WAN gossip协议跨广域网的与其他数据中心进行数据同步。
PS：在Client注册的服务心跳监控检查由Client负责。
