一种业务软件系统架构管控方法及装置与流程

1.本技术涉及软件管控技术领域，尤其涉及一种业务软件系统架构管控方法及装置。


背景技术：

2.软件系统经过一段时间需求迭代会产生严重的架构腐化，每一次需求迭代会产生一些变化因子，这些变化因子和过去的因子会按照指数级的耦合关系，比如2个变化因子一条边，3个变化因子三条边，4个变化因子12个边
……
以此类推可能的变化扩散点是n*(n-1)/2。
3.尤其的，对于业务系统，每周迭代一次，每次即使只携带了一个变化引子，年底一次需求就需要评估1421个风险点。更何况，实际上每周迭代所携带的变化因子往往不止一个。进而就产生了困扰软件开发症状：代码逻辑难以理清楚(关联边，扩散面理不清)；稳定性降低和故障数提升；开发效率降低，响应业务速度越来越慢；公司规模越来越大，但员工付出成本越来越高。
4.针对业务软件系统随着需求迭代产生的架构腐化问题，现有技术中提供了许多框架，譬如传统的mvc，分层模型，以及最新的spring-cloud，dapr、云原生等，虽然这些框架可以比较有效的降低业务系统外围的技术复杂度，但无法解构业务系统内部复杂性，不能真正有效治理业务领域真正的复杂性。


技术实现要素：

