文章目录

  • 1. Consul 简介
  • 2. Consul 架构
  • 核心原理
  • 3. Consul 服务注册与服务发现


1. Consul 简介

Consul 是用于实现分布式系统的服务发现与配置的开源工具，本身也是分布式高可用的，其主要特性如下，读者如有兴趣可前往官方传送门

  1. 服务发现
    Consul 的 Client可以注册服务，其他 Client 可以通过 DNS 或者 HTTP 接口的方式来很方便地发现服务
  2. 健康检测
    Consul 的 Client 提供了健康检查的机制，这些信息可以用于检查集群的健康状态，或者被服务发现组件用来避免流量被转发到有故障的服务上
  3. Key/Value 存储
    应用程序可以根据自己的需要使用 Consul 提供的 Key/Value 存储， Consul 提供了简单易用的 HTTP 接口，结合其他工具可以实现动态配置、功能标记、领袖选举等功能
  4. 多数据中心
    Consul 支持开箱即用的多数据中心，这意味着用户不需要为了让业务扩展到多个区域而建立额外的抽象层

2. Consul 架构

consul架构 consul底层实现_服务发现


以上为 Consul 的架构图，需要注意的点如下：

  1. 节点分类 Consul 分为 Client 和 Server两种节点(所有的节点也被称为Agent)，其中Server 节点保存数据，Client 负责健康检查及转发数据请求到Server。所有的 Server 节点组成了一个集群，他们之间运行 Raft 协议，通过共识仲裁选举出 Leader。所有的业务数据都通过 Leader 写入到集群中做持久化，当有半数以上的节点存储了该数据后，Server集群才会返回ACK，从而保障了数据的强一致性。所有的 Follower 会跟随 Leader 的脚步，保证其有最新的数据副本
  2. 数据中心内部通信 Consul 数据中心内部的所有节点通过 Gossip 协议（8301端口）维护成员关系，这也被叫做LAN GOSSIP。当数据中心内部发生拓扑变化时，存活的节点们能够及时感知，比如Server节点down掉后，Client 就会将对应Server节点从可用列表中剥离出去。
    集群内数据的读写请求既可以直接发到Server，也可以通过 Client 转发到Server，请求最终会到达 Leader 节点。在允许数据轻微陈旧的情况下，读请求也可以在普通的Server节点完成，集群内数据的读写和复制都是通过8300端口完成
  3. 跨数据中心通信 Consul支持多数据中心，上图中有两个 DataCenter，他们通过网络互联，注意为了提高通信效率，只有Server节点才加入跨数据中心的通信。跨数据中心的 Gossip 协议使用8302端口，也被称为WAN GOSSIP，是全局范围内唯一的。
    通常情况下，不同的Consul数据中心之间不会复制数据。当请求另一个数据中心的资源时，Server 会将其转发到目标数据中心的随机Server 节点，该节点随后可以转发给本地 Leader 处理

端口

作用

8300

RPC 调用

8301

数据中心内部 GOSSIP 协议使用

8302

跨数据中心 GOSSIP 协议使用

8500

HTTP API 和 Web 接口使用

8600

用于 DNS 服务端

核心原理

consul 实现的核心在于两点：

  1. Gossip 协议
    集群内节点间信息通过 Gossip 协议高效同步，保障了拓扑变动以及控制信号的及时传递，这与 Redis 集群中的 Gossip协议 是一样的
  2. Raft 协议
    数据中心内 Server 节点间依赖 Raft 协议达成日志存储的强一致性

3. Consul 服务注册与服务发现

consul架构 consul底层实现_分布式_02

如上图是一个正常的 Consul 集群，在服务器 A、B、C上分别部署了Consul Server，并且选举了服务器 A上的 Consul Server 节点为 Leader，则服务注册与发现的步骤如下：

  1. 服务注册
    Service A、B 分别在 服务器D 和 服务器E 上通过Consul Client 注册，服务注册到 Consul 可以通过 HTTP API（8500端口）的方式，也可以通过Consul 配置文件的方式。Consul Client 将注册信息通过 RPC 转发到Consul Server，服务信息保存在 Server 的各个节点中，并通过 Raft 实现强一致性
  2. 服务发现
    服务器F 中 Service C 需要访问Service A，这时 Service C 首先访问本机Consul Client 提供的 HTTP API（如果服务发现采用的是DNS方式，则Service C 直接使用 Service A 的服务发现域名，域名解析请求首先到达本机DNS代理，然后转发到本机 Consul Client），Consul Client 会将请求转发到 Consul Server。Consul Server 查询到 Service A 当前的信息返回，最终 Service C 拿到了Service A 所有实例部署的IP和端口，之后就可以选择向 Service A的一个实例发起请求了