配置中心那点事

2016-11-23 14:12:05

配置中心怎么做

  • 配置分发,实现有两种方式
    推:实时性变更,需要应用和配置中心保持长连接,复杂度高
    拉:实时性相对差,没有增量更新机制会增加配置中心压力,复杂度低
  • 订阅和发布
    支持配置变更通知,如果是推送,server把每次变更实时发送给订阅客户端
    如果是拉取,则通过比较client和server的数据md5来实现有效变更通知。server会下发数据和md5给client,client请求的时候会带上md5,假如md5变化,则server重新下发,否则无需变更,返回”无变更”
  • 多环镜、集群配置管理
    同一份程序在不同的环境(开发,测试,生产)、不同的集群(如不同的数据中心)经常需要有不同的配置,所以需要有完善的环境、集群配置管理
  • 权限控制和操作审计:配置能改变程序的行为,需要有完善的权限控制,以防错误的配置引起的故障。变更操作都要有审计日志,可以方便的追踪问题
  • 版本管理
    所有的配置发布都有版本概念,从而可以方便的支持配置的回滚
  • 支持灰度发布
    支持配置的灰度发布,比如点了发布后,只对部分应用实例生效,等观察一段时间没问题后再推给所有应用实例,两种解决方案:
    a.配置项增加一个host属性,表示这个配置项只“发布”给某些IP
    b.定义一个优先级,客户端优先加载本地配置文件,这样如果某些机器上的应用需要特殊配置,那么可以采用老的方式上去修改其本地配置文件
  • 支持降级
    非核心服务降级开关。发生问题时,降级服务的非核心服务
  • 同时支持web页面和Restful API接口
  • 支持多语言,支持php这种无状态语言
  • 支持容错性,当server出现问题时,不影响client的运行
  • 支持本地缓存,减少每次获取配置项时与server的网络消耗,仅server更新时通知client

客户端怎么支持

  • 配合配置中心的推送,在参数变化时调用客户端自行实现的回调接口,不需要重启应用
  • 支持环境变量,JVM启动参数,配置文件,配置中心等多种来源按优先级互相覆盖,并有接口暴露最后的参数选择
  • 配置文件中支持多套profile,如开发,单元测试,集成测试,生产

开源解决方案现状

开源之外呢?
应该说最好的配置中心还是在各个互联网公司的基础架构部里,虽然不是完美,虽然修修补补,常见的两种玩法

  • 一种玩法是基于zk和etcd,一般支持界面和api,用数据库来保存版本历史,预案,走流程,最后下发到zk或etcd这种有推送能力的存储里(服务注册本身也是用zk或etcd,选型就一块了)。客户端都直接和zk或etcd打交道
    灰度发布麻烦些,其中一种实现是同时发布一个可接收的IP列表,客户端监听到配置节点变化时,对比一下自己是否属于该列表
    PHP这种无状态的语言和其他zk/etcd不支持的语言,只好自己在客户端的机器上起一个Agent来监听变化,再写到配置文件或Share Memory了

  • 另一种玩法是基于运维自动化的配置文件的推送,一样有数据库与界面或API来管理配置,下发时生成配置文件,基于各种运维自动化工具如Puppet,Ansible推送到每个客户端。而应用则定时重新读取这个外部的配置文件

ref
一篇好TM长的关于配置中心的文章
服务化体系之-配置中心,在ZK或etcd之外
开源分布式配置中心选型


您的鼓励是我写作最大的动力

俗话说,投资效率是最好的投资。 如果您感觉我的文章质量不错,读后收获很大,预计能为您提高 10% 的工作效率,不妨小额捐助我一下,让我有动力继续写出更多好文章。