软件部署方法及装置
文献发布时间：2023-06-19 19:28:50
技术领域
本申请实施例涉及云计算技术领域，尤其涉及一种软件部署方法及装置。
背景技术
在步入云计算时代后，应用软件从单体架构向微服务架构转变，以云原生的微服务架构部署交付。如何实现快捷地部署、管理以及升级软件应用是目前要解决的关键问题。
在传统模式下，企业先提出自己的业务需求，软件开发人员针对企业的业务需求进行软件开发并上门部署、调试安装、升级并长期维护。
然而，传统模式下的软件部署流程工程浩大，完成所需时间较长，后续的调试、维护和升级都需要巨大且持续的成本投入。因此，传统模式的软件部署不适用于云环境，存在软件部署难度大、效率低的问题。
发明内容
本申请提供一种软件部署方法及装置，以解决软件部署难度大、效率低的问题。
第一方面，本申请提供一种软件部署方法，应用于云平台中的软件部署系统，所述云平台包括多个服务器，所述方法包括：
接收第一客户端发送的软件部署请求，所述软件部署请求用于请求在所述云平台中部署第一软件；
根据所述软件部署请求，确定所述第一软件对应的至少一个服务组件、以及在所述多个服务器中确定至少一个目标服务器；
根据所述至少一个服务组件，在所述至少一个目标服务器中部署所述第一软件。
在一种可能的设计中，所述根据所述至少一个服务组件，在所述至少一个目标服务器中部署所述第一软件，包括：
将所述至少一个服务组件部署至所述至少一个目标服务器；
确定所述至少一个服务组件之间的通信关系；
根据所述通信关系，设置所述至少一个服务组件之间的通信接口，具有通信关系的两个服务组件之间设置有通信接口；
在所述至少一个服务组件中确定入口服务组件。
在一种可能的设计中，所述将所述至少一个服务组件部署至所述至少一个目标服务器，包括：
确定每个服务组件对应的目标服务器；
针对任意一个服务组件，在所述服务组件对应的目标服务器中确定所述服务组件对应的第一容器，并将所述服务组件部署于所述第一容器中。
在一种可能的设计中，所述确定所述至少一个服务组件之间的通信关系，包括：
确定每个服务组件对应的目标服务器；
确定位于同一目标服务器中的服务组件之间具有通信关系；
在每个目标服务器中确定目标服务组件，并确定具有通信关系的两个目标服务器中的目标服务组件之间具有通信关系。
在一种可能的设计中，所述软件部署请求中包括所述M个服务组件的标识和每个服务组件的组件数量；根据所述软件部署请求，确定所述第一软件对应的至少一个服务组件，包括：
确定第i个服务组件的组件数量为N
确定所述第一软件对应的至少一个服务组件包括
在一种可能的设计中，所述软件部署请求中包括第一组件标识；在所述至少一个服务组件中确定入口服务组件，包括：
获取所述第一组件标识对应的组件数量；
若所述第一组件标识对应的组件数量为1，则将所述至少一个服务组件中所述第一组件标识对应服务组件确定为所述入口服务组件；
若所述第一组件标识对应的组件数量大于1，则根据所述第一组件标识对应的服务组件所在的目标服务器的剩余资源量，确定所述入口服务组件。
在一种可能的设计中，所述将所述服务组件部署在所述服务组件对应的第一容器中之后，包括：
获取所述第一客户端发送的软件升级请求，所述软件升级请求包括所述第一软件的标识和待升级服务组件的标识，所述待升级服务组件为新增服务组件或者更新服务组件；
根据所述软件升级请求，对所述第一软件进行升级处理。
在一种可能的设计中，所述待升级服务组件为新增服务组件；根据所述软件升级请求，对所述第一软件进行升级处理，包括：
获取所述新增服务组件；
在所述多个服务器中确定所述新增服务组件对应的第一服务器；
在所述第一服务器中确定所述新增服务组件对应的第二容器，将所述新增服务组件部署在第二容器中。
在一种可能的设计中，所述待升级服务组件为更新服务组件；根据所述软件升级请求，对所述第一软件进行升级处理，包括：
获取所述更新服务组件；
在所述多个服务器中确定所述更新服务组件对应的第二服务器；
在所述第二服务器中确定所述更新服务组件对应的第三容器，将所述更新服务组件部署在第三容器中；
确定所述更新服务组件对应的已有服务组件，并在所述云平台中删除所述已有服务组件，所述已有服务组件和所述更新服务组件的组件标识相同。
第二方面，本申请提供一种软件部署装置，包括：
接收模块，用于接收第一客户端发送的软件部署请求，所述软件部署请求用于请求在所述云平台中部署第一软件；
确定模块，用于根据所述软件部署请求，确定所述第一软件对应的至少一个服务组件、以及在所述多个服务器中确定至少一个目标服务器；
处理模块，用于根据所述至少一个服务组件，在所述至少一个目标服务器中部署所述第一软件。
在一种可能的设计中，所述处理模块具体用于：
将所述至少一个服务组件部署至所述至少一个目标服务器；
确定所述至少一个服务组件之间的通信关系；
根据所述通信关系，设置所述至少一个服务组件之间的通信接口，具有通信关系的两个服务组件之间设置有通信接口；
在所述至少一个服务组件中确定入口服务组件。
在一种可能的设计中，所述处理模块具体用于：
确定每个服务组件对应的目标服务器；
针对任意一个服务组件，在所述服务组件对应的目标服务器中确定所述服务组件对应的第一容器，并将所述服务组件部署于所述第一容器中。
在一种可能的设计中，所述处理模块具体用于：
确定每个服务组件对应的目标服务器；
确定位于同一目标服务器中的服务组件之间具有通信关系；
在每个目标服务器中确定目标服务组件，并确定具有通信关系的两个目标服务器中的目标服务组件之间具有通信关系。
在一种可能的设计中，所述软件部署请求中包括所述M个服务组件的标识和每个服务组件的组件数量；所述确定模块具体用于：
确定第i个服务组件的组件数量为N
确定所述第一软件对应的至少一个服务组件包括
在一种可能的设计中，所述软件部署请求中包括第一组件标识；所述处理模块具体用于：
获取所述第一组件标识对应的组件数量；
若所述第一组件标识对应的组件数量为1，则将所述至少一个服务组件中所述第一组件标识对应服务组件确定为所述入口服务组件；
若所述第一组件标识对应的组件数量大于1，则根据所述第一组件标识对应的服务组件所在的目标服务器的剩余资源量，确定所述入口服务组件。
在一种可能的设计中，所述处理模块具体用于：
获取所述第一客户端发送的软件升级请求，所述软件升级请求包括所述第一软件的标识和待升级服务组件的标识，所述待升级服务组件为新增服务组件或者更新服务组件；
根据所述软件升级请求，对所述第一软件进行升级处理。
在一种可能的设计中，所述处理模块具体用于：
获取所述新增服务组件；
在所述多个服务器中确定所述新增服务组件对应的第一服务器；
在所述第一服务器中确定所述新增服务组件对应的第二容器，将所述新增服务组件部署在第二容器中。
在一种可能的设计中，所述处理模块具体用于：
获取所述更新服务组件；
在所述多个服务器中确定所述更新服务组件对应的第二服务器；
在所述第二服务器中确定所述更新服务组件对应的第三容器，将所述更新服务组件部署在第三容器中；
确定所述更新服务组件对应的已有服务组件，并在所述云平台中删除所述已有服务组件，所述已有服务组件和所述更新服务组件的组件标识相同。
第三方面，本申请提供一种软件部署设备，包括：
存储器，用于存储程序；
处理器，用于执行所述存储器存储的所述程序，当所述程序被执行时，所述处理器用于执行如上第一方面以及第一方面各种可能的设计中任一所述的方法。
第四方面，本申请提供一种计算机可读存储介质，包括指令，当其在计算机上运行时，使得计算机执行如上第一方面以及第一方面各种可能的设计中任一所述的方法。
第五方面，本申请提供一种计算机程序产品，所述程序产品包括：计算机程序，所述计算机程序存储在可读存储介质中，电子设备的至少一个处理器可以从所述可读存储介质读取所述计算机程序，所述至少一个处理器执行所述计算机程序使得电子设备执行如上第一方面以及第一方面各种可能的设计中任一所述的方法。
本申请提供一种软件部署方法及装置，该方法包括：接收第一客户端发送的软件部署请求，软件部署请求用于请求在云平台中部署第一软件。根据软件部署请求，确定第一软件对应的至少一个服务组件、以及在多个服务器中确定至少一个目标服务器。根据至少一个服务组件，在至少一个目标服务器中部署第一软件。其中，软件部署系统接收第一客户端发送的软件部署请求来实现部署第一软件，根据软件部署请求确定为第一软件所需的至少一个服务组件，将第一软件所需的至少一个服务组件部署于云平台的服务器中，即实现了可以为第一客户端提供第一软件应用，这提升了软件部署的效率。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1为本申请所提供的一种应用场景；
图2为本申请实施例提供的软件部署方法的流程图一；
图3为本申请实施例提供的软件部署方法的流程图二；
图4为本申请实施例提供的将各服务组件储存于各自对应的目标服务器的示意图；
图5为本申请实施例提供的建立服务组件之间通信关系的示意图一；
图6为本申请实施例提供的建立服务组件之间通信关系的示意图二；
图7为本申请实施例提供的软件部署方法的流程图三；
图8为本申请实施例提供的软件部署装置的结构示意图；
图9为本申请实施例提供的软件部署设备的硬件结构示意图。
通过上述附图，已示出本申请明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本申请构思的范围，而是通过参考特定实施例为本领域技术人员说明本申请的概念。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。
为了便于理解本申请的技术方案，下面对本申请所涉及的相关概念、背景技术、现有技术、现有技术所存在的技术问题以及本申请的技术构思进行介绍：
云计算服务实现了将个人、企业所需的软硬件、资料都放到网络上，在任何时间、地点，使用不同的电子设备相互连接，实现存取、运算等目的。通过使计算分布在大量的分布式计算机上，而非本地计算机或远程服务器中，为个人或企业提供所需的存储、运算等能力。在步入云计算时代后，应用软件从单体架构向微服务架构转变，以云原生的微服务架构部署交付。如何实现快捷地部署、管理以及升级软件应用是目前要解决的关键问题。
在传统模式下，企业先提出自己的业务需求，软件开发人员针对企业的业务需求进行软件开发并上门部署、调试安装、升级并长期维护。
然而，传统模式下的软件部署流程工程浩大，完成所需时间较长，后续的调试、维护和升级都需要巨大且持续的成本投入。因此，传统模式的软件部署方式不适用于云环境，存在软件部署难度大、效率低的问题。
基于上述存在的问题，本申请提出了如下的技术构思：基于云计算服务模式，发明人考虑实现在云计算服务的基础上为个人、企业等用户提供相应的软件部署、升级等服务。具体的，考虑在云计算服务器端建立一个软件部署系统，在该软件部署系统中存储有多个软件各自对应的服务组件。其中，服务组件可以用于指示软件对应的多个微服务。这样一旦用户提出软件部署请求时，软件部署系统根据用户的软件部署请求，在云计算服务器上为用户部署软件气请求对应的软件所需的服务组件，以实现对用户所需软件的部署，从而用户可以通过云计算服务获取软件服务。同时，当用户提出软件升级请求时，软件部署系统可以根据用户的软件升级请求对用户所需升级软件进行升级，以满足用户对于软件的升级请求，从而用户可以通过云计算服务获取升级版本的服务。因此，这提升了软件部署的效率。
下面，结合图1，介绍本申请实施例的一种应用场景，图1为本申请所提供的一种应用场景。
请参见图1，包括云服务器，企业用户终端以及个体用户终端。其中，在云服务器中设置有软件部署系统。如图1所示，企业用户终端向云服务器发送软件部署请求，云服务器中的软件部署系统根据软件部署请求为企业用户在云服务器部署相应的软件。另外，个体用户终端向云服务器发送软件升级请求，软件部署系统根据软件升级请求针对个体用户在云服务器端所部署的软件中个体用户所需升级的软件进行升级处理，以满足个体用户对软件进行升级处理的需求。
下面，通过具体实施例，对本申请所示的技术方案进行详细说明。需要说明的是，下面几个实施例可以单独存在，也可以相互结合，对于相同或相似的内容，在不同的实施例中不再重复说明。
基于上述介绍的技术构思，下面结合图2和具体的实施例对本申请所提供的软件部署方法进行详细介绍，图2为本申请实施例提供的软件部署方法的流程图一。
如图2所示，该方法包括：
S201、接收第一客户端发送的软件部署请求，软件部署请求用于请求在云平台中部署第一软件。
本申请实施例的执行主体可以为云平台中的软件部署系统。
在本实施例中，第一客户端是指云平台的个体用户或企业用户所使用的设备终端。其中，电子设备可以为电脑、手机及平板等可与云平台进行通信的电子设备。
第一客户端在与云平台建立通信后，第一客户端可以向云平台发送软件部署请求。其中，软件部署请求用于请求为第一用户端在云平台部署软件。软件部署请求中包括：所请求部署软件的软件名称，所请求部署软件所需的服务组件，以及各服务组件所需要的数量。其中，服务组件例如可以为软件对应的微服务组件。
需要说明的是，微服务架构主要是中间层分解，将大的应用拆分成很多小应用，即每个小应用就为一个微服务。微服务可以部署在不同的服务器上，也可以部署在不同的容器上。这种微服务的架构的优点在于：当其中一个微服务出现故障时不会影响到其他微服务，或者，其中一个微服务的负载也不会影响到其他应用等。一个微服务代码只会关注一个特定的业务功能，所以一个微服务业务清晰，代码量较少。因此，对于微服务的部署和维护都会相对简单。
例如，云平台的部署系统收到的软件部署请求中包括所要求部署的软件名称为软件A，软件A所需的服务组件包括5个。其中，该5个服务组件分别为服务组件a、服务组件b、服务组件c、服务组件d以及服务组件e。以及该5个服务组件各自对应的部署数量。例如，该5个服务组件各自所需部署的数量为3、2、4、6、3。即要实现部署软件部署请求对应的软件，即需要部署3个服务组件a、2个服务组件b、4个服务组件c、6个服务组件d以及3个服务组件e。
S202、根据软件部署请求，确定第一软件对应的至少一个服务组件、以及在多个服务器中确定至少一个目标服务器。
基于上述步骤S201，以软件部署请求中包括所请求部署软件的软件名称、所请求部署软件所需的服务组件，以及各服务组件所需要的数量为例，对根据软件部署请求，进行软件部署的具体实现进行介绍。
下面，对确定第一软件对应的至少一个服务组件的一种可能的实现方式进行说明。
在一种可能的实现方式中，在软件部署系统中存储有各种服务组件，根据软件部署请求，软件部署系统首先在所存储的多种服务组件中找出所需的服务组件。以步骤S201中的软件部署请求为例进行说明。即软件部署请求中的第一软件为软件A，第一软件所需的服务组件包括5个，且5个服务组件分别为：服务组件a、服务组件b、服务组件c、服务组件d以及服务组件e。另外，该5个服务组件所需部署的数量分别为：3、2、4、6、3。因此，软件部署系统从所存储的多种服务组件中找出服务组件a、服务组件b、服务组件c、服务组件d以及服务组件e。之后，根据各服务组件所需部署的数量，对各服务组件进行部署，即确定了第一软件对应的至少一个服务组件。其中，同一时刻多个相同的服务组件中仅有一个处于正常工作状态，其他相同的服务组件处于待机状态。需要说明的是，其他相同的服务组件处于待机状态时可定时将正处于正常工作状态的服务组件上的运行数据等信息同步获取并存储于自身服务组件上。这可以有效保证当处于正常工作状态的服务组件出现故障，或该处于正常工作状态的服务组件所处的服务器发生故障或可用资源过低时，在其他相同的服务组件中选择一个服务组件可以立即进入正常工作状态，这保证了软件应用的正常运行。
需要说明的是，软件部署系统需要为各个服务组件确定所部署的目标服务器。
下面，对在多个服务器中确定至少一个目标服务器的一种可能的实现方式进行说明。
在一种可能的实现方式中，软件部署系统获取各个服务器的资源可用率。其中，各服务器对应的资源可用率为该服务器的可用资源的数量与该服务器的所有资源的总数量的比值。根据各服务器的资源可用率的情况，为服务组件确定对应的目标服务器。需要说明的是，各服务组件所占的内存大小、运行所需资源大小以及运行产生的数据所占的内存大小可以是相同的也可以为不同的，对此不作限定。例如，在为每个服务组件确定所存储的服务器的过程中，针对多个服务器中的任意一个可以通过判断该服务器对应的资源可用率是否大于或等于预设阈值，来确定是否在该服务器中存储服务组件。具体的，若该服务器对应的资源可用率大于或等于预设阈值，则确定可以在该服务器中存储服务组件；若该服务器对应的资源可用率小于预设阈值，则确定不可以在该服务器中存储服务组件。
S203、根据至少一个服务组件，在至少一个目标服务器中部署第一软件。
基于上述步骤S202，确定了第一软件对应的至少一个服务组件、以及在多个服务器中确定至少一个目标服务器。接下来，将第一软件对应的至少一个服务组件，部署于至少一个目标服务器中，以实现第一软件的成功部署。
在一种可能的实现方式中，将每个服务组件部署在该服务组件对应的目标服务器中。通过接口的方式，实现将第一软件对应的服务组件两两相连，以使第一软件对应的至少一个服务组件在均能够正常工作，即第一软件对应的各种功能的服务组件均能正常工作，即实现了第一软件的成功部署。
本申请实施例提供的软件部署方法，包括：接收第一客户端发送的软件部署请求，软件部署请求用于请求在云平台中部署第一软件。根据软件部署请求，确定第一软件对应的至少一个服务组件、以及在多个服务器中确定至少一个目标服务器。根据至少一个服务组件，在至少一个目标服务器中部署第一软件。其中，软件部署系统接收第一客户端发送的软件部署请求来实现部署第一软件，根据软件部署请求确定为第一软件所需的至少一个服务组件，将第一软件所需的至少一个服务组件部署于云平台的服务器中，即实现了可以为第一客户端提供第一软件应用，这提升了软件部署的效率。
在上述实施例的基础上，下面结合一个具体的实施例对本申请提供的软件部署方法进行进一步的介绍，结合图3进行介绍，图3为本申请实施例提供的软件部署方法的流程图二。
如图3所示，该方法包括：
S301、接收第一客户端发送的软件部署请求，软件部署请求用于请求在云平台中部署第一软件。
其中，步骤S301与步骤S201的实现方式类似，在此不再赘述。
S302、确定第i个服务组件的组件数量为N
S303、确定第一软件对应的至少一个服务组件包括
接下来，对步骤S302与步骤S303放在一起介绍。
在本实施例中，软件部署系统获取到来自第一客户端的软件部署请求，该软件部署请求中包括M个服务组件的标识和每个服务组件所需的组件数量。
例如，第一软件所需的服务组件包括5个，该5个服务组件分别为服务组件a、服务组件b、服务组件c、服务组件d以及服务组件e。同时，该5个服务组件各自所需部署的数量为3、2、4、6、3。因此，第1个服务组件为服务组件a,且第一个服务组件的组件数量为N
在确定了第一软件所需的服务组件以及各服务组件对应的组件数量的基础上。接下来，确定第一软件对应的服务组件的总数量。
在上述例子的基础上，根据第一软件所需的服务组件以及各服务组件对应的组件数量，来确定的第一软件对应的至少一个服务组件。
其中，该第一软件对应的至少一个服务组件所包括的服务组件的总数量为：N
S304、根据软件部署请求，确定第一软件对应的至少一个服务组件、以及在多个服务器中确定至少一个目标服务器。
其中，步骤S304与步骤S202中的实现方式类似，在此不再赘述。
S305、确定每个服务组件对应的目标服务器。
S306、针对任意一个服务组件，在服务组件对应的目标服务器中确定服务组件对应的第一容器，并将服务组件部署于第一容器中。
接下来，对步骤S305与步骤S306放在一起进行说明。
下面，对在多个服务器中确定至少一个目标服务器的一种可能的实现方式进行说明。
在一种可能的实现方式中，软件部署系统获取各个服务器的资源可用率。其中，各服务器对应的资源可用率为该服务器的可用资源的数量与该服务器的所有资源的总数量的比值。根据各服务器的资源可用率的情况，为服务组件确定对应的目标服务器。需要说明的是，各服务组件所占的内存大小、运行所需资源大小以及运行产生的数据所占的内存大小可以是不同的也可以为不同的，对此不作限定。例如，在为每个服务组件确定所存储的服务器的过程中，针对多个服务器中的任意一个可以通过判断该服务器对应的资源可用率是否大于或等于预设阈值，来确定是否在该服务器中存储服务组件。具体的，若该服务器对应的资源可用率大于或等于预设阈值，则确定可以在该服务器中存储服务组件；若该服务器对应的资源可用率小于预设阈值，则确定不可以在该服务器中存储服务组件。
在计算机领域中，容器是指与系统其它部分分离隔开的一系列进程。
在一种可能的实现方式中，针对各服务部件，在各服务组件对应的目标服务器中设置一个容器，即服务组件对应的第一容器；在第一容器设置在服务组件对应的目标服务器中，将服务组件部署于该服务组件对应的第一容器中。
下面，结合图4和一个具体示例，对该种可能的实现方式进行进一步介绍，图4为本申请实施例提供的将各服务组件储存于各自对应的目标服务器的示意图。
参照图4，根据各目标服务器的资源可用率，为各服务组件确定的各自对应的目标服务器。如图4所示，为3个服务组件a确定的目标服务器分别为目标服务器1、目标服务器3以及目标服务器5；为2个服务组件b确定的目标服务器分别为目标服务器2和目标服务器6；为4个服务组件c确定的目标服务器分别为目标服务器2、目标服务器3、目标服务器5以及目标服务器6；为6个服务组件d确定的目标服务器分别为目标服务器1、目标服务器2、目标服务器3、目标服务器4以及目标服务器5；为3个服务组件e确定的目标服务器分别为目标服务器3、目标服务器4以及目标服务器5。
S307、确定位于同一目标服务器中的服务组件之间具有通信关系。
基于上述步骤S305和步骤S306，为每个服务组件确定了对应的目标服务器中以及将服务组件部署于该服务组件对应的第一容器中。需要说明的是，在同一目标服务器中存在同时部署多个服务组件的情况。
下面，以步骤S303中各服务组件储存于各自对应的目标服务器为例，下面对确定位于同一目标服务器中的服务组件之间具有通信关系的一种可能的实现方式进行示例性说明。
在一种可能的实现方式中，首先确定第一软件中的各服务组件所部署的目标服务器。接下来，针对各目标服务器，考虑在各目标服务器中所部署的第一软件的至少一个服务组件中，将在距离最近的两个服务组件之间建立通信关系。
下面，结合图4和图5，通过一个具体示例，对该种可能的实现方式进行说明，图5为本申请实施例提供的建立服务组件之间通信关系的示意图一。
例如，根据图4可以确定在各目标服务器中所部署第一软件的各个服务组件的具体情况。具体的，在目标服务器1中，部署了服务组件a和服务组件d；在目标服务器2中，部署了服务组件b、服务组件c以及服务组件d；在目标服务器3中，部署了服务组件a、服务组件d以及服务组件e；在目标服务器4中，部署了服务组件c、服务组件d以及服务组件e；在目标服务器4中，部署了服务组件a、服务组件d以及服务组件e；在目标服务器5中，部署了服务组件a、服务组件c、服务组件d以及服务组件e；在目标服务器6中，部署了服务组件b、服务组件c以及服务组件d。接下来，参照图5，为各目标服务器中确定服务组件之间通信关系。如图5所示，在目标服务器1中，将在服务组件a和服务组件d之间建立通信关系，以实现目标服务器中各服务组件之间的互相通信。在目标服务器2中，将在服务组件b和服务组件d之间建立通信关系，以及在服务组件d和服务组件c之间建立通信关系，以实现目标服务器2中各服务组件之间的互相通信。在目标服务器3中，将在服务组件e和服务组件a之间建立通信关系，以及在服务组件a和服务组件d之间建立通信关系，以实现目标服务器3中各服务组件之间的互相通信。同理，对目标服务器4、目标服务器5以及目标服务器6中服务组件之间的通信关系进行确定，在此不再赘述。
S308、在每个目标服务器中确定目标服务组件，并确定具有通信关系的两个目标服务器中的目标服务组件之间具有通信关系。
上述步骤S307，是对处于同一目标服务器内的服务组件之间通信关系进行确定的一种方法。接下来，将为部署于不同目标服务器的服务组件建立通信关系，以使在处于不同目标服务器的服务组件之间建立通信关系。在每个服务组件中确定目标服务组件。若在目标服务器中存在一个服务组件，则此服务组件作为目标服务组件。若在目标服务器中存在两个或两个服务组件以上，则将其中一个服务组件确定为目标服务组件，在剩余的服务组件中挑选一个作为目标服务组件，即若在目标服务器中存在两个或两个服务组件以上，则在此目标服务器中需确定两个目标服务组件。
下面，结合图6和一个具体的示例，对该种可能的实现方式进行说明，图6为本申请实施例提供的建立服务组件之间通信关系的示意图二。
参见图6，以目标服务器2、目标服务器3以及目标服务器4为例进行说明。在目标服务器2中将服务组件b作为目标服务组件，以及将服务组件c作为目标服务组件；在目标服务器3中将服务组件e作为目标服务组件，以及将服务组件d作为目标服务组件；在目标服务器4中将服务组件c作为目标服务组件，以及将服务组件e作为目标服务组件。那么，如图6所示，通过在目标服务器2中服务组件c和目标服务器3中服务组件d之间建立通信关系，以及，通过在目标服务器3中服务组件e和目标服务器4中服务组件c之间建立通信关系，来实现目标服务器2、3、4中的服务组件之间的通信。
S309、根据通信关系，设置至少一个服务组件之间的通信接口，具有通信关系的两个服务组件之间设置有通信接口。
基于上述步骤S307以及步骤S308，确定了位于同一目标服务器中的服务组件之间具有通信关系，以及，确定具有通信关系的两个目标服务器中的目标服务组件之间具有通信关系。
下面，根据服务组件之间的通信关系，对设置至少一个服务组件之间的通信接口的一种可能的实现方式进行说明。
在一种可能的实现方式中，在具有通信关系的两个服务组件所在的第一容器上设置通信接口，来实现服务组件之间的通信。
S310、获取第一组件标识对应的组件数量。
需要说明的是，在第一软件的各个服务组件中会选择其中一个服务组件作为入口服务组件，也就是说，第一组件标识对应的服务组件会作为第一软件应用的服务入口。
例如，在步骤S303中例子的基础上，对获取第一组件标识对应的组件数量进行说明。若从软件部署请求中获取到第一组件标识为服务组件c。同时，可以从软件服务请求中获取服务组件c所需的部署数量为4。将服务组件c所需的部署数量确定为第一组件标识对应的组件数量。例如，服务组件c所需的部署数量为4，即获取到了第一组件标识(服务组件c)对应的组件数量。
S311、若第一组件标识对应的组件数量为1，则将至少一个服务组件中第一组件标识对应的服务组件确定为入口服务组件。
在本实施例中，由于第一软件中的第一组件标识对应的服务组件的数量至少为一个。而第一软件仅有一个入口服务组件。也就是说，需要根据第一软件中第一组件标识对应的组件数量，来确定入口服务组件。
在本实施例中，若第一软件中第一组件标识对应的组件数量为1，则第一组件标识对应的服务组件确定为入口服务组件。
S312、若第一组件标识对应的组件数量大于1，则根据第一组件标识对应的服务组件所在的目标服务器的剩余资源量，确定入口服务组件。
在一种可能的实现方式中，当在第一软件中第一组件标识对应的组件数量大于1时，根据第一组件标识对应的服务组件所在的目标服务器的剩余资源量，将剩余资源量最大的目标服务器确定为中的服务组件标识为第一组件标识确定为入口服务组件。
本申请实施例提供的软件部署方法，包括：确定第i个服务组件的组件数量为N
在上述实施例的基础上，下面结合一个具体的实施例对本申请提供的软件部署方法进行进一步的介绍，结合图7进行介绍，图7为本申请实施例提供的软件部署方法的流程图三。
如图7所示，该方法包括：
S701、获取第一客户端发送的软件升级请求，软件升级请求包括第一软件的标识和待升级服务组件的标识，待升级服务组件为新增服务组件或者更新服务组件。
需要说明的是，随着用户需求的不断提高，软件功能也在不断升级。用户会根据自己的需要选择是否提出软件升级请求。若用户选择提出软件升级请求，用户会通过该第一客户端发送软件升级请求，以使请求软件部署系统对软件进行升级。
其中，软件升级请求中包括第一软件的标识和待升级服务组件的标识。需要强调说明的是，软件升级是对第一软件中的至少一个服务组件进行升级。将需要升级的服务组件称为待升级服务组件。具体的，根据软件升级的具体情况可以分为两种：一种为第一软件新增服务组件，另一种为对第一软件已有的服务组件进行更新。
因此，接下来在软件升级的过程中，需要判断具体判断待升级服务组件为新增服务组件还是更新服务组件。
S702、获取新增服务组件。
在本实施例中，当获取到第一客户端发送的软件升级请求时，根据软件请求中的第一软件的标识以及待升级服务组件的标识。当在第一软件中不存在与待升级服务组件的标识相同的服务组件时，则该待升级服务组件为新增服务组件。
在一种可能的实现方式中，软件部署系统从所存储的多种服务组件中找出服务组件标识为待升级服务组件标识的服务组件，即获取到新增服务组件。
S703、在多个服务器中确定新增服务组件对应的第一服务器。
在一种可能的实现方式中，获取各服务器的资源可用率，将资源可用率最大的服务器确定为该新增服务器对应的第一服务器。
在本实施例中，只是对在多个服务器中确定新增服务组件对应的第一服务器进行示例性的说明，并不是对在多个服务器中确定新增服务组件对应的第一服务器的实现方式做以限制，对在多个服务器中确定新增服务组件对应的第一服务器的实现方式可以根据实际需求进行选择。
S704、在第一服务器中确定新增服务组件对应的第二容器，将新增服务组件部署在第二容器中。
基于上述步骤为新增服务组件确定了新增服务组件所部署的第一服务器，接下来在第一服务器中创建一个第二容器，将新增服务组件部署于第二容器中。
S705、获取更新服务组件。
在本实施例中，当获取到第一客户端发送的软件升级请求时，根据软件请求中的第一软件的标识以及待升级服务组件的标识。当在第一软件中存在与待升级服务组件的标识相同的服务组件时，则该待升级服务组件为更新服务组件。
在一种可能的实现方式中，软件部署系统从所存储的多种服务组件中找出服务组件标识为待升级服务组件标识的服务组件，即获取到更新服务组件。
S706、在多个服务器中确定更新服务组件对应的第二服务器。
在一种可能的实现方式中，获取各服务器的资源可用率，将资源可用率最大的服务器确定为该更新服务器对应的第二服务器。
在本实施例中，只是对在多个服务器中确定更新服务组件对应的第二服务器进行示例性的说明，并不是对在多个服务器中确定更新服务组件对应的第二服务器的实现方式做以限制，对在多个服务器中确定更新服务组件对应的第二服务器的实现方式可以根据实际需求进行选择。
S707、在第二服务器中确定更新服务组件对应的第三容器，将更新服务组件部署在第三容器中。
基于上述步骤为更新服务组件确定了更新服务组件所部署的第二服务器，接下来在第二服务器中创建一个第三容器，将更新服务组件部署于第三容器中。
S708、确定更新服务组件对应的已有服务组件，并在云平台中删除已有服务组件，已有服务组件和更新服务组件的组件标识相同。
在本实施例中，当软件部署系统将更新服务组件成功部署于第二服务器中的第三容器时，软件部署系统确定在第一软件中与更新服务组件对应的已有的服务组件，其中，已有服务组件和服务组件的组件标识相同。
接下来，软件部署系统在云平台将第一软件中与更新服务组件对应的已有服务组件删除掉。
本申请实施例提供的软件部署方法，包括：获取第一客户端发送的软件升级请求，软件升级请求包括第一软件的标识和待升级服务组件的标识，待升级服务组件为新增服务组件或者更新服务组件。获取新增服务组件。在多个服务器中确定新增服务组件对应的第一服务器。在第一服务器中确定新增服务组件对应的第二容器，将新增服务组件部署在第二容器中。获取更新服务组件。在多个服务器中确定更新服务组件对应的第二服务器在第二服务器中确定更新服务组件对应的第三容器，将更新服务组件部署在第三容器中。确定更新服务组件对应的已有服务组件，并在云平台中删除已有服务组件，已有服务组件和更新服务组件的组件标识相同。其中，第一客户端向云服务器发送软件升级请求，软件部署系统根据软件升级请求对云服务器端所需升级的软件进行升级处理，以满足第一客户端对软件进行升级处理的需求。
图8为本申请实施例提供的软件部署装置的结构示意图。如图8所示，该装置800包括：接收模块801、确定模块802以及处理模块803。
接收模块801，用于接收第一客户端发送的软件部署请求，所述软件部署请求用于请求在所述云平台中部署第一软件；
确定模块802，用于根据所述软件部署请求，确定所述第一软件对应的至少一个服务组件、以及在所述多个服务器中确定至少一个目标服务器；
处理模块803，用于根据所述至少一个服务组件，在所述至少一个目标服务器中部署所述第一软件。
在一种可能的设计中，所述处理模块803具体用于：
将所述至少一个服务组件部署至所述至少一个目标服务器；
确定所述至少一个服务组件之间的通信关系；
根据所述通信关系，设置所述至少一个服务组件之间的通信接口，具有通信关系的两个服务组件之间设置有通信接口；
在所述至少一个服务组件中确定入口服务组件。
在一种可能的设计中，所述处理模块803具体用于：
确定每个服务组件对应的目标服务器；
针对任意一个服务组件，在所述服务组件对应的目标服务器中确定所述服务组件对应的第一容器，并将所述服务组件部署于所述第一容器中。
在一种可能的设计中，所述处理模块803具体用于：
确定每个服务组件对应的目标服务器；
确定位于同一目标服务器中的服务组件之间具有通信关系；
在每个目标服务器中确定目标服务组件，并确定具有通信关系的两个目标服务器中的目标服务组件之间具有通信关系。
在一种可能的设计中，所述软件部署请求中包括所述M个服务组件的标识和每个服务组件的组件数量；所述确定模块802具体用于：
确定第i个服务组件的组件数量为N
确定所述第一软件对应的至少一个服务组件包括
在一种可能的设计中，所述软件部署请求中包括第一组件标识；所述处理模块803具体用于：
获取所述第一组件标识对应的组件数量；
若所述第一组件标识对应的组件数量为1，则将所述至少一个服务组件中所述第一组件标识对应服务组件确定为所述入口服务组件；
若所述第一组件标识对应的组件数量大于1，则根据所述第一组件标识对应的服务组件所在的目标服务器的剩余资源量，确定所述入口服务组件。
在一种可能的设计中，所述处理模块803具体用于：
获取所述第一客户端发送的软件升级请求，所述软件升级请求包括所述第一软件的标识和待升级服务组件的标识，所述待升级服务组件为新增服务组件或者更新服务组件；
根据所述软件升级请求，对所述第一软件进行升级处理。
在一种可能的设计中，所述处理模块803具体用于：
获取所述新增服务组件；
在所述多个服务器中确定所述新增服务组件对应的第一服务器；
在所述第一服务器中确定所述新增服务组件对应的第二容器，将所述新增服务组件部署在第二容器中。
在一种可能的设计中，所述处理模块803具体用于：
获取所述更新服务组件；
在所述多个服务器中确定所述更新服务组件对应的第二服务器；
在所述第二服务器中确定所述更新服务组件对应的第三容器，将所述更新服务组件部署在第三容器中；
确定所述更新服务组件对应的已有服务组件，并在所述云平台中删除所述已有服务组件，所述已有服务组件和所述更新服务组件的组件标识相同。
本实施例提供的装置，可用于执行上述方法实施例的技术方案，其实现原理和技术效果类似，本实施例此处不再赘述。
图9为本申请实施例提供的软件部署设备的硬件结构示意图，如图9所示，本实施例的软件部署设备900包括：处理器901以及存储器902；其中
存储器902，用于存储计算机执行指令；
处理器901，用于执行存储器存储的计算机执行指令，以实现上述实施例中软件部署方法所执行的各个步骤。具体可以参见前述方法实施例中的相关描述。
可选地，存储器902既可以是独立的，也可以跟处理器901集成在一起。
当存储器902独立设置时，该软件部署设备还包括总线903，用于连接所述存储器902和处理器901。
本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，实现如上软件部署设备所执行的软件部署方法。
本申请实施例还提供一种计算机程序产品，程序产品包括：计算机程序，计算机程序存储在可读存储介质中，电子设备的至少一个处理器可以从可读存储介质读取计算机程序，至少一个处理器执行计算机程序使得电子设备执行上述任一实施例提供的方案。
在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。例如，以上所描述的设备实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。
上述以软件功能模块的形式实现的集成的模块，可以存储在一个计算机可读取存储介质中。上述软件功能模块存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(英文：processor)执行本申请各个实施例所述方法的部分步骤。
应理解，上述处理器可以是中央处理单元(英文：Central Processing Unit，简称：CPU)，还可以是其他通用处理器、数字信号处理器(英文：Digital Signal Processor，简称：DSP)、专用集成电路(英文：Application Specific Integrated Circuit，简称：ASIC)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合发明所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。
存储器可能包含高速RAM存储器，也可能还包括非易失性存储NVM，例如至少一个磁盘存储器，还可以为U盘、移动硬盘、只读存储器、磁盘或光盘等。
总线可以是工业标准体系结构(Industry Standard Architecture，ISA)总线、外部设备互连(Peripheral Component，PCI)总线或扩展工业标准体系结构(ExtendedIndustry Standard Architecture，EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，本申请附图中的总线并不限定仅有一根总线或一种类型的总线。
上述存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。存储介质可以是通用或专用计算机能够存取的任何可用介质。
本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。