是一个服务管理软件。
支持多数据中心下,分布式高可用的,服务发现和配置共享。
consul支持健康检查,允许存储键值对。
一致性协议采用 Raft 算法,用来保证服务的高可用.
成员管理和消息广播 采用GOSSIP协议,支持ACL访问控制。
ACL技术在路由器中被广泛采用,它是一种基于包过滤的流控制技术。控制列表通过把源地址、目的地址及端口号作为数据包检查的基本元素,并可以规定符合条件的数据包是否允许通过。
gossip就是p2p协议。他主要要做的事情是,去中心化。
这个协议就是模拟人类中传播谣言的行为而来。首先要传播谣言就要有种子节点。种子节点每秒都会随机向其他节点发送自己所拥有的节点列表,以及需要传播的消息。任何新加入的节点,就在这种传播方式下很快地被全网所知道。
什么是服务注册?
一个服务将其位置信息在“中心注册节点”注册的过程。该服务一般会将它的主机IP地址以及端口号进行注册,有时也会有服务访问的认证信息,使用协议,版本号,以及关于环境的一些细节信息。什么是服务发现?
当一项服务存在于多个主机节点上时,client端如何决策获取相应正确的IP和port。
在传统情况下,当出现服务存在于多个主机节点上时,都会使用静态配置的方法来实现服务信息的注册。
而当在一个复杂的系统里,需要较强的可扩展性时,服务被频繁替换时,为避免服务中断,动态的服务注册和发现就很重要。
相关开源项目:Zookeeper,Doozer,Etcd,强一致性的项目,这些项目主要用于服务间的协调,同时又可用于服务的注册。
什么是强一致性协议?
按照某一顺序串行执行存储对象读写操作, 更新存储对象之后, 后续访问总是读到最新值。 假如进程A先更新了存储对象,存储系统保证后续A,B,C进程的读取操作都将返回最新值。强一致性模型有几种常见实现方法, 主从同步复制, 以及quorum复制等。1. docker、coreos 实例的注册与配置共享
2. vitess集群
3. SaaS应用的配置共享
4.与confd服务集成,动态生成nignx与haproxy配置文件
1. 使用 Raft 算法来保证一致性,比poxes算法更直接。zookeeper采用的时poxes算法。
Raft大概将整个过程分为三个阶段,leader election,log replication和commit(safety)。
每个server处于三个状态:leader,follower,candidate。正常情况下,所有server中只有一个是leader,其它的都是follower。server之间通过RPC消息通信。follower不会主动发起RPC消息。leader和candidate(选主的时候)会主动发起RPC消息。
首先选择一个leader全权负责管理日志复制,leader从客户端接收log entries,将它们复制给集群中的其它机器,然后负责告诉其它机器什么时候将日志应用于它们的状态机。举个例子,leader可以在无需询问其它server的情况下决定把新entries放在哪个位置,数据永远是从leader流向其它机器。一个leader可以fail或者与其他机器失去连接,这种情形下会有新的leader被选举出来。
http://www.jdon.com/artichect/raft.html
http://blog.csdn.net/cszhouwei/article/details/38374603
2. 支持多数据中心,内外网的服务采用不同的端口进行监听。这样可以避免单点故障。
zookeeper等不支持多数据中心功能的支持
3. 支持健康检查
4. 提供web界面
5. 支持http协议与dns协议接口
我的是mac os x
通过工具安装:
brew cask install consul
brew cask安装也很方便
http://brew.sh/#install
测试
consul
以服务端形式运行consul
consul agent -server -bootstrap-expect 1 -data-dir /tmp/consul
consul members
查看consul服务节点
将http请求发给consul server
$ curl localhost:8500/v1/catalog/nodes1. 创建文件夹/etc/consul.d
.d代表有许多配置文件在里面
2. 将服务配置文件写入文件夹内
如 $ echo '{"service": {"name": "web", "tags": ["rails"], "port": 80}}' >/etc/consul.d/web.json
3. 重启consul,并将配置文件的路径给consul
$ consul agent -server -bootstrap-expect 1 -data-dir /tmp/consul -config-dir /etc/consul.d
4. 查询ip和端口
DNS方式:dig @127.0.0.1 -p 8600 web.service.consul SRV
Http方式:curl http://localhost:8500/v1/catalog/service/web
5. 更新
通过http api能对service配置文件增删改查,如果更新完成后,可以通过signup命令来生效
一个consul agent就是一个独立的程序。一个长时间运行的守护进程,运行在concul集群中的每个节点上。
启动一个consul agent ,只是启动一个孤立的node,如果想知道集群中的其他节点,应该将consul agent加入到集群中去 cluster。
agent有两种模式:server与client。server模式包含了一致性的工作:保证一致性和可用性(在部分失败的情况下),响应RPC,同步数据到其他节点代理。
client 模式用于与server进行通信,转发RPC到服务的代理agent,它仅保存自身的少量一些状态,是非常轻量化的东西。本身是相对无状态的。
agent除去设置server/client模式、数据路径之外,还最好设置node的名称和ip。
一张经典的consul架构图片:
LAN gossip pool包含了同一局域网内所有节点,包括server与client。这基本上是位于同一个数据中心DC。
WAN gossip pool一般仅包含server,将跨越多个DC数据中心,通过互联网或广域网进行通信。
Leader服务器负责所有的RPC请求,查询并相应。所以其他服务器收到client的RPC请求时,会转发到leader服务器。
第一,没有必要配置客户端与服务器的地址; 发现是自动完成的。 第二,检测节点故障的工作不放置在服务器上,但被分布。 这使得故障检测比天真的心跳方案更具扩展性。 第三,它是作为一个消息层通知时,重要事件,如leader选举举行。
安装vagrant, sudo vagrant init 初始化vagrant环境。
vagrant up 启动一个虚拟node节点
vagrant status 查看vm启动的状态,包括vm的名称
vagrant ssh vm_name 登陆到vm节点
bootstrap的模式,该模式node可以指定自己作为leader,而不用进行选举。然后再依次启动其他server,配置为非bootstrap的模式。最后把第一个serverbootstrap模式停止,重新以非bootstrap模式启动,这样server之间就可以自动选举leader。
分别在两个vm上配置consul agent,如
$ vagrant ssh n1
vagrant@n1:~$ consul agent -server -bootstrap-expect 1 \-data-dir /tmp/consul -node=agent-one -bind=172.20.20.10
$ vagrant ssh n2 vagrant@n2:~$ consul agent -data-dir /tmp/consul -node=agent-two \这个时候,应用consul members 进行查询,两个consul node分别是独立,没有什么关联。
将client加入到server 集群中
vagrant@n1:~$ consul join 172.20.20.11
再用consul members查询,就发现多了一个node节点。
这样手动
加入新节点太麻烦,而较好的方法就将节点配置成自动加入集群
consul agent -atlas-join \-atlas-token="YOUR_ATLAS_TOKEN"
离开集群
ctrl+c,或者 kill 指定的agent进程,就可以将相关的agent推出集群
让consul 运行起来。consul server推荐至少在3~5个之间,推荐的方法是一开始启动其中一台server,并且配置到bootstrap的模式,该模式node可以指定自己作为leader,而不用进行选举。然后再依次启动其他server,配置为非bootstrap的模式。最后把第一个serverbootstrap模式停止,重新以非bootstrap模式启动,这样server之间就可以自动选举leader。
http://www.bubuko.com/infodetail-800623.html
curl http://localhost:8500/v1/health/state/critical // 应用http接口查询失败的节点