版本1.3.0新特性
1、支持在线维护配置分组；
2、项目groupId从com.xxl迁移至com.xuxueli，为推送maven中央仓库做准备；
3、v1.3.0版本开始，推送公共依赖至中央仓库；
<dependency>
<groupId>com.xuxueli</groupId>
<artifactId>xxl-conf-core</artifactId>
<version>1.3.0</version>
</dependency>
《分布式配置管理平台XXL-CONF》
一、简介
1.1 概述
XXL-CONF 是一个分布式配置管理平台，其核心设计目标是“为分布式业务提供统一的配置管理服务”。现已开放源代码，开箱即用。
1.2 特性
1、简单易用: 上手非常简单, 只需要引入maven依赖和一行配置即可;
2、在线管理: 提供配置管理中心, 支持在线管理配置信息;
3、实时推送: 配置信息更新后, Zookeeper实时推送配置信息, 项目中配置数据会实时更新并生效, 不需要重启线上机器;
4、高性能: 系统会对Zookeeper推送的配置信息, 在Encache中做本地缓存, 在接受推送更新或者缓存失效时会及时更新缓存数据, 因此业务中对配置数据的查询并不存在性能问题;
5、配置备份: 配置数据首先会保存在Zookeeper中, 同时, 在MySQL中会对配置信息做备份, 保证配置数据的安全性;
6、HA: 配置中心基于Zookeeper集群, 只要集群节点保证存活数量大于N/2+1, 就可保证服务稳定, 避免单点风险;
7、分布式: 可方便的接入线上分布式部署的各个业务线, 统一管理配置信息;
8、配置共享: 平台中的配置信息针对各个业务线是平等的, 各个业务线可以共享配置中心的配置信息, 当然也可以配置业务内专属配置信息;
9、配置分组: 支持对配置进行分组管理, 每条配置将会生成全局唯一标示GroupKey,在client端使用时,需要通过该值匹配对应的配置信息;
1.3 背景
why not properties
常规项目开发过程中, 通常会将配置信息位于在项目resource目录下的properties文件文件中, 配置信息通常包括有: jdbc地址配置、redis地址配置、活动开关、阈值配置、黑白名单……等等。使用properties维护配置信息将会导致以下几个问题:
1、需要手动修改properties文件;
2、需要重新编译打包;
3、需要重启线上服务器 (项目集群时,更加令人崩溃) ;
4、配置生效不及时: 因为流程复杂, 新的配置生效需要经历比较长的时间才可以生效;
5、不同环境上线包不一致: 例如JDBC连接, 不同环境需要差异化配置;
why XXL-CONF
1、不需要 (手动修改properties文件) : 在配置管理中心提供的Web界面中, 定位到指定配置项, 输入新的配置的值, 点击更新按钮即可;
2、不需要 (重新编译打包) : 配置更新后, 实时推送新配置信息至项目中, 不需要编译打包;
3、不需要 (重启线上服务器) : 配置更新后, 实时推送新配置信息至项目中, 实时生效, 不需要重启线上机器; (在项目集群部署时, 将会节省大量的时间, 避免了集群机器一个一个的重启, 费时费力)
4、配置生效 "非常及时" : 点击更新按钮, 新的配置信息将会即可推送到项目中, 瞬间生效, 非常及时。比如一些开关类型的配置, 配置变更后, 将会立刻推送至项目中并生效, 相对常规配置修改繁琐的流程, 及时性可谓天壤之别;
5、不同环境 "同一个上线包" : 因为差异化的配置托管在配置中心, 因此一个上线包可以复用在生产、测试等各个运行环境, 提供能效;
1.4 下载
源码地址 (将会在两个git仓库同步发布最新代码)
github地址
git.oschina地址
最新Release版本: v1.3.0 最新Beta版本: v1.3.0
中央仓库地址 (最新Release版本)
<dependency>
<groupId>com.xuxueli</groupId>
<artifactId>xxl-conf-core</artifactId>
<version>1.3.0</version>
</dependency>
