一种软件工程管理方法、装置、存储介质及电子设备与流程

本申请涉及软件工程管理领域，具体而言，涉及一种软件工程管理方法、装置、存储介质及电子设备。

背景技术：

由于dmallos前期系统研发按照互联网企业系统拆分方式进行，导致各个业务条线的子系统拆分较细，子系统的数量较多。仅供应链与iot研发部下应用的数量可达400+，庞大的子系统大幅增加了开发、维护等方面的复杂度和成本。dmallos在后续的迭代过程中，需要通过制定一定的规范来合理的控制os的子系统的数量。

随着业务的快速发展，无论业务所含领域复杂度的高低、无论业务实际流量的大小、无论应用定级的重要与否，应用都采用先垂直后水平的业务模块拆分，再按类似后台管理服务(web)、对外提供api服务(rpc)、定时任务执行服务(job)和异步消息处理服务(mq)等不同特性的服务来部署，带来的是业务系统数量和部署实例数量的高速增涨。因此，急需一种软件工程管理方法，能随着业务的发展，灵活的进行业务领域的伸缩部署，从而做到业务系统数量和部署实例尽可能与业务实际发展需求尽可能相符。

技术实现要素：

本申请的目的在于提供一种软件工程管理方法、装置、存储介质及电子设备，以至少部分改善上述问题。

为了实现上述目的，本申请实施例采用的技术方案如下：

第一方面，本申请实施例提供一种软件工程管理方法，应用于电子设备，所述方法包括：

依据配置信息中的目标业务领域构建本地包，其中，所述本地包包括运行所述目标业务领域的运行逻辑；

依据预先设置的部署规则，在所述本地包的基础上，构建完整部署包；

其中，所述完整部署包用于在目标虚拟机内部运行，以完成所述目标业务领域对应的作业，所述完整部署包包括所述部署规则，所述部署规则包含所述目标虚拟机加载各个运行逻辑的加载方式。

第二方面，本申请实施例提供一种软件工程管理装置，应用于电子设备，所述装置包括：

业务领域模块，用于依据配置信息中的目标业务领域构建本地包，其中，所述本地包包括运行所述目标业务领域的运行逻辑；

部署模块，用于依据预先设置的部署规则，在所述本地包的基础上，构建完整部署包；

其中，所述完整部署包用于在目标虚拟机内部运行，以完成所述目标业务领域对应的作业，所述完整部署包包括所述部署规则，所述部署规则包含所述目标虚拟机加载各个运行逻辑的加载方式。

第三方面，本申请实施例提供一种存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述的方法。

第四方面，本申请实施例提供一种电子设备，所述电子设备包括：处理器和存储器，所述存储器用于存储一个或多个程序；当所述一个或多个程序被所述处理器执行时，实现上述的方法。

相对于现有技术，本申请实施例所提供的一种软件工程管理方法、装置、存储介质及电子设备，依据配置信息中的目标业务领域构建本地包，其中，本地包包括运行目标业务领域的运行逻辑；依据预先设置的部署规则，在本地包的基础上，构建完整部署包；其中，完整部署包用于在目标虚拟机内部运行，以完成目标业务领域对应的作业，完整部署包包括部署规则，部署规则包含目标虚拟机加载各个运行逻辑的加载方式。工程师可以根据需要支撑的业务改变配置信息，从而确定目标业务领域，生成对应的本地包。当完成部署后，即生成了可以支撑对应业务的虚拟机应用，简单快捷，效率高。

为使本申请的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它相关的附图。

图1为本申请实施例提供的电子设备的结构示意图；

图2为本申请实施例提供的软件工程管理方法的流程示意图；

图3为本申请实施例提供的目标业务领域示意图；

图4为本申请实施例提供的软件工程管理方法的流程示意图之一；

图5为本申请实施例提供的s101的子步骤示意图；

图6为本申请实施例提供的软件工程管理装置的模块示意图。

图中：10-处理器；11-存储器；12-总线；13-通信接口；业务领域模块-201；部署模块-202。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。

因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本申请的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

在本申请的描述中，需要说明的是，术语“上”、“下”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，或者是该申请产品使用时惯常摆放的方位或位置关系，仅是为了便于描述本申请和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本申请的限制。

在本申请的描述中，还需要说明的是，除非另有明确的规定和限定，术语“设置”、“连接”应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本申请中的具体含义。

下面结合附图，对本申请的一些实施方式作详细说明。在不冲突的情况下，下述的实施例及实施例中的特征可以相互组合。

