亲宝软件园·资讯

展开

Disconf分布式配置管理

kl 人气:0

技术背景

在一个分布式环境中,同类型的服务往往会部署很多实例。这些实例使用了一些配置,为了更好地维护这些配置就产生了配置管理服务。通过这个服务可以轻松地管理成千上百个服务实例的配置问题。

王阿晶提出了基于zooKeeper的配置信息存储方案的设计与实现[1], 它将所有配置存储在zookeeper上,这会导致配置的管理不那么方便,而且他们没有相关的源码实现。淘宝的diamond[2]是淘宝内部使用的一个管理持久配置的系统,它具有完整的开源源码实现,它的特点是简单、可靠、易用,淘宝内部绝大多数系统的配置都采用diamond来进行统一管理。他将所有配置文件里的配置打散化进行存储,只支持KV结构,并且配置更新的推送是非实时的。百度内部的BJF配置中心服务[3]采用了类似淘宝diamond的实现,也是配置打散化、只支持KV和非实时推送。

同构系统是市场的主流,特别地,在业界大量使用部署虚拟化(如JPAAS系统,SAE,BAE)的情况下,同一个系统使用同一个部署包的情景会越来越多。但是,异构系统也有一定的存在意义,譬如,对于“拉模式”的多个下游实例,同一时间点只能只有一个下游实例在运行。在这种情景下,就存在多台实例机器有“主备机”模式的问题。目前国内并没有很明显的解决方案来统一解决此问题。

功能特点与设计理念

disconf是一套完整的基于zookeeper的分布式配置统一解决方案。

功能特点

支持配置(配置项+配置文件)的分布式化管理

配置异构系统管理

注解式编程,极简的使用方式:我们追求的是极简的、用户编程体验良好的编程方式。通过简单的标注+极简单的代码撰写,即可完成复杂的配置分布式化。

需要Spring编程环境

设计理念

简单,用户体验良好:

可以托管任何类型的配置文件,这与[2,3]只能支持KV结构的功能有较大的改进。

配置更新实时推送

提供界面良好Web管理功能,可以非常方便的查看配置被哪些实例使用了。

详细设计

架构设计

disconf服务集群模式:

disconf的模块架构图:

每个模块的简单介绍如下:

流程设计

运行流程详细介绍:

与2.0版本的主要区别是支持了:主备分配功能/主备切换事件。

模块实现

disconf-web提供了前后端分离的web架构,具体可见:https://github.com/knightliao/disconf/tree/master/disconf-web

本部分会重点介绍disconf-client的实现方式。

注解式disconf实现

本实现会涉及到 配置仓库容器模块、扫描模块、下载模块、watch模块,

使用AOP拦截的一个好处是可以比较轻松的实现配置控制,比如并发环境下的配置统一生效。

特别地,本方式提供的编程模式非常简单,例如使用以下配置类的程序在使用它时,可以直接@Autowired进来进行调用,使用它时就和平常使用普通的JavaBean一样,但其实它已经分布式化了。配置更新时,配置类亦会自动更新。

@Service
@DisconfFile(filename = "redis.properties")
public class JedisConfig {
    // 代表连接地址
    private String host;
    // 代表连接port
    private int port;
    /**
     * 地址, 分布式文件配置
     * 
     * @return
     */
    @DisconfFileItem(name = "redis.host", associateField = "host")
    public String getHost() {
        return host;
    }
    public void setHost(String host) {
        this.host = host;
    }
    /**
     * 端口, 分布式文件配置
     * 
     * @return
     */
    @DisconfFileItem(name = "redis.port", associateField = "port")
    public int getPort() {
        return port;
    }
    public void setPort(int port) {
        this.port = port;
    }
}

基于XML配置disconf实现

本实现提供了无任何代码侵入方式的分布式配置。

ReloadablePropertiesFactoryBean继承了Spring Properties文件的PropertiesFactoryBean类,管理所有当配置更新时要进行reload的配置文件。对于被管理的每一个配置文件,都会通过 配置仓库容器模块、扫描模块、下载模块、watch模块 进行配置获取至配置仓库里。

ReloadingPropertyPlaceholderConfigurer继承了Spring Bean配置值控制类PropertyPlaceholderConfigurer。在第一次扫描spring bean 时,disconf会记录配置文件的配置与哪些bean有关联。

ReloadConfigurationMonitor是一个定时任务,定时check本地配置文件是否有更新。

当配置中心的配置被更新时,配置文件会被下载至实例本地,ReloadConfigurationMonitor即会监控到此行为,并且通知 ReloadingPropertyPlaceholderConfigurer 对相关的bean类进行值更新。

特别的,此种方式无法解决并发情况下配置统一生效的问题。

主备分配实现

在实现中,为每个配置提供主备选择的概念。用户实例在获取配置前需要先进行全局唯一性竞争才能得到配置值。在这里,我们采用基于zookeeper的全局唯一性锁来实现。

COMPARISONS

 淘宝Diamond[2]Disconf比较
数据持久性存储在mysql上存储在mysql上都持久化到数据库里,都易于管理
推拉模型拉模型,每隔15s拉一次全量数据基于Zookeeper的推模型,实时推送disconf基于分布式的Zookeeper来实时推送,不断是在稳定性、实效性、易用性上均优于diamond
配置读写支持实例对配置读写。支持某台实例写配置数据,并广播到其它实例上只支持实例对配置读。通过在disconf-web上更新配置到达到广播写到所有应用实例从目前的应用场景来看,实例对配置的写需求不是那么明显。disconf支持的中心化广播方案可能会与人性思考更加相似。
容灾多级容灾模式,配置数据会dump在本地,避免中心服务挂机时无法使用多级容灾模式,优先读取本地配置文件。双方均支持在中心服务挂机时配置实例仍然可以使用
配置数据模型只支持KV结构的数据,非配置文件模式支持传统的配置文件模式(配置文件),亦支持KV结构数据(配置项)使用配置文件的编程方式可能与程序员的编程习惯更为相似,更易于接受和使用。
编程模型需要将配置文件拆成多个配置项,没有明显的编程模型在使用配置文件的基础上,提供了注解式和基于XML的两种编程模型
并发性多条配置要同时生效时,无法解决并发同时生效的问题基于注解式的配置,可以解决并发性问题

加载全部内容

相关教程
猜你喜欢
用户评论