CN112463181A - 多云场景下的软件制品分发方法、装置、设备和存储介质 - Google Patents

Abstract

本申请涉及多云场景下的软件制品分发方法、装置、设备和存储介质，属于互联网领域，所述方法包括：从第一数据源获取在持续集成、研发环境和测试环境下产生的数据，分析这些数据，得到软件制品的服务依赖关系以作为基础依赖需求；从第二数据源获取多云区域分别在各自的业务运行场景下产生的数据，分析这些数据，得到各云区域的软件制品的服务依赖关系以作为各云区域的实际依赖需求；将各云区域的实际依赖需求分别和基础依赖需求进行汇总，生成各云区域的分发规则；按照各分发规则，向各云区域分发软件制品。能够节约带宽成本和存储成本同时提高软件制品的分发效率。

Description

多云场景下的软件制品分发方法、装置、设备和存储介质

技术领域

本申请涉及互联网技术领域，特别是涉及多云场景下的软件制品分发方法、装置、设备和存储介质。

背景技术

随着物联网应用软件交付能力的提升，持续集成与持续交付（CI/CD）已成为众多企业软件研发与交付流程的标准配置。随着云产品与技术的发展，对各种云场景下的软件提升可靠性及多地域交付特性的需求被提出。以下，对常见的几种云环境进行简单介绍：“公有云”是为大众建的云服务，各用户可以通过互联网来获取云端资源的使用，其优势是成本低且扩展性好，缺点是保密数据的安全性低；“私有云”是为使用者单独使用而构建的云服务，保密数据的安全性高；“混合云”包含公有云和私有云，集公有云的方便便捷与私有云的安全稳定为一体；“多云”是一种云架构，由多个云服务组合而成，既可以包含公共云，也可以包含私有云。

特别是，在“混合云”、“多云”等环境下，针对软件的交付，需要将CI/CD流程的产物即软件制品（通常为“软件包”或“容器镜像”）推送到各个云的制品库中，以便在部署时进行使用。其中，软件制品是指由源码编译打包生成的二进制文件，不同的开发语言对应着不同格式的二进制文件，这些二进制通常可以直接运行在服务器上。制品库用以管理源代码编译后的构建产物，支持 Docker、Maven、Helm、npm、PyPI 包等常见制品库类型。制品库可以跟源代码协同进行版本化控制，可以与本地各构建工具和云上的持续集成、持续部署无缝结合，并支持漏洞扫描等特性，是一种企业处理软件开发过程中产生的所有包类型的标准化方式。

目前软件制品一般通过客户端上传到公有云或私有云制品库，或通过集成第三方SDK对软件制品进行自动分发。而这些方式存在以下缺陷：

（1）在微服务成熟的当下，业务的新增速度很快，每次新增业务都要对分发策略进行更新，易存在配置遗漏造成分发的软件制品不全，而且，人工配置效率较低。

（2）不同云区域的业务运行环境中服务依赖情况可能不同，按同一策略分发软件制品至各个云区域，不仅提高了分发的带宽成本和对软件制品的存储成本，造成资源浪费，还影响分发效率。

目前针对相关技术中如何节约带宽成本和存储成本同时提高软件制品的分发效率，尚未提出有效的解决方案。

发明内容

本申请实施例提供了一种多云场景下的软件制品分发方法、装置、设备和存储介质，以至少解决相关技术中如何节约带宽成本和存储成本同时提高软件制品的分发效率的问题。

第一方面，本申请实施例提供了一种多云场景下的软件制品分发方法，包括：从第一数据源获取在持续集成、研发环境和测试环境下产生的第一数据，分析所述第一数据，得到软件制品的服务依赖关系以作为基础依赖需求；从第二数据源获取多云区域分别在各自的业务运行场景下产生的第二数据，分析所述第二数据，得到各所述云区域的软件制品的服务依赖关系以作为各所述云区域的实际依赖需求；将各所述云区域的所述实际依赖需求分别和所述基础依赖需求进行汇总，生成各所述云区域的分发规则；按照各所述分发规则，向各所述云区域分发软件制品。

