基于Docker + Consul + Registrator的服务注册与发现集群搭建

关注

原创最新推荐文章于 2026-06-06 13:18:03 发布 785 阅读 AI 写同款· GEO 优化 ›

Docker consul容器服务自动发现和更新服务注册与发现是微服务架构中不可或缺的重要组件。起初服务都是单节点的，不保障高可用性，也不考虑服务的压力承载，服务之间调用单纯的通过接口访问。直到后来出现了多个节点的分布式架构，起初的解决手段是在服务前端负载均衡，这样前端必须要知道所有后端服务的网络位置，并配置在配置文件中。这里就会有几个问题如果需要调用后端服务A-N，就需要配置N个服务的网络位置，配置很麻烦。后端服务的网络位置变化，都需要改变每个调用者的配置。既然有这些问题，那么服务注册与发现就是解决这些问题的。阅读详情

前言

近年微服务架构在互联网应用领域中愈来愈火，引入微服务主要解决了单体应用多个模块的紧耦合、无法扩展和运维困难等问题。微服务架构就是按照功能粒度将业务模块进行垂直拆分，对单体应用本身进行服务化和组件化，每个组件单独部署为小应用（从DB到UI）。微服务与微服务之间通过Service API进行交互，同时为了支持水平扩展、性能提升和服务可用性，单个服务允许同时部署一个或者多个服务实例。在运行时，每个实例通常是一个云虚拟机或者Docker容器。

微服务系统内部多个服务的实例之间如何通信？如何感知到彼此的存在和销毁？生产者服务如何知道消费者服务的地址？如何实现服务与注册中心的解耦？这就需要一个第三方的服务注册中心，提供对生产者服务节点的注册管理和消费者服务节点的发现管理。

正文

1. 服务发现与注册

1.1. 具体流程

服务注册中心：作为整个架构中的核心，要支持分布式、持久化存储，注册信息变动实时通知消费者。
服务提供者：服务以 docker 容器化方式部署(实现服务端口的动态生成)，可以通过 docker-compose 的方式来管理。通过 Registrator 检测到 docker 进程信息以完成服务的自动注册。
服务消费者：要使用服务提供者提供的服务，和服务提供者往往是动态相互转位置的。

一个较为完整的服务注册与发现流程如下：

注册服务：服务提供者到注册中心注册；
订阅服务：服务消费者到注册中心订阅服务信息，对其进行监听；
缓存服务列表：本地缓存服务列表，减少与注册中心的网络通信；
调用服务：先查找本地缓存，找不到再去注册中心拉取服务地址，然后发送服务请求；
变更通知：服务节点变动时 (新增、删除等)，注册中心将通知监听节点，更新服务信息。

1.2. 相关组件

一个服务发现系统主要由三部分组成：

注册器(registrator)：根据服务运行状态，注册/注销服务。主要要解决的问题是，何时发起注册/注销动作。
注册表(registry)：存储服务信息。常见的解决方案有zookeeper、etcd、cousul等。
发现机制(discovery)：从注册表读取服务信息，给用户封装访问接口。

1.3. 第三方实现

对于第三方的服务注册与发现的实现，现有的工具主要有以下三种：

zookeeper：一个高性能、分布式应用程序协调服务，用于名称服务、分布式锁定、共享资源同步和分布式配置管理。
Etcd：一个采用HTTP协议的健/值对存储系统，主要用于共享配置和服务发现，提供的功能相对Zookeeper和Consul相对简单。
Consul：一个分布式高可用的服务发现和配置共享的软件，支持服务发现与注册、多数据中心、健康检查和分布式键/值存储。

简单对比：

与Zookeeper和etcd不一样，Consul内嵌实现了服务发现系统，不需要构建自己的系统或使用第三方系统，客户只需要注册服务，并通过DNS或HTTP接口执行服务发现。

2. Consul和Registrator

2.1. Consul简介

Consul是什么

Consul 是一种分布式的、高可用、支持水平扩展的的服务注册与发现工具。它大致包括以下特性：

