版本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> 博客地址 (将会在两个博客同步更新文档) oschina地址 cnblogs地址 XXL-CONF v1.3.0，分布式配置管理平台下载地址