在其中一些实施例中，所述第一数据源包括CMDB（Configuration ManagementDatabase，配置管理数据库）、链路跟踪***、配置中心和Helm Chart中的至少一种。

在其中一些实施例中，所述第二数据源包括链路跟踪***、配置中心、日志分析器和网络流量分析器中的至少一种。

在其中一些实施例中，在所述第一数据源为CMDB和/或配置中心的情况下，所述的从第一数据源获取在持续集成、研发环境和测试环境下产生的第一数据，分析所述第一数据，得到软件制品的服务依赖关系以作为基础依赖需求包括：从所述CMDB和/或所述配置中心获取在持续集成、研发环境和测试环境下产生的第一数据，该第一数据以Key-Value键值对的形式保存；通过比对键值对的关键词，将与服务依赖有关的信息筛选出来；对筛选后的信息去重，得到软件制品的服务依赖关系以作为基础依赖需求。

在其中一些实施例中，所述分发规则由依赖需求列表呈现，在所述的按照各所述分发规则，向各所述云区域分发软件制品之后，所述方法还包括：定期更新并剔除所述依赖需求列表中过期的依赖需求。

在其中一些实施例中，在生成各所述云区域的分发规则之后，所述多云场景下的软件制品分发方法还包括：根据各所述云区域的所述实际依赖需求，对各所述云区域的所述依赖需求列表进行校正和补充，其中，所述实际依赖需求包括线上服务配置数据和软件调用历史数据。

在其中一些实施例中，所述的按照各所述分发规则，向各所述云区域分发软件制品包括：在具有制品库的公有云或私有云的场景下，通过客户端或SDK上传软件制品；当提供容器镜像仓库时，通过Docker客户端镜像上传软件制品；在没有制品库的公有云或私有云的场景下，使用HTTP、FTP、SFTP、或SSH协议上传软件制品。

第二方面，本申请实施例提供了一种多云场景下的软件制品分发装置，包括：外部数据源对接模块、依赖分析处理模块、依赖汇总存储模块和制品分发模块，其中，外部数据源对接模块用于从第一数据源获取在持续集成、研发环境和测试环境下产生的第一数据；从第二数据源获取多云区域分别在各自的业务运行场景下产生的第二数据；依赖分析处理模块用于分析所述第一数据，得到软件制品的服务依赖关系以作为基础依赖需求；分析各所述云区域的所述第二数据，得到各所述云区域的软件制品的服务依赖关系以作为各所述云区域的实际依赖需求；依赖汇总存储模块用于将各所述云区域的所述实际依赖需求分别和所述基础依赖需求进行汇总，生成各所述云区域的分发规则；制品分发模块用于按照各所述分发规则，向各所述云区域分发软件制品。

第三方面，本申请实施例提供了一种电子设备，包括处理器和存储有计算机程序的存储介质，所述计算机程序被所述处理器执行时实现如上述任一项所述的多云场景下的软件制品分发方法。

第四方面，本申请实施例提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如上述任一项所述的多云场景下的软件制品分发方法。

根据上述内容，本申请实施例的多云场景下的软件制品分发方法，包括：从第一数据源获取在持续集成、研发环境和测试环境下产生的数据，分析这些数据，得到软件制品的服务依赖关系以作为基础依赖需求；从第二数据源获取多云区域分别在各自的业务运行场景下产生的数据，分析这些数据，得到各云区域的软件制品的服务依赖关系以作为各云区域的实际依赖需求；将各云区域的实际依赖需求分别和基础依赖需求进行汇总，生成各云区域的分发规则；按照各分发规则，向各云区域分发软件制品。能够针对各云区域自动化配置分发规则（即依赖需求），提高了配置效率；而且，基于分发规则，实现了对不同业务场景下的云区域按需分发软件制品，避免按同一策略将所有软件制品都分发至各个云区域，节约了带宽成本和存储成本同时提高了软件制品的分发效率。另外，及时剔除过期的依赖服务可以减少软件制品的非必要同步，降低存储成本和带宽成本，并提高同步的效率。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据本申请实施例的多云场景下的软件制品分发方法的流程图；

