服务注册与发现 - Consul - 基础
一、简介
Consul是HashiCorp公司推出的开源工具，用于实现分布式下的服务发现与配置，
与其他分布式服务发现方案相比，Consul内置了服务注册与发现框架、分布式一致性协议实现、健康检查、Key/Value Store存储，多数据中心方案、
不再续约依赖于其他工具（比如Zookeeper），使用起来也较为简单，
Consul使用Go语言编写，支持(Linux/Ubuntu/MacOS/Windows)，安装包仅包含一个文件，方便与Docker无缝集成。
二、consule 核心 agent组件
Agent是一个独立的程序，通过守护进程的方式，运行在consul集群中的每个节点上。
每个Consul agent维护它自己的服务集合以及检查注册和健康信息。
agent负责执行自己的健康检查和更新本地状态 其中，Agent 根据节点的性质，分为： Agent Server 和 Agent Client
- Agent Client
client将 HTTP 和 DNS 接口请求转发给局域网内的服务端集群。
- Agent Server
server 保存client的注册信息，集群的配置信息, 维护集群高可用, 在局域网内与本地客户端通讯, 通过广域网与其它数据中心通讯。
每个数据中心的 server 数量推荐为 3 个或是 5 个,通过 Raft 算法来保证一致性。
三、agent 模式
- CLIENT表示consul的client模式，就是客户端模式。
是consul节点的一种模式，这种模式下，所有注册到当前节点的服务会被转发到SERVER，本身是不持久化这些信息。
简单的说，client 处理健康检查，注册服务等，但是这个注册只是转发到server中，如果有成千上万的服务，分别启动多个client,可以减少server 压力。
- SERVER表示consul的server模式，表明这个consul是个server。
这种模式下，功能和CLIENT都一样，唯一不同的是，它会把所有的信息持久化的本地，这样遇到故障，信息是可以被保留的。
SERVER-LEADER 和其它 SERVER-FOLLOWER 不一样的一点是，它需要负责同步注册的信息给其它的SERVER，同时也要负责各个节点的健康监测。
四、consul 通信接口
- RPC
用于内部通讯Gossip/日志分发/选主等
- HTTP API
服务发现/健康检查/KV存储等几乎所有功能, 默认端口为8500
- Consul Commands (CLI)
consul命令行工具可以与consul agent进行连接，提供部分consul的功能。
实际上Consul CLI 默认就是调用的HTTP API来与consul集群进行通讯。
- DNS
仅用于服务查询
例如: dig @127.0.0.1 -p 8600 web.service.consul
我们可以通过cosul提供的DNS接口来获取当前的服务“web”对应的可用节点。
五、consul 内部端口使用汇总
六、consul 请求调用链路
七、consul 去中心化思想实现
consul 使用了基于gossip协议的Serf实现，Serf是一个服务发现，编配工具，它去中心化，不像集中式结构那样统一分配管理；
Serf提供成员关系，纠错检查，广播等功能。gossip协议主要是基于UDP，实现任意node-to-node间的通信。Consul正是使用serf 提供的gossip协议来管理成员和广播消息到集群。
gossip 协议（gossip protocol）是基于流行病传播方式的节点或者进程之间信息交换的协议，来确保网络中所有节点的数据一样。其中节点间的交互方式主要以下有三种：
Push：发起信息的节点 A 随机选择联系节点 B，并向B发送自己的信息，节点 B 在收到信息后，更新比自己新的数据，一般拥有新信息的节点才会作为发起节点。
Pull：发起信息的节点 A 随机选择联系节点 B，并从对方获取信息。一般无新信息的节点才会作为发起节点。
Push&Pull：发起信息的节点 A 向选择的节点 B 发送信息，同时从对方获取数据，用于更新自己的本地数据。
八、consul内部原理
1、服务器 Server1、Server2、Server3 上分别部署了 Consul Server, 组成了Consule集群，通过raft选举算法, server2成为leader节点。
2、服务器 Server4 和 Server5 上通过 Consul Client 分别注册 Service A、B、C，（服务A，B，C注册到 Consul 可以通过 HTTP API（8500 端口）的方式，
也可以通过 Consul 配置文件的方式。）
3、Consul Client将注册信息通过 RPC 转发到 Consul Server，服务信息保存在 Server 的各个节点中，并且通过 Raft 实现了强一致性。
4、服务器 Server6 中 Program D 要访问 Service B，此时 Program D 先访问本机 Consul Client 提供的 HTTP API，Consul Client 会将请求转发到 Consul Server。
Consul Server 查询到 Service B 并返回，最终 Program D 拿到了 Service B 的所有部署的 IP 和端口，根据负载均衡策略，选择Service B 的其中一个并向其发起请求。
如果服务发现采用的是 DNS 方式，则 Program D 中使用 Service B 的服务发现域名，域名解析请求首先到达本机 DNS 代理，
然后转发到本机 Consul Client，consul Client 会将请求转发到 Consul Server。随后的流程和上述一直。
九、其他
WAN：Wide Area Network，广域网。
LAN：Local Area Network，局域网。
参考资料