仓库组与路由

本章承接入门教程的仓库基础概念，深入讲解企业级私服中的仓库组织与请求路由机制。入门已了解本地仓库、远程仓库、中央仓库和私服的基本概念，本章将掌握 Nexus 中仓库组（Repository Group）的设计原理、路由规则，以及 hosted、proxy、group 三种仓库类型的分工协作。

核心机制

在企业环境中，Maven 依赖的来源是多元的：

团队自研的私有构件（如 com.feixiang:payment-service:1.0.0）
第三方开源库（如 org.springframework:spring-context）
特定厂商的商用 SDK（如阿里云、腾讯云私有仓库）
中央仓库中没有的老旧版本或特殊变体

如果开发者在 pom.xml 或 settings.xml 中为每个来源单独配置一个 <repository>，配置会迅速膨胀，且每次构建都要依次轮询多个仓库，效率低下。

仓库组（Repository Group） 的核心思想是聚合与透明：将多个物理仓库逻辑合并为一个虚拟仓库，对外暴露单一 URL。Maven 客户端只需配置这一个 URL，请求进入私服后，由内部路由规则决定到哪个物理仓库取构件。

三种仓库类型

Nexus（以及 Artifactory）中的仓库分为三种类型，每种承担不同的职责：

类型	英文	作用	数据流向	典型命名
宿主仓库	Hosted	存储本地上传的构件	上传 → 本地存储	`maven-releases`、`maven-snapshots`
代理仓库	Proxy	代理外部仓库，缓存构件	远程下载 → 本地缓存	`maven-central-proxy`、`aliyun-proxy`
仓库组	Group	聚合多个仓库，统一入口	请求路由 → 成员仓库	`maven-public`

路由规则

当 Maven 向仓库组请求一个构件（如 com/feixiang/payment-service/1.0.0/payment-service-1.0.0.jar）时，Nexus 按以下规则处理：

按成员顺序遍历：仓库组内部有一个有序的成员列表（如 hosted → proxy1 → proxy2）
逐个查询：依次向每个成员仓库查询该构件是否存在
命中即返回：第一个包含该构件的仓库直接返回，后续仓库不再查询
全部未命中：返回 404，Maven 构建失败

这个顺序至关重要。通常推荐将 hosted 仓库放在最前面（自研构件查询最快），其次是常用代理仓库，最后是通用中央代理。

生活类比：医院分诊台

想象一家大型综合医院（Nexus 私服）：

Hosted 仓库像医院的内部药房：只存放本院医生开的药（自研构件），本院患者（内部项目）优先来这里取。
Proxy 仓库像医院的外部代购点：本院没有的药，去外面药店（中央仓库）买，买回来后在代购点存一份，下次再有人要就直接拿。
Group 仓库像医院的统一分诊台：患者（Maven 请求）只认分诊台（单一 URL）。分诊台护士按规则判断：内部药房有没有？没有的话去哪个代购点找？患者完全不需要知道背后有几家药店。

图示

上图展示了仓库组的路由流程：Maven 客户端只感知一个 URL（maven-public），请求到达 Nexus 后，按成员顺序依次查询 hosted 和 proxy 仓库。Proxy 仓库在本地缓存缺失时，才会向外部源发起远程下载。这个设计让开发者配置极简，同时保证了查询效率和带宽节约。

完整示例

场景

飞翔科技的 Nexus 私服由运维李眉维护，架构师白歌制定仓库策略。团队有自研构件、开源依赖、阿里云加速三种来源。后端小崔和前端黄俪的项目都需要配置仓库，CTO 大翔要求"所有项目配置统一，不许各自为政"。

操作前：混乱的多仓库配置

在没有仓库组之前，小崔的 settings.xml 可能是这样的：

<profiles>
    <profile>
        <id>multi-repo</id>
        <repositories>
            <!-- 自研 RELEASE -->
            <repository>
                <id>feixiang-releases</id>
                <url>http://nexus.feixiang.tech/repository/maven-releases/</url>
            </repository>
            <!-- 自研 SNAPSHOT -->
            <repository>
                <id>feixiang-snapshots</id>
                <url>http://nexus.feixiang.tech/repository/maven-snapshots/</url>
            </repository>
            <!-- 阿里云加速 -->
            <repository>
                <id>aliyun</id>
                <url>https://maven.aliyun.com/repository/public/</url>
            </repository>
            <!-- 中央仓库备用 -->
            <repository>
                <id>central</id>
                <url>https://repo.maven.apache.org/maven2/</url>
            </repository>
        </repositories>
    </profile>