图2是根据本申请实施例的多云场景下的软件制品分发方法的各阶段示意图；

图3是根据本申请实施例的多云场景下的软件制品分发装置和各数据源的关系示意图；

图4是根据本申请实施例的电子设备的结构框图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行描述和说明。应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。基于本申请提供的实施例，本领域普通技术人员在没有作出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

如上文所述，通过传统的人工配置手段来配置软件制品的分发策略，显然已经不适用于如今微服务遍地开花的现代互联网。在拥有成千上万微服务的环境内，人工配置出错后的纠正和在这过程中的效率降低都是企业成本的增加。

本申请实施例主要从以下两个角度解决目前存在的技术问题：

（1）自动获取服务依赖关系（即依赖需求），免除人工配置：

依靠现有的能反应软件服务依赖关系的数据源，从中获取数据，整合得到各云区域的分发规则，在进行软件制品的上传（包括同步）时，只需要对照各分发规则，即可自动化分发软件制品到需要运行此软件的云端。

（2）针对多云区域，独立分析分发规则，降低冗余，节省存储成本：

将基础依赖需求和运行时的实际依赖需求分开获取并计算，由此可以得出每个云区域的分发规则，从而根据各分发规则对各云区域按需分发软件制品，避免“一股脑”地将所有软件制品按统一分发策略分发到所有的云区域，由于存储和带宽都需要付费，且部分地区收费较高，如国内往海外交付软件制品，所以本申请实施例提供的多云场景下的软件制品分发方法能够节约存储成本和带宽成本，同时提高软件制品的分发效率。

下文所记载的“依赖”、“依赖关系”、“依赖项”、“服务依赖”、“服务依赖关系”、“依赖需求”、“软件调用依赖”均指软件服务上下游的依赖关系，不同的用语表达既为了语句通顺，也为了方便读者理解。图1是根据本申请实施例的多云场景下的软件制品分发方法的流程图，如图1所示，该流程包括：

S100：从第一数据源获取在持续集成、研发环境和测试环境下产生的第一数据，分析第一数据，得到软件制品的服务依赖关系以作为基础依赖需求；

S200：从第二数据源获取多云区域分别在各自的业务运行场景下产生的第二数据，分析第二数据，得到各云区域的软件制品的服务依赖关系以作为各云区域的实际依赖需求；

S300：将各云区域的实际依赖需求分别和基础依赖需求进行汇总，生成各云区域的分发规则；

S400：按照各分发规则，向各云区域分发软件制品。

根据上述内容，能够针对各云区域自动化配置分发规则，提高了配置效率；而且，基于分发规则，实现了对不同业务场景下的云区域按需分发软件制品，避免按同一策略将所有软件制品都分发至各个云区域，节约了带宽成本和存储成本同时提高了软件制品的分发效率。

以下，对本申请实施例的多云场景下的软件制品分发方法的各步骤进行详细的说明。

步骤S100：从第一数据源获取在持续集成、研发环境和测试环境下产生的第一数据，分析第一数据，得到软件制品的服务依赖关系以作为基础依赖需求。图2是根据本申请实施例的多云场景下的软件制品分发方法的各阶段示意图，请参阅图2 所示，在持续集成、研发与测试阶段，从第一数据源（最好是多种数据源）获取第一数据，该第一数据是元数据，为各个第一数据源自身记录的业务信息，分析第一数据，得到软件制品上下游的服务依赖关系，其中，第一数据源包括但不限于CMDB、链路跟踪***、配置中心、Helm Chart。

