虚拟存储库最佳实践

“/repo”的悲伤故事

对于某些人来说，Artifactory通常希望的最终状态是让它只使用一个URL来满足所有工件下载需求。理论上，这听起来像是一个轻松的一站式购物解决方案。然而，这种类型的设置存在许多问题，并且Artifactory不支持这种方法。

作为最佳实践，一个虚拟存储库不应该聚合超过20个存储库。

/repo -全局虚拟

在Artifactory版本2和3中，有一个全局虚拟存储库被称为/回购，它聚合了Artifactory应用程序中发现的所有本地和远程存储库。由于Artifactory最初是一个小而专门的应用程序，所以事情开始得很好。用户会将他们的构建指向artifactory.com/repo并且知道他们能够将任何基于java的包拉到Artifactory中。

然而，问题很快就开始显现出来。

构建会从错误的存储库中提取错误的工件。Maven的Snapshot版本会根据首先解析的路径而急剧跳转。下载会花费很长时间，因为存储库必须聚合多个路径。Artifactory的开发使用理念导致了这个存储库的存在终身残疾在Artifactory 4.7.3。

我们得到了什么教训?

大型虚拟的问题

虚拟存储库聚合其他存储库。这应该能够顺利地扩展，但是当超过20个聚合存储库时就会出现问题(要知道所包含的存储库的规模会影响这个数字)。Artifactory必须执行计算事件在它的虚拟仓库里，每次都要为一个工件服务。这确保响应来自正确的存储库。虚拟存储库使用这个解析算法:

1. 提供在当地的存储库第一。
2. 提供在远程存储库缓存第二。
3. 下载和服务远程工件最后的

为了确定哪个存储库包含特定的工件，Artifactory必须检查虚拟中的每个存储库。的跟踪工件检索REST API可用于查看实际的逻辑。的最糟糕的情况如果工件位于虚拟列表的最后一个远程存储库中，该怎么办?如果一个给定的工件位于分辨率算法的底部(如上面的步骤#3所示)，它将花费更长的时间来下载直接拉动从远程存储库。

UI性能问题

在管理大型虚拟存储库时，还会出现其他更微妙的问题。由于Artifacts浏览器必须显示任何给定文件夹中的所有工件和子文件夹，因此虚拟存储库需要执行嵌套的检查来确定显示什么。这意味着检查每个远程端点，以及每个本地文件夹您的虚拟存储库正在聚合。

下面是一个只有远程存储库的2秒加载时间的例子:

在大多数情况下，虚拟存储库需要对多个远程端点完成许多HEAD请求。在一个大型虚拟存储库文件夹上，用户界面操作(比如打开一个文件夹)可能需要三十(30)秒才能完成。

聚合问题

虚拟存储库用于不同的存储库类型将有不同的逻辑处理程序。例如，如果两个Maven Snapshot构建共享相同的路径，虚拟存储库将根据解析顺序提供一个“不正确的”文件:

您可以通过更改存储库的解析顺序来修复这个特定的路径问题，但这是可以做到的打破使用相同的大型虚拟存储库的其他构建。

大型虚拟的替代方案

这很简单解决方案与管理大型虚拟存储库相关的问题-使用更具体、更小的虚拟存储库。有更少的限制可以在Artifactory中创建的虚拟存储库的数量。每个开发团队都可以构建自己的虚拟存储库，以适应特定的构建或项目需求。这也将存储库管理问题委托给对维护此类解决方案最感兴趣的特定方。