XXL-CONF 终于完成 springboot 迁移，并推送 DockerHub

[xuxueli]

XXL-CONF 是一个分布式配置管理平台，拥有"强一致性、毫秒级动态推送、多环境、多语言、配置监听、权限控制、版本回滚"等特性。现已开放源代码，开箱即用。

GitHub 仓库： https://github.com/xuxueli/xxl-conf

官方文档： http://www.xuxueli.com/xxl-conf/#/

Docker Hub： https://hub.docker.com/r/xuxueli/xxl-conf-admin/

Docker 运行 XXL-CONF 步骤：

// 下载镜像：Docker 地址： https://hub.docker.com/r/xuxueli/xxl-conf-admin/
docker pull xuxueli/xxl-conf-admin


// 创建容器并运行：可通过 "PARAMS" 支持自定义 mysql 与 zk 地址；
docker run -e PARAMS="--mysqladdress=172.17.0.2:3306 --zkaddress=172.17.0.3:2181" -p 8080:8080 -v /tmp:/data/applogs --name xxl-conf-admin  -d xuxueli/xxl-conf-admin

[OctopusGO]

这么厉害的么

[NUT]

一直关注这个项目， 最开始只是简单的 xml 配置，到现在采用 disconf 类似的 注解。挺赞的。

对于 todo 的
3、考虑移除 ZK，改为 "Server 端广播 + long-polling" 方式实现，降低学习、部署成本；

我不建议这么做，而是 基于当下的 javaClient 实现一个 agent 来实现配置转发，和请求的过程。即原有的 server 不变，对于异构语言（ PHP、go ）等，直接链接 agent， 可以通过 http 或者 ws 协议和 agent 数据交互，提供相应的接口和协议规范，可以依靠社区力量完善其他语言客户端，比 Server 端广播 + long-polling 靠谱很多。另外 zk 有着生产环境的验证，您做成能保证 Server 端广播比 zk 还稳定么？ 所以这个路线个人主观认为，在走岔路。

鉴于其他语言对于 zk client 实现，坑很多。所以 agent 使用 java 刚好避免这个坑。 大佬你觉得呢？

[xuxueli]

@OctopusGO 可以试用下啊，不怕和其他竞品对比，差的就是一个机会！

xxl-conf，强一致性配置中心，迭代了三年，生产级别。

[xuxueli]

@NUT 赞！关于这点咱俩不谋而合。

“ Java 应用可通过 "Client 方式" 方便的获取配置中心的数据；

非 Java 语言应用，可通过提供的 "配置中心 Agent 服务" 获取配置中心配置；可据此通过 Http （ long-polling ）获取配置数据并实时感知配置变更，从而实现多语言支持。”

上述内容摘自 xxl-conf 官方文档，已经原声支持了 client 和 agent 两种接入方式。

而且，得益于 zk，xxl-conf 配置中心考虑迭代提供注册中心和分布式锁的特性支持。

[NUT]

@xuxueli #4 👍