Consul 服务注册与发现一站式解决方案

 

consul简介

 

• Consul 是一个支持多数据中心分布式高可用的服务发现和配置共享的服务软件,由 HashiCorp 公司用 Go 语言开发, 基于 Mozilla Public License 2.0 的协议进行开源. Consul 支持健康检查,并容许 HTTP 和 DNS 协议调用 API 存储键值对.
• 一致性协议采用 Raft 算法,用来保证服务的高可用. 使用 GOSSIP 协议管理成员和广播消息, 而且支持 ACL 访问控制.
• Consul 的方案更 "一站式"，内置了服务注册与发现框架、分布一致性协议实现、健康检查、Key/Value 存储、多数据中心方案，再也不须要依赖其余工具（好比 ZooKeeper 等）。使用起来也较为简单。Consul 用 Golang 实现，所以具备自然可移植性（支持 Linux、windows 和 Mac OS X）；安装包仅包含一个可执行文件，方便部署，与 Docker 等轻量级容器可无缝配合

 

使用场景

 

• docker 实例的注册与配置共享
• coreos 实例的注册与配置共享
• vitess 集群
• SaaS 应用的配置共享
• 与 confd 服务集成，动态生成 nginx 和 haproxy 配置文件

产品对比

 

同类工具备如下这些

etcd Distributed reliable key-value store for the most critical data of a distributed system

zookeeper Apache ZooKeeper is an effort to develop and maintain an open-source server which enables highly reliable distributed coordination.

 

相同点

• 架构相似，都有服务节点，而这些服务节点的操做都要求达到节点的仲裁数（一般，节点的仲裁数遵循的是简单多数原则
• 强一致性，用于构建复杂的分布式系统

不一样点

• zooKeeper, etcd只提供一个原始的K/V值存储，并要求开发人员构建他们本身的系统来提供服务发现功能，cosnul提供服务发现功能
• consul基于gossip的健康检查机制脱颖而出。ZooKeeper健康检查机制须要胖客户端，增长了工做量。etcd无健康检查功能
• consul使用Raft算法来保证一致性, 比复杂的Paxos算法更直接. 相比较而言, zookeeper采用的是 Paxos, 而 etcd 使用的则是 Raft.
• 支持多数据中心，内外网的服务采用不一样的端口进行监听。多数据中心集群能够避免单数据中心的单点故障, 而其部署则须要考虑网络延迟, 分片等状况等. zookeeper和etcd 均不提供多数据中心功能的支持.
• 支持 http 和 dns 协议接口. zookeeper的集成较为复杂, etcd 只支持 http 协议.
• 官方提供web管理界面, etcd 无此功能

 

架构

 

术语解释

Consul集群间使用了GOSSIP协议通讯和raft一致性算法。

• Agent——agent是一直运行在Consul集群中每一个成员上的守护进程。经过运行consul agent来启动。agent能够运行在client或者server模式。指定节点做为client或者server是很是简单的，除非有其余agent实例。全部的agent都能运行DNS或者HTTP接口，并负责运行时检查和保持服务同步。
• Client——一个Client是一个转发全部RPC到server的代理。这个client是相对无状态的。client惟一执行的后台活动是加入LAN gossip池。这有一个最低的资源开销而且仅消耗少许的网络带宽。
• Server——一个server是一个有一组扩展功能的代理，这些功能包括参与Raft选举，维护集群状态，响应RPC查询，与其余数据中心交互WAN gossip和转发查询给leader或者远程数据中心。
• DataCenter——咱们定义数据中心为一个私有的，低延迟和高带宽的一个网络环境。
• Consensus——一致性，使用Consensus来代表就leader选举和事务的顺序达成一致。为了以容错方式达成一致，通常有超过半数一致则能够认为总体一致。Consul使用Raft实现一致性，进行leader选举，在consul中的使用bootstrap时，能够进行自选，其余server加入进来后bootstrap就能够取消。
• Gossip——Consul创建在Serf的基础之上，它提供了一个用于多播目的的完整的gossip协议。Serf提供成员关系，故障检测和事件广播。Serf是去中心化的服务发现和编制的解决方案，节点失败侦测与发现，具备容错、轻量、高可用的特色。
• LAN Gossip——