具体的，上述CMDB通常为关系型数据库，包含了配置项全生命周期的信息以及配置项之间的关系(包括物理关系、实时通信关系、非实时通信关系和依赖关系)；上述链路跟踪***通常为基于OpenTracing规范实现的分布式链路跟踪服务，可以采集服务调用过程中一系列的过程信息；上述配置中心通常配置了应用依赖的数据库、中间件、其他软件服务的地址及相关参数，以文本的形式保存，可以对关键词进行提取来判断是否有依赖关系；上述Helm Chart：容器部署编排服务Helm的编排管理文件，由于本身就是用作服务的编排，可以直接从中解析出服务的依赖关系。其中，优选获取CMDB的数据，CMDB作为配置管理数据库，是最被企业广泛应用的基础设施，从中获取数据较为容易。

作为一个示例，首先，寻找合适的记录了持续集成、研发环境和测试环境下的服务依赖关系的第一数据源并进行对接。服务依赖关系通常可以通过一些外部***来获得，如上述的CMDB和/或配置中心。具体的，可以通过API接口获取数据，这些数据通常以Key-Value键值对的形式保存，再通过比对键值对的关键词，将与服务依赖有关的信息筛选出来。关键词对比就是对比各种基建和服务的名字在配置的依赖项里有没有，如关键词为mysql，kafka，foo，bar，其中mysql和kafka是常见基建，foo和bar为公司内部其他服务的名字，例如，通过API接口读取配置中心的数据，得到两个键值对：mysql_addr: 127.0.0.1和mysql_port: 3306，这两个键值对的信息为软件的服务依赖，意味着，提供mysql数据库服务的地址信息是：addr: 127.0.0.1和port: 3306。接着，对筛选后的信息去重，得到软件制品的服务依赖关系以作为基础依赖需求。从而可以针对新创建的服务，在软件制品未进行分发时，就获取其与已上线服务的依赖关系。例如，此阶段得到的基础依赖需求为：

。

步骤S200：从第二数据源获取多云区域分别在各自的业务运行场景下产生的第二数据，分析第二数据，得到各云区域的软件制品的服务依赖关系以作为各云区域的实际依赖需求。上述第二数据源包括但不限于链路跟踪***、配置中心数据、日志分析器，企业可能还有别的可以直接或间接反馈分析服务间调用的产品，如“网络流量分析器”。上述第二数据是元数据，为各个第二数据源自身记录的业务信息。优选的，获取配置中心的数据，通常软件在各个环境的差异均由不同的配置带来，配置中也往往较准确的反应了应用在当前环境的依赖项。需要说明的是，步骤S100和步骤S200中的数据源均可替代，只要能反应真实的软件调用依赖即可。只是，步骤S100中的第一数据源更侧重软件生产运行阶段即生产环境中能使用的数据源，该第一数据源更侧重于各种配置的依赖项；步骤S200中的第二数据源更侧重于对实际中软件调用依赖的分析。上述的侧重比较符合当前互联网公司普遍现状。

请继续参阅图2所示，例如多云区域包含云区域α和云区域β，该云区域α和云区域β可以是私有云、公有云等任意一种形式的场景。在云区域α的业务运行场景下，采集第二数据源产生的数据，然后分析出软件上下游的服务依赖关系以作为该云区域α的实际依赖需求，例如为：

。

同理，在云区域β的业务运行场景下，采集第二数据源产生的数据，此处需要说明的是，由于云区域α和云区域β各自的业务运行场景可以是独立的，所以对云区域β的第二数据源的选择可以不同于对云区域α的第二数据源的选择。然后，根据采集的数据分析出软件上下游的服务依赖关系以作为该云区域β的实际依赖需求，例如为：

。

步骤S300：将各云区域的实际依赖需求分别和基础依赖需求进行汇总，生成各云区域的分发规则。基于以上步骤S100和步骤S200，针对云区域α，可以将该云区域α的实际依赖需求和上述基础依赖需求进行汇总，从而得到该云区域α的分发规则为：

该分发规则可以由依赖需求列表呈现，该依赖需求列表包含该云区域α的实际依赖需求和基础依赖需求汇总后的依赖需求。

同理，针对云区域β，可以将该云区域β的实际依赖需求和上述基础依赖需求进行汇总，从而得到该云区域β的分发规则为：

该分发规则可以由依赖需求列表呈现，该依赖需求列表包含该云区域β的实际依赖需求和基础依赖需求汇总后的依赖需求。

