【微服务SpringCloud】：Consul 注册中心

1、概念

1.1、什么是 Consul ?

Consul 是由 HashiCorp 公司使用 Go 语言开发的开源工具。

Consul是分布式的、高可用的、 可横向扩展的用于实现分布式系统的服务发现与配置。提供了微服务系统中的服务治理、配置中心、控制总线等功能。Consul 安装包仅包含一个可执行文件，方便部署，与 Docker 等轻量级容器可无缝配合。Consul 的特点如下：

• 服务发现（Service Discovery）：Consul提供了通过 DNS 或者 HTTP 接口的方式来注册服务和发现服务。
• 健康检查（Health Checking）：Consul的Client可以提供任意数量的健康检查，既可以与给定的服务相关联(“webserver是否返回200 OK”)，也可以与本地节点相关联(“内存利用率是否低于90%”)。操作员可以使用这些信息来监视集群的健康状况，服务发现组件可以使用这些信息将流量从不健康的主机路由出去。
• Key/Value存储：应用程序可以根据自己的需要使用Consul提供的Key/Value存储。 Consul提供了简单易用的HTTP接口，结合其他工具可以实现动态配置、功能标记、领袖选举等等功能。
• 安全服务通信：Consul可以为服务生成和分发TLS证书，以建立相互的TLS连接。意图可用于定义允许哪些服务通信。服务分割可以很容易地进行管理，其目的是可以实时更改的，而不是使用复杂的网络拓扑和静态防火墙规则。
• 多数据中心：Consul支持开箱即用的多数据中心，这意味着用户不需要担心需要建立额外的抽象层让业务扩展到多个区域。

如图是一个事例系统图。图中的 Server （图中红色部分）是 consul 服务端，多个 Server 之间构成集群，并通过局域网或广域网通信实现数据一致性，集群间使用了 GOSSIP 协议通信和 raft 一致性算法。Client（图中紫色部分）是consul客户端，Client不保存数据，客户端将接收到的请求转发给响应的 Server 端，每个Server或Client都是一个consul agent。

• Agent：主要用于开启 Consul 的守护进程，可以运行在 Client 或者 Server 上。
• Client：客户端，将 HTTP 和 DNS 接口请求通过 RPC 转发给局域网内的服务端集群。通常一个微服务对应一个 Client ，并且将其部署到同一台服务器上。
• Server：服务端，是一个有一组扩展功能的代理，这些功能包括参与Raft选举，维护集群状态，响应 RPC 查询，与其他数据中心交互 WANgossip 和转发查询给leader或者远程数据中心。在一个数据中心中，Server的数量推荐 3-5个。因为在集群中有一个规则，大于等于一半集群不可用，则整个集群不可用，所以推荐数量推荐奇数个。

1.2、工作原理

这张图就代表了 Consul 的工作原理，在张图中：

• producer：表示服务提供者，当服务提供者启动时，会将信息注册到 Consul中，并且每隔 10s （默认）会接收到 Consul 的健康检查，检验服务提供者是否健康。
• consumer：表示服务消费者，当 consumer 请求 producer 时，会从 Consul 拿到一张临时表，这张表中包含了所有 producer 的信息，并且 Consul 每隔 10s 会更新这张临时表。
• Consul：表示注册中心，在内部划又分为 client 和 Server。

1.3、RAFT 算法 和 GOSSIP 协议通信

Consul 中可能存在3-5台 Consul Server ，但是可能会存在多台 Consul Client ，每个 Client 都会向 Server 报告状态，随着 Client 数量的增加 Server 的压力随之增大。而 Consul 采用了 GOSSIP 协议通信，所有的 Agent 之间（包括服务器模式和普通模式）运行着 Gossip 协议，服务器节点和普通 Agent 都会加入这个 Gossip 集群，收发 Gossip 消息。每隔一段时间，每个节点都会随机选择几个节点发送 Gossip 消息，其他节点会再次随机选择其他几个节点接力发送消息。这样一段时间过后，整个集群都能收到这条消息。

Consul 实现了 CAP 理论中的 CP，所以为了保证Consul Server 数据一致性，Consul 使用了基于强一致性的 RAFT 算法。在 Raft 中，有下列三个角色：

1. Leader：处理所有 Consul Client 交互，日志复制等，一般一个集群只有一个 Leader。
2. Follower: 类似选民，完全被动
3. Candidate：可以被选为一个新的 Leader。

Leader 全权负责所有客户端的请求，以及将数据同步到 Follower 中（同一时刻系统中只存在一个Leader）。Follower 能被动响应请求 RPC，但不主动发起请求，Candidate是 Follower 向 Leader 转换的中间状态。

2、安装 Consul

Consul 不同于 Eureka 需要单独安装，访问Consul 官网下载 Consul 的最新版本。根据不同的系统类型选择不同的安装包，从下图也可以看出 Consul 支持所有主流系统。

在下载完成之后，安装包就只有一个.exe 文件，我们启动这个 .exe 文件就可以运行 Consul 。

运行 Consul，打开 cmd ，输入指令consul agent -dev -client=0.0.0.0。指令的意思是：以开发者模式启动代理，并不限制访问的IP，既所有IP都可以访问。 除了以开发者模式外，还可以通过client和server启动代理，这两种方式通常是在 Consul 集群中完成的。

3、服务注册

Consul 的服务注册有两种方式，分别是通过服务定义和 HTTP API 的方式。下面我们就简单的了解这两种方式。

3.1、使用服务定义的方式完成服务注册

