本文主要参考
整体架构
consul是一个用于微服务的服务注册与服务发现引擎，原生支持多数据中心的部署。
- CLIENT：用于处理服务注册、健康检查与服务发现（几乎一切业务逻辑）。
- SERVER：采用主从架构，使用半数复制来保证集群信息的持久化，存储一切服务信息。
* 可以将SERVER看作数据库，将CLIENT看作业务信息的校验与处理，并对SERVER进行读写。 * SERVER本身也包含CLIENT的功能。
服务注册
- SREVICE向指定的CLIENT发送注册请求
- CLIENT将信息持久化到本地
- 若指定了健康检查，则CLINET执行检查
- 若健康检查通过，CLINET将该服务注册到SERVER
- FOLOWER将请求转发到LEADER
- LEADER持久化到本地，并等待半数的SERVER复制成功
健康检查
- 方式：Script、HTTP、TCP、SSL
- CLIENT维护所有向其发送注册请求的服务的健康状态，一旦状态发生变化，就对SERVER进行更新
服务发现
- 向指定的CLIENT发送服务解析请求
- CLIENT向SERVER进行查询（由于是半数复制，可能出现滞后）
- SERVER返回结果
RAFT
- 各DATACENTER中的所有SERVICE使用RAFT协议进行日志同步与选举，信息同步
GOSSIP
- 同一个DATACENTER内的所有Agent使用LAN GOSSIP进行状态同步，如角色变动，节点宕机等
- 不同DATACENTER内的所有SERVER使用WAN GOSSIP进行状态同步，如角色变动，节点宕机等
思考
- 由于CLIENT维护所有向其发送注册请求的服务的健康状态，一旦该CLIENT挂掉，所有由它维护的SERVICE将没有健康检查，如何解决这个问题？
- 一个SERVICE向多个CLIENT注册，同时在服务发现的逻辑中进行去重：治标不治本
- 在SERVICE端对CLIENT与SERVICE进行关联，若发现CLIENT下线，则SERVER删除所有关联的SERVICE：对外保证了SERVICE的可用性，但原先SERVICE无人管理，浪费资源
- 在SERVICE端添加心跳机制，周期性向CLIENT发送探针，若CLIENT下线，重新发起服务注册：无法处理CLIENT到SERVICE之间的隔离情况，且很难保证SERVICE与指定CLIENT的网络连接（通常通过反代的形式维护CLIENT的高可用）
- SERVICE定期向指定CLIENT做服务发现，若失败（包括网络失败和可用服务不包含自己），则重新注册：无法处理CLIENT缓存，且很难保证SERVICE与指定CLIENT的网络连接
- SERVICE与CLIENT部署在同一个物理机中，CLIENT发生panic后立即重启，可通过持久化方式载入之前信息，或重新注册该机器上的服务，再在SERVICE上对CLIENT与SERVICE进行关联，即可解决。