步骤S400：按照各分发规则，向各云区域分发软件制品。例如，在往云区域α进行软件制品的分发（包括同步）时，能通过判断软件制品是否在云区域α的依赖需求列表内来决定是否要将软件制品发送（包括同步）至云区域α的制品库；在往云区域β进行软件制品的分发（包括同步）时，能通过判断软件制品是否在云区域β的依赖需求列表内来决定是否要将软件制品发送（包括同步）至云区域β的制品库。

以上多云区域包括云区域α和云区域β仅作为示意性的举例，实际上，本申请实施例的多云区域可以包含两个以上的云区域，这些云区域可以是私有云，也可以是公有云。

因此，本申请实施例的多云场景下的软件制品分发方法能够对不同业务场景下的云区域按需分发软件制品，避免“一股脑”地将所有的软件制品按统一分发策略分发到所有的云区域，从而达到节约存储成本和带宽成本同时提高软件制品分发效率的目的。进一步举例，若按照传统的软件制品分发方法，云区域x和云区域y对应的统一分发策略包含依赖需求{a,b,c,d,e,f,g,h}，则需要根据依赖需求{a,b,c,d,e,f,g,h}来发送软件制品至云区域x和云区域y。而采用本申请实施例的方案，例如分析出基础依赖需求为{a,b,c}，云区域x的实际依赖需求为{d,e,f}，云区域y的实际依赖需求为{g,h}，那么汇总后，得到云区域x的依赖需求列表包括依赖需求{a,b,c,d,e,f}，云区域y的依赖需求列表包括依赖需求{a,b,c,g,h}，然后分别按照各自的依赖需求列表向云区域x和云区域y分发软件制品。可见，上述过程实现了按需分发软件制品，不仅减少了软件制品的发送总量，降低带宽成本，提高分发效率，而且，云区域x和云区域y分别接收（包括同步）的软件制品总量降低，节约了存储成本。

值得说明的是，本申请实施例不仅要收集基础依赖需求还要收集各云区域的实际依赖需求，是因为，上述基础依赖需求仅代表***中有记录的及非线上运行过程中的依赖，并不能覆盖软件实际运行过程的依赖，一般软件在各个环境有不同配置的依赖项，因此在各个环境中的依赖也不尽相同。

本申请实施例不仅要收集各云区域的实际依赖需求还要收集基础依赖需求，是因为，现在软件迭代速度较快，很多软件都是以微服务的架构部署，服务间新增依赖需求较为普遍，当服务新增了依赖需求且并未上线运行时，其依赖关系能被线下***记录或探查，从而可以提前准备好对应的软件制品。

因此，根据以上内容，可以生成为各云区域定制的交付需求（即分发规则），并应用到软件制品的自动分发流程中。从而能够按照各分发规则向各云区域分发软件制品。

另外，经过提取、分析和汇总后，获得的目标数据可以反映服务间的调用和依赖关系，不仅可以用作制品交付分发的依据，还可以用于“服务安全行分析”、“服务网络流量分析”等技术。

本申请实施例中，针对软件制品的上传（包括同步）也存在多种方式，在具有制品库的公有云或私有云的场景下，例如包括：

（1）兼容多种格式的制品库：利用其专用的客户端或SDK进行上传；

（2）对象存储服务：通过客户端或SDK将软件制品上传，部署时下载软件制品；

（3）容器镜像仓库：利用Docker客户端进行镜像上传。

作为一个示例，使用公有云或私有云制品库服务的客户端或SDK来进行软件制品的分发。在没有制品库的公有云或私有云的场景下，可以使用HTTP、FTP、SFTP或SSH等通用协议作为软件制品的分发方式。

针对软件制品的分发方法，作为一种实施方式，可以围绕软件制品的“多副本同步”功能，如开源容器镜像中心“Harbor”，提供容器镜像“多副本同步”的功能，并在同步功能中，可以通过正则表达式过滤特定的、符合需求的制品。但这类功能无法满足“按需同步”的需求。

