1. 概述

Consul 是 HashiCorp 公司基于 go 语言研发用于服务发现和配置共享开的分布式高可用的系统。提供内服务注册与发现框架，分布一致性协议实现，健康检查，Key/Value存储，多数据中心方案，以及 Web UI 支持。

2. 特性

• Consul 采用 Raft 一致性协议算法来保证服务的高可用，使用 GOSSIP 协议管理成员和广播消息，并且支持 ACL 访问控制。
• 服务注册与发现: Consul 同时支持 DNS 或者 HTTP 两种接口进行服务注册和服务发现。
• 支持健康检查: Consul 可以通过定期运行脚本进行健康检查，根据脚本的返回值判断机器或服务是否健康，返回值为0时才代表健康。用户可以自定义的任意shell/Python脚本进行服务(Redis/MySQL等)的健康检查，这点相比其他同类工具更灵活。值得注意的是consul中返回值0是没问题（passed），1是警告（warning），其他值是检查失败（critical）
• Key/Value 存储: 一个用来存储动态配置的系统。提供简单的 HTTP 接口，可以在任何地方操作。
• 支持多数据中心方案:支持多机房配置，可以避免单机房单点故障，多个数据中心要求每个数据中心都要安装一组 Consul cluster，多个数据中心间基于 gossip protocol 协议来通讯，使用Raft算法实现一致性。
• 简易安装部署:安装包仅包含一个二进制文件，支持跨平台(*Nix,WIN)运行。可与Docker 等轻量级容器实现无缝配合。
• 官方提供 web 管理界面, etcd 无此功能

3. 同类工具对比

4. 架构及原理

4.1 整体架构

Consul 分为 Client 和 Server 两种节点（所有的节点也被称为 Agent），Server 节点保存数据，Client 负责健康检查及转发数据请求到 Server。

Server 节点有一个 Leader 和多个 Follower，Leader 节点会将数据同步到 Follower，Server 的数量推荐是 3 个或者 5 个，在 Leader 挂掉的时候会启动选举机制产生一个新的 Leader。

集群内数据的读写请求既可以直接发到 Server，也可以通过 Client 使用 RPC 转发到 Server，请求最终会到达 Leader 节点。

4.2 服务注册

一种是通过 consul 的服务注册 http API，由服务自己调用 API 实现注册，另一种方式是通过json 个是的配置文件实现注册，将需要注册的服务以 json 格式的配置文件给出。consul官方建议使用第二种方式，因为配置文件的方便后续维护。

配置文件中会指定一个自定义的健康检查脚本，通过该脚本，用户可以灵活的判断当前服务是否可用。

4.3 服务查询

服务查询有两种方式，一种是 DNS 接口，一种是HTTP API。

4.3.1 DNS 接口

服务注册到 conusl 后都会有个域名，以 servie.consul 做为后缀，如NAME.service.consul，consul DNS 接口使用的是8600端口，通过查询域名，可以返回提供服务的 IP 和 端口。

4.3.2 HTTP API

curl http://localhost:8500/v1/catalog/service/xxx

4.4 服务发现流程

假设在两台机器上分别注册了服务A，服务B和服务C。现在服务D想要访问服务A，主要有两种方式：

1. 通过 HTTP 接口。服务B首先访问本机的 consul client 提供的HTTP API，本机client将请求转发到 consul server，server 查询到服务A的信息返回，最终服务D拿到了服务A的所有部署的IP和端口，然后就可以选择服务A的其中一个部署发起请求。
2. 通过 DNS 接口。服务D直接使用服务A的发现域名(该域名是服务A注册的)，域名解析请求首先到达本机DNS代理，然后转发的本机的consul client，client再转发给consul server，server 返回服务A的某个部署的IP和端口。

参考资料

https://learn.hashicorp.com/tutorials/consul/get-started