一、背景

制品，artifact，也称为工件，是指在构建或持续集成过程中从源码创建而成的二进制包，而这些二进制包通常是通过赋予其的版本号来唯一定位和管理的。制品仓库，artifact repository，则是存储和管理这些版本化的二进制包，并对外提供检索和访问方法的应用程序。

制品仓库通常分为*仓库、企业仓库和本地仓库。*仓库面向公众开放，存储和管理预先构建好的二进制包，通常提供软件开发的各种公共框架和通用工具库，如面向Java的Maven*仓库，面向Docker镜像的DockerHub等。企业仓库则通常位于企业或团队内部，一是缓存并统一管理*仓库的公共制品供内部使用，以提升访问效率并加强监管，二是用于存储和管理企业或团队自身创建而成的各种制品，包括最终交付的应用，或者企业或团队内部使用的公共库等。本地仓库则是构建系统的缓存，记录构建过程中所需及创建的各种制品，并与*仓库或企业仓库交互，完成制品在不同仓库之间的传递。

在当前的DevOps体系当中，企业制品仓库已成为其中的一个重要环节，除了存储和管理制品之外，还需要和持续集成、自动测试、持续部署，以及管理、审批等各种系统进行对接和协同，实现信息的集成、共享和流转，从而实现流水线式的持续交付。此外，企业制品仓库也是企业信息安全管理中的重要节点，只有通过安全审计的制品才能够被纳入到企业制品仓库，以实现企业持续交付流水线当中的受信源。
目前世界500强中93%的企业，全球共有5000家以上的企业都已经放弃了Sonatype的Nexus而使用JFrog的方案。 为什么会是这样？本文根据二者最新的发展情况，从制品管理的各个角度列出二者的技术现状加以比较，相信大家能够清晰地得到结论。

二、制品管理的概览比较

首先，本文从作为企业制品仓库所需的主要技术要求对二者做一个概览的比较：

从中可以看出，JFrog的产品支持的语言包类型更为丰富，高可用、定制化扩展，以及元数据等技术方案更为完备，而且提供了Sonatype工具所不具备的复制同步能力，能够更好的支持跨地域的团队协同。

我们再从更细节一些的技术点对二者进行比较，如下图所示：

从中可以看出，JFrog能够支持代理更多类型的*制品仓库，并且能够提供Docker镜像的分层展示。另外，在制品存储、增强查询等方面，JFrog也提供了更多的支持。
所以，仅从概览来看，JFrog无疑比Sonatype具备更为丰富和全面的能力。

三、制品管理的方案比较

第二部分对JFrog和Sonatype的产品特点进行了概览的比较，本节将从二者的方案特点进行更为全面的分析。
首先来看二者的商业模式，如下图所示：

JFrog提供了更为灵活自主的试用方式：在本地化部署的基础上，也提供了对于云端和混合云架构的支持，能够适应客户不同的基础架构需求；而且，具备大规模的可扩展性，能够帮助客户节省成本。
再从部署方式来看，如下图：

JFrog提供了丰富、全面、自动化的部署方式，包括面向Kubernetes环境的Helm Chart编排，方便了产品的部署应用。
再来看可扩展性，如下图：

可以看出，JFrog能够全面支持企业级应用的扩展需求，并保证其稳定性。
当前的开发环境更多的是团队协作方式，从而要求制品仓库也能够支持跨数据中心、跨城市，甚至跨国的协同工作。二者在团队协同方面的特点如下图所示：

很明显，JFrog面向多团队、跨地域的协同工作提供了丰富、全面的解决方案，而Sonatype只能支持单数据中心的应用模式。
在当前的DevOps体系当中，制品仓库需要能够与持续交付工具链中的其他系统很好的集成与对接，而从这一角度来看，二者的技术特点如下图所示：

JFrog全面的API覆盖、全功能的CLI工具，以及自定义的元数据等能力使得其制品仓库能够方便、全面地和客户现有的环境和工具进行集成与对接，从而方便地建设全面、一致的DevOps方案。此外，JFrog还提供了功能扩展的用户插件框架，支持定制化的二次开发。在这一方面，Sonatype只能提供有限的支持。
从最基本的制品管理的能力来看，JFrog是唯一真正的全语言支持，如下图所示：

而从制品的存储方式来看，JFrog提供了更为丰富的解决方案，能够适应客户不同的业务需求，从而更大程度地节约成本。如下图所示：

最后，从制品仓库的认证安全管理体系来看，JFrog提供了更广泛的访问、认证方式，以及灵活的权限体系，如下图所示：

综合上面的比较可以看出，从作为企业制品仓库所需的各个技术层面和细节来看，JFrog的产品和方案无疑成熟度更高，能够为企业提供更为丰富、全面、强大且灵活的支持，而Sonatype的产品和方案只能在受限的范围内提供支持。这也正是目前JFrog在全球商业制品库市场占有率第一的原因所在。

四、DevSecOps的方案比较

在当下软件应用的开发过程当中，自研的内部代码所占的比例逐步地减少，开源的框架和共用库已经得到了广泛的引用。然而，开源软件的大量引用也给我们的应用带来了安全隐患。据统计，目前14%的NPM包、30%的Docker Hub镜像都包含安全漏洞，而Maven包里有59%的已知安全漏洞还没有得到修复，而漏洞的平均修复时间是290天，最严重级别漏洞的平均修复时间也仅是265天。因此，提供针对外来制品的安全检测，构建制品受信源，已成为当前DevOps体系中对企业制品仓库的重要需求。
要想实现实现及时、准确的制品安全扫描，首先要基于准确、全面的安全漏洞数据库。JFrog和Sonatype使用的安全漏洞数据库情况如下图所示：

可见，在NVD（美国国家漏洞数据库）提供的CVE（公共漏洞和暴露）的基础上，JFrog还提供了VulnDB这一商业漏洞数据库。而VulnDB提供了更大范围的安全漏洞数据，如下图所示：

JFrog和Sonatype的安全检测方案都可以与企业的CI/CD流水线集成。然而支持的程度还是有所不同的，如下图所示：

从上图可以看出，JFrog的方案能够覆盖更为广泛的DevOps的链条，从而将传统的DevOps过程扩展成为DevSecOps，这也是业界当前的发展方向。
JFrog的方案能够在DevOps的各个阶段提供安全漏洞监控方面的支持，如下图:

而且，JFrog的方案还能够将安全漏洞的监控扩展到研发或生产过程中。JFrog提供的KubeXray能够在Kubernetes的运行环境中检测并处理POD的安全漏洞问题，如下图:

而通过与IDE，如IntelliJ IDEA、Eclipse、Visual Studio等的结合，JFrog使得开发人员在开发过程中就能够时刻关注和了解应用的安全状况，从而实现安全扫描的左移。如下图：

除了发现制品的安全漏洞之外，JFrog还提供了针对安全漏洞的精准定位和影响范围分析的能力，使得安全漏洞的发现和修复更加精准和全面。如下图:

综上所述，JFrog是目前能够唯一提供端到端DevSecOps支持的企业制品仓库产品，除了提供最完整的商业漏洞数据库外，JFrog的产品和方案还唯一实现了安全漏洞的跨语言种类的深层次精准定位和影响范围分析。

五、总结

企业制品仓库已成为企业建设DevOps体系的重要环节，除了基本的制品存储与管理外，还需要能够与DevOps全链条实现对接与集成，并提供安全漏洞扫描与监控，建设企业可信源，从而实现完整的DevSecOps解决方案。
通过本文的对比和分析可以清楚地看出，JFrog的产品和解决方案无疑是更为全面、更为丰富、更为灵活、更为强大的选择。