</profiles>

问题：

每个新项目都要复制粘贴这段配置，容易写错 URL
构建时 Maven 要依次轮询 4 个仓库，任何一个网络抖动都会拖慢构建
黄俪的前端项目（Node.js + 前端 Maven 插件）也要配同样的仓库，维护成本高
李眉想切换阿里云到腾讯云，需要通知所有开发改配置

操作后：仓库组统一入口

李眉在 Nexus 上创建仓库组 maven-public，成员顺序如下：

顺序	成员仓库	类型	作用
1	`maven-releases`	Hosted	存放飞翔科技自研 RELEASE 构件
2	`maven-snapshots`	Hosted	存放飞翔科技自研 SNAPSHOT 构件
3	`aliyun-proxy`	Proxy	代理阿里云公共仓库，加速国内下载
4	`maven-central-proxy`	Proxy	代理 Maven Central，兜底查询

所有开发者只需配置一个 URL：

<mirrors>
    <mirror>
        <id>feixiang-public</id>
        <name>FeiXiang Maven Public Group</name>
        <url>http://nexus.feixiang.tech/repository/maven-public/</url>
        <mirrorOf>*</mirrorOf>
    </mirror>
</mirrors>

或者，如果项目需要更精细的控制（如某些构件不走镜像），在 pom.xml 中配置：

<repositories>
    <repository>
        <id>feixiang-public</id>
        <name>FeiXiang Public Group</name>
        <url>http://nexus.feixiang.tech/repository/maven-public/</url>
        <releases>
            <enabled>true</enabled>
        </releases>
        <snapshots>
            <enabled>true</enabled>
            <updatePolicy>daily</updatePolicy>
        </snapshots>
    </repository>
</repositories>

路由过程演示

小崔构建 order-service，需要解析以下依赖：

com.feixiang:payment-service:1.0.0
- 请求到达 maven-public
- 顺序查询 maven-releases → 命中，直接返回
- maven-snapshots、aliyun-proxy、maven-central-proxy 均不查询
org.springframework.boot:spring-boot-starter:2.7.12
- 请求到达 maven-public
- maven-releases → 未命中
- maven-snapshots → 未命中
- aliyun-proxy → 本地缓存未命中，向阿里云远程查询 → 命中，下载并缓存，返回给 Maven
- maven-central-proxy 不查询
com.oracle.database.jdbc:ojdbc8:21.9.0.0（商用 JDBC 驱动）
- 请求到达 maven-public
- maven-releases → 未命中
- maven-snapshots → 未命中
- aliyun-proxy → 阿里云没有该商用驱动 → 未命中
- maven-central-proxy → 本地缓存未命中，向 Central 查询 → 命中，下载并缓存，返回

变化分析：

小崔和黄俪的配置从 4 个仓库缩减为 1 个 URL，新人入职直接复制标准 settings.xml 即可
李眉将阿里云切换为腾讯云时，只需在 Nexus 后台修改 aliyun-proxy 的远程地址，所有开发者零感知
自研构件查询永远走前两个 hosted 仓库，速度最快，不浪费外部带宽
第三方构件首次下载后缓存在 proxy 仓库，全公司共享，大幅节约外网流量

易错点与常见问题

误区一：仓库组成员顺序无所谓

错误认知："我把所有仓库丢进一个 Group 就行，顺序不重要。"

纠正：顺序直接决定查询效率和结果正确性。如果 maven-central-proxy 排在第一位，每次请求自研构件都要先查一遍中央仓库（网络延迟 + 404 响应），严重拖慢构建。更严重的是：如果中央仓库中存在与自研构件相同坐标的恶意或意外上传的构件（称为"依赖混淆攻击"），错误的顺序会导致项目下载到错误的构件。

反例：某团队将 maven-central-proxy 放在 maven-releases 之前。攻击者在 Central 上注册了 com.feixiang:internal-crypto-lib:1.0.0（与团队内部加密库同名），团队项目构建时优先从 Central 下载了恶意版本，导致安全事件。正确顺序必须是 hosted 在前，proxy 在后，确保内部构件优先于外部仓库。