1. 什么是consul？
是一个服务管理软件。
支持多数据中心下，分布式高可用的，服务发现和配置共享。
consul支持健康检查，允许存储键值对。
一致性协议采用 Raft 算法,用来保证服务的高可用.
成员管理和消息广播 采用GOSSIP协议，支持ACL访问控制。
ACL技术在路由器中被广泛采用，它是一种基于包过滤的流控制技术。控制列表通过把源地址、目的地址及端口号作为数据包检查的基本元素，并可以规定符合条件的数据包是否允许通过。
gossip就是p2p协议。他主要要做的事情是，去中心化。
这个协议就是模拟人类中传播谣言的行为而来。首先要传播谣言就要有种子节点。种子节点每秒都会随机向其他节点发送自己所拥有的节点列表，以及需要传播的消息。任何新加入的节点，就在这种传播方式下很快地被全网所知道。
什么是服务注册？
一个服务将其位置信息在“中心注册节点”注册的过程。该服务一般会将它的主机IP地址以及端口号进行注册，有时也会有服务访问的认证信息，使用协议，版本号，以及关于环境的一些细节信息。
什么是服务发现？
当一项服务存在于多个主机节点上时，client端如何决策获取相应正确的IP和port。
在传统情况下，当出现服务存在于多个主机节点上时，都会使用静态配置的方法来实现服务信息的注册。
而当在一个复杂的系统里，需要较强的可扩展性时，服务被频繁替换时，为避免服务中断，动态的服务注册和发现就很重要。
相关开源项目：Zookeeper，Doozer，Etcd，强一致性的项目，这些项目主要用于服务间的协调，同时又可用于服务的注册。
什么是强一致性协议？
按照某一顺序串行执行存储对象读写操作， 更新存储对象之后， 后续访问总是读到最新值。 假如进程A先更新了存储对象，存储系统保证后续A,B,C进程的读取操作都将返回最新值。强一致性模型有几种常见实现方法， 主从同步复制， 以及quorum复制等。
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接口查询失败的节点
9. K/V存储
true
true
结果：[{"CreateIndex":98,"ModifyIndex":101,"Key":"web/key2","Flags":42,"Value":"dGVzdA=="}]
10. 断电恢复outage recover
11. 其他
服务发现是怎么工作呢？
每一个服务发现工具都会提供一套API，使得组件可以用其来设置或搜索数据。正是如此，对于每一个组件，服务发现的地址要么强制编码到程序或容器内部，要么在运行时以参数形式提供。通常来说，发现服务用键值对形式实现，采用标准http协议交互。服务发现门户的工作方式是：当每一个服务启动上线之后，他们通过发现工具来注册自身信息。它记录了一个相关组件若想使用某服务时的全部必要信息。例如，一个MySQL数据库服务会在这注册它运行的ip和端口，如有必要，登录时的用户名和密码也会留下。
当一个服务的消费者上线时，它能够在预设的终端查询该服务的相关信息。然后它就可以基于查到的信息与其需要的组件进行交互。负载均衡就是一个很好的例子，它可以通过查询服务发现得到各个后端节点承受的流量数，然后根据这个信息来调整配置。
这可将配置信息从容器内拿出。一个好处是可以让组件容器更加灵活，并不受限于特定的配置信息。另一个好处是使得组件与一个新的相关服务实例交互时变得简单，可以由管理工具动态进行调整配置。
211
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
