随着业务的发展，应用系统中的配置通常会越来越多，常见的一些应用配置大致会有数据源配置，数据源组件配置，业务组件配置等，对于这类配置都会比较稳定且较少变化，通常会放在文件中随应用一起发布。但实际中会有某些配置信息变化有一定频率和规律，并且希望能够做到尽量实时，比如一些营销类，或活动类应用系统，若使用传统的配置文件，加上重新发布应用可能会有些不方便，因此，才有了分布式配置管理平台，旨在能更好地解决这类问题。本文将介绍相关细节，及一个轻量的开源实现diablo。

分布式配置，也即配置中心。通常有以下的场景或需求，可以需要考虑使用分布式配置：

对于一个可靠的分布式配置平台，大致应该满足一些基本特性，如：

Diablo的架构设计比较简单轻量，如图：

Diablo集群中的Server被视为是对等的，即各节点没有主从(Master/Slave)关系，是逻辑相等的，这样就避免了Master/Slave架构带来的问题，如数据同步延迟，数据丢失等问题。

客户端应用获取配置时，仅会从本地缓存中获取，开发人员在控制台更改配置后，会通知客户端刷新缓冲；

配置平台本身并没有太多复杂的关联关系，因此使用NoSQL也能满足常用的查询。在设计存储Key上，因尽量保证Key的简洁清晰，比如，存储应用记录，可以以apps:1来标识一条记录，而存储结构最好使用hash，而不是使用JSON字符串。在使用Redis时，diablo避免使用了一些特殊函数，如管道，事务等，因为这些函数在一些Redis的高可用解决方案(如Redis Cluster，Redis Proxy等)中通常不支持，这样用户可以自由使用不同的Redis高可用方案。

配置更新实时生效是配置平台的核心功能之一，对于获取配置的方式，大致有两种模式：

diablo使用了特殊Pull模式，即(长轮询)Long Pulling。当客户端发起Http请求后，服务端接收处理完请求，并不会立即返回客户端，而是等待一定条件发生或超时后才返回客户端，这里的一定条件就是当有配置发生变更时，这样就有效减少了客户端请求，也达到了实时生效的目的。对于Java长连接的实现，主要使用了Servlet规范中的AsyncContext，使得服务端接收到请求后，并不会让Servlet容器立即返回客户端，而是当调用AsyncContext.complete()方法时，才会返回。

diablo默认实现了Java语言的客户端，希望以后能支持node，go，python等语言。由于diablo仅通过Http接口提供服务，不同语言只要遵循API接口，即可实现不同的语言版本。若读者有意实现，可参考该客户端规范，下图为客户端与服务端的交互过程：

服务器集群部署：对于一个高可用的服务器集群，建议可以nginx等代理服务器作转发，这样在服务器集群发生变化时，客户端应用也不用更新任何配置，如：

以上，则是有关分布式配置管理平台设计与实现的相关细节，也欢迎issue和fork项目diablo。