服务发现： Consul 通过 DNS 或者 HTTP 接口使服务注册和服务发现变的很容易。一些外部服务，例如 saas 提供的也可以一样注册；
健康检查：健康检测使 consul 可以快速的告警在集群中的操作。和服务发现的集成，可以防止服务转发到故障的服务上面；
键/值存储：一个用来存储动态配置的系统。提供简单的 HTTP 接口，可以在任何地方操作；
多数据中心：支持多数据中心以避免单点故障，内外网的服务采用不同的端口进行监听。而其部署则需要考虑网络延迟, 分片等情况等。zookeeper和etcd均不提供多数据中心功能的支持；
一致性算法：采用 Raft 一致性协议算法，比Paxos算法好用。使用 GOSSIP 协议管理成员和广播消息, 并且支持 ACL 访问控制；
服务管理Dashboard：提供一个 Web UI 的服务注册于健康状态监控的管理页面。

Consul的几个概念

下图是Consul官方文档提供的架构设计图：

图中包含两个Consul数据中心，每个数据中心都是一个consul的集群。在数据中心1中，可以看出consul的集群是由N个SERVER，加上M个CLIENT组成的。而不管是SERVER还是CLIENT，都是consul集群的一个节点。所有的服务都可以注册到这些节点上，正是通过这些节点实现服务注册信息的共享。除了这两个，还有一些小细节一一简单介绍。

CLIENT

CLIENT表示consul的client模式，就是客户端模式。是consul节点的一种模式，这种模式下，所有注册到当前节点的服务会被转发到SERVER节点，本身是不持久化这些信息。

SERVER

SERVER表示consul的server模式，表明这个consul是个server节点。这种模式下，功能和CLIENT都一样，唯一不同的是，它会把所有的信息持久化的本地。这样遇到故障，信息是可以被保留的。

SERVER-LEADER

中间那个SERVER下面有LEADER的描述，表明这个SERVER节点是它们的老大。和其它SERVER不一样的一点是，它需要负责同步注册信息给其它的SERVER，同时也要负责各个节点的健康监测。

其它信息

其它信息包括各个节点之间的通信方式，还有一些协议信息、算法。它们是用于保证节点之间的数据同步、实时性要求等等一系列集群问题的解决。这些有兴趣的自己看看官方文档。

2.2. Registrator简介

什么是Registrator

Registrator是一个独立于服务注册表的自动服务注册/注销组件，一般以Docker container的方式进行部署。Registrator会自动侦测它所在的宿主机上的所有Docker容器状态（启用/销毁），并根据容器状态到对应的服务注册列表注册/注销服务。

事实上，Registrator通过读取同一台宿主机的其他容器Container的环境变量进行服务注册、健康检查定义等操作。

Registrator支持可插拔式的服务注册表配置，目前支持包括Consul, etcd和SkyDNS 2三种注册工具。

2.3. Docker安装Consul集群

2.3.1. 集群节点规划

我本地的使用的是Ubuntu16.04的虚拟机：

Consul的配置参数信息说明：

2.4. Docker安装Consul集群

2.4.1. 拉取consul官方镜像

madison@ubuntu:~$ docker pull consul:latest

2.4.2. 启动Server节点

运行consul镜像，启动Server Master节点node1：

node1:

madison@ubuntu:~$ docker run -d --name=node1 --restart=always \

-e 'CONSUL_LOCAL_CONFIG={"skip_leave_on_interrupt": true}' \

-p 8300:8300 \

-p 8301:8301 \

-p 8301:8301/udp \

-p 8302:8302/udp \

-p 8302:8302 \

-p 8400:8400 \

-p 8500:8500 \

-p 8600:8600 \

-h node1 \

consul agent -server -bind=172.17.0.2 -bootstrap-expect=3 -node=node1 \

-data-dir=/tmp/data-dir -client 0.0.0.0 -ui

查看node1的日志，追踪运行情况：

现在集群中还没有选举leader节点，继续启动其余两台Server节点node2和node3：

node2:

madison@ubuntu:~$ docker run -d --name=node2 --restart=always \

-e 'CONSUL_LOCAL_CONFIG={"skip_leave_on_interrupt": true}' \

-p 9300:8300 \

-p 9301:8301 \

-p 9301:8301/udp \

-p 9302:8302/udp \

-p 9302:8302 \

-p 9400:8400 \

-p 9500:8500 \

-p 9600:8600 \

-h node2 \

consul agent -server -bind=172.17.0.3 \

-join=192.168.127.128 -node-id=$(uuidgen | awk '{print tolower($0)}') \

-node=node2 \

