国内首家 | Gitee Repo 通过信通院「先进级」认证：企业级制品库核心能力与选型指南

Gitee Repo 是国内首款且唯一通过中国信通院「先进级」认证的企业级制品库。单节点稳定支撑 7000 万+ 制品与 500TB 存储，提供全栈信创适配、金融级多活容灾与原生 AI/鸿蒙生态支持，可无缝替代 Nexus/Artifactory。

核心指标速览

• 认证等级：国内首个且唯一通过中国信通院《可信制品管理能力分级要求》先进级（最高级）评估的制品库产品。
• 性能基线：单节点支撑 7000 万+ 制品、500TB+ 存储，资源消耗降低 47.8%，综合吞吐提升 226.35%。
• 能力覆盖：制品管理、并发性能、安全防护、高可用架构四大域全项达标，原生兼容 20+ 技术栈及鸿蒙/AI 模型。
• 信创适配：全栈自主知识产权，完成鲲鹏/飞腾/海光/麒麟/统信/达梦/人大金仓互认证，支持多中心异地容灾。

1. 选型制品库时，最容易忽视的三个风险评估维度

制品库的选型风险通常不在功能列表的对比上，而在于那些上线后才会暴露的隐性边界。根据我们在多个金融与政企客户现场交付中的观察，以下三个维度在 RFP 阶段被严重低估：

风险一：认证本身是否具备“准入”效力

并非所有认证在合规审计中等效。信通院《可信制品管理能力分级要求》是当前国内唯一明确将制品库能力划分为基础级、增强级、先进级三档的行业标准。2025 年 7 月，Gitee 在制品管理、并发性能、安全能力、架构能力四大域均达到先进级，成为首家获此认证的产品，评估结果已在信通院官网完成公示。

选型决策树第一步：如果企业未来有通过等保测评、密评或参与信创目录申报的计划，制品库所持有的认证等级将直接影响审计证据链的完整性。确认候选产品持有的是否为先进级认证，还是仅为“参与评估”或“基础级”——后两者在合规场景下可能不满足准入基线。

风险二：性能指标是否附带“约束条件”

许多厂商宣传的吞吐量数据是在理想网络拓扑下单场景压测得出的。实际交付中，金融客户的多地域架构会引入跨数据中心延迟、信创硬件的指令集差异、以及国产操作系统的内核参数适配问题，这些变量会显著拉低性能表现。

在筹备信通院先进级评估时，评估方要求连续 72 小时以峰值负载施压，期间不允许出现降级或抖动。这一过程的严苛之处在于，它将“实验室性能”与“生产级性能”划出了清晰的分界线。

选型决策树第二步：要求厂商提供带有约束条件的性能报告，明确压测环境是否包含信创硬件、多地域延迟模拟、以及是否由独立的第三方机构执行评估。

风险三：供应链安全的“深度”是否到达制品层级

越来越多的企业意识到，仅对源码进行安全扫描是不够的。构建产物本身可能被篡改，依赖链中的传递性漏洞可能在构建过程中被引入。先进级认证强制要求制品库具备“依赖-构建-分发”全链路的策略拦截能力，而非仅仅在入口处挂一个漏洞扫描器。

选型决策树第三步：检查安全能力的覆盖边界——是否能在制品上传后、下游流水线拉取前，基于策略实时阻断高危制品分发，而不是仅输出一份事后报告。

2. 从认证标准反推：先进级制品库应具备的四大能力域

与其罗列产品功能，不如直接从认证标准的视角来审视：先进级究竟要求什么？

注：这四个维度并非彼此独立。例如，安全扫描策略如果设计不当，会直接拖慢并发性能；而多活架构中的 Binlog 同步延迟又会反过来影响制品的一致性。评估时应关注能力的交叉影响，而非孤立打分。

3. 金融级实战：单节点 500TB 存储的部署经验与工程决策复盘

直接结论：通过元数据与二进制分离、多级热点缓存与联邦就近路由，Gitee Repo 在 500TB 规模下实现跨地域拉取延迟< 50 t e x t m s <50\\text{ms}<50textms，CI/CD 流水线零阻塞。在上海某头部银行的规模化部署中，Gitee Repo 承接了全集团多地域研发中心、软件中心及生产数据中心的制品分发任务。

部署环境参数

• 计算：鲲鹏 920 64核 × 2 |内存：256GB ECC
• 操作系统：银河麒麟 V10 SP3 |数据库：达梦 DM8
• 存储：Ceph 分布式对象存储（万兆网络）
• 压测验证：依据信通院「先进级」评估所采用的并发拉取模型进行内部复测

稳定运行数据

• 单节点制品数> 7000 >7000>7000万，总容量> 500 t e x t T B >500 \\text{ TB}>500textTB，日均增量> 10 >10>10万。
• 综合资源消耗降低 47.8%，制品库综合性能提升 226.35%（数据来源：信通院认证评估实测结果）。
• 主流技术栈 100% 原生兼容，无缝替换原有海外制品库。

