文章目录
一、概述
-
最实在去
官网
-
【路人甲】
- 实现分布式系统的服务发现与配置(Service Discovery And Configuration Make Easy)
- 微服务治理 的所有解决方案
- 本身也是分布式高可用的
Service Discovery:
当某个应用可用的时候，可以向 consul 客户端注册自己，或者让 consul 客户端通过配置发现自己，这样，
如果有需要这个应用的其他应用就可以通过 consul 快速找到一个可用的应用了。
Health Check:
consul 客户端提供任意数量的健康检查，包括对应用保持心跳、主机物理资源监控等。健康检查可以被
operator 检测并操作，防止流量进入不健康的主机。
KV Store:
应用按需使用 consul 的 KV存储 ，可以用于动态配置、功能标记、协调、领袖选举等，通过客户端的 HTTP 接口可以灵活方便使用。
Multi Datacenter:
consul 提供开箱即用的多数据中心，这意味着用户不需要担心需要建立额外的抽象层让业务扩展到多个区域。
二、架构
没有放官方的，借用
这位老兄的
讲解架构：
- 节点分类
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 服务端 |
三、核心原理
集群内节点间信息通过 Gossip 协议高效同步，保障了拓扑变动以及控制信号的及时传递，这与 Redis 集群中的 Gossip协议 是一样的
数据中心内
Server 节点
间依赖 Raft 协议达成
日志存储
的强一致性
Leader选举 —– 日志复制 —– 两个超时 —– 重新选举
四、服务注册和服务发现
五、源码分析