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

前言

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

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

---

正文

1. 服务发现与注册

1.1. 具体流程

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

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

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

1.2. 相关组件

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

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

1.3. 第三方实现

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

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