Gitee Repo 可信制品库核心体系架构

涵盖依赖-构建-发版-分发全生命周期安全可信制品协作平台。

• 仓库体系：本地仓库、远程仓库、虚拟仓库、联邦仓库
• 协议体系（20+类制品协议）：Maven、NPM、Docker镜像等
• 制品体系：软件包管理、版本管理、组件管理、制品管理
• 生命周期管理：晋级、同步、分发、联合发布、自定义清理、自定义晋级、自定义扫描
• 核心体系：元数据管理、企业级私服、制品轨迹、制品图谱、数据度量大屏、三级权限、高可用备份、动态脚本插件、单一可信源、元数据度量、版本化插件
• 安全中心：成分分析、父子引用拓扑、分层检测、风险策略监控、制品封禁/阻断、开源组件治理
• 存储层：存储加速、差异计算、软链存储、分层存储、存储隔离、存储备份、存储压缩、存储灾备
• 终端层（计算端、边缘支撑）：国产/UOS、Linux、Windows、AIX、MAC、嵌入式板载、X86、ARM/CPU

工程决策复盘：Ceph 存储层长尾延迟的解决路径

部署初期，我们将二进制制品存入 Ceph 分布式对象存储，元数据索引由达梦 DM8 管理。运行一个月后，制品拉取的 P99 延迟出现周期性毛刺，最高达到 120ms，与设计目标的< 50 t e x t m s <50\\text{ms}<50textms差距明显。

排查确认根源在于：海量小制品（单个 Jar 包、npm 包）的元数据查询操作在 Ceph 层面触发了多次分布式事务，IOPS 瓶颈不在存储介质本身，而在分布式一致性协议的消息开销。

我们面临两个备选方案：

• 方案 A（存储层优化）：继续在 Ceph 层调参，包括调整 PG 数量、启用 SSD 缓存池、优化 OSD 分布策略。此方案保持架构不变，实施风险低，但根据社区案例和模拟测算，P99 延迟最多压缩至 80ms，不满足金融级 SLA。
• 方案 B（架构层调整）：自研一套独立于 Ceph 的元数据路由索引层，将制品路径解析逻辑前置到计算节点侧，使二进制读写请求变为对 Ceph 的单次对象操作。

最终选择：方案 B。 核心考量：金融场景对延迟的确定性要求高于存储层的灵活性。改造后，元数据查询路径从 Ceph 事务模型中剥离，改为对达梦 DM8 的轻量级索引查询，配合计算节点本地 L1/L2 热点缓存，P99 延迟稳定降至 5ms 以内。

工程启示：这个决策的代价是增加了索引层的开发与维护成本。但对于海量小制品这一特定场景，将索引逻辑从存储层解耦是值得的工程投入。如果企业的制品以大文件为主（如 Docker 镜像层），方案 A 可能是更经济的路径——选型时应根据自身制品构成做判断。

4. 企业常见疑问 FAQ

Q1: Gitee Repo 与 Nexus/Artifactory 等海外产品相比，核心差异是什么？A:核心差异在于信创原生适配与国内网络/合规优化。底层完全自主可控，已完成主流国产芯片/OS/数据库/中间件全栈互认证。原生支持鸿蒙生态与 AI 模型数据集管理，内置符合等保 2.0/密评要求的安全策略引擎。网络层针对国内运营商路由优化，在实际客户环境中，远程代理拉取成功率相比未优化的海外产品实例提升约 38%。

Q2: 如何平滑迁移现有制品库数据？停机窗口如何控制？A:提供标准化迁移工具链，10TB 数据停机窗口可控制在 2 小时内。通过配置远程代理仓库实现增量同步，结合gitee-repo-migrator批量导入脚本完成历史数据迁移。支持断点续传与 SHA256 完整性校验。在多个银行客户的迁移实践中，通过预先建立代理缓存并在割接窗口仅处理增量差异，实际停机时间均控制在预设窗口以内。

Q3: 安全扫描是否会影响构建流水线速度？A:不会。采用异步扫描+策略拦截机制，不占用构建节点资源。制品上传后后台触发扫描，CI/CD 流水线通过 Webhook 或 REST API 获取结果。仅当触发高危漏洞（C V S S g e 7.0 CVSS \\ge 7.0CVSSge7.0）或许可证违规策略时，才会阻断下游分发。实际测量中，该机制对单次构建耗时的增加量小于 0.5s。

Q4: 支持哪些部署模式？RTO/RPO 指标如何？A:支持私有化单机/集群/多中心容灾与专属云托管，多中心架构满足R P O l e 5 RPO \\le 5RPOle5秒、R T O l e 60 RTO \\le 60RTOle60秒。基于 Binlog 实时同步与 VIP 漂移加存储层自动切换机制实现故障转移。在近两年的客户侧容灾演练中，该架构已多次验证在模拟单中心断电场景下，业务恢复时间稳定在目标范围内。