Release Notes
1、轻量级改造：废弃ZK，改为 "DB + 磁盘 + long polling" 方案，部署更轻量，学习更简单；集群部署更方便，与单机一致；
2、pom依赖清理、升级；客户端唯一依赖组件为 "slf4j-api"，彻底的零依赖。配置中心升级部分依赖；
3、Docker基础镜像切换，精简镜像；
4、高性能：得益于配置中心的 "磁盘配置" 与客户端的 "LocalCache"，因此配置服务性能非常高；单机可承担大量配置请求；
5、跨语言：底层通过http服务（long-polling）拉取配置数据并实时感知配置变更，从而实现多语言支持。
6、访问令牌（accessToken）：为提升系统安全性，配置中心和客户端进行安全性校验，双方AccessToken匹配才允许通讯；
7、启动时，优先全量加载镜像数据到registry层，避免逐个请求耗时；
简介
XXL-CONF 是一个轻量级分布式配置管理平台，拥有"轻量级、秒级动态推送、多环境、多语言、配置监听、权限控制、版本回滚"等特性。现已开放源代码，开箱即用。
特性
1、简单易用: 接入灵活方便，一分钟上手；
2、轻量级: 部署简单，不依赖第三方服务，一分钟上手；
3、配置中心HA：配置中心支持集群部署，提升配置中心系统容灾和可用性。
4、在线管理: 提供配置中心, 通过Web界面在线操作配置数据，直观高效；
5、多环境支持：单个配置中心集群，支持自定义多套环境，管理多个环境的的配置数据；环境之间相互隔离；
6、多数据类型配置：支持多种数据类型配置，如：String、Boolean、Short、Integer、Long、Float、Double 等；
7、跨语言：底层通过http服务（long-polling）拉取配置数据并实时感知配置变更，从而实现多语言支持。
8、高性能：得益于配置中心的 "磁盘配置" 与客户端的 "LocalCache"，因此配置服务性能非常高；单机可承担大量配置请求；
9、实时性: 秒级动态推送；配置更新后, 实时推送配置信息, 项目中配置数据会实时更新并生效, 不需要重启线上机器;
10、配置变更监听功能：可开发Listener逻辑，监听配置变更事件，可据此动态刷新JDBC连接池等高级功能；
11、最终一致性：底层借助内置广播机制，保障配置数据的最终一致性，从而保证配置数据的同步；
12、配置备份: 配置数据同时在磁盘与MySQL中存储和备份，并定期同步， 提高配置数据的安全性;
13、多种获取配置方式：支持 "API、 注解、XML占位符" 等多种方式获取配置，可灵活选择使用；
14、兼容Spring原生配置：兼容Spring原生配置方式 "@Value"、"${}" 加载本地配置功能；与分布式配置获取方式隔离，互不干扰；
15、分布式: 支持多业务线接入并统一管理配置信息，支撑分布式业务场景;
16、项目隔离: 以项目为维度管理配置, 方便隔离不同业务线配置;
17、高性能: 通过LocalCache对配置数据做缓存, 提高性能;
18、客户端断线重连强化：设置守护线程，周期性检测客户端连接、配置同步，提高异常情况下配置稳定性和时效性；
19、空配置处理：主动缓存null或不存在类型配置，避免配置请求穿透到远程配置Server引发雪崩问题；
20、用户管理：支持在线添加和维护用户，包括普通用户和管理员两种类型用户；
21、配置权限控制；以项目为维度进行配置权限控制，管理员拥有全部项目权限，普通用户只有分配才拥有项目下配置的查看和管理权限；
22、历史版本回滚：记录配置变更历史，方便历史配置版本回溯，默认记录10个历史版本；
23、配置快照：客户端从配置中心获取到的配置数据后，会周期性缓存到本地快照文件中，当从配置中心获取配置失败时，将会使用使用本地快照文件中的配置数据；提高系统可用性；
24、访问令牌（accessToken）：为提升系统安全性，配置中心和客户端进行安全性校验，双方AccessToken匹配才允许通讯；
引用来自“prelove88”的评论
惊喜来得太快了，说干就干，这速度！！！👍👍👍引用来自“许雪里”的评论
废弃ZK其实有得有失，不过决定了就是要干：https://github.com/xuxueli/xxl-conf/issues/60引用来自“就像风”的评论
为什么废弃zk推送就会从毫秒级变成秒级？ #DuiC# 依然可以做到毫秒级推送。引用来自“许雪里”的评论
因为 XXL-CONF 定位不同，线上公司接入也有一些了，个别公司配置数量很小但是非常多。所以迭代方向是：支持海量配置，多机房集群部署。
你提到的这个看了一下，其他特性还不错，但是数据放内存，这一条就限制了它的横向扩展性。
这里的秒级，指的是集群全部节点，同时刷新，1s以内送达。而不是单机，或者部分机器。
引用来自“就像风”的评论
1. 支持海量数据对于配置中心来说也只是MB的量级，没有哪个企业的配置能达到GB的量级，即便有那也早早的会进行业务拆分。2. 说 #DuiC# 不支持横向扩展，其实并不了解#DuiC#的实现，#DuiC#会利用数据库做服务管理，在修改数据后会即时通知各个实例更新内存中的配置（毫秒级），所以#DuiC#在集群部署时甚至不需要一行配置或者一行代码，只管启实例即可。
3. #DuiC# 能将所有配置放置在内存中是对于产品本身有一个合理的定位，因配置所占用的内存非常有限，所以性能是首先要追求的，其实是#DuiC#支持按需要获取配置，如果查库这效率实在太低而且不实用。
4. #DuiC# 的定位并不仅仅是服务端的配置管理，而是管理整个产品线上的应用配置包括android/ios/web等。
5. 多机房部署，这实现方式有很多种当然#DuiC#也是可以实现的，不过这个特性的重要程度对于一个配置管理来说到底有多重要，我觉得还是需要考量的。
引用来自“许雪里”的评论
几个问题。1、配置仅仅是MB级别？
2、android，ios也直连配置中心拿配置？
3、跨机房不重要？
这几个问题，我们认知有本质的区别。
我们遇到过一个kv配置就几百K，嘉定、北京等多机房，要容灾，等等。
因为遇到的问题不一样，所以要解决的痛点也不一样，等你也遇到我们的问题，就明白我们的设计出发点了。
引用来自“就像风”的评论
假设1个配置项需要占用1K的空间，那么1G的空间可以容纳 1,048,576 个配置项，超过千万。事实上实际场景平均每个配置项所需要占用的空间只能用字节计算，所以实际1G空间能存在的配置项要远远高于这个。从实际出发目前没有哪个项目能够拥有如此多的配置项。引用来自“许雪里”的评论
配置中心是承担各业务所有项目的，不知道你们有多少项目要接入，我见过一个配置中心接入上千个项目的，部分配置一条几百K，所以需要细粒度到KV格式，都是前人的经验总结。你提到 ”假设一个配置1k” ，还有”没有哪个项目有这么多配置” ，你假设不存在的情况，恰好是我们遇到的问题，这认知有区别，讨论下去没有意义的，打住吧。
引用来自“就像风”的评论
就占用空间的问题继续讨论也不会有任何意义。不过我需要强调一点数据放在内存，完全不会限制应用的横向扩展。因为数据最终还是持久化在DB中的。
可参考章节 “5.9 跨机房（异地多活）”
---
得益于配置中心集群关系对等特性，集群各节点提供幂等的配置服务；因此，异地跨机房部署时，只需要请求本机房配置中心即可，实现异地多活；
举个例子：比如机房A、B 内分别部署配置中心集群节点。即机房A部署 a1、a2 两个配置中心服务节点，机房B部署 b1、b2 两个配置中心服务节点；
那么各机房内应用只需要请求本机房内部署的配置中心节点即可，不需要跨机房调用。即机房A内业务应用请求 a1、a2 获取配置、机房B内业务应用 b1、b2 获取配置。
这种跨机房部署方式实现了配置服务的 "异地多活"，拥有以下几点好处：
1、配置服务加载更快：配置请求本机房内搞定；
2、配置服务更稳定：配置请求不需要跨机房，不需要考虑复杂的网络情况，更加稳定；
2、容灾性：即使一个机房内配置中心全部宕机，仅会影响到本机房内应用加载服务，其他机房不会受到影响。
引用来自“prelove88”的评论
惊喜来得太快了，说干就干，这速度！！！👍👍👍引用来自“许雪里”的评论
废弃ZK其实有得有失，不过决定了就是要干：https://github.com/xuxueli/xxl-conf/issues/60引用来自“就像风”的评论
为什么废弃zk推送就会从毫秒级变成秒级？ #DuiC# 依然可以做到毫秒级推送。引用来自“许雪里”的评论
因为 XXL-CONF 定位不同，线上公司接入也有一些了，个别公司配置数量很小但是非常多。所以迭代方向是：支持海量配置，多机房集群部署。
你提到的这个看了一下，其他特性还不错，但是数据放内存，这一条就限制了它的横向扩展性。
这里的秒级，指的是集群全部节点，同时刷新，1s以内送达。而不是单机，或者部分机器。
引用来自“就像风”的评论
1. 支持海量数据对于配置中心来说也只是MB的量级，没有哪个企业的配置能达到GB的量级，即便有那也早早的会进行业务拆分。2. 说 #DuiC# 不支持横向扩展，其实并不了解#DuiC#的实现，#DuiC#会利用数据库做服务管理，在修改数据后会即时通知各个实例更新内存中的配置（毫秒级），所以#DuiC#在集群部署时甚至不需要一行配置或者一行代码，只管启实例即可。
3. #DuiC# 能将所有配置放置在内存中是对于产品本身有一个合理的定位，因配置所占用的内存非常有限，所以性能是首先要追求的，其实是#DuiC#支持按需要获取配置，如果查库这效率实在太低而且不实用。
4. #DuiC# 的定位并不仅仅是服务端的配置管理，而是管理整个产品线上的应用配置包括android/ios/web等。
5. 多机房部署，这实现方式有很多种当然#DuiC#也是可以实现的，不过这个特性的重要程度对于一个配置管理来说到底有多重要，我觉得还是需要考量的。
引用来自“许雪里”的评论
几个问题。1、配置仅仅是MB级别？
2、android，ios也直连配置中心拿配置？
3、跨机房不重要？
这几个问题，我们认知有本质的区别。
我们遇到过一个kv配置就几百K，嘉定、北京等多机房，要容灾，等等。
因为遇到的问题不一样，所以要解决的痛点也不一样，等你也遇到我们的问题，就明白我们的设计出发点了。
引用来自“就像风”的评论
假设1个配置项需要占用1K的空间，那么1G的空间可以容纳 1,048,576 个配置项，超过千万。事实上实际场景平均每个配置项所需要占用的空间只能用字节计算，所以实际1G空间能存在的配置项要远远高于这个。从实际出发目前没有哪个项目能够拥有如此多的配置项。引用来自“许雪里”的评论
配置中心是承担各业务所有项目的，不知道你们有多少项目要接入，我见过一个配置中心接入上千个项目的，部分配置一条几百K，所以需要细粒度到KV格式，都是前人的经验总结。你提到 ”假设一个配置1k” ，还有”没有哪个项目有这么多配置” ，你假设不存在的情况，恰好是我们遇到的问题，这认知有区别，讨论下去没有意义的，打住吧。
不过我需要强调一点数据放在内存，完全不会限制应用的横向扩展。因为数据最终还是持久化在DB中的。
引用来自“prelove88”的评论
惊喜来得太快了，说干就干，这速度！！！👍👍👍引用来自“许雪里”的评论
废弃ZK其实有得有失，不过决定了就是要干：https://github.com/xuxueli/xxl-conf/issues/60引用来自“就像风”的评论
为什么废弃zk推送就会从毫秒级变成秒级？ #DuiC# 依然可以做到毫秒级推送。引用来自“许雪里”的评论
因为 XXL-CONF 定位不同，线上公司接入也有一些了，个别公司配置数量很小但是非常多。所以迭代方向是：支持海量配置，多机房集群部署。
你提到的这个看了一下，其他特性还不错，但是数据放内存，这一条就限制了它的横向扩展性。
这里的秒级，指的是集群全部节点，同时刷新，1s以内送达。而不是单机，或者部分机器。
引用来自“就像风”的评论
1. 支持海量数据对于配置中心来说也只是MB的量级，没有哪个企业的配置能达到GB的量级，即便有那也早早的会进行业务拆分。2. 说 #DuiC# 不支持横向扩展，其实并不了解#DuiC#的实现，#DuiC#会利用数据库做服务管理，在修改数据后会即时通知各个实例更新内存中的配置（毫秒级），所以#DuiC#在集群部署时甚至不需要一行配置或者一行代码，只管启实例即可。
3. #DuiC# 能将所有配置放置在内存中是对于产品本身有一个合理的定位，因配置所占用的内存非常有限，所以性能是首先要追求的，其实是#DuiC#支持按需要获取配置，如果查库这效率实在太低而且不实用。
4. #DuiC# 的定位并不仅仅是服务端的配置管理，而是管理整个产品线上的应用配置包括android/ios/web等。
5. 多机房部署，这实现方式有很多种当然#DuiC#也是可以实现的，不过这个特性的重要程度对于一个配置管理来说到底有多重要，我觉得还是需要考量的。
引用来自“许雪里”的评论
几个问题。1、配置仅仅是MB级别？
2、android，ios也直连配置中心拿配置？
3、跨机房不重要？
这几个问题，我们认知有本质的区别。
我们遇到过一个kv配置就几百K，嘉定、北京等多机房，要容灾，等等。
因为遇到的问题不一样，所以要解决的痛点也不一样，等你也遇到我们的问题，就明白我们的设计出发点了。
引用来自“就像风”的评论
假设1个配置项需要占用1K的空间，那么1G的空间可以容纳 1,048,576 个配置项，超过千万。事实上实际场景平均每个配置项所需要占用的空间只能用字节计算，所以实际1G空间能存在的配置项要远远高于这个。从实际出发目前没有哪个项目能够拥有如此多的配置项。你提到 ”假设一个配置1k” ，还有”没有哪个项目有这么多配置” ，你假设不存在的情况，恰好是我们遇到的问题，这认知有区别，讨论下去没有意义的，打住吧。
引用来自“prelove88”的评论
惊喜来得太快了，说干就干，这速度！！！👍👍👍引用来自“许雪里”的评论
废弃ZK其实有得有失，不过决定了就是要干：https://github.com/xuxueli/xxl-conf/issues/60引用来自“就像风”的评论
为什么废弃zk推送就会从毫秒级变成秒级？ #DuiC# 依然可以做到毫秒级推送。引用来自“许雪里”的评论
因为 XXL-CONF 定位不同，线上公司接入也有一些了，个别公司配置数量很小但是非常多。所以迭代方向是：支持海量配置，多机房集群部署。
你提到的这个看了一下，其他特性还不错，但是数据放内存，这一条就限制了它的横向扩展性。
这里的秒级，指的是集群全部节点，同时刷新，1s以内送达。而不是单机，或者部分机器。
引用来自“就像风”的评论
1. 支持海量数据对于配置中心来说也只是MB的量级，没有哪个企业的配置能达到GB的量级，即便有那也早早的会进行业务拆分。2. 说 #DuiC# 不支持横向扩展，其实并不了解#DuiC#的实现，#DuiC#会利用数据库做服务管理，在修改数据后会即时通知各个实例更新内存中的配置（毫秒级），所以#DuiC#在集群部署时甚至不需要一行配置或者一行代码，只管启实例即可。
3. #DuiC# 能将所有配置放置在内存中是对于产品本身有一个合理的定位，因配置所占用的内存非常有限，所以性能是首先要追求的，其实是#DuiC#支持按需要获取配置，如果查库这效率实在太低而且不实用。
4. #DuiC# 的定位并不仅仅是服务端的配置管理，而是管理整个产品线上的应用配置包括android/ios/web等。
5. 多机房部署，这实现方式有很多种当然#DuiC#也是可以实现的，不过这个特性的重要程度对于一个配置管理来说到底有多重要，我觉得还是需要考量的。
引用来自“许雪里”的评论
几个问题。1、配置仅仅是MB级别？
2、android，ios也直连配置中心拿配置？
3、跨机房不重要？
这几个问题，我们认知有本质的区别。
我们遇到过一个kv配置就几百K，嘉定、北京等多机房，要容灾，等等。
因为遇到的问题不一样，所以要解决的痛点也不一样，等你也遇到我们的问题，就明白我们的设计出发点了。
引用来自“prelove88”的评论
惊喜来得太快了，说干就干，这速度！！！👍👍👍引用来自“许雪里”的评论
废弃ZK其实有得有失，不过决定了就是要干：https://github.com/xuxueli/xxl-conf/issues/60引用来自“就像风”的评论
为什么废弃zk推送就会从毫秒级变成秒级？ #DuiC# 依然可以做到毫秒级推送。引用来自“许雪里”的评论
因为 XXL-CONF 定位不同，线上公司接入也有一些了，个别公司配置数量很小但是非常多。所以迭代方向是：支持海量配置，多机房集群部署。
你提到的这个看了一下，其他特性还不错，但是数据放内存，这一条就限制了它的横向扩展性。
这里的秒级，指的是集群全部节点，同时刷新，1s以内送达。而不是单机，或者部分机器。
引用来自“就像风”的评论
1. 支持海量数据对于配置中心来说也只是MB的量级，没有哪个企业的配置能达到GB的量级，即便有那也早早的会进行业务拆分。2. 说 #DuiC# 不支持横向扩展，其实并不了解#DuiC#的实现，#DuiC#会利用数据库做服务管理，在修改数据后会即时通知各个实例更新内存中的配置（毫秒级），所以#DuiC#在集群部署时甚至不需要一行配置或者一行代码，只管启实例即可。
3. #DuiC# 能将所有配置放置在内存中是对于产品本身有一个合理的定位，因配置所占用的内存非常有限，所以性能是首先要追求的，其实是#DuiC#支持按需要获取配置，如果查库这效率实在太低而且不实用。
4. #DuiC# 的定位并不仅仅是服务端的配置管理，而是管理整个产品线上的应用配置包括android/ios/web等。
5. 多机房部署，这实现方式有很多种当然#DuiC#也是可以实现的，不过这个特性的重要程度对于一个配置管理来说到底有多重要，我觉得还是需要考量的。
引用来自“许雪里”的评论
几个问题。1、配置仅仅是MB级别？
2、android，ios也直连配置中心拿配置？
3、跨机房不重要？
这几个问题，我们认知有本质的区别。
我们遇到过一个kv配置就几百K，嘉定、北京等多机房，要容灾，等等。
因为遇到的问题不一样，所以要解决的痛点也不一样，等你也遇到我们的问题，就明白我们的设计出发点了。
2. android, ios 也直接配置这有何问题？
3. xxl-conf 对于跨机房有做啥特别的处理？显然没有，所以你能实现的其它都能实现，这显然不是xxl-conf特有的。我前面也说过了跨机房的实现方式有很多做法，显然xxl-conf并没有在其中做什么特别的工作。
引用来自“prelove88”的评论
惊喜来得太快了，说干就干，这速度！！！👍👍👍引用来自“许雪里”的评论
废弃ZK其实有得有失，不过决定了就是要干：https://github.com/xuxueli/xxl-conf/issues/60引用来自“就像风”的评论
为什么废弃zk推送就会从毫秒级变成秒级？ #DuiC# 依然可以做到毫秒级推送。引用来自“许雪里”的评论
因为 XXL-CONF 定位不同，线上公司接入也有一些了，个别公司配置数量很小但是非常多。所以迭代方向是：支持海量配置，多机房集群部署。
你提到的这个看了一下，其他特性还不错，但是数据放内存，这一条就限制了它的横向扩展性。
这里的秒级，指的是集群全部节点，同时刷新，1s以内送达。而不是单机，或者部分机器。
引用来自“就像风”的评论
1. 支持海量数据对于配置中心来说也只是MB的量级，没有哪个企业的配置能达到GB的量级，即便有那也早早的会进行业务拆分。2. 说 #DuiC# 不支持横向扩展，其实并不了解#DuiC#的实现，#DuiC#会利用数据库做服务管理，在修改数据后会即时通知各个实例更新内存中的配置（毫秒级），所以#DuiC#在集群部署时甚至不需要一行配置或者一行代码，只管启实例即可。
3. #DuiC# 能将所有配置放置在内存中是对于产品本身有一个合理的定位，因配置所占用的内存非常有限，所以性能是首先要追求的，其实是#DuiC#支持按需要获取配置，如果查库这效率实在太低而且不实用。
4. #DuiC# 的定位并不仅仅是服务端的配置管理，而是管理整个产品线上的应用配置包括android/ios/web等。
5. 多机房部署，这实现方式有很多种当然#DuiC#也是可以实现的，不过这个特性的重要程度对于一个配置管理来说到底有多重要，我觉得还是需要考量的。
1、配置仅仅是MB级别？
2、android，ios也直连配置中心拿配置？
3、跨机房不重要？
这几个问题，我们认知有本质的区别。
我们遇到过一个kv配置就几百K，嘉定、北京等多机房，要容灾，等等。
因为遇到的问题不一样，所以要解决的痛点也不一样，等你也遇到我们的问题，就明白我们的设计出发点了。
引用来自“prelove88”的评论
惊喜来得太快了，说干就干，这速度！！！👍👍👍引用来自“许雪里”的评论
废弃ZK其实有得有失，不过决定了就是要干：https://github.com/xuxueli/xxl-conf/issues/60引用来自“就像风”的评论
为什么废弃zk推送就会从毫秒级变成秒级？ #DuiC# 依然可以做到毫秒级推送。引用来自“许雪里”的评论
因为 XXL-CONF 定位不同，线上公司接入也有一些了，个别公司配置数量很小但是非常多。所以迭代方向是：支持海量配置，多机房集群部署。
你提到的这个看了一下，其他特性还不错，但是数据放内存，这一条就限制了它的横向扩展性。
这里的秒级，指的是集群全部节点，同时刷新，1s以内送达。而不是单机，或者部分机器。
2. 说 #DuiC# 不支持横向扩展，其实并不了解#DuiC#的实现，#DuiC#会利用数据库做服务管理，在修改数据后会即时通知各个实例更新内存中的配置（毫秒级），所以#DuiC#在集群部署时甚至不需要一行配置或者一行代码，只管启实例即可。
3. #DuiC# 能将所有配置放置在内存中是对于产品本身有一个合理的定位，因配置所占用的内存非常有限，所以性能是首先要追求的，其实是#DuiC#支持按需要获取配置，如果查库这效率实在太低而且不实用。
4. #DuiC# 的定位并不仅仅是服务端的配置管理，而是管理整个产品线上的应用配置包括android/ios/web等。
5. 多机房部署，这实现方式有很多种当然#DuiC#也是可以实现的，不过这个特性的重要程度对于一个配置管理来说到底有多重要，我觉得还是需要考量的。
引用来自“prelove88”的评论
惊喜来得太快了，说干就干，这速度！！！👍👍👍引用来自“许雪里”的评论
废弃ZK其实有得有失，不过决定了就是要干：https://github.com/xuxueli/xxl-conf/issues/60引用来自“就像风”的评论
为什么废弃zk推送就会从毫秒级变成秒级？ #DuiC# 依然可以做到毫秒级推送。所以迭代方向是：支持海量配置，多机房集群部署。
你提到的这个看了一下，其他特性还不错，但是数据放内存，这一条就限制了它的横向扩展性。
这里的秒级，指的是集群全部节点，同时刷新，1s以内送达。而不是单机，或者部分机器。
引用来自“prelove88”的评论
惊喜来得太快了，说干就干，这速度！！！👍👍👍引用来自“许雪里”的评论
废弃ZK其实有得有失，不过决定了就是要干：https://github.com/xuxueli/xxl-conf/issues/601，成本高：依赖zk，需要额外维护一套zk集群，维护成本较高。移除之后，成本大大降低。
2，横向扩展受限：依赖zk，接入方数量受限于zk集群规模。当配置数量与接入方越来越多，对zk的watch与读写压力越来越大。移除zk后，理论上可以无限水平扩展。
当然，移除zk也有缺点。
1，强一致性特性，退化成最终一致性。
2，毫秒级推送更新，退化为秒级别推送更新。
如果需要强一致性特性，可以使用 XXL-CONF 1.5.x 版本，将会一同持续维护。
引用来自“jlkm2010”的评论
一开始就该废弃zk引用来自“prelove88”的评论
惊喜来得太快了，说干就干，这速度！！！👍👍👍既然要废弃，就要彻底废弃。
XXL-CONF 底层架构升级之后，彻底完成轻量级改造，无论单机还是集群部署，第三方零依赖。