统一配置中心的设计方案

3,510 阅读4分钟

对于配置文件,我们不陌生,它提供我们可以动态修改程序运行能力。引用别人的一句话就是:系统运行时(runtime)飞行姿态的动态调整。

我可以把我们的工作称之为在快速飞行的飞机上修理零件。我们人类总是无法掌控和预知一切。对于我们系统来说,我们总是需要预留一些控制线条,以便在我们需要的时候做出调整,控制系统方向(如灰度控制、限流调整),这对于拥抱变化的互联网行业尤为重要。对于单机版,我们称之为配置(文件),对于分布式集群系统,我们称之为配置中心(系统);下面聊聊我们的配置中心。

演进中的配置

当我们是一个单机服务的是,我们的配置通常写在一个文件中的,代码发布的时候,把配置文件和程序推送到机器上去。

当随着业务的用户量增加,通常我们会把我们的服务进行多机器(集群)部署。这时候,配置的发布就变成了如下:

业务的急剧扩张,导致单机服务无法满业务需求。这时候需要对单体大服务进行切开,服务走向SOA(微服务化)。

这种场景中,配置文件的部署可能如上图所示。这样去部署配置简直是一场噩梦,而且无法做到快速的动态的调整。失去了配置主要意义之一。这时候就需要今天说的统一配置中心。

配置中心之简版

首先来看下我们理想中的配置中心需要具备哪些特点。

配置的增删改查

不同环境配置隔离(开发、测试、预发布、灰度/线上)

高性能、高可用性

请求量多、高并发

读多写少

我们可以设计出如下的简版配置中心

设计说明点:

  • 通过OA系统对每一条配置(每一个配置有唯一的配置ID)进行增删改查。

  • 区分不同环境的配置,每个环境同一配置ID对应不同数据库记录。

  • 配置最终以json格式(便于编辑和理解)储存在mysql数据库中。

  • 引入redis集群,做配置的缓存(比如可以设置配置修改后1分钟后生效)

  • 配置对外服务,多机器部署,满足性能需要。

  • 如果有必要,可以引入配置历史修改记录。

很多时候,这样可以基本上满足我们对配置系统的基本需求。

这种设计,由于所有的配置都存放在集中式缓存中,这样集中式的缓存也会有他的性能瓶颈。而且,每次配置的访问都需要发起rpc请求(网络请求),因此考虑在客户端引入本地缓存的选择及其原理(localCache,例如Ehcache)。

配置中心之性能改进

为了提高配置中心的可用性,减少网络请求等因素对性能带来的影响,我们考虑在客户端引入localcache,来解决系统的高可用,高性能、可伸缩性。

相对于第一版的改进点是,在客户端引入localcache。开启线程异步调用配置服务,更新本地配置。这样可以减少rpc调用。

这种方式较为简单,但是存在一个问题,就是一旦用户量大的时候,会增加很多无意义的轮询。因为配置中心的定位就表明了他的修改并不会很多,所以大多数情况下的轮询都是无意义的。会给缓存系统增加很多无谓的压力。

同时,由于各个客户端的拉取时间及网络延迟等都不尽相同,也会存在数据一致性的问题,

配置中心之可用性改进

还好,配置通常都只会有一个入口修改,因此可以考虑在配置修改后,通知应用服务清理本地缓存和分布式缓存。这里可以引入mq或ZooKeeper。

感兴趣的朋友可以了解下阿里巴巴的Diamond,他的工作原理就是这种通过推拉结合的方式,减少不必要的轮询,并且可以降低缓存系统的负载。

声明:本文来自粉丝投稿,Hollis已获得独家授权,并对部分内容做了修改。原作者:林湾村龙猫

- MORE | 更多精彩文章 -

如果你看到了这里,说明你喜欢本文。

那么请长按二维码,关注Hollis

转发朋友圈,是对我最大的支持。