Kivi

没有什么远大理想,只是永远都不会满足而已


  • 首页

  • 关于

  • 标签

  • 归档

consul调研

发表于 2017-03-08 更新于 2017-07-02 分类于 consul 阅读次数:
本文字数: 3.7k 阅读时长 ≈ 3 分钟

场景

  • 我的服务相互依赖,而且数量较多,需要有合适的机制解决繁杂的配置文件配置问题
  • 我要架设微服务架构,需要一个服务注册中心,需要一个较为完善的服务发现的机制

上面是我找到consul的原因

什么是consul

官网的一句话总结里面有这么几个关键词:

  • 服务发现
  • 简化配置
  • 分布式(去中心化)
  • 高可用
  • 多数据中心

在github上,consul给出了这么几个关键特性:

  • 服务发现
  • 健康检查
  • 键值存储
  • 多数据中心支持

以上便是我对cosnul的初步印象

consul的架构

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确实一个非常不错的选择。

# consul # 微服务 # 注册发现
mongodb常见Q&A整理
consul简单集群搭建
  • 文章目录
  • 站点概览
kivi

kivi

nodejs | server
58 日志
17 分类
32 标签
RSS
  1. 1. 场景
  2. 2. 什么是consul
  3. 3. consul的架构
  4. 4. 与同类型的产品相比较,consul有哪些优势
    1. 4.1. 同类工具有以下这些
    2. 4.2. 相同点
    3. 4.3. 不同点
    4. 4.4. 总结
    5. 4.5. 更多关于工具的对比,参考下面
  5. 5. 工具成熟程度
    1. 5.1. 技术背景
      1. 5.1.1. 技术支撑
      2. 5.1.2. 国内使用情况
    2. 5.2. LTS
    3. 5.3. 社区
      1. 5.3.1. 文档
      2. 5.3.2. 社区
      3. 5.3.3. 总结
  6. 6. 投入回报比
    1. 6.1. 使用成本
      1. 6.1.1. 安装
      2. 6.1.2. 配置
    2. 6.2. 学习成本
    3. 6.3. 长期/短期利益衡量
    4. 6.4. 对当前工作流的影响
  7. 7. 总结
© 2019 kivi | 173k | 2:37
由 Hexo 强力驱动 v3.9.0
|
主题 – NexT.Pisces v7.3.0
|