场景
- 我的服务相互依赖，而且数量较多，需要有合适的机制解决繁杂的配置文件配置问题
- 我要架设微服务架构，需要一个服务注册中心，需要一个较为完善的服务发现的机制
上面是我找到consul的原因
什么是consul
官网的一句话总结里面有这么几个关键词:
- 服务发现
- 简化配置
- 分布式(去中心化)
- 高可用
- 多数据中心
在github上，consul给出了这么几个关键特性：
- 服务发现
- 健康检查
- 键值存储
- 多数据中心支持
以上便是我对cosnul的初步印象
consul的架构
这里简单说明consul几个方言：
Agent：Consul集群中长时间运行的守护进程，以consul agent 命令开始启动. 在客户端和服务端模式下都可以运行，可以运行DNS或者HTTP接口， 它的主要作用是运行时检查和保持服务同步
Client: 客户端, 无状态, 消耗极少的资源，将接口请求转发给局域网内的服务端集群
server: 服务端, 保存配置信息, 高可用集群, 在局域网内与本地客户端通讯, 通过广域网与其他数据中心通讯. 每个数据中心的 server 数量推荐为 3 个或是 5 个
Datacenter: 数据中心，多数据中心联合工作保证数据存储安全快捷
Consensus：一致性协议使用的是Raft Protocol
Gossip: consul是基于serf构建的, serf使用gossip protocol来实现各种特性
LAN Gossip: 包含了同一局域网所有内节点的gossip池
WAN Gossip: 广域网中由Server组成的gossip池
RPC： 远程过程调用
对于consul的详细理解，可以参考官方文档
总结为以下几点：
- 如图所示，consul支持多数据中心
- 每个数据中心由server和client组成。server推荐由3～5个节点组成(基于可用性和性能的平衡),节点越多, 数据恢复一致周期越长，但是节点无数量限制, 横向拓展非常方便
- 所有节点基于gossip protocol加入集群。即一个数据中心就是一个gossip池，这么做有以下几个目的
- 不需要给clent配置server地址，自动化服务发现（关于这点我还比较疑惑）
- 所有节点能做到相互故障感知，比传统的心跳机制更容易拓展到更大集群规模
- gossip protocol做为一个消息层传递重大消息，例如lead election
- server节点也是wan_goosip池的成员，wan_gossip与lan_gossip的区别是wan_gossip做了高网络延迟的相关优化。wan_gossip的目的是让多个数据中心互相感知，同时添加一个新的数据中心就像添加一个节点到wan_gossip池中一样简单。也因为所有server再同一gossip池中，所以能轻松实现跨数据中心请求
与同类型的产品相比较，consul有哪些优势
同类工具有以下这些
- 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.
- Doozerd A consistent distributed data store.
相同点
- 架构类似，都有服务节点，而这些服务节点的操作都要求达到节点的仲裁数（通常，节点的仲裁数遵循的是简单多数原则
- 强一致性，用于构建复杂的分布式系统
不同点
- 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和其他的工具来比，一方面提供了完整的工具集让降低了使用的工作量成本，另一方面在作为一个服务注册发现中心，自身有相对完善的机制，确实是中小型团队的推荐方案。
更多关于工具的对比，参考下面
官网链接，主要看这个就够了
服务发现 zookeeper ,consul ,etcd 的一些比较(文中表格有参考价值)
工具成熟程度
技术背景
技术支撑
HashiCorp是一家企业级服务公司，公司致力于革命性的数据中心管理技术研发，让开发者通过一个工具就来构建完整的开发环境，提高开发效率。这里是他们的开源项目列表。
consul的技术支撑来自这里，目前github star已拥有8600+，算是比较优质的项目了
国内使用情况
consul是新东西，加上真的贯彻微服务架构的公可能没那么多，感觉好像没有太多人用，但是随便一搜总能搜到一些公司的技术分享用到了consul,比如这个，还有这个（挺潮的，ansible,consul,docker）等等，大家都开始陆陆续续的踩坑了。现在看来也不至于新到没人用
LTS
目前consul还处于0.x的状态，更新的速度并不快，简单来讲，这个工具还处于试水阶段。虽然是0.7（目前是0.7.5），但是发布过30个版本了。所以也不算是第一批入坑的人，这里作为一个已经使用过consul的“司机”，我觉得consul还是很好用的，目前没遇到过什么根本无法解决，或者是需要等更新才能解决的难题，可能我使用的功能相对简单，但是如果根据28原则来看，这些功能真的够了
目前没有看到相关的LTS计划，包括版本升级之类的，真的要升级，还是要多看release文档，多测试。
社区
文档
这是目前我觉得最蛋疼的事情了，少有优质中文setup文档，这也是我刚开始接触consul的时候，感觉最痛苦的地方，下一篇会写consul入门文章。
学习的整体思路还是先看官网，注意消化理解，然后setup，遇到问题stackoverflow，最后提issue，这是目前我学习任何一门新的开源工具的实(tao)践(lu)。
社区
没有中文社区，可能能在go中文社区，docker中文社区等周边社区看到consul的影子，stackoverflow find by tags: consul 357, consul-template 31，作为新生一代的服务注册发现工具，社区方面还有待提高
总结
社区方面可能是consul目前看来的缺点吧
投入回报比
使用成本
安装
consul的安装很简单，下载然后解压就行了一个可执行文件搞定一切，安装文档
配置
配置相对于安装要复杂一些，这里是完整的配置选项。个人觉得搭建consul集群可能首面临的问题是要规划一个集群环境，当然这个通过docker做也比较方便，关于配置，在下一篇文章中会重点描述
学习成本
consul的使用是比较简单的，就是简单的http，dns等API调用，非常方便，简单易用。
长期/短期利益衡量
这个主要就是看具体情景了，如果不是特别需要用到其他的服务注册发现工具，我觉得consul是一个不错的低成本选择。所以从短期利益来看，用这个很快，基本的功能很全，能分分钟造出来火箭；从长远角度看目前确实个人评估能力有限，暂时考虑不到。
对当前工作流的影响
这个确实对开发主要影响体现在现在使用网络接口获取配置，跟原来使用配置文件的方式不太一样了。尤其是node程序，举个简单的例子，还是有很多人在用express的时候，启动文件和应用程序配置文件(app.js)没有分开，这样的话想要在启动主程序之前做一些初始化的工作，就得改点东西了，如果用临时的方式处理（把app.js包在初始化配置的会掉函数中），可能没那么优雅
总结
以上对比的与consul相关的工具可能就是一个分布式kv系统，而consul提供的是一套fullstack的工具集合。从某种程度来说，consul提供的每一个小的工具，都是一个最佳实践，再有这些小的最佳实践组成一个健全的工具集合，暴露出简单的API给client。如果没有特别的需要必须使用其他工具（例如使用Hadoop的话可能会选择zookeeper），或者是没有那么极客必须要自己去构建一个完善的注册发现系统，consul确实一个非常不错的选择。