服务发现系统consul

1. 什么是consul？

是一个服务管理软件。

支持多数据中心下，分布式高可用的，服务发现和配置共享。

consul支持健康检查，允许存储键值对。

一致性协议采用 Raft 算法,用来保证服务的高可用.

成员管理和消息广播 采用GOSSIP协议，支持ACL访问控制。

ACL技术在路由器中被广泛采用，它是一种基于包过滤的流控制技术。控制列表通过把源地址、目的地址及端口号作为数据包检查的基本元素，并可以规定符合条件的数据包是否允许通过。

gossip就是p2p协议。他主要要做的事情是，去中心化。 

这个协议就是模拟人类中传播谣言的行为而来。首先要传播谣言就要有种子节点。种子节点每秒都会随机向其他节点发送自己所拥有的节点列表，以及需要传播的消息。任何新加入的节点，就在这种传播方式下很快地被全网所知道。

什么是服务注册？

一个服务将其位置信息在“中心注册节点”注册的过程。该服务一般会将它的主机IP地址以及端口号进行注册，有时也会有服务访问的认证信息，使用协议，版本号，以及关于环境的一些细节信息。

什么是服务发现？

服务发现可以让一个应用或者组件发现其运行环境以及其它应用或组件的信息。用户配置一个服务发现工具就可以将实际容器跟运行配置分离开。常见配置信息包括：ip、端口号、名称等。

当一项服务存在于多个主机节点上时，client端如何决策获取相应正确的IP和port。

在传统情况下，当出现服务存在于多个主机节点上时，都会使用静态配置的方法来实现服务信息的注册。

而当在一个复杂的系统里，需要较强的可扩展性时，服务被频繁替换时，为避免服务中断，动态的服务注册和发现就很重要。

相关开源项目：Zookeeper，Doozer，Etcd，强一致性的项目，这些项目主要用于服务间的协调，同时又可用于服务的注册。

什么是强一致性协议？

按照某一顺序串行执行存储对象读写操作， 更新存储对象之后， 后续访问总是读到最新值。 假如进程A先更新了存储对象，存储系统保证后续A,B,C进程的读取操作都将返回最新值。强一致性模型有几种常见实现方法， 主从同步复制， 以及quorum复制等。

http://blog.csdn.net/shlazww/article/details/38736511

2. consul的具体应用场景

1. docker、coreos 实例的注册与配置共享

2. vitess集群

3. SaaS应用的配置共享

4.与confd服务集成，动态生成nignx与haproxy配置文件

3. 优势

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协议接口

4. 安装

我的是mac os x

通过工具安装：

brew cask install consul

brew cask安装也很方便

http://brew.sh/#install

5. 测试 与 运行consul

测试

consul

以服务端形式运行consul

consul agent -server -bootstrap-expect 1 -data-dir /tmp/consul

consul members

查看consul服务节点

将http请求发给consul server

$ curl localhost:8500/v1/catalog/nodes
[{"Node":"Armons-MacBook-Air","Address":"10.1.10.38"}]

6. 注册服务

1. 创建文件夹/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命令来生效

7. 组建集群

一个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 \
    -bind=172.20.20.11

这个时候，应用consul members 进行查询，两个consul node分别是独立，没有什么关联。

将client加入到server 集群中

vagrant@n1:~$ consul join 172.20.20.11

再用consul members查询，就发现多了一个node节点。

这样手动

加入新节点太麻烦，而较好的方法就将节点配置成自动加入集群

 consul agent -atlas-join \
  -atlas=ATLAS_USERNAME/infrastructure \

  -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

8. 查询健康状态

 curl http://localhost:8500/v1/health/state/critical    // 应用http接口查询失败的节点

对于失败的节点，应用DNS查询时，是无法拿到返回结果的

dig @127.0.0.1 -p 8600 web.service.consul

9. K/V存储

consul还提供了键/值存储的功能。

如 查询 所有K/V

curl -v http://localhost:8500/v1/kv/?recurse

保存键为web/key2, flags 为42， 值为true的记录。

curl -X PUT -d 'test' http://localhost:8500/v1/kv/web/key2?flags=42
true

删除记录：

curl -X DELETE http://localhost:8500/v1/kv/web/sub?recurse

更新值：

curl -X PUT -d 'newval' http://localhost:8500/v1/kv/web/key1?cas=97
true

更新index：

curl "http://localhost:8500/v1/kv/web/key2?index=101&wait=5s"

结果：[{"CreateIndex":98,"ModifyIndex":101,"Key":"web/key2","Flags":42,"Value":"dGVzdA=="}]

更详细的consul命令详解：

http://m.oschina.net/blog/353392

10. 断电恢复outage recover

当有一台服务器不可用时，处理的方法有：

1. 对服务器进恢复，然后重新上线

2. 用新服务器，替代旧的consul服务器

这两种方式都需要将服务器ip与原来的ip相同。

3. 添加新的服务器，而ip无需与原来的相同。步骤： 停掉所有的consul服务器，将损坏的服务器ip从raft/peer.json中移除，重启其他服务器，并将新的服务器加入集群。

11. 其他

========== 转载一小段别人的总结 ==========

服务发现是怎么工作呢？

每一个服务发现工具都会提供一套API，使得组件可以用其来设置或搜索数据。正是如此，对于每一个组件，服务发现的地址要么强制编码到程序或容器内部，要么在运行时以参数形式提供。通常来说，发现服务用键值对形式实现，采用标准http协议交互。

服务发现门户的工作方式是：当每一个服务启动上线之后，他们通过发现工具来注册自身信息。它记录了一个相关组件若想使用某服务时的全部必要信息。例如，一个MySQL数据库服务会在这注册它运行的ip和端口，如有必要，登录时的用户名和密码也会留下。

当一个服务的消费者上线时，它能够在预设的终端查询该服务的相关信息。然后它就可以基于查到的信息与其需要的组件进行交互。负载均衡就是一个很好的例子，它可以通过查询服务发现得到各个后端节点承受的流量数，然后根据这个信息来调整配置。

这 可将配置信息从容器内拿出 。一个好处是可以让组件容器更加灵活，并不受限于特定的配置信息。另一个好处是使得组件与一个新的相关服务实例交互时变得简单， 可以由管理工具动态进行调整配置 。