我的架构之路 — 配置中心(一)—简单实用的配置中心

  1. 云栖社区>
  2. 博客>
  3. 正文

我的架构之路 — 配置中心(一)—简单实用的配置中心

coolma2000 2017-12-09 01:59:41 浏览9040
展开阅读全文

离开淘宝,我没有去处于风口的摩拜,而是加入了铁甲网,可能也是一种中庸之道吧。不过铁甲竟然也搬家到了亮马桥河畔,不远处就是摩拜。
到铁甲第一个项目就是搭建一个配置中心,实现配置的统一管理,实现配置的动态更新,初步要求就是尽快出来,简单、稳定。

淘宝有diamond,但没有开源(内部绑定太多,很早之前有个开源版本),否决了;百度有disconf,但需要mysql、redis、zookeper、nginx 一堆东西,好吧,经过讨论,咱是要一个简单好用的配置管理,那就pass掉吧。

于是又到GitHub找了个开源项目superdiamond,搭建了一个初步的配置中心demo。实现原理是客户端通过netty连接到配置中心实时获得配置信息。参考界面如下:

image

image

但接着发现有些问题要考虑:
1、如果配置中心当掉,会导致客户端取不到配置;
2、如果网络断掉,最新配置无法同步到客户端,服务器端还需要记住这些数据,并进行重新发送尝试。维护各个端的状态信息感觉比较麻烦。
3、配置中心多台机器如何互相同步

所以,最终的想法是,自己重头开发一个简单稳定的配置中心。

主要的改造是:客户端不从配置中心读取配置,而是定时连接mysql读取数据。这就有个前提,mysql是稳定的,当然,mysql如果不稳定,那业务系统也就无法用了,谈配置中心也没意义了。

image

1)开发者还是通过配置中心界面来修改配置信息,配置修改后修改时间字段也会更新。但配置的下发不再是实时推送到客户端的方式,而是由客户端去mysql拉取。

2)客户端应用启动的时候,第一次会从mysql拉取本应用全部的配置,如果成功,同时本地保存一份配置;如果尝试3次都失败,则从本地备份目录读取配置。

3)mysql后面则每隔20秒去拉取最新的配置(客户端每次拉取后需要记录最大的时间,下次以此时间为起点去拉取变化的配置)

总体上,这种设计方案比较简单实用,只对mysql有强依赖,对配置中心本身没有强依赖,即配置中心当掉后取配置还照样转。

网友评论

登录后评论
0/500
评论
coolma2000
+ 关注