Consul中的每一个数据中心有一个LAN池，它包含了这个数据中心的全部成员，包括clients和servers。LAN池用于如下几个目的:

成员关系信息容许client自动发现server, 减小了所须要的配置量。

分布式失败检测机制使得由整个集群来作失败检测这件事， 而不是集中到几台机器上。

gossip池使得相似领导人选举这样的事件变得可靠并且迅速。

• WAN Gossip——

WAN池是全局惟一的，由于全部的server都应该加入到WAN池中，不管它位于哪一个数据中心。由WAN池提供的成员关系信息容许server作一些跨数据中心的请求。一体化的失败检测机制容许Consul优雅地去处理：整个数据中心失去链接， 或者仅仅是别的数据中心的某一台失去了链接。

• RPC——远程过程调用。这是一个容许client请求server的请求/响应机制。

 

架构分解

• 首先，咱们能够看到有两个数据中心，标签为"Datacenter 1"和"Datacenter 2"。consul对多数据中心提供最高等级的支持并预期这将成为广泛状况。
• 在每一个数据中心内，混合有客户端和服务器。预期由3到5个服务器。强调在失败状况下的可达到和性能之间的平衡，由于添加更多机器会致使一致性变得日益缓慢。不过，对于客户端的数量没有限制，并且能够很容易的扩展到成千上万。
• 在一个数据中心内的全部节点加入一个gossip 协议。这意味着对于一个给定的数据中心，有一个包含全部节点的gossip池。这服务于几个目的：
• 首先，不须要用服务器地址来配置客户端；发现是自动完成的。
• 其次，检测节点失败的工做不是放置在服务器上，而是分布式的。这使得失败检测比心跳机制更加可扩展。
• 另外，当重要事件好比leader选举发生时它被用来做为消息层(messaging layer)来通知。

1. 每一个数据中心中的服务器是单个Raft 端集合(peer set)的全部组成部分。这意味着他们一块儿工做来选举leader，一个有额外职责的被选定的服务器。leader负责处理全部请求和事务。事务也必须复制到全部做为一致协议一部分的端(peer)。由于这个要求，当一个非leader服务器收到RPC请求时，它转发请求到集群leader。

• 服务器节点也做为广域网 gossip 协议池的一部分运做。这个池和局域网池有所不一样，由于它为因特网的高延迟作了优化并预期只包含其余consul服务器(注：特指在其余数据中心中的consul服务器，见图中的"Datacenter 2")节点。这个池的目的是允许数据中心们以低接触(low-touch)风格相互发现。上线一个新的数据中心和加入现有的广域网gossip同样容易。由于服务器都在全体经营这个池，池能够开启跨数据中心请求。当服务器收到一个给不一样数据中心的请求时，它转发请求到正确的数据中心中的任意服务器。这个服务器可能随即转发给本地leader。
• 这使得数据中心之间的耦合的很是低。而由于失败检测，链接缓存和多路通信，跨数据中心请求相对比较快而可靠。

 

Gossip协议

 

• Gossip算法如其名，灵感来自办公室八卦，只要一我的八卦一下，在有限的时间内全部的人都会知道该八卦的信息，这种方式也与病毒传播相似，所以Gossip有众多的别名“闲话算法”、“疫情传播算法”、“病毒感染算法”、“谣言传播算法”。
• 但Gossip并非一个新东西，以前的泛洪查找、路由算法都归属于这个范畴，不一样的是Gossip给这类算法提供了明确的语义、具体实施方法及收敛性证实。
• http://blog.csdn.net/u012422829/article/details/77828870

Anti-Entropy(反熵)

