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

前言

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

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

正文

1. 服务发现与注册

1.1. 具体流程

服务注册中心:作为整个架构中的核心,要支持分布式持久化存储注册信息变动实时通知消费者。

服务提供者:服务以容器化方式部署(实现服务端口动态生成),可以通过 的方式来管理。通过 检测到 进程信息以完成服务的自动注册

服务消费者:要使用服务提供者提供的服务,和服务提供者往往是动态相互转位置的。

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

注册服务:服务提供者到注册中心注册

订阅服务:服务消费者到注册中心订阅服务信息,对其进行监听

缓存服务列表:本地缓存服务列表,减少与注册中心的网络通信;

调用服务:查找本地缓存,找不到再去注册中心拉取服务地址,然后发送服务请求;

变更通知:服务节点变动时 (新增删除等),注册中心将通知监听节点,更新服务信息。

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是什么

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

服务发现:通过 或者 接口使服务注册和服务发现变的很容易。一些外部服务,例如 提供的也可以一样注册;

健康检查:健康检测使 可以快速的告警在集群中的操作。和服务发现的集成,可以防止服务转发到故障的服务上面;

键/值存储:一个用来存储动态配置的系统。提供简单的 接口,可以在任何地方操作;

多数据中心:支持多数据中心以避免单点故障,内外网的服务采用不同的端口进行监听。而其部署则需要考虑网络延迟, 分片等情况等。 和 均不提供多数据中心功能的支持;

一致性算法:采用 一致性协议算法,比 算法好用。 使用 协议管理成员和广播消息, 并且支持 访问控制;

服务管理Dashboard:提供一个 的服务注册于健康状态监控的管理页面。

Consul的几个概念

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

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

CLIENT

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

SERVER

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

SERVER-LEADER

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

其它信息

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

2.2. Registrator简介

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

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

支持可插拔式服务注册表配置,目前支持包括 , 和 三种注册工具。

2.3. Docker安装Consul集群

2.3.1. 集群节点规划

我本地的使用的是 的虚拟机:

2.3.2. Consul集群安装

的配置参数信息说明:

2.4. Docker安装Consul集群

2.4.1. 拉取consul官方镜像

2.4.2. 启动Server节点

运行 镜像,启动 节点 :

node1:

查看 的日志,追踪运行情况:

现在集群中还没有选举 节点,继续启动其余两台 节点 和 :

node2:

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

node3:

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

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

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

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

2.4.4. 启动Client节点

node4:

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

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

2.4.5. 查看集群状态

数据中心中的4个节点 , , 和 分别成功启动, 表示他们的状态,都为 。 , , 以 模式启动,而 以 模式启动。

2.5. Docker安装Registrator

2.5.1. 拉取Registrator的镜像

2.5.2. 启动Registrator节点

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

查看 的容器进程启动日志:

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

查看Consul数据中心的leader节点,作为服务注册表;

同步当前宿主机的启用容器,以及所有的服务端口;

分别将各个容器发布的服务地址/端口注册到Consul的服务注册列表。

2.5.3. 查看Consul的注册状态

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

服务注册列表

节点下挂载着 数据中心中的所有的 节点,包括 和 。

通信节点列表

启动 以后,宿主机中的所有容器把服务都注册到 的 上,测试完成!

总结

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

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180422G085ST00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券