通过服务定义完服务注册有两种填写配置的方式，一种是通过指令直接运行，一种是将配置写在以 .json或 .hcl为后缀的配置文件中，然后在运行代理时指定配置文件路径。

在使用服务定义完成服务注册时，配置项有很多，下面只是其中一小部分重要配置项：

{
  "service": {
    "id": "redis", //指定服务 ID ，如果未指定，name将使用该字段的值。每个节点的服务必须具有唯一的 ID，因此如果默认值name会与其他服务冲突，您应该指定唯一的值。
    "name": "redis",//指定服务的名称。是必须参数
    "tags": ["primary"],//可用于添加服务级别标签的字符串值列表。
    "address": "",//指定特定于服务的 IP 地址或主机名的字符串值。如果未指定值，则默认使用代理节点的 IP 地址。此参数没有服务端验证。
    "port": 8000,//指定服务特定端口号的整数值。address定义参数时需要指定端口号，以提高服务的可发现性。
}

一般在微服务中不会使用这种方式完成服务注册。

3.2、使用 HTTP API 的方式完成服务注册

Consul 提供了很多 HTTP API 接口，用于对节点、服务、检查、配置等执行基本的 CRUD 操作。具体的 API 官网，我们只对了解一下服务注册的 API。

• 在启动代理之后，发送put请求到http://localhost:8500/v1/catalog/register地址可以完成服务注册，在发送请求的时发送一些参数：

  {
    "Datacenter": "dc1",//指定数据中心，如果未提供，则默认为代理的数据中心
    "Node": "t2.320", // 指定要注册的节点 ID。
    "Address": "localhost", // 指定要注册的地址。
    "Service": {//指定注册服务,同配置文件中的一样，这里不说复述
      "ID": "redis1",
      "Service": "redis",
      "Tags": ["primary", "v1"],
      "Address": "127.0.0.1",
      "Port": 9999
    }
  }
  

• 在服务注册完成之后，发送put请求到http://localhost:8500/v1/catalog/deregister地址可以完成服务注销，在发送请求的时发送一些参数：

  {
    "Datacenter": "dc1",//需要注销的服务所在的数据中心
    "Node": "t2.320"//需要注销的服务的ID
  }
  

• 发送get请求到http://localhost:8500/v1/catalog/datacenters地址可以查询数据中心。
• 发送get请求到http://localhost:8500/v1/catalog/services地址可以查询数据中心中所有的以注册服务。
• 发送get请求到http://localhost:8500/v1/catalog/service/:service地址可以查询某个具体的服务

consul 中的API，这里就简单了了解一下，如果有需要可以官网查看全部的 API 信息。

4、在微服务中完成服务注册和调用

Consul 的应用大多数还是在微服务中使用，通过配置将微服务注册到 Consul 中，然后供其他微服务调用。

• 引入依赖：引入 Consul 需要的依赖

  <!--SpringCloud提供的基于Consul的服务发现-->
   <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-consul-discovery</artifactId>
   </dependency>
  <!--actuator用于心跳检查-->
  <dependency>
       <groupId>org.springframework.boot</groupId>
       <artifactId>spring-boot-starter-actuator</artifactId>
  </dependency>
  

• 在配置文件中，添加配置完成服务注册，下述这些配置项，只是配置项中的一部分：

  server:
    port: 8001
  
  spring:
   application:
     name: consul-order
   cloud:
     consul: #consul相关配置
       host: 127.0.0.1 #ConsulServer请求地址
       port: 8500 #ConsulServer端口
       discovery:
         #是否注册
         register: true
         #实例ID
         instance-id: ${spring.application.name}-1
         #服务实例名称
         service-name: ${spring.application.name}
         #服务实例端口
         port: ${server.port}
         #健康检查路径
         healthCheckPath: /actuator/health
         #健康检查时间间隔
         healthCheckInterval: 15s
         #开启ip地址注册
         prefer-ip-address: true
         #实例的请求ip
         ip-address: ${spring.cloud.client.ip-address}
  

服务消费者想要从注册中心拿到数据，也需要将服务注册到 Consul 中，然后通过RestTemplate访问，服务消费者进行服务注册的步骤同上。

4、Consul 集群

在之前的所有过程中，我们都是通过开发者模式运行代理，但是在项目开发完成之后，我们需要将项目部署到生产环境。所以这个时候就需要使用 Consul 集群，一个 Consul 集群中需要多台 Consul Server 和多台 Consul Client。

通过指令启动多台 Consul Server 代理：

consul agent -server -bootstrap-expect 3  -node=server-1 -bind=监听的ip地址 -ui -client 0.0.0.0

consul agent -server -bootstrap-expect 2  -node=server-2 -bind=监听的ip地址 -ui -client 0.0.0.0

consul agent -server -bootstrap-expect 2  -node=server-3 -bind=监听的ip地址 -ui -client 0.0.0.0

-server：表示以 server身份启动代理；-bootstrap-expec表示集群要求的最少 server 数量，当低于这个数量，集群即失效；-node表示节点id，在同一集群不能重复；-bind表示监听的ip地址；-client表示客户端的ip地址(0.0.0.0表示不限制)

通过指令启动 Consul Client 代理：

consul agent -client=0.0.0.0  -node=client-1

我们启动了四台 Consul 代理，这四台代理之间其实没有任何联系，都是独立的存在。所以我们还需要通过命令将它们连接在一起形成一个集群。在除了 Leader 外的代理中执行如下代码。

//ip地址表示集群中的Leader地址，Leader是一个Server.
consul join ip地址