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。

术语

代理(agent)：代理是Consul集群上每个成员的守护进程，它是由consul agent开始运行。代理能够以客户端或服务器模式运行。由于所有节点都必须运行代理，所以将节点引用为客户端或服务器更为简单，但还有其他实例的代理。所有代理可以运行DNS或HTTP接口，并负责运行检查和保持服务同步。
客户端：客户端可以将所有RPC请求转发到服务器的代理。客户端是相对无状态的。客户端执行的唯一后台活动是LANgossip池。它消耗最小的资源开销和少量的网络带宽。
服务器端：服务器端是具有扩展的功能的代理，它主要参与维护集群状态，响应RPC查询，与其他数据中心交换WAN gossip ，以及向上级或远程数据中心转发查询。
数据中心：虽然数据中心的定义似乎很明显，但仍有一些细微的细节必须考虑。我们将一个数据中心定义为一个私有、低延迟和高带宽的网络环境。这不包括通过公共互联网的通信，但是为了我们的目的，单个EC2区域内的多个可用区域将被视为单个数据中心的一部分
Gossip：consul是建立在serf之上的，它提供了一个完整的gossip协议，用在很多地方。Serf提供了成员，故障检测和事件广播。Gossip的节点到节点之间的通信使用了UDP协议。
LAN Gossip：指在同一局域网或数据中心的节点上的LAN Gossip池。
WAN Gossip：指包含服务器的WAN Gossip池，这些服务器在不同的数据中心，通过网络进行通信。

高级特性

1.HTTP API
2.ACL

Consul工作模式

图中有两个数据中心，分别为Datacenter1和Datacenter2。Consul一层支持多个数据中心，每个数据中心内，有客户端和服务器端，服务区端一般为3~5个，这样可以在稳定和性能上达到平衡，因为更多的机器会使数据同步很慢。不过客户端是没有限制的，可以有成千上万个。

数据中心到所有节点都使用的时候Gossip协议。这就意味着有一个Gossip池，其中包含给定数据中心所有的节点。客户端不需要去配置服务器地址信息，发现服务会自动完成；检测故障节点的工作不是放在服务器端，而是分布式的；数据中心被用作消息层，以便在选择leader这种重要的事情发生的时候做通知。

每个数据中心都是都是单个Raft对等设备的一部分。这意味着他们一起工作，选择一个单一的领导者——一个具有额外职责的选定的服务器。leader负责处理所有查询和事物。事物也必须作为同步协议的一部分复制到所有对等体。由于这个要求，当非领导服务器端接收到RPC请求时，就会将请求其转发给集群leader。

服务器端节点作为WANGossip池的一部分运行，WAN池和LAN池不同的是，针对网络高延迟做了优化，而且只包含其他Consul服务器的节点。这个池的目的是允许数据中心以最少的消耗方式发现对方。在线启动新的数据中心与加入现有的WAN Gossip一样简单。因为这些服务器都在这个池中运行，它还支持跨数据中心请求。当服务器收到对不同数据中心的请求时，它会将其转发到正确数据中心中的随机服务器。那个服务器可能会转发给本地的leader。

这样会使数据中心的耦合非常低，由于故障检测，连接缓存和复用，跨数据中心请求相对快速可靠。

从上图可以看到，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

Gossip协议（流言传播协议）

Consul使用Gossip协议来管理成员和集群广播消息，这些都是通过使用Serf库的。Serf所使用的Gossip协议基于SWIM:可伸缩的弱一致的感染模式的过程组成员协议，并做了一些细微的修改。

Consul中的Gossip

Consul使用了两个不同的Gossip池，称为LAN池和WAN池。每个数据中心都有一个LAN池，其中包含数据中心的所有成员，包括服务器端和客户端。LAN的成员客户端可以自动发现服务器，减少所需配置的数量。分布式故障检测可以让故障检测的工具被整个集群共享，Gossip池可以快速可靠的将事件广播，比如选择leader。

WAN池是全局唯一的，所有的服务器都应该在WAN池中，而不关心数据中心在哪里。WAN池提供的成员信息允许服务器执行跨数据中心请求。集成的故障检测功能使Consul能够优雅地处理整个数据中心或者远程数据中心的一个服务器失连。

Lifeguard Enhancements

在分组软实时处理可能的情况下，SWIN假设本地节点是健康的。但在本地节点遇到CPU或者网络节点资源匮乏的时候，可能不会认为节点不健康。结果是安全检测状态可能会偶尔瘫痪，导致虚假报警。Lifeguard解决了这个问题。

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

工作流程

转自：https://www.jianshu.com/p/32dc52f28a14

posted @ 2020-01-29 23:50 林锅阅读(1117) 评论(0) 编辑收藏举报

刷新页面返回顶部

林锅技术园

https://github.com/GaVender