本申请意在提供一种可灵活伸缩支撑业务域的软件工程管理方法，从工程结构上支持应用支撑业务领域的数据量可多可少，从工程结构上支持应用的服务可拆可合的灵活部署(后台管理服务、对外提供api服务、定时任务执行服务和异步消息处理服务等)，从而实现部署实例尽可能与业务实际需求尽可能相符，最终控制新零售领域saas业务系统数量和部署实例数量在一个合理范围内，从而降低研发和维护的复杂度和成本。

本申请实施例提供了一种电子设备，可以是服务器或计算机设备。请参照图1，电子设备的结构示意图。电子设备包括处理器10、存储器11、总线12。处理器10、存储器11通过总线12连接，处理器10用于执行存储器11中存储的可执行模块，例如计算机程序。

处理器10可以是一种集成电路芯片，具有信号的处理能力。在实现过程中，软件工程管理方法的各步骤可以通过处理器10中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器10可以是通用处理器，包括中央处理器(centralprocessingunit，简称cpu)、网络处理器(networkprocessor，简称np)等；还可以是数字信号处理器(digitalsignalprocessor，简称dsp)、专用集成电路(applicationspecificintegratedcircuit，简称asic)、现场可编程门阵列(field－programmablegatearray，简称fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

存储器11可能包含高速随机存取存储器(ram：randomaccessmemory)，也可能还包括非不稳定的存储器(non-volatilememory)，例如至少一个磁盘存储器。

总线12可以是isa(industrystandardarchitecture)总线、pci(peripheralcomponentinterconnect)总线或eisa(extendedindustrystandardarchitecture)总线等。图1中仅用一个双向箭头表示，但并不表示仅有一根总线12或一种类型的总线12。

存储器11用于存储程序，例如软件工程管理装置对应的程序。软件工程管理装置包括至少一个可以软件或固件(firmware)的形式存储于存储器11中或固化在电子设备的操作系统(operatingsystem，os)中的软件功能模块。处理器10在接收到执行指令后，执行所述程序以实现软件工程管理方法。

可能地，本申请实施例提供的电子设备还包括通信接口13。通信接口13通过总线与处理器10连接。

应当理解的是，图1所示的结构仅为电子设备的部分的结构示意图，电子设备还可包括比图1中所示更多或者更少的组件，或者具有与图1所示不同的配置。图1中所示的各组件可以采用硬件、软件或其组合实现。

本申请实施例提供的一种软件工程管理方法，可以但不限于应用于图1所示的电子设备，具体的流程，请参考图2：

s101，依据配置信息中的目标业务领域构建本地包。

其中，本地包包括运行目标业务领域的运行逻辑。

具体地，请参考图3，图3为本申请实施例提供的目标业务领域示意图。若图3所示，业务领域包括商品业务领域(subbusinessdomainmodule-1(ware))、商家业务领域(subbusinessdomainmodule-2(vender))、门店业务领域(subbusinessdomainmodule-3(shop))以及其他业务领域(subbusinessdomainmodule-n)。

配置信息可以包含其中任意一个或多个业务领域，配置信息所包含业务领域即为目标业务领域。工程师可以根据需要支撑的业务改变配置信息，从而确定目标业务领域，生成对应的本地包。

s102，依据预先设置的部署规则，在本地包的基础上，构建完整部署包。

其中，完整部署包用于在目标虚拟机内部运行，以完成目标业务领域对应的作业，完整部署包包括部署规则，部署规则包含目标虚拟机加载各个运行逻辑的加载方式。

当完成部署后，即生成了可以支撑对应业务的虚拟机应用，简单快捷，效率高。

综上所述，本申请实施例提供了一种软件工程管理方法，依据配置信息中的目标业务领域构建本地包，其中，本地包包括运行目标业务领域的运行逻辑；依据预先设置的部署规则，在本地包的基础上，构建完整部署包；其中，完整部署包用于在目标虚拟机内部运行，以完成目标业务领域对应的作业，完整部署包包括部署规则，部署规则包含目标虚拟机加载各个运行逻辑的加载方式。工程师可以根据需要支撑的业务改变配置信息，从而确定目标业务领域，生成对应的本地包。当完成部署后，即生成了可以支撑对应业务的虚拟机应用，简单快捷，效率高。

在图3的基础上，关于灵活拆分业务领域，本申请实施例还提供了一种的实现方式。例如，配置信息mavenconfig：profile＝full，表示所有的业务领域均被包含在配置信息中，所有的业务领域均为目标业务领域；配置信息mavenconfig：profile＝sub，表示vender和ware对应的业务领域均被包含在配置信息中，vender和ware对应的业务领域为目标业务领域；配置信息mavenconfig：profile＝single，表示ware对应的业务领域均被包含在配置信息中，ware对应的业务领域为目标业务领域。

工程师通过不同的配置信息去构建本地包，其部署后的实例所支撑的业务领域也是不同的。

在图2的基础上，关于如何运行完整部署包，本申请实施例还提供了一种可能的实现方式，请参考图4，软件工程管理方法还包括：

s103，将完整部署包部署于对应的目标虚拟机中。

具体地，完整部署包用于在目标虚拟机内部运行，以完成目标业务领域对应的作业，依据部署规则将各个运行逻辑的加载至目标虚拟机。

s104，监测目标虚拟机的运行负载。

在一种可能的实现方式中，运行负载为单位时间内目标虚拟机处理的业务量大小或流入流出目标虚拟机的流量大小。

s105，判断运行负载是否超出第一负载阈值。若是，则执行s106；若否，则执行s110。

当运行负载超出第一负载阈值时，说明当前负载过重，此时执行s106，生成告警提示；反之则需要判断当前负载是否过轻，则执行s110。

s106，生成告警提示。

告警提示用于提示对应人员进行处理，避免长时间负载过重，导致宕机的问题。

在运行负载超出第一负载阈值的情况下，关于如何降低目标虚拟机的负载，本申请实施例还提供了一种可能的实现方式，请继续参考图4，软件工程管理方法还包括：

s107，判断目标业务领域中的子业务领域的数量是否大于1。若是，则执行s108；若否，则执行s112。

需要说明的是，s107中的目标业务领域为目标虚拟机中当前支撑的全部业务领域。例如，目标虚拟机中当前支撑的业务领域包括商品业务领域(subbusinessdomainmodule-1(ware))和商家业务领域(subbusinessdomainmodule-2(vender))时，商品业务领域(subbusinessdomainmodule-1(ware))和商家业务领域(subbusinessdomainmodule-2(vender))均可以被作为子业务领域。

当目标虚拟机中当前支撑的业务领域仅为一种大的业务领域时，关于子业务领域，本申请实施例还提供了一种可能的实现方式，每一个业务领域均包括不同的服务，例如后台管理服务(controller)、对外提供api服务(rpc)、定时任务执行服务和异步消息处理服务，每一个业务领域下的不同服务均可以作为一个子业务领域。

当目标业务领域中的子业务领域的数量大于1时，表示虚拟机支撑的业务领域还可以拆分，此时执行s108；反之，则表示不能拆分，执行s112。

s108，生成拆分询问请求。

其中，拆分询问请求用于提示用户是否对目标虚拟机中的目标业务领域进行拆分。

在一种可能的实现方式中，拆分询问请求包含可拆分的子业务领域的标识以及每一个子业务领域对应产生的负载，以便于用户观察。

s109，在接收到确认拆分指示后，依据各个子业务领域在运行负载中的占比，将原目标业务领域拆分为至少两个新的目标业务领域。

在一种可能的实现方式中，当可拆分的子业务领域的数量大于或等于3时，可以依据每一个子业务领域对应产生的负载，生成推荐拆分方式，在接收到推荐拆分方式确认指令后，按照推荐拆分方式将原目标业务领域拆分为至少两个新的目标业务领域。

然后执行s115，基于新的目标业务领域构建新的本地包，依据预先设置的部署规则，在新的本地包的基础上，构建新的完整部署包。

新的完整部署包分别部署于不同的虚拟机，每一个虚拟机的负载均被控制在预设范围内，避免出现负载过重。

在运行负载未超出第一负载阈值的情况下，关于如何目标虚拟机的利用率，本申请实施例还提供了一种可能的实现方式，请继续参考图4，软件工程管理方法还包括：

s110，判断运行负载是否小于第二负载阈值。若是，则执行s111；若否，则执行s112。

其中，第二负载阈值小于第一负载阈值。

当运行负载小于第二负载阈值后，说明目标虚拟机当前的状态较为空闲，利用率低，此时需要增加其利用率，故执行s111；反之，则执行s112。

s111，判断是否存在待融合虚拟机。若是，则执行s113；若否，则执行s112。

其中，待融合虚拟机为除目标虚拟机以外的，且运行负载小于第二负载阈值的虚拟机。

当存在待融合虚拟机，则存在融合的可能，执行s113；反之，则执行s112。

s112，跳过。

s113，生成融合询问请求。

其中，融合询问请求包括目标虚拟机和待融合虚拟机的标识信息，融合询问请求用于提示用户是否对目标虚拟机和待融合虚拟机中的目标业务领域进行融合。

s114，在接收到确认融合指示后，依据目标虚拟机和待融合虚拟机中的目标业务领域生成新的目标业务领域。

s115，基于新的目标业务领域构建新的本地包，依据预先设置的部署规则，在新的本地包的基础上，构建新的完整部署包。

在图2的基础上，在电子设备预先配置有各个业务领域对应的运行逻辑的情况下，关于s101中的内容，本申请实施例还提供了一种可能的实现方式，请参考图5，s101包括：

s101-1，依据配置信息中的目标业务领域筛选出对应的运行逻辑。

需要说明的是，运行逻辑可以由一段代码构成。

s101-2，将运行逻辑组合构建为本地包。

请继续参考图3，图3中的deploymodule(web/rpc)为部署模块(pop-deploy)。

本申请实施例中，业务层逻辑和控制层逻辑从部署模块分离，部署模块具备灵活的业务组装能力和灵活的服务部署能力，从而使应用具备灵活伸缩支撑业务域能力。

业务领域之间依赖服务接口而不是服务实现，使得部署时不用考虑业务领域之间依赖的对象是否在同一实例成为可能，从而降低了应用支撑业务域伸缩时的成本。

部署模块加载项应通过通配符来匹配，将应用部署时伸缩业务域的配置维护成本降到最小。部署模块要装载的逻辑模块通过配置做到灵活可变，使得应用实例支撑的业务可伸缩成为可能。跨业务领域的通用能力独立成通用模块和业务领域内对外提供能力的逻辑放在通用模块，尽可能的提升了代码的复用率。

本申请实施例中，运用语言多态特性和通配符匹配加载能力，采用模块化构建思想和配置能力来实现可灵活伸缩支撑业务域的软件工程管理方法。将业务领域作为工程业务模块最小单元，业务模块下仅含逻辑模块，部署模块作为业务领域共用，而部署模块承载的业务领域由配置控制而不是传统默认固定，这样部署的业务领域才能灵活组装。

在无代码或少量配置代码调整下实现部署业务的拆分或合并。支持工程内业务领域垂直拆分，业务领域内支持功能模块水平拆分。部署模块支撑的业务领域由maven最终构建打包组装完成。

请参阅图6，图6为本申请实施例提供的一种软件工程管理装置，可选的，该软件工程管理装置被应用于上文所述的电子设备。

软件工程管理装置包括：业务领域模块201和部署模块202。

业务领域模块201，用于依据配置信息中的目标业务领域构建本地包，其中，本地包包括运行目标业务领域的运行逻辑。可选地，业务领域模块201可以执行上述的s101。

部署模块202，用于依据预先设置的部署规则，在本地包的基础上，构建完整部署包。

其中，完整部署包用于在目标虚拟机内部运行，以完成目标业务领域对应的作业，完整部署包包括部署规则，部署规则包含目标虚拟机加载各个运行逻辑的加载方式。

可选地，部署模块202可以执行上述的s102。

在一种可能的实现方式中，部署模块202还用于将完整部署包部署于对应的目标虚拟机中；监测目标虚拟机的运行负载；当运行负载超出第一负载阈值时，生成告警提示。

当运行负载超出第一负载阈值时，部署模块202还用于判断目标业务领域中的子业务领域的数量是否大于1；若是，则生成拆分询问请求，其中，拆分询问请求用于提示用户是否对目标虚拟机中的目标业务领域进行拆分；在接收到确认拆分指示后，依据各个子业务领域在运行负载中的占比，将原目标业务领域拆分为至少两个新的目标业务领域。

可选地，部署模块202可以执行上述的s103～s109。

业务领域模块201还用于基于新的目标业务领域构建新的本地包，依据预先设置的部署规则，在新的本地包的基础上，构建新的完整部署包。可选地，业务领域模块201可以执行上述的s115。

需要说明的是，本实施例所提供的软件工程管理装置，其可以执行上述方法流程实施例所示的方法流程，以实现对应的技术效果。为简要描述，本实施例部分未提及之处，可参考上述的实施例中相应内容。

本申请实施例还提供了一种存储介质，该存储介质存储有计算机指令、程序，该计算机指令、程序在被读取并运行时执行上述实施例的软件工程管理方法。该存储介质可以包括内存、闪存、寄存器或者其结合等。

下面提供一种电子设备，可以是服务器或计算机设备，该电子设备如图1所示，可以实现上述的软件工程管理方法；具体的，该电子设备包括：处理器10，存储器11、总线12。处理器10可以是cpu。存储器11用于存储一个或多个程序，当一个或多个程序被处理器10执行时，执行上述实施例的软件工程管理方法。

在本申请所提供的实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本申请的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

对于本领域技术人员而言，显然本申请不限于上述示范性实施例的细节，而且在不背离本申请的精神或基本特征的情况下，能够以其它的具体形式实现本申请。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本申请的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。