因此，进一步的，本申请实施例的多云场景下的软件制品分发方法还包括：根据各云区域的实际依赖需求，对各云区域的依赖需求列表进行校正和补充，其中，该实际依赖需求包括线上服务配置数据和软件调用历史数据。从而能够根据线上的实际运行情况来更新依赖需求列表，达到按需同步的目的。例如，当某一云区域新增业务（即新增依赖项的配置）时，该云区域的依赖需求列表也会更新，从而实现按需同步。

进一步的，定期更新并剔除依赖需求列表中过期的依赖，通过及时剔除过期的服务依赖可以减少软件制品的非必要同步，降低带宽成本和存储成本，同时提高软件制品的分发效率。可选的，若规定期限内在依赖需求列表中未检测到曾存在的依赖项，即可判断此依赖项的服务在对应的云区域已下线。

本申请实施例还提供一种多云场景下的软件制品分发装置，该装置用于实现上述实施例及优选实施方式。如以下所使用的术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。图3是根据本申请实施例的多云场景下的软件制品分发装置和各数据源的关系示意图，如图3所示，该装置包括：外部数据源对接模块、依赖分析处理模块、依赖汇总存储模块和制品分发模块，其中：

上述外部数据源对接模块用于从第一数据源获取在持续集成、研发环境和测试环境下产生的数据；从第二数据源获取多云区域分别在各自的业务运行场景下产生的数据。该模块包含整合各个数据源的API对接层，用于发起请求获取数据，并序列化、格式标准化。

上述依赖分析处理模块，用于分析第一数据，得到软件制品的服务依赖关系以作为基础依赖需求；分析各云区域的第二数据，得到各云区域的软件制品的服务依赖关系以作为各云区域的实际依赖需求，其中，第一数据和第二数据为元数据，是各个数据源自身记录的业务信息。例如，利用获取的数据进行核心关键词、键值对的比对，分析得到依赖需求。

上述依赖汇总存储模块，用于将各云区域的实际依赖需求分别和基础依赖需求进行汇总，生成各云区域的分发规则，并对生成的结果进行持久化存储。

上述制品分发模块，用于按照各分发规则，向各云区域分发软件制品。例如，使用公有云制品库服务的客户端或SDK或互联网内通用传输协议将软件制品分发（包括同步）到各个云区域的制品库。

作为一种实施方式，上述多云场景下的软件制品分发装置的各模块执行以下步骤：

步骤1：外部数据源对接模块对接各个数据源API，接受到元数据信息，元数据是各个数据源自身记录的业务信息；

步骤2：对步骤1中获取的数据在依赖分析处理模块中进行处理，通过关键词匹配的方法，将元数据中与服务依赖有关的信息筛选出来，对筛选的信息去重后交给依赖汇总存储模块；

步骤3：依赖汇总存储模块对各云区域分析依赖需求以产生依赖需求列表，并对生成的各云区域的依赖需求列表进行持久化存储，将其提供给制品分发模块，制品分发模块在需要时可以调用该依赖需求列表的数据。如果是发布区域的数据，需要对齐进行定期更新，及时剔除已下线的服务。

步骤4：制品分发模块在进行软件制品的分发（包括同步）时，根据步骤3中产生的依赖需求列表，即可将软件制品分发到对应的云区域，继而可以将软件制品按需分发到对应的云区域制品库。

需要说明的是，上述各个模块可以是功能模块也可以是程序模块，既可以通过软件来实现，也可以通过硬件来实现。对于通过硬件来实现的模块而言，上述各个模块可以位于同一处理器中；或者上述各个模块还可以按照任意组合的形式分别位于不同的处理器中。

本申请实施例还提供一种电子设备，图4是根据本申请实施例的电子设备的结构框图，如图4所示，该电子设备可以包括处理器81以及存储有计算机程序指令的存储器82。

具体地，上述处理器81可以包括中央处理器（CPU），或者特定集成电路（Application Specific Integrated Circuit，简称为ASIC），或者可以被配置成实施本申请实施例的一个或多个集成电路。