-data-dir=/tmp/data-dir -client 0.0.0.0 -ui

查看node2节点的进程启动日志：

node3:

madison@ubuntu:~$ docker run -d --name=node3 --restart=always \

-e 'CONSUL_LOCAL_CONFIG={"skip_leave_on_interrupt": true}' \

-p 10300:8300 \

-p 10301:8301 \

-p 10301:8301/udp \

-p 10302:8302/udp \

-p 10302:8302 \

-p 10400:8400 \

-p 10500:8500 \

-p 10600:8600 \

-h node2 \

consul agent -server -bind=172.17.0.4 \

-join=192.168.127.128 -node-id=$(uuidgen | awk '{print tolower($0)}') \

-node=node3 \

-data-dir=/tmp/data-dir -client 0.0.0.0 -ui

查看node3节点的进程启动日志：

当3个Server节点都启动并正常运行时，观察node2和node3的进程日志，可以发现node1被选举为leader节点，也就是这个数据中心的Server Master。

再次查看node1节点的进程启动日志：

观察日志发现，node2和node3都成功join到了node1所在的数据中心dc1。当集群中有3台Consul Server启动时，node1被选举为dc1中的主节点。然后，node1会通过心跳检查的方式，不断地对node2和node3进行健康检查。

2.4.4. 启动Client节点

node4:

madison@ubuntu:~$ docker run -d --name=node4 --restart=always \

-e 'CONSUL_LOCAL_CONFIG={"leave_on_terminate": true}' \

-p 11300:8300 \

-p 11301:8301 \

-p 11301:8301/udp \

-p 11302:8302/udp \

-p 11302:8302 \

-p 11400:8400 \

-p 11500:8500 \

-p 11600:8600 \

-h node4 \

consul agent -bind=172.17.0.5 -retry-join=192.168.127.128 \

-node-id=$(uuidgen | awk '{print tolower($0)}') \

-node=node4 -client 0.0.0.0 -ui

查看node4节点的进程启动日志:

可以发现：node4是以Client模式启动运行的。启动后完成后，把dc1数据中心中的以Server模式启动的节点node1、node2和node3都添加到本地缓存列表中。当客户端向node4发起服务发现的请求后，node4会通过RPC将请求转发给Server节点中的其中一台做处理。

2.4.5. 查看集群状态

madison@ubuntu:~$ docker exec -t node1 consul members

dc1数据中心中的4个节点node1, node2, node3和node4分别成功启动，Status表示他们的状态，都为alive。node1, node2, node3以Server模式启动，而node4以Client模式启动。

2.5. Docker安装Registrator

2.5.1. 拉取Registrator的镜像

madison@ubuntu:~$ docker pull gliderlabs/registrator:latest

2.5.2. 启动Registrator节点

madison@ubuntu:~$ docker run -d --name=registrator \

-v /var/run/docker.sock:/tmp/docker.sock \

--net=host \

gliderlabs/registrator -ip="192.168.127.128" consul://192.168.127.128:8500

--net指定为host表明使用主机模式。-ip用于指定宿主机的IP地址，用于健康检查的通信地址。consul://192.168.127.128:8500: 使用Consul作为服务注册表，指定具体的Consul通信地址进行服务注册和注销（注意：8500是Consul对外暴露的HTTP通信端口）。

查看Registrator的容器进程启动日志：

Registrator在启动过程完成了以下几步操作：

查看Consul数据中心的leader节点，作为服务注册表；
同步当前宿主机的启用容器，以及所有的服务端口；
分别将各个容器发布的服务地址/端口注册到Consul的服务注册列表。

2.5.3. 查看Consul的注册状态

Consul提供了一个Web UI来可视化服务注册列表、通信节点、数据中心和键/值存储等，直接访问宿主机的8500端口。

服务注册列表：

NODES节点下挂载着dc1数据中心中的所有的Consul节点，包括Consul Server和Client。

通信节点列表：

启动Registrator以后，宿主机中的所有容器把服务都注册到Consul的SERVICES上，测试完成！

总结

单数据中心的Consul集群的搭建就完成了！！！后续章节我会介绍如何使用Registrator进行服务注册的标签化。然后通过docker部署多实例的Web容器来实现基于HTTP的RESTful Service和基于TCP的RPC Service的服务注册和健康检查定义，并演示如何以标签标识一个服务的多个实例。