5.为克服现有技术中的不足，本技术提供一种业务软件系统架构管控方法及装置，能够针对业务流程的复杂度采用不同架构进行处理，提升工程效能。
6.本技术提供的一种业务软件系统架构管控方法，所述方法包括以下步骤：
7.基于业务流程的业务逻辑复杂度，将存储的业务流程预先分为简单业务流程和复杂业务流程；其中，当所述业务流程的业务逻辑复杂度低于设定阈值时，将该业务流程被分为简单业务流程；当所述业务流程的业务逻辑复杂度高于设定阈值时，将该业务流程被分为复杂业务流程；
8.基于用户指定的业务流程获取该业务流程的业务逻辑复杂度，并确定该业务流程为简单业务流程或复杂业务流程；
9.采用crud-flow架构处理用户指定的业务流程；其中，所述crud-flow架构包括crud架构和flow架构，若用户指定的业务流程为简单业务流程，采用crud架构处理该业务流程；若用户指定的业务流程为复杂业务流程，采用flow架构处理该业务流程。
10.在一种可能的实施方式中，通过以下方式确定业务流程的业务逻辑复杂度：
11.根据业务流程预先设置的节点信息、节点间关系信息确定所述业务流程的业务逻辑复杂度。
12.在一种可能的实施方式中，所述通用计算引擎包括python引擎、matlab引擎、ai引
擎中的一种或多种，用于所述后端服务层基于不同的计算请求调用相适配的通用计算引擎。
13.在一种可能的实施方式中，所述flow架构通过调用业务组件的方式处理业务流程。
14.在一种可能的实施方式中，所述flow架构通过调用业务组件的方式处理业务流程之前，还包括以下步骤：
15.采用xml文件编排、并使用标准组件进行封装，得到不同业务流程相对应的不同业务组件；其中，在所述xml文件中通过node表示业务流程的状态，并且基于可配置的状态机完成所述node之间的流转；
16.对业务组件中逻辑关联性低的多个局部组件进行隔离。
17.在一种可能的实施方式中，所述flow架构通过调用业务组件的方式处理业务流程，包括以下步骤：
18.当监测到所述业务组件中的业务节点发生故障时，在所述业务节点之外，插入容错节点以正常处理业务流程。
19.在一种可能的实施方式中，所述flow架构通过调用业务组件的方式处理业务流程，还包括以下步骤：
20.对所述xml文件进行反序列化生成流程图，实现flow架构的可视化。
21.在一种可能的实施方式中，所述采用crud架构处理的业务流程包括数据的增删改查。
22.本技术提供的一种业务软件系统架构管控装置，包括：
23.分类模块，用于基于业务流程的业务逻辑复杂度，将存储的业务流程预先分为简单业务流程和复杂业务流程；其中，当所述业务流程的业务逻辑复杂度低于设定阈值时，将该业务流程被分为简单业务流程；当所述业务流程的业务逻辑复杂度高于设定阈值时，将该业务流程被分为复杂业务流程；
24.确定模块，用于基于用户指定的业务流程获取该业务流程的业务逻辑复杂度，并确定该业务流程为简单业务流程或复杂业务流程；
25.处理模块，用于采用crud-flow架构处理用户指定的业务流程；其中，所述crud-flow架构包括crud架构和flow架构，若用户指定的业务流程为简单业务流程，采用crud架构处理该业务流程；若用户指定的业务流程为复杂业务流程，采用flow架构处理该业务流程。
26.本技术提供的一种电子设备，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器执行时执行上述任一所述的业务软件系统架构管控方法的步骤。
27.本技术提供的一种电子设备，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器执行时执行上述任意一项所述的业务软件系统架构管控方法的步骤。
28.本实施例提供的一种业务软件系统架构管控方法及装置，基于业务流程的业务逻
辑复杂度，将存储的业务流程预先分为简单业务流程和复杂业务流程；基于用户指定的业务流程获取该业务流程的业务逻辑复杂度，并确定该业务流程为简单业务流程或复杂业务流程；采用crud-flow架构处理用户指定的业务流程；其中，所述crud-flow架构包括crud架构和flow架构，若用户指定的业务流程为简单业务流程，采用crud架构处理该业务流程；若用户指定的业务流程为复杂业务流程，采用flow架构处理该业务流程，从而达到针对不同的业务流程采用不同的架构进行处理，整体架构清晰可控。
附图说明
29.为了更清楚地说明本技术实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。
30.图1示出了本技术一实施例所述业务软件系统架构管控方法的流程图；
31.图2示出了本技术一实施例所述flow架构构建业务组件的流程图；
32.图3示出了本技术一实施例所述crud架构的示意图；
33.图4示出了本技术一实施例所述业务软件系统架构管控装置的结构框图；
34.图5示出了示出了本技术一实施例所述电子设备的结构框图。
具体实施方式
35.为使本技术实施例的目的、技术方案和优点更加清楚，下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，应当理解，本技术中附图仅起到说明和描述的目的，并不用于限定本技术的保护范围。另外，应当理解，示意性的附图并未按实物比例绘制。本技术中使用的流程图示出了根据本技术的一些实施例实现的操作。应该理解，流程图的操作可以不按顺序实现，没有逻辑的上下文关系的步骤可以反转顺序或者同时实施。此外，本领域技术人员在本技术内容的指引下，可以向流程图添加一个或多个其他操作，也可以从流程图中移除一个或多个操作。
36.另外，所描述的实施例仅仅是本技术一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本技术实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本技术的实施例的详细描述并非旨在限制要求保护的本技术的范围，而是仅仅表示本技术的选定实施例。基于本技术的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本技术保护的范围。
37.需要说明的是，本技术实施例中将会用到术语“包括”，用于指出其后所声明的特征的存在，但并不排除增加其它的特征。
38.目前，随着业务软件开发行业的发展，业务软件系统数量越来越多。其中，业务软件系统架构描述的对象是直接构成系统的抽象业务组件，各个抽象业务组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口来实现。尤其的，业务流程的描述千差万别，需要浪费大量时间对不同的描述方法进行适应。而对于业务软件系统而言，都会随着需求迭代，产生架构腐化问题。
39.基于此，本技术提供一种业务软件系统架构管控方法、装置电子设备及存储介质，基于业务流程的业务逻辑复杂度，将存储的业务流程预先分为简单业务流程和复杂业务流程；基于用户指定的业务流程获取该业务流程的业务逻辑复杂度，并确定该业务流程为简单业务流程或复杂业务流程；采用crud-flow架构处理用户指定的业务流程；其中，所述crud-flow架构包括crud架构和flow架构，若用户指定的业务流程为简单业务流程，采用crud架构处理该业务流程；若用户指定的业务流程为复杂业务流程，采用flow架构处理该业务流程，从而达到针对不同的业务流程采用不同的架构进行处理，整体架构清晰可控。
40.参见说明书附图1，图1示出了本技术实施例所述业务软件系统架构管控方法的流程图，具体的，所述业务软件系统架构管控方法包括以下步骤s1-s3：
41.s1、基于业务流程的业务逻辑复杂度，将存储的业务流程预先分为简单业务流程和复杂业务流程；其中，当所述业务流程的业务逻辑复杂度低于设定阈值时，将该业务流程被分为简单业务流程；当所述业务流程的业务逻辑复杂度高于设定阈值时，将该业务流程被分为复杂业务流程；
42.s2、基于用户指定的业务流程获取该业务流程的业务逻辑复杂度，并确定该业务流程为简单业务流程或复杂业务流程；
43.s3、采用crud-flow架构处理用户指定的业务流程；其中，所述crud-flow架构包括crud架构和flow架构，若用户指定的业务流程为简单业务流程，采用crud架构处理该业务流程；若用户指定的业务流程为复杂业务流程，采用flow架构处理该业务流程。
44.在步骤s1中，业务软件系统为了满足用户的不同需求，参数配置和业务流程的分支繁多，在后续迭代过程中，因而会使得业务软件系统架构更为复杂，维护困难。所以，在本技术中，将业务软件系统配置的业务流程根据业务流程的业务逻辑复杂度进行分类，具体的，基于业务流程的业务逻辑复杂度，预先将业务流程分为简单业务流程和复杂业务流程，进行分类存放，进而针对不同类别的业务流程采用不同的业务软件系统架构进行处理，从而让业务软件系统架构清晰可控。
45.在一实施例中，根据业务流程预先设置的节点信息、节点间关系信息确定所述业务流程的业务逻辑复杂度。例如，在一业务流程中若节点信息越多，节点间关系信息越丰富，其业务逻辑复杂度就越高。则能够设置一定的计算规则，并根据该计算规则计算各个业务流程的业务逻辑复杂度，且通过设置的阈值对各个业务流程进行分类。具体的，当所述业务流程的业务逻辑复杂度低于设定阈值时，将该业务流程被分为简单业务流程；当所述业务流程的业务逻辑复杂度高于设定阈值时，将该业务流程被分为复杂业务流程。
46.在步骤s2中，当接收到用户指定的业务流程时，就能够立即确定出该业务流程属于简单业务流程或者复杂业务流程。在一实施例中，可以预先对每个预设的服务流程进行编号，根据服务流程编号确定该服务路程归属为简单业务流程或者复杂业务流程。例如，简单业务流程的集合中，编号分别为a1、a2、a3
……
，复杂业务流程的集合中，编号分别为b1、b2、b3
……
，所以只要知道了业务流程的编号就能够确定出该业务流程为该业务流程属于简单业务流程或者复杂业务流程，非常清晰且迅捷。
47.在步骤s3中，采用crud-flow架构处理用户指定的业务流程；其中，所述crud-flow架构包括crud架构和flow架构，下面先对本技术较为关键的、用于处理复杂业务流程的flow架构进行详细阐述。
48.具体的，flow架构通过调用业务组件的方式处理业务流程。即，在flow架构中设置了业务组件库。并且，参见说明附图2，flow架构通过调用业务组件的方式处理业务流程之前，通过以下步骤构建业务组件：
49.s301、采用xml文件编排、并使用标准组件进行封装，得到不同业务流程相对应的不同业务组件；其中，在所述xml文件中通过node表示业务流程的状态，并且基于可配置的状态机完成所述node之间的流转；
50.s302、对业务组件中逻辑关联性低的多个局部组件进行隔离。
51.步骤s301中，业务组件库是指由业务组件组合成的组件集合，支持独立发布和使用；业务组件为具有业务属性，能够独立完成某项业务功能的软件单元，包含完成该业务功能的完整界面和处理逻辑，内部包含完整的程序框架，应用程序集成该业务组件后可以实现该组件的功能；标准组件是指包含ui层和控制层逻辑的可独立运作或与其他组件协同运作的代码集合。本实施例中的标准组件除了实现组件本身逻辑之外，还需要提供一个配套的属性配置器，主要用来规定组件可配置的属性以及配置方式。在该实施例中，业务组件可以是定位组件、购物组件、支付组件等中的一种或多种，本技术并不对此进行限制和固定。
52.所述xml为可扩展标记语言(extensible markup language)，被设计用来传输和存储数据，不用于表现和展示数据。在本技术中，通过容易理解的xml编排流程，并采用node来表明流程的状态，同时基于可配置的状态机实现状态之间的流转。
53.在一实施例中，若一涉及支付环节的业务流程为，确认下单后，在第三方渠道初始化订单进行预支付，然后确认密码；在确认密码后调用支付渠道，如果支付异常，则查询补偿，最终回馈支付成功或者支付失败。将该业务流程通过xml文件进行编排，如下：
[0054][0055][0056]
可见，通过xml文件能够清楚的掌握业务软件系统中有多少业务，每个业务有什么
流程。并且，进一步的，通过对xml文件进行反序列化，生成非结构化数据对象，并确定所述非结构化数据对象之间的连接关系，从而构建非结构化数据地图，实现flow架构的可视化，通过图形化对flow架构进行掌控。
[0057]
另外，所述flow架构能够在业务节点(pay)之外，可轻易插入容错node(例如unkow节点)，这样并不影响预设的业务流程。例如，当监测到所述业务组件中的业务节点发生故障时，在所述业务节点之外，插入容错节点以正常处理业务流程。可见，这种通过在业务节点(pay)之外插入容错node的方式，可以确保整个业务流程数据的一致性和异常可靠性。
[0058]
步骤s302中，所述flow架构对业务组件中逻辑关联性低的多个局部组件进行隔离。基于业务组件的隔离技术，局部组件的逻辑变更不会影响整体业务流程的可靠性，错误也会被容错节点兜底。非常复杂业务流程的变更和迭代其复杂度是线性的，并不会产生指数级的耦合。
[0059]
对于crud-flow架构中crud架构，参见说明书附图3，crud架构分为三层，分别为controller层、service层和dao层，其中controller层的职责为输入校验，页面处理；service层的职责为数据校验，识别转化；dao层的职责为持久化，用于对简单业务流程的处理，如数据的增、删、改、查，其工作原理较为简单，且为本领域技术人员所熟知的，在此不做赘述。
[0060]
在一实施例中，当接收到的用户指定的业务流程为复杂业务流程时，由crud-flow架构中的flow架构从业务组件库中调用该复杂业务流程相对应的业务组件，并进行解析，获取业务组件信息，且将获取的业务组件信息发送至上层应用。相应的，当接收到的用户指定的业务流程为简单业务流程时，由crud-flow架构中的crud架构直接进行处理。可见，通过本技术提供的一种业务软件系统架构管控方法，能够针对不同的业务流程采用不同的架构进行处理，尤其的，对于flow架构采用xml文件编排业务流程，整体架构清晰可控，并且各种异常处理机制和兜底机制一目了然、系统健壮性增强。
[0061]
如说明书附图4所示，本技术还提供了一种业务软件系统架构管控装置，包括：
[0062]
分类模块401，用于基于业务流程的业务逻辑复杂度，将存储的业务流程预先分为简单业务流程和复杂业务流程；其中，当所述业务流程的业务逻辑复杂度低于设定阈值时，将该业务流程被分为简单业务流程；当所述业务流程的业务逻辑复杂度高于设定阈值时，将该业务流程被分为复杂业务流程；
[0063]
确定模块402，用于基于用户指定的业务流程获取该业务流程的业务逻辑复杂度，并确定该业务流程为简单业务流程或复杂业务流程；
[0064]
处理模块403，用于采用crud-flow架构处理用户指定的业务流程；其中，所述crud-flow架构包括crud架构和flow架构，若用户指定的业务流程为简单业务流程，采用crud架构处理该业务流程；若用户指定的业务流程为复杂业务流程，采用flow架构处理该业务流程。
[0065]
在一些实施方式中，所述分类模块401通过以下方式确定业务流程的业务逻辑复杂度：
[0066]
根据业务流程预先设置的节点信息、节点间关系信息确定所述业务流程的业务逻辑复杂度。
[0067]
在一些实施方式中，处理模块403基于所述flow架构通过调用业务组件的方式处
player)、浏览器(browser)等，用于实现各种应用业务。
[0082]
在本技术实施例中，通过调用存储器505存储的程序或指令，处理器501用于执行如一种业务软件系统架构管控方法中的步骤，能够针对业务流程的复杂度采用不同架构进行处理，提升工程效能。
[0083]
本技术还提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行如业务软件系统架构管控方法中的步骤。
[0084]
具体地，该存储介质能够为通用的存储介质，如移动磁盘、硬盘等，该存储介质上的计算机程序被运行时，能够执行上述业务软件系统架构管控方法。
[0085]
在本技术所提供的实施例中，应该理解到，所揭露装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
[0086]
作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
[0087]
另外，在本技术提供的实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
[0088]
功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本技术各个实施例方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-only memory)、随机存取存储器(ram，random access memory)、磁碟或者光盘等各种可以存储程序代码的介质。
[0089]
最后应说明的是：以上实施例，仅为本技术的具体实施方式，用以说明本技术的技术方案，而非对其限制，本技术的保护范围并不局限于此，尽管参照前述实施例对本技术进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本技术揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本技术实施例技术方案的精神和范围。都应涵盖在本技术的保护范围之内。因此，本技术的保护范围应以权利要求的保护范围为准。