其中，存储器82可以包括用于数据或指令的大容量存储器。举例来说而非限制，存储器82可包括硬盘驱动器（Hard Disk Drive，简称为HDD）、软盘驱动器、固态驱动器（SolidState Drive，简称为SSD）、闪存、光盘、磁光盘、磁带或通用串行总线（Universal SerialBus，简称为USB）驱动器或者两个或更多个以上这些的组合。在合适的情况下，存储器82可包括可移除或不可移除（或固定）的介质。在合适的情况下，存储器82可在数据处理装置的内部或外部。在特定实施例中，存储器82是非易失性（Non-Volatile）存储器。在特定实施例中，存储器82包括只读存储器（Read-Only Memory，简称为ROM）和随机存取存储器（RandomAccess Memory，简称为RAM）。在合适的情况下，该ROM可以是掩模编程的ROM、可编程ROM（Programmable Read-Only Memory，简称为PROM）、可擦除PROM（Erasable ProgrammableRead-Only Memory，简称为EPROM）、电可擦除PROM（Electrically Erasable ProgrammableRead-Only Memory，简称为EEPROM）、电可改写ROM（Electrically Alterable Read-OnlyMemory，简称为EAROM）或闪存（FLASH）或者两个或更多个以上这些的组合。在合适的情况下，该RAM可以是静态随机存取存储器（Static Random-Access Memory，简称为SRAM）或动态随机存取存储器（Dynamic Random Access Memory，简称为DRAM），其中，DRAM可以是快速页模式动态随机存取存储器（Fast Page Mode Dynamic Random Access Memory，简称为FPMDRAM）、扩展数据输出动态随机存取存储器（Extended Date Out Dynamic RandomAccess Memory，简称为EDODRAM）、同步动态随机存取内存（Synchronous Dynamic Random-Access Memory，简称SDRAM）等。

存储器82可以用来存储或者缓存需要处理和/或通信使用的各种数据文件，以及处理器81所执行的可能的计算机程序指令。

处理器81通过读取并执行存储器82中存储的计算机程序指令，以实现上述实施例中的任意一种多云场景下的软件制品分发方法。

在其中一些实施例中，电子设备还可包括通信接口83和总线80。其中，如图4所示，处理器81、存储器82、通信接口83通过总线80连接并完成相互间的通信。

通信接口83用于实现本申请实施例中各模块、装置、单元和/或设备之间的通信。通信接口83还可以实现与其他部件例如：外接设备、图像/数据采集设备、数据库、外部存储以及图像/数据处理工作站等之间进行数据通信。

总线80包括硬件、软件或两者，将电子设备的部件彼此耦接在一起。总线80包括但不限于以下至少之一：数据总线（Data Bus）、地址总线（Address Bus）、控制总线（ControlBus）、扩展总线（Expansion Bus）、局部总线（Local Bus）。举例来说而非限制，总线80可包括图形加速接口（Accelerated Graphics Port，简称为AGP）或其他图形总线、增强工业标准架构（Extended Industry Standard Architecture，简称为EISA）总线、前端总线（FrontSide Bus，简称为FSB）、超传输（Hyper Transport，简称为HT）互连、工业标准架构（Industry Standard Architecture，简称为ISA）总线、无线带宽（InfiniBand）互连、低引脚数（Low Pin Count，简称为LPC）总线、存储器总线、微信道架构（Micro ChannelArchitecture，简称为MCA）总线、***组件互连（Peripheral Component Interconnect，简称为PCI）总线、PCI-Express（PCI-X）总线、串行高级技术附件（Serial AdvancedTechnology Attachment，简称为SATA）总线、视频电子标准协会局部（Video ElectronicsStandards Association Local Bus，简称为VLB）总线或其他合适的总线或者两个或更多个以上这些的组合。在合适的情况下，总线80可包括一个或多个总线。尽管本申请实施例描述和示出了特定的总线，但本申请考虑任何合适的总线或互连。

