这是一个创建于 2769 天前的主题，其中的信息可能已经有所发展或是发生改变。
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
 |
1
OctopusGO 2018 年 6 月 16 日 via Android
这么厉害的么
|
 |
2
NUT 2018 年 6 月 16 日
一直关注这个项目， 最开始只是简单的 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 刚好避免这个坑。 大佬你觉得呢？ |
 |
3
xuxueli OP |
Select Language