Nexus 路由就像是你可以应用到Nexus组上的过滤器，当Nexus尝试在一个Nexus组中寻找构件的时候，路由允许你在一个特定的构件搜索中包含或者排除一些仓库。有很多不同的场景中你可能需要配置路由，最平常的是当你想要确信你正从一个特定组的特定的仓库中获取构件。特别是当你想要确信你正从宿主Releases及Snapshots仓库中获取你自己组织的构件的时候，路由功能很有用。当你正尝试从一个Nexus组中解析一个构件的时候，Nexus路由十分适用；当Nexus从一组仓库中解析一个构件的时候，使用路由允许你更改Nexus将查阅的仓库。
Figure 16.14, “Nexus中的路由配置页面”显示了路由配置页面。在路由上点击会看到一个页面，能让你配置路由的属性。路由的可用配置选项是：
- URL模式
-
这是Nexus用来匹配请求的模式。如果这个模式与请求表达式匹配，Nexus就会在特定的构件查询中包含或者排除所列出的仓库。在Figure 16.14, “Nexus中的路由配置页面”中的两个模式是：
- .*/(com|org)/somecompany/.*
-
这个模式会匹配所有包含"/com/somecompany/"或者"/org/somecompany"的路径。圆括弧中的表达式匹配com或者org，"*"匹配一个或多个字符。你可以使用一个像这样的路由来匹配你自己组织的构件，并且将这样的请求对应到宿主的Nexus Releases及Snapshots仓库。
- .*/org/some-oss/.*
-
这个模式用作一个排除路由。它匹配所有包含"/org/some-oss/"的路径。这个特殊的排除路由为所有与该路径匹配的构件排除宿主的Releases和Snapshots仓库。当Nexus尝试解析与该路劲匹配的构件时，它会排除Releases和Snapshots仓库。
- 路由类型
-
路由类型可以是“包含”或者“排除”。一个包含路由类型定义了一组仓库，当URL模式匹配的时候这些仓库将被搜索。同样的情况下，一个排除路由定义的仓库则将不会被搜索。
- 有序路由仓库
-
这是一个Nexus用来搜索以寻找某个特殊构件的一个有序仓库列表。Nexus从上至下搜索；当它找某个构件的时候，会返回第一个匹配的结果。当它寻找元数据的时候，同一组中所有的仓库会被检查，并且最后返回一个归并的结果。归并的时候，前面的仓库拥有较高的优先权。当一个项目正在寻找
LATEST或者RELEASE版本的时候，这可能会影响结果。在一个Nexus组中，你应该在快照版仓库前定义发布版仓库，否则LATEST可能会错误的解析成一个快照版本。
在该图中你你能看到两个Nexus默认带有的假路由。第一个路由是一个包含路由，它是一个自定义路由的例子，一个组织可能用来确信内部生成的构件是从Releases和Snapshots仓库解析的。如果你组织的groupId都由com.somecompany开头，并且你们将内部生成的构件部署到了Releases和Snapshots仓库，该路由让Nexus不浪费时间去从公共的Maven仓库，如中央Maven仓库或者Apache Snapshots仓库，去解析构件。
第二个假路由是一个排除路由。当请求路径包含"/org/some-oss"的时候，路由会排除Releases和Snapshots仓库。如果我们使用"apache"或者"codehaus"替换"some-oss"，这个例子就可能更有意义了。如果这个模式是"/org/apache"，该规则告诉Nexus，当试图解析这些依赖的时候，排除内部的Releases和Snapshots仓库。换句话说，不要浪费时间从你组织的内部仓库中去寻找Apache依赖。
如果两个路由有冲突在怎么办？Nexus会在它处理排除路由之前处理包含路由。记住Nexus路由只会在当搜索一个组的时候影响Nexus解析构件。当Nexus开始从一个Nexus组中解析一个构件，它开始于组中的一个仓库列表。如果有匹配的包含路由，Nexus就会使用组中仓库和包含路由中仓库的交集。在Nexus组中定义的顺序不会受包含路由的影响。Nexus之后就会在这个新的组中应用排除路由。最后在这个结果列表中搜索匹配构件。
总结来说，路由还有很多Nexus的设计者们未预期到的创新可能性，但是，如果你开始信赖冲突或者重叠路由，我们还是建议你小心。保守使用路由，使用教程中的URL模式，随着Nexus的发展，将会有更多的特性允许更细类度的规则以让你阻止特定构件和特定构件版本的请求。记住路由只能用在Nexus组中，当从某个特定仓库中请求一个构件的时候，路由不会被用到。