另外，结合上述实施例中的多云场景下的软件制品分发方法，本申请实施例可提供一种计算机可读存储介质来实现。该计算机可读存储介质上存储有计算机程序指令；该计算机程序指令被处理器执行时实现上述实施例中的任意一种多云场景下的软件制品分发方法。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (9)

1.一种多云场景下的软件制品分发方法，其特征在于，包括：

从第一数据源获取在持续集成、研发环境和测试环境下产生的第一数据，分析所述第一数据，得到软件制品的服务依赖关系以作为基础依赖需求，其中，所述第一数据源包括CMDB、链路跟踪***、配置中心和Helm Chart中的至少一种；

从第二数据源获取多云区域分别在各自的业务运行场景下产生的第二数据，分析所述第二数据，得到各所述云区域的软件制品的服务依赖关系以作为各所述云区域的实际依赖需求；

将各所述云区域的所述实际依赖需求分别和所述基础依赖需求进行汇总，生成各所述云区域的分发规则；

按照各所述分发规则，向各所述云区域分发软件制品。

2.根据权利要求1所述的多云场景下的软件制品分发方法，其特征在于，所述第二数据源包括链路跟踪***、配置中心、日志分析器和网络流量分析器中的至少一种。

3.根据权利要求1所述的多云场景下的软件制品分发方法，其特征在于，在所述第一数据源为CMDB和/或配置中心的情况下，所述的从第一数据源获取在持续集成、研发环境和测试环境下产生的第一数据，分析所述第一数据，得到软件制品的服务依赖关系以作为基础依赖需求包括：

从所述CMDB和/或所述配置中心获取在持续集成、研发环境和测试环境下产生的第一数据，该第一数据以Key-Value键值对的形式保存；

通过比对键值对的关键词，将与服务依赖有关的信息筛选出来；

对筛选后的信息去重，得到软件制品的服务依赖关系以作为基础依赖需求。

4.根据权利要求1所述的多云场景下的软件制品分发方法，其特征在于，所述分发规则由依赖需求列表呈现，在所述的按照各所述分发规则，向各所述云区域分发软件制品之后，所述方法还包括：

定期更新并剔除所述依赖需求列表中过期的依赖需求。

5.根据权利要求4所述的多云场景下的软件制品分发方法，其特征在于，在生成各所述云区域的分发规则之后，所述方法还包括：

根据各所述云区域的所述实际依赖需求，对各所述云区域的所述依赖需求列表进行校正和补充，其中，所述实际依赖需求包括线上服务配置数据和软件调用历史数据。

6.根据权利要求1所述的多云场景下的软件制品分发方法，其特征在于，所述的按照各所述分发规则，向各所述云区域分发软件制品包括：

在具有制品库的公有云或私有云的场景下，通过客户端或SDK上传软件制品；当提供容器镜像仓库时，通过Docker客户端镜像上传软件制品；

在没有制品库的公有云或私有云的场景下，使用HTTP、FTP、SFTP、或SSH协议上传软件制品。

7.一种多云场景下的软件制品分发装置，其特征在于，包括：

外部数据源对接模块，用于从第一数据源获取在持续集成、研发环境和测试环境下产生的第一数据；从第二数据源获取多云区域分别在各自的业务运行场景下产生的第二数据；

依赖分析处理模块，用于分析所述第一数据，得到软件制品的服务依赖关系以作为基础依赖需求；分析各所述云区域的所述第二数据，得到各所述云区域的软件制品的服务依赖关系以作为各所述云区域的实际依赖需求；

依赖汇总存储模块，用于将各所述云区域的所述实际依赖需求分别和所述基础依赖需求进行汇总，生成各所述云区域的分发规则；

制品分发模块，用于按照各所述分发规则，向各所述云区域分发软件制品。

8.一种电子设备，包括处理器和存储有计算机程序的存储介质，其特征在于，所述计算机程序被所述处理器执行时实现如权利要求1至6中任一项所述的多云场景下的软件制品分发方法。

9.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至6中任一项所述的多云场景下的软件制品分发方法。

Images