服务发现--Consul

前言

服务注册、服务发现作为构建微服务架构得基础设施环节，重要性不言而喻。在当下，比较热门用于做服务注册和发现的开源项目包括zookeeper、etcd、euerka和consul。今天在这里对近期学习consul的一些知识继续浓缩和汇总，作为自己学习过程中的一个总结。

Consul简介

Consul是基于GO语言开发的开源工具，主要面向分布式，服务化的系统提供服务注册、服务发现和配置管理的功能。Consul的功能都很实用，其中包括：服务注册/发现、健康检查、Key/Value存储、多数据中心和分布式一致性保证等特性。Consul本身只是一个二进制的可执行文件，所以安装和部署都非常简单，只需要从官网下载后，在执行对应的启动脚本即可。

Consul特性

基础特性

1.服务注册/发现
为什么微服务架构下就需要做服务注册和服务发现呢？微服务的目标就是要将原来大一统的系统架构，拆分成细粒度的按功能职责分成的小系统，这样就会出现很多小的系统，部署的节点也会随之增加。试想一下，如果没有一个统一的服务组件来管理各系统间的列表，微服务架构是很难落地实现的。
Consul提供的服务注册/发现功能在数据强一致性和分区容错性上都有非常好的保证，但在集群可用性下就会稍微差一些（相比Euerka来说）。

2.数据强一致性保证
Consul采用了一致性算法Raft来保证服务列表数据在数据中心中各Server下的强一致性，这样能保证同一个数据中心下不管某一台Server Down了，请求从其他Server中同样也能获取的最新的服务列表数据。数据强一致性带来的副作用是当数据在同步或者Server在选举Leader过程中，会出现集群不可用。

3.多数据中心
Consul支持多数据中心(Data Center),多个数据中心之间通过Gossip协议进行数据同步。多数据中心的好处是当某个数据中心出现故障时，其他数据中心可以继续提供服务，提升了可用性。

4.健康检查
Consul支持基本硬件资源方面的检查，如：CPU、内存、硬盘等

5.Key/Value存储
Consul支持Key/Value存储功能，可以将Consul作为配置中心使用，可以将一些公共配置信息配置到Consul，然后通过Consul提供的 HTTP API来获取对应Key的Value。

高级特性

1.HTTP API
2.ACL

Consul工作模式

 

Consul工作模式

从上图可以看到，Consul中包括的3种不同的角色：Client、Server、Server-Leader。还有一个在图上没有标出来的角色Agent，一共4个角色，下面会逐一介绍它们的作用。

• Agent
  1.是一个守护线程
  2.跟随Consul应用启动而启动
  3.负责检查、维护节点同步

• Client
  1.转发所有请求给Server
  2.无状态，不持久化数据
  3.参与LAN Gossip的健康检查

• Server
  1.持久化数据
  2.转发请求给Server-Leader
  3.参与Server-Leader选举
  4.通过WAN Gossip，与其他数据中心交换数据

• Server-Leader
  1.响应RPC请求
  2.服务列表数据同步给Server

Consul工作原理

服务注册的方式

Consul服务注册有两种方式：HTTP API & JSON配置文件
方式一：HTTP API

http://{ip}:8500/v1/agent/service/register/:service

方式二：JSON 配置文件

{
    "services": [
            {
                    "id": "serverId",
                    "name": "serverName",
                    "tags": [
                            "primary"
                    ],
                    "address": "127.0.0.1",
                    "port": 9003,
                    "checks": [
                            {
                                    "id": "api-servie",
                                    "name": "Service 'xx' check",
                                    "http": "http://127.0.0.1:9003/public/health",
                                    "method": "GET",
                                    "interval": "10s",
                                    "timeout": "1s"
                            }
                    ]
            }
    ]

}

启动Consul增加启动参数-config-dir

nohup ./consul agent -dev -config-dir=/consul-conf/service.json &

服务发现的方式

服务发现的方式同时有两种：HTTP API & DNS Agent
方式一：HTTP API

获取某个service下健康的服务列表信息
http://{ip}:8500/v1/health/service/:service

方式二：DNS Agent

工作流程

 

Consul工作流程

 

在 Spring Cloud 体系中，几乎每个角色都会有两个以上的产品提供选择，比如在注册中心有：Eureka、Consul、zookeeper、etcd 等；网关的产品有 Zuul、Spring Cloud Gateway 等。在注册中心产品中，最常使用的是 Eureka 和 Consul，两者各有特点，企业可以根据自述项目情况来选择。

前面给大家详细介绍了 Eureka ，本节给大家介绍 Consul 的使用。

什么是Consul

Consul 是 HashiCorp 公司推出的开源产品，用于实现分布式系统的服务发现、服务隔离、服务配置，这些功能中的每一个都可以根据需要单独使用，也可以同时使用所有功能。Consul 官网目前主要推 Consul 在服务网格中的使用。