• Consule 使用一个高级的方式来维护 service 和 health 信息的方法。Anti-Entropy（反熵 ） 机制被用来保证在不一样节点上的备份（replica）都持有最新版本
• Agent
• 　　每一个Consul agent维护它本身的服务集合以及检查注册和健康信息。agent负责执行本身的健康检查和更新本地状态。
• Catalog
• 　　Consul的服务发现基于一个服务目录。这个目录是经过聚合agents提交的信息造成的。目录维护了集群的高级视图，它包括哪些服务可用，哪些节点容许这些服务，健康信息等等。目录是用来展现这些信息的，能够经过各类Consul提供的接口，包含DNS和HTTP。
• 　　与agent相比，目录上下文中的服务和检查的字段更为有限。这是由于目录只服务于记录和返回关于服务，节点和健康的信息。
• 　　只有server节点维护目录。这是由于目录是经过Raft日志复制来提供一个统一的集群视图。
• http://blog.mallux.me/2017/03/19/consul/
• http://www.voidcn.com/article/p-oqtnkvov-ye.html

一致性Raft

• Consul使用Raft算法实现分布式存储的一致性。Raft节点在集群中有follower,candidate或leader三种状态，初始为follower，在这个状态下节点能够接收来自leader的日志单元和投票选leader。若是一段时间内收不到来自leader的心跳，则升级为candidate向集群全部node发送投票邀请，若是candidate收到过半节点的投票则升级为leader，leader负责接收日志单元并复制给全部follower
• 集群当选出leader后才能接收新的日志单元，节点收到日志时把日志转发给leader，leader将日志保存到本地存储复制给全部follower，当超过半数的follower成功复制后日志单元状态变为‘committed’，进而交给状态机去执行。而后leader会将日志单元的committ状态发送给全部follower让他们来更新到各自状态机。
• Consul自动的经过快照机制将Raft日志压缩来避免其无限增加
• 在consul集群里，只有server结点经过Raft算法进行数据一致性管理，缘由是Raft集群的结点数量不能太多(在3-5)，若是client也参与到Raft那么随着集群结点数量增长，在Raft算法下集群效率会降低，client结点只是将数据请求转发给server

 

Raft启动方式

