Artifactory 版本：4.15.0 或最新
摘要（可选信息，但可以帮助任何人更好地理解我的情况）：
- Build+Test 管道以 jar/war/zip/tar/rpms 等形式生成工件。
- 一旦这些工件被生成并存储在 Artifactory 中，它们通常与构建/测试相关的属性（即构建时间、构建 url、使用的构建工具、测试通过状态、测试覆盖率等与给定的工件相关联），我想挑选这些工件用于创建多个子系统级别的版本，因为每个子系统都有来自不同管道（服务/应用程序/项目）的不同工件。
- 子系统级别的发布只是告诉，为项目的给定版本选择给定的 jar/war/zip/rpm 等（确保完成一些测试，一些工件属性通过/匹配定义的选择标准），基本上结束子系统发布的结果是该子系统级别的部署清单文件。
- 一些子系统版本包含公共工件（可来自各种项目的共享），一些包含为目标部署环境（子系统或更高级系统版本）创建的特定工件。
- 部署和测试在每个子系统级别完成，一旦它们通过了一组测试、性能基准等，在给定的部署+测试环境级别（针对该子系统版本）的所有部署+测试相关属性都将应用于包含的所有工件，即使该子系统发布的所有工件。
现在，系统级版本包含许多子系统级版本，即它们引用许多子系统级版本或子系统级清单文件（任何通用/终端系统特定子系统的 JSON 格式）。我知道，欢乐时光。
最后，部署和测试在系统级别执行，并且来自任何子系统发布级别工件（通用/特定环境）和任何其他“全局工件”（共同构成完整的系统级别发布）的所有工件都使用这些属性进行标记.
应用/拥有属性背后的想法（服务/应用程序级别 - 构建+测试，子系统和系统发布级别）应用于任何“项目级别工件（jar/war/rpms/zip/tar/etc） ” pipeline/automation-deploy/test 步骤，即：用户可以随时通过传递一组属性轻松查询 Artifactory，以获取任何服务/应用程序/子系统/的工件（rpms/zip/tar/etc..）系统级别，用于部署/测试它。
--
我正在研究一种解决方案，用于发布依赖/基于工件属性（Artifactory）的各种管道，并想知道在将“ N 个属性”应用于工件或使用的值类型方面是否有任何建议或限制？
如果 Artifactory 中附加到工件的属性数量超过一定数量，是否会对性能产生影响？
OR我打算使用
的属性值类型（键=值对）采用以下形式：
prop1="value1" or numberValue
prop2=[value1, value2]
prop3={..JSON blob ..}
只是想看看是否有人遇到过此类限制的任何问题（如果有的话）。我检查了 Artifactory 网站和其他博客，但找不到任何关于属性数量或与属性关联的值类型的限制以及它们在查询或使用 Artifactory 属性时如何影响 Artifactory 性能的任何信息。