consul入门基础-使用要点

Consul 是一个支持多数据中心分布式高可用的服务发现和配置共享的服务软件,由 HashiCorp 公司用 Go 语言开发, 基于 Mozilla Public License 2.0 的协议进行开源. Consul 支持健康检查,并允许 HTTP 和 DNS 协议调用 API 存储键值对. 一致性协议采用 Raft 算法,用来保证服务的高可用. 使用 GOSSIP 协议管理成员和广播消息, 并且支持 ACL 访问控制.

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基础架构 服务和健康检查涵盖的两个比较重要的概念： Agent(代理)和Catalog（服务目录）：

Agent（代理）：每个Consul代理（Agent） 都有自己的一套服务(services) 和 检查(checks) 的注册信息，以及健康状况(status)信息。代理负责执行健康检查以及更新本地状态。代理上下文中的服务和检查有丰富的配置选项可用。 这是因为代理负责通过使用运行状况检查生成有关其服务及其运行状况的信息。

Catalog（目录）：Consul的服务发现是由服务目录(Catalog)支持的。此目录是通过聚合代理(Agent)提交的信息而形成的。目录维护集群的高级视图，包括哪些服务可用、哪些节点运行这些服务、运行状况信息等等。目录用来暴露这些信息， 通过consul提供的各种接口（包括DNS和HTTP）。与代理相比，目录上下文中的服务和检查的字段集要有限得多。这是因为目录只负责记录和返回有关服务、节点和运行状况的信息.

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。

Agent会自动将查询转发给Server Agent。 每个数据中心都运行一个Consul Server集群。当有跨数据中心的服务发现或配置请求时，本地Consul Server将请求转发到远程数据中心并返回结果。

Client节点通过一个轻量级的进程，负责服务注册、健康检查，将请求转发给Server节点等。 Client节点数量不限。

每个数据中心的Consul集群都会在运行于server模式下的agent节点中选出一个Leader节点，这个选举过程通过Consul实现的raft协议保证，多个 server节点上的Consul数据信息是强一致的。

Consul部署架构 

只使用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负责。

多数据中心部署架构图 多数据中心部署架构仅供理解整个架构，一般场景暂时不会用到。

网络通信 多中心 

 网络交互 节点分类 1、Consul 分为 Client 和 Server 两种节点(所有的节点也被称为Agent)； 2、其中Server 节点存储和处理请求，同时将数据同步至其他 Server 节点； 3、Client 转发服务注册、服务发现请求到 Server 节点，同时还负责服务的健康检查； 4、所有的 Server 节点组成了一个集群，他们之间运行 Raft 协议，通过共识仲裁选举出 Leader。所有的业务数据都通过 Leader 写入到集群中做持久化，当有半数以上的节点存储了该数据后，Server集群才会返回ACK，从而保障了数据的强一致性。所有的 Follower 会跟随 Leader 的脚步，保证其有最新的数据副本

数据中心内部通信 1.Consul 数据中心内部的所有节点通过 Gossip 协议（8301端口）维护成员关系，这也被叫做LAN GOSSIP。当数据中心内部发生拓扑变化时，存活的节点们能够及时感知，比如Server节点down掉后，Client 就会将对应Server节点从可用列表中剥离出去。 2.集群内数据的读写请求既可以直接发到Server，也可以通过 Client 转发到Server，请求最终会到达 Leader 节点。 3.在允许数据轻微陈旧的情况下，读请求也可以在普通的Server节点完成，集群内数据的读写和复制都是通过8300端口完成。

跨数据中心通信 1.Consul支持多数据中心，上图中有两个 DataCenter，他们通过网络互联，注意为了提高通信效率， 只有Server节点才加入跨数据中心的通信。 2.跨数据中心的 Gossip 协议使用8302端口，也被称为WAN GOSSIP，是全局范围内唯一的。 3.通常情况下，不同的Consul数据中心之间不会复制数据。当请求另一个数据中心的资源时，Server 会将其转发到目标数据中心的随机 Server 节点，该节点随后可以转发给本地 Leader 处理。

各个端口说明 端口 用途 8300 RPC 调用 8301 数据中心内部 GOSSIP 协议使用 8302 跨数据中心 GOSSIP 协议使用 8500 HTTP API 和 Web 接口使用 8600 用于 DNS 服务端

服务注册与发现