• Raft集群的启动方式有两种，其中一种直接的办法是用个配置文件记录全部server的列表，每一个server启动后用这个静态的列表做为Raft的server，但这须要全部server维护一个静态的配置文件
• ‘-bootstrap’参数，若是集群先启动一个server而且他优先成为leader(Consul在这里作了特殊设置，让这个bootstrap server从log中恢复成leader状态)，以后加入的全部server一直是follower状态。但这还有个问题，就是仍是得固定一台server成为第一个leader，启动参数必须与其余server不一样(必须带有-bootstrap）
• ‘-bootstrap-expect’参数，全部server都用同一参数’-boostrap-expect N’说明集群的server个数为N，在有N个server join进来后，cluster开始启动raft逻辑选主。注意，N必定要与server总数相同，不然会出现split-brain(双主)问题，好比N=3 儿集群server总数为7，就极可能出现两个leader的状况。

读操做一致性

• 对于读操做，consul支持多种一致性模式：
• ‘default’, 这种模式下若是leader由于与成员分离致使新的leader被选出的状况下，虽然旧的leader不能再提交日志，但还能够负责进行读取操做，这回致使部分读取的数据是过时的。但这种状态不会维持多长时间，由于旧的leader的状态很快就会降级为follower
• ‘consistent’，这种模式下要求leader给follower发消息确认仍然是leader，这就形成了读取操做时多了一步操做增长了延迟
• ‘stale’，这个模式下每一个server均可以负责读取，这就致使读出来的数据由于还未在leader把数据复制到所有follower时被读出儿形成不一致，但这种状况也是少数，而且效率会很是快，而且即使没有leader的状况下还可以提供读操做

 

健康检查

• Agent的一个重要任务是作系统级和程序级的健康检测，检测经过配置文件或HTTP接口来定义并被保存到Agent所运行的节点
• 定时脚本检查(script+Interval), 调用一个第三方的程序进行健康检测，使用退出码或标准输出来代表检测结果(相似Nagios), 输出内容不能超过4K，默认的检查超时时间是30秒，能够经过配置文件里的”timeout”来定义。Agent使用enable_script_checks参数来打开这种检查
• 脚本退出码与检测结果对应关系：
• 0, passing
• 1, warning
• other, failing
• 脚本的任何输出内容会被保存到消息的‘Output’字段， Agent启动后
• 定时HTTP检查(HTTP+Interval), 定时经过HTTP GET调用指定的URL，根绝HTTP返回码判断服务状态。‘2xx’表示经过检查，‘429’表示警告，其他均表示故障。默认状况下http请求的timeout与检查的interval相同，最长为10秒。能够经过‘timeout’来在配置文件里设置。检查返回的内容大小不能超过4K，超过部分会被截断。默认状况下支持SSL，能够经过tls_skip_verify来关掉。
• 定时TCP检查(TCP+Interval), 定时经过TCP链接检查指定host/IP和端口，根据是否可以创建链接成功与否断定service状态，成功链接表示service正常，不然表示事态危急. 默认超时时间10秒。
• TTL检查，经过服务主动的定时更新TTL，超过期间的定位service故障。
• 定时Docker检查，经过调用常驻docker里的一个检查程序来进行，这个程序经过调用Docker Exec API来启动，须要consul agent具备调用Docker HTTP API或Unix Socket的权限。consul用 DOCKER_HOST 来定位Docker API端点，检查程序运行完后要返回适当的退出码和输出，输出内容不能超过4K。Agent须要经过enable_script_check来打开这种检查
• 默认会将check的状态设置为‘critical’，这是防止服务在没有被检查前就被加入到调用这个服务的系统里

 

 

状态监视

• 使用Whach能够监视KV、nodes、service、checks等对象的变化，当有更新时会触发watch定义的可执行的handler。
• Watch经过阻塞的HTTP API实现，Agent会根据调用相应api请求自动监视指定内容，当有变化时通知handler
• Watch还能够加入到Agent的配置文件中的watches生成
• watch还能够经过‘consule watch’命令来直接运行并把结果输出处处理程序
• 当watch监控到数据的更新，能够调用一个handler还作后续处理，watch会将监控的结果以JSON格式发送给handler的标准输入(stdin), watch不一样的对象结果的格式会不一样
• watch的类型：
• Key
• keprefix
• services
• nodes
• service
• checks
• event

 

Session会话

• Consul 提供了一个可用于 构建分布式锁 的会话（session）机制。 Session 充当节点、运行情况检查和键/值数据之间的绑定层。 它们旨在提供细粒度的锁定，并受到松散耦合的分布式系统的分布式锁服务（The Chubby Lock Service for Loosely-Coupled Distributed Systems）的大量启发。
• Consul 中的 session 表示具备很是特定语义的 contract 。 当构建会话时，能够提供节点名称、健康检查列表、行为、TTL 和 锁定延迟。 新构造的 session 具备可用于识别它的命名 ID。 此 ID 可与 KV 存储一块儿使用以获取锁：用于互斥的咨询机制。
• Consule 提供的 contract ，在下列任何状况下，会话将失效：
• 节点已取消注册
• 任何健康检查都被取消注册
• 任何健康检查都进入临界状态
• 会话被明确销毁
• TTL 到期（若是适用）
• 当 session 无效时，会被销毁，不能再使用。 相关锁的操做取决于在建立时指定的行为。 Consul 支持 release 和 delete 行为。 若是未指定任何内容，则 release 行为是缺省值。

 

---

---

 

 

命令

kv - Key/Value存储

agent - Agent控制

catalog - 管理nodes和services

health - 管理健康监测

session - Session操做

acl - ACL建立和管理

event - 用户Events

status - Consul系统状态

 

Agent API

/v1/agent/checks : 返回本地agent注册的全部检查(包括配置文件和HTTP接口)

/v1/agent/services : 返回本地agent注册的全部 服务

/v1/agent/members : 返回agent在集群的gossip pool中看到的成员

/v1/agent/self : 返回本地agent的配置和成员信息

/v1/agent/join/<address> : 触发本地agent加入node

/v1/agent/force-leave/<node>>: 强制删除node

/v1/agent/check/register : 在本地agent增长一个检查项，使用PUT方法传输一个json格式的数据

/v1/agent/check/deregister/<checkID> : 注销一个本地agent的检查项

/v1/agent/check/pass/<checkID> : 设置一个本地检查项的状态为passing

/v1/agent/check/warn/<checkID> : 设置一个本地检查项的状态为warning

/v1/agent/check/fail/<checkID> : 设置一个本地检查项的状态为critical

/v1/agent/service/register : 在本地agent增长一个新的服务项，使用PUT方法传输一个json格式的数据

/v1/agent/service/deregister/<serviceID> : 注销一个本地agent的服务项

 

Catalog API

/v1/catalog/register : Registers a new node, service, or check

/v1/catalog/deregister : Deregisters a node, service, or check

/v1/catalog/datacenters : Lists known datacenters

/v1/catalog/nodes : Lists nodes in a given DC

/v1/catalog/services : Lists services in a given DC

/v1/catalog/service/<service> : Lists the nodes in a given service

/v1/catalog/node/<node> : Lists the services provided by a node

 

Health API

/v1/healt/node/<node>: 返回node所定义的检查，可用参数?dc=

/v1/health/checks/<service>: 返回和服务相关联的检查，可用参数?dc=

/v1/health/service/<service>: 返回给定datacenter中给定node中service

/v1/health/state/<state>: 返回给定datacenter中指定状态的服务，state能够是"any", "unknown", "passing", "warning", or "critical"，可用参数?dc=

Session API

/v1/session/create: Creates a new session

/v1/session/destroy/<session>: Destroys a given session

/v1/session/info/<session>: Queries a given session

/v1/session/node/<node>: Lists sessions belonging to a node

/v1/session/list: Lists all the active sessions

ACL API

/v1/acl/create: Creates a new token with policy

/v1/acl/update: Update the policy of a token

/v1/acl/destroy/<id>: Destroys a given token

/v1/acl/info/<id>: Queries the policy of a given token

/v1/acl/clone/<id>: Creates a new token by cloning an existing token

/v1/acl/list: Lists all the active tokens

Event API

/v1/event/fire/<name>: 触发一个新的event，用户event须要name和其余可选的参数，使用PUT方法

/v1/event/list: 返回agent知道的events

Status API

/v1/status/leader : 返回当前集群的Raft leader

/v1/status/peers : 返回当前集群中参与投票的节点

自定义事件

Event:

consul event -name=test -http-addr=localhost:8500

consul watch -type=event -name=test "echo 'see it'”

Key:

curl -XPUT 'http://localhost:8500/v1/kv/web/k1' -d '{"name":"mm"}’

consul watch -type=key –key=web/k1 "echo 'see it'”

更多内容见:

http://blog.csdn.net/younger_china/article/details/52243799

 

 

---

 

Why client per node

SRV 中的target实际指向了注册节点的域名,因此说明 consul 的 DNS 规则是无论你service 注册的时候不管你怎么提交本身的 IP, 在 DNS 上,永远以注册的Consul节点的 IP 做为 Service 的实际 IP,都是 SRV 规则致使的,

因此总结一下,在本地部署 consul Client 的缘由是标识 Service 的实际 IP, 这确实也是逼不得已的方式,若是使用 HTTPDNS 的话,效率不但低,并且算是一个私有协议,不利于和基础环境的融合.