与其它分布式服务注册与发现的方案相比，Consul 的方案更“一站式”——内置了服务注册与发现框架、分布一致性协议实现、健康检查、Key/Value 存储、多数据中心方案，不再需要依赖其它工具。Consul 本身使用 go 语言开发，具有跨平台、运行高效等特点，也非常方便和 Docker 配合使用。

Consul 的主要特点有：
Service Discovery : 服务注册与发现，Consul 的客户端可以做为一个服务注册到 Consul，也可以通过 Consul 来查找特定的服务提供者，并且根据提供的信息进行调用。

Health Checking: Consul 客户端会定期发送一些健康检查数据和服务端进行通讯，判断客户端的状态、内存使用情况是否正常，用来监控整个集群的状态，防止服务转发到故障的服务上面。

KV Store: Consul 还提供了一个容易使用的键值存储。这可以用来保持动态配置，协助服务协调、建立 Leader 选举，以及开发者想构造的其它一些事务。

Secure Service Communication: Consul 可以为服务生成分布式的 TLS 证书，以建立相互的 TLS 连接。 可以使用 intentions 定义允许哪些服务进行通信。 可以使用 intentions 轻松管理服务隔离，而不是使用复杂的网络拓扑和静态防火墙规则。

Multi Datacenter: Consul 支持开箱即用的多数据中心，这意味着用户不需要担心需要建立额外的抽象层让业务扩展到多个区域。

Consul 角色
Server: 服务端, 保存配置信息, 高可用集群, 在局域网内与本地客户端通讯, 通过广域网与其它数据中心通讯。 每个数据中心的 Server 数量推荐为 3 个或是 5 个。

Client: 客户端, 无状态, 将 HTTP 和 DNS 接口请求转发给局域网内的服务端集群。

Consul 旨在对 DevOps 社区和应用程序开发人员友好，使其成为现代、弹性基础架构的理想选择。

使用Consul 的优势

使用 Raft 算法来保证一致性, 比复杂的 Paxos 算法更直接。相比较而言, zookeeper 采用的是 Paxos, 而 etcd 使用的则是 Raft。

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

支持健康检查。 etcd 不提供此功能。

支持 http 和 dns 协议接口。 zookeeper 的集成较为复杂, etcd 只支持 http 协议。

官方提供 Web 管理界面, etcd 无此功能。

Consul 保持了 CAP 中的 CP，保持了强一致性和分区容错性。

Consul 支持 Http\gRPC\DNS 多种访问方式。

Consul 的调用过程

首先我们根据一张图来了解一下 Consul 服务调用过程：

1、当 Producer 启动的时候，会向 Consul 发送一个 post 请求，告诉 Consul 自己的 IP 和 Port；

2、Consul 接收到 Producer 的注册后，每隔 10s（默认）会向 Producer 发送一个健康检查的请求，检验 Producer 是否健康；

3、当 Consumer 发送 GET 方式请求 /api/address 到 Producer 时，会先从 Consul 中拿到一个存储服务 IP 和 Port 的临时表，从表中拿到 Producer 的 IP 和 Port 后再发送 GET 方式请求 /api/address；

4、该临时表每隔 10s 会更新，只包含有通过了健康检查的 Producer。

Spring Cloud Consul 项目是针对 Consul 的服务治理实现。Consul 是一个分布式高可用的系统，它包含多个组件，但是作为一个整体，在微服务架构中，为我们的基础设施提供服务发现和服务配置的工具。

Consul 和 eureka的对比

我们先来通过一个表格做简单对比

Feature	Euerka	Consul
服务健康检查	可配支持	服务状态，内存，硬盘等
多数据中心	—	支持
kv 存储服务	—	支持
一致性	—	raft
cap	ap	cp
使用接口(多语言能力)	http（sidecar）	支持 http 和 dns
watch 支持	支持 long polling/大部分增量	全量/支持long polling
自身监控	metrics	metrics
安全	—	acl /https
编程语言	Java	go
Spring Cloud 集成	已支持	已支持

通过对比可以得知， Consul 功能更强大，Euerka 更容易使用。

Consul 强一致性©带来的是：

服务注册相比 Eureka 会稍慢一些。因为 Consul 的 raft 协议要求必须过半数的节点都写入成功才认为注册成功,。Leader 挂掉时，重新选举期间整个 Consul 不可用。保证了强一致性但牺牲了可用性。

Consul 强烈的一致性意味着它可以作为领导选举和集群协调的锁定服务。

Eureka 保证高可用(A)和最终一致性：

服务注册相对要快，因为不需要等注册信息 replicate 到其它节点，也不保证注册信息是否 replicate 成功。当数据出现不一致时，虽然 A, B 上的注册信息不完全相同，但每个 Eureka 节点依然能够正常对外提供服务，这会出现查询服务信息时如果请求 A 查不到，但请求 B 就能查到。如此保证了可用性但牺牲了一致性。

 

https://blog.csdn.net/qwe86314/article/details/95094751

链接：https://www.jianshu.com/p/32dc52f28a14