前言
kkRepo ( https://github.com/klboke/kkRepo )一个对标 Nexus ,解决 Nexus 社区版本限制痛点的开源制品仓库项目,目前已经支持了 Maven, npm, PyPI, Go, Helm, Cargo/Rust, Docker/OCI, NuGet, RubyGems, Yum, and Raw 这些仓库,下一步打算支持华为的鸿蒙 ohpm 仓库。
主动出击,寻找痛点用户
项目发布后,我就在 Google 搜索 “nexus 社区版限制” 这个关键词。找到了
这个博文,因为我发现类似的内容,这个博文在 Google 的 SEO 排名第一。然后在博文下跟帖回复了。
你好,我们开发了一个可以平替 Nexus 的软件,代码完全开源,也支持一键从 Nexus 迁移到 nexus-plus ,且我们已经在生产环境运行很久了。想调研下,因为 Nexus 的开源免费功能部分限制的越来越多的情况下,是否有兴趣切到 nexus-plus 来。附项目地址: https://github.com/klboke/nexus-plus
7 天之后,就有用户看到了我的评论,然后成功互加到微信。在微信上全力协助他,解答各种疑问。从加微信到他们生产落地不到一周时间。从 Nexus 开始迁移到 kkRepo 只用了 1 天时间。

以下来自对方的真实切换背景
我们是一家光伏制造企业,研发团队超过 500 人,覆盖 50 多个项目,内部多条产品线共用统一的 CI/CD 流水线。制品仓库作为构建基础设施的核心组件,承担着 Maven 、npm 、pypi 等多种制品的托管与分发职责,是整个研发体系的关键基础设施。
过去几年,我们一直使用 Sonatype Nexus Repository 3.78.2-04 ( Community Edition ),通过 Docker Compose 部署,底层数据库使用 PostgreSQL ,制品 blob 存储使用 OSS 。随着业务规模扩大,Nexus Community Edition 的一些限制逐渐暴露出来,最终促使我们启动了制品仓库的平替与迁移工作。
迁移到 kkRepo 后,实际效果:
不再有组件数量和请求量上限,不用担心触发硬性封顶 支持多副本部署和滚动升级,升级不再需要停服 可以按需扩容,支持弹性伸缩 元数据在 MySQL 中,blob 在 OSS 中,数据备份和恢复更方便 CI 配置和客户端全部无需修改,切换后业务侧没有收到任何失败反馈
后记
kkRepo 从开源到现在,不到一个月的时间,中间还经历了改项目名称这么狗血的事情,然后能在这么短时间内在 500 人研发团队规模的企业落地,安全平稳的从 Nexus 迁移到了 kkRepo ,完全超出了我的预期。这证明了 kkRepo 这个项目有真实的项目价值,以及落地场景。希望 kkRepo 这个项目能帮助到更多的企业,发挥更大的价值。