场景
- 我的服务相互依赖,而且数量较多,需要有合适的机制解决繁杂的配置文件配置问题
- 我要架设微服务架构,需要一个服务注册中心,需要一个较为完善的服务发现的机制
上面是我找到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确实一个非常不错的选择。