XXL-CONF v1.6.0 发布,废弃 ZK 轻量级架构升级

许雪里
 许雪里
发布于 2018年11月29日
收藏 24

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匹配才允许通讯;

文档地址

技术交流

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 开源中国社区 [http://www.oschina.net]
本文标题:XXL-CONF v1.6.0 发布,废弃 ZK 轻量级架构升级
加载中

精彩评论

许雪里
许雪里
#xxl-conf# 跨机房特性已经更新到文档: http://www.xuxueli.com/xxl-conf/

可参考章节 “5.9 跨机房(异地多活)”

---
得益于配置中心集群关系对等特性,集群各节点提供幂等的配置服务;因此,异地跨机房部署时,只需要请求本机房配置中心即可,实现异地多活;

举个例子:比如机房A、B 内分别部署配置中心集群节点。即机房A部署 a1、a2 两个配置中心服务节点,机房B部署 b1、b2 两个配置中心服务节点;

那么各机房内应用只需要请求本机房内部署的配置中心节点即可,不需要跨机房调用。即机房A内业务应用请求 a1、a2 获取配置、机房B内业务应用 b1、b2 获取配置。

这种跨机房部署方式实现了配置服务的 "异地多活",拥有以下几点好处:

1、配置服务加载更快:配置请求本机房内搞定;
2、配置服务更稳定:配置请求不需要跨机房,不需要考虑复杂的网络情况,更加稳定;
2、容灾性:即使一个机房内配置中心全部宕机,仅会影响到本机房内应用加载服务,其他机房不会受到影响。
许雪里
许雪里

引用来自“prelove88”的评论

惊喜来得太快了,说干就干,这速度!!!:thumbsup::thumbsup::thumbsup:
废弃ZK其实有得有失,不过决定了就是要干:https://github.com/xuxueli/xxl-conf/issues/60
p
prelove88
惊喜来得太快了,说干就干,这速度!!!:thumbsup::thumbsup::thumbsup:

最新评论(16

许雪里
许雪里

引用来自“prelove88”的评论

惊喜来得太快了,说干就干,这速度!!!:thumbsup::thumbsup::thumbsup:

引用来自“许雪里”的评论

废弃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中的。
:+1: 其实合适的就是最好的,你是要解决你遇到的问题,#xxl-conf# 是要解决我们以及 #xxl-conf# 用户的问题。没有绝对的优劣。
许雪里
许雪里
#xxl-conf# 跨机房特性已经更新到文档: http://www.xuxueli.com/xxl-conf/

可参考章节 “5.9 跨机房(异地多活)”

---
得益于配置中心集群关系对等特性,集群各节点提供幂等的配置服务;因此,异地跨机房部署时,只需要请求本机房配置中心即可,实现异地多活;

举个例子:比如机房A、B 内分别部署配置中心集群节点。即机房A部署 a1、a2 两个配置中心服务节点,机房B部署 b1、b2 两个配置中心服务节点;

那么各机房内应用只需要请求本机房内部署的配置中心节点即可,不需要跨机房调用。即机房A内业务应用请求 a1、a2 获取配置、机房B内业务应用 b1、b2 获取配置。

这种跨机房部署方式实现了配置服务的 "异地多活",拥有以下几点好处:

1、配置服务加载更快:配置请求本机房内搞定;
2、配置服务更稳定:配置请求不需要跨机房,不需要考虑复杂的网络情况,更加稳定;
2、容灾性:即使一个机房内配置中心全部宕机,仅会影响到本机房内应用加载服务,其他机房不会受到影响。
就像风
就像风

引用来自“prelove88”的评论

惊喜来得太快了,说干就干,这速度!!!:thumbsup::thumbsup::thumbsup:

引用来自“许雪里”的评论

废弃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”的评论

惊喜来得太快了,说干就干,这速度!!!:thumbsup::thumbsup::thumbsup:

引用来自“许雪里”的评论

废弃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” ,还有”没有哪个项目有这么多配置” ,你假设不存在的情况,恰好是我们遇到的问题,这认知有区别,讨论下去没有意义的,打住吧。
就像风
就像风

引用来自“prelove88”的评论

惊喜来得太快了,说干就干,这速度!!!:thumbsup::thumbsup::thumbsup:

引用来自“许雪里”的评论

废弃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空间能存在的配置项要远远高于这个。从实际出发目前没有哪个项目能够拥有如此多的配置项。
就像风
就像风

引用来自“prelove88”的评论

惊喜来得太快了,说干就干,这速度!!!:thumbsup::thumbsup::thumbsup:

引用来自“许雪里”的评论

废弃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. 配置是MB级别的,事实上你目前的配置有达到GB级别又或者你遇到了GB级别的配置管理场景吗?当然前提是要从实际角度出发,毕竟配置是纯文本管理,我从前面采用ZK那一套KV存储方式完全能够得出,如果你纯文本的配置达到GB级别,可以想象那是什么场景。
2. android, ios 也直接配置这有何问题?
3. xxl-conf 对于跨机房有做啥特别的处理?显然没有,所以你能实现的其它都能实现,这显然不是xxl-conf特有的。我前面也说过了跨机房的实现方式有很多做法,显然xxl-conf并没有在其中做什么特别的工作。
许雪里
许雪里

引用来自“prelove88”的评论

惊喜来得太快了,说干就干,这速度!!!:thumbsup::thumbsup::thumbsup:

引用来自“许雪里”的评论

废弃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”的评论

惊喜来得太快了,说干就干,这速度!!!:thumbsup::thumbsup::thumbsup:

引用来自“许雪里”的评论

废弃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#也是可以实现的,不过这个特性的重要程度对于一个配置管理来说到底有多重要,我觉得还是需要考量的。
许雪里
许雪里

引用来自“prelove88”的评论

惊喜来得太快了,说干就干,这速度!!!:thumbsup::thumbsup::thumbsup:

引用来自“许雪里”的评论

废弃ZK其实有得有失,不过决定了就是要干:https://github.com/xuxueli/xxl-conf/issues/60

引用来自“就像风”的评论

为什么废弃zk推送就会从毫秒级变成秒级? #DuiC# 依然可以做到毫秒级推送。
因为 XXL-CONF 定位不同,线上公司接入也有一些了,个别公司配置数量很小但是非常多。
所以迭代方向是:支持海量配置,多机房集群部署。

你提到的这个看了一下,其他特性还不错,但是数据放内存,这一条就限制了它的横向扩展性。

这里的秒级,指的是集群全部节点,同时刷新,1s以内送达。而不是单机,或者部分机器。
就像风
就像风

引用来自“prelove88”的评论

惊喜来得太快了,说干就干,这速度!!!:thumbsup::thumbsup::thumbsup:

引用来自“许雪里”的评论

废弃ZK其实有得有失,不过决定了就是要干:https://github.com/xuxueli/xxl-conf/issues/60
为什么废弃zk推送就会从毫秒级变成秒级? #DuiC# 依然可以做到毫秒级推送。
返回顶部
顶部