CN114138258A - 一种复杂软件耦合建模方法 - Google Patents

Abstract

本发明涉及计算机软件构造架构领域。提出了一种复杂软件耦合建模方法，其特征在于，包括以下步骤：步骤1，构建服务工厂联合体；步骤2，服务工厂任务调度。本方法有助于克服现有复杂软件建模以及传统微服务架构不适用于大型工业复杂软件研发的问题，通过对企业间公开服务资源、私有服务资源进行服务分配，在跨多个厂商、不同领域的复杂软件动态部署和研发过程中统筹规划组件之间的关联性，能够法高效调动各服务的研发资源和接口资源，通过服务细分对服务资源进行解耦，极大提高了服务的可靠性，统一的公共服务中心和监控系统促进公有调度算法的及时性和易维护性，合作厂商间共同维护的私有调度算法保障了合作的私密性。

Description

一种复杂软件耦合建模方法

技术领域

本发明涉及计算机软件构造架构领域。

背景技术

传统工业领域复杂软件系统软件研发过程中常常面临开发低效、代码复用率低、系统成长扩展过程复杂等问题；同时，由于国内不同厂商软件之间的较高信息壁垒，难以提供跨功能、跨厂商的应用服务，从而导致自主软件的功能单一化，竞争力低下等问题。研究基于云平台的服务互操作技术，实现给予云平台的服务集中部署和管理，不仅有助于打破原有技术隔阂，实现数据和应用的互联互通，更有助于自主工业软件打破国外工业软件生态系统垄断，创立和发展自主工业软件生态体系。

近年来，基于微服务架构的松散耦合的软件开发体系结构在软件行业得到了初步的应用，对比与传统的单体应用建构模式，微服务架构下独立组件或服务间松散耦合，不同组件可自由采用独立不同的技术堆栈，包括数据库以及数据模型，给打破不同厂商的信息壁垒提供了技术上的可能。然而，流行的微服务架构模型在面对跨多个厂商、不同领域的复杂软件动态部署和研发过程中，往往无法统筹规划组件之间的关联性，无法高效调动各服务的研发资源和接口资源。

发明内容

有鉴于此，本发明目的在于克服现有复杂软件建模以及微服务架构不能很好适用于大型工业复杂软件研发的问题，提出一种新的基于服务工厂模式的工业复杂软件耦合建模方法。

本方法采用服务工厂对不同厂商、不同领域的组件或服务进行解构，特定的服务工厂负责其特定软件组件的研发与维护，同时通过由各自服务调度工厂组成的服务分配中心进行通信。区别于流行的微服务架构中的服务注册中心和配置中心，服务工厂更倾向于厂商或工业领域的抽象，通过对应用/服务的分配和申领，不同厂商将提供特有和公共服务中心提供的服务，并自由享有公共服务及依据权限享有其他服务工厂提供的私有服务。

本发明技术方案：

一种复杂软件耦合建模方法，其特征在于，包括以下步骤：

步骤1，构建服务工厂联合体；

步骤2，服务工厂任务调度。

其中，步骤1包括以下步骤：

1.1.各厂商、工业机构、数据提供商等自然组织a…n等构建服务工厂联合体。服务工厂联合体统筹规划公共服务中心C的服务资源，成立公共开发资源池，用于相应公有服务池和调度算法、节点监控系统的开发维护，各自然组织可独自或合作组建一个或多个服务工厂 a…n,并依据业务类型和资源规模选择提供的服务，参考伪代码1服务中心发现与注册，形成如说明书附图1的服务工程模式架构。

1.2.对于任一服务工厂k，利用公共开发资源池和私有开发资源，参照说明书附图3 服务框架1，通过实例化服务调度工厂，实现与公共服务中心C的对接通信，完成服务工厂的接入。

1.3.各服务工厂a…n对其负责的应用或服务进行服务水平细分和服务垂直细分，细分为服务节点a-1,a-2,…,n-1,n-j，参考说明书附图2及伪代码2服务节点调度与性能监控，通过公共服务中心C实现调度算法接口的接入，同时，在调度算法的实例中，应确保对所有接入的服务节点能够进行性能监控。

1.4.各服务工厂a…n根据1.3对内进行服务分配，同时，将服务节点独自或组合进行封装，对外封装成服务节点接入公共服务中心C。

1.5.各自然组织a…n直接通过公共服务中心C根据需求调用服务、开发资源，对未能满足的需求，向公共服务中心提出需求。公共服务中心C根据需求的服务类型和规模对全体服务工厂进行意向征询，促进公开或私有合作。

1.6.服务需求者i通过公共服务中心C相应调度算法，实现对能满足需求的服务节点 (如a-1-1,b-2-1)进行定位和调用，调度算法同时实现同类服务节点的负载均衡，通过性能监控系统对公共服务中心的服务供需状况进行反馈(如反馈给服务工厂a和b)，进一步促进厂商间合作和资源共享。

步骤2包括以下步骤：

2.1.各服务工厂a…n动态调整提供的服务，并根据公共服务中心的供需关系动态调整对应服务节点a-1,a-2,…,n-1,n-j的数量，实现调度算法的智能调度、资源的动态部署和弹性分配。

2.2.服务工厂模式全体参与者动态维护和开发调度算法，通过奖惩机制促进资源供需关系的满足，促进厂商间资源开放、业务合作、底层服务共享。

2.3.公共服务中心C定期对服务节点a-1,a-2,…,n-1,n-j情况汇总汇报，促进相似度较高的节点成立新的服务工厂便于后续维护以及规模的扩大；促进具有明显互补作用的不同服务工厂的服务节点部署的一致性，便于动态调整对应服务节点的规模。

本发明的有益效果是：

本发明提出的服务工厂模式的复杂软件耦合建模方法有助于克服现有复杂软件建模以及传统微服务架构不适用于大型工业复杂软件研发的问题，通过对企业间公开服务资源、私有服务资源进行服务分配，在跨多个厂商、不同领域的复杂软件动态部署和研发过程中统筹规划组件之间的关联性，能够法高效调动各服务的研发资源和接口资源，通过服务细分对服务资源进行解耦，极大提高了服务的可靠性，统一的公共服务中心和监控系统促进公有调度算法的及时性和易维护性，合作厂商间共同维护的私有调度算法保障了合作的私密性。公共服务池资源的共享开放同时鼓励厂商对其私有资源的开放，对建立国产复杂工业软件生态可起到良好的引导促进作用。

附图说明

图1是本发明服务工厂模式总体示意图。

图2是本发明实施过程中的服务水平细分和垂直细分模式图。

图3是本发明服务工厂模式中的单一服务工厂实施细节图。

具体实施方式

实施例

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图，对本发明进行进一步详细说明。

一种复杂软件耦合建模方法，采用服务工厂对不同厂商、不同领域的组件或服务进行解构，特定的服务工厂负责其特定软件组件的研发与维护，同时通过由各自服务调度工厂组成的服务分配中心进行通信。区别于流行的微服务架构中的服务注册中心和配置中心，服务工厂更倾向于厂商或工业领域的抽象，通过对应用/服务的分配和申领，不同厂商将提供特有和公共服务中心提供的服务，并自由享有公共服务及依据权限享有其他服务工厂提供的私有服务。

作为整个服务工厂模式的基础设施，公共服务中心是各特有服务工厂共同研发维护的，提供以工业知识、工业经验、工业需求为主要内容的开发基础资源，同时负责公共服务接口实现及其智能调度、动态部署、弹性分配。厂商通过开发社区提供公共资源服务，加入公共服务中心，同时，厂商提供的公共服务加入由全体服务工厂共享的公共服务池。厂商提供工业知识及经验并提出服务需求，公共服务中心优先查找公共服务池能否满足厂商的服务需求，若无法满足则提出服务分配请求，鼓励能提供相应服务的厂商研发，促进厂商间服务资源合作。公共服务中心采用统一的数据存储以及通信方案，并由开发社区统一开发维护，通过公有调度实现上述服务需求查询分配；对于涉及厂商核心知识、技术或经验的服务，厂商间可通过公共服务中心认可的私有调度进行数据和服务的调用，实现相互之间的有偿服务调用。公有调度针对工业软件开发中所需的各种服务资源，进行检索和动态匹配服务工厂，并根据各服务工厂的业务规模、服务供需情况，对服务资源进行动态预测，进而实现资源调度与优化控制，提高在自主工业软件生态系统的设计研发过程中资源流动的精确性和高效性。通过对私有调度使用的合理限制，可以鼓励不同厂商、不同领域间服务资源的开放性，鼓励服务工厂提供公共服务资源，实现自主软件的开放和合作共赢。

作为服务工厂模式的重要参与者，各厂商、工业机构、数据提供商等自然组织成立服务工厂并自主维护其服务资源，享有公共服务资源的同时负责相应基础设施的维护和更新换代，服务工厂将其服务逐级划分，层层分离，将耦合的服务需求解耦成子服务，从而提升应用的可扩展性和灵活性，节约不必要的重复研发成本，提升性能，对于不涉及核心技术和知识的子服务，服务工厂模式鼓励将其公开加入公共服务池；对于涉及核心技术和知识的子服务，可通过特有封装和接口提供给需求者调用，通过供需两方的专有调度实现资源分配。公有调度算法通过信任度、可靠性、负载率、复杂度、公共资源贡献度等评价指标，运用多属性决策方法确定服务资源调度的优先级；私有调度算法由供需方自主实现个性化调度和分配。通过上述服务工厂的服务分配过程，把服务资源的建立和维护从正常的业务逻辑中剥离出去，通过抽象来实现，进而对复杂工业软件建模过程进行解耦，对于服务资源调用过程，服务分配过程被完全屏蔽，在调度算法的作用下，完全无需关注服务的具体分配细节。

以下为本申请定义：

服务工厂与参与服务工厂模式的各厂商、工业机构、数据提供商等自然组织的关系：服务工厂模式的每一个自然组织团体参与者均参与公共服务中心的构成，并依据其业务情况和规模独立或合作组建一个或多个服务工厂。

服务工厂中服务的定义：服务工厂要提供服务，这种服务可以是应用模块或应用本身，也可以是更高层次上的业务模块、数据资源；此外，服务的部署，服务节点间的通信、调用、监控也是服务。服务并非服务工厂模式的最小单元，一项服务可以通过服务水平细分和服务垂直细分划分为细粒度的服务节点。

服务粒度控制：不同服务资源的粒度不同，且对于大多数应用场景，服务并不是越细越好，服务工厂在开发维护时应对其负责的服务进行粒度控制，在提供服务之前需综合业务实际情况和规模对业务域内计划提供的服务进行水平拆分，再以技术视角进行垂直划分。服务垂直细分，即技术上的垂直拆分，实现起来较为容易，直接促成了服务资源间的共用和互补；服务水平细分，即业务域的水平划分，则可能存在模糊边界，其细分完成度直接决定了该服务工厂服务资源的可靠性和开发维护成本，不合理的服务水平细分可能导致调度算法无法及时获取需求服务资源的服务节点区位，间接导致该服务工厂的贡献度低，不利于其享有公共服务池资源。

服务性能监控：对于服务工厂，某一特定服务资源是由众多独立的服务节点组成，并且各节点间通信频繁，必须要有服务性能监控机制保证调度算法的及时性和可靠性，该监控系统同时为公共服务中心反馈服务资源的供需关系和情况。因此，监控是全方位的，服务、网络、数据库、中间件等各种类型的服务节点缺一不可。私有服务节点的独立地位本质上与这种全方位监控系统相违背，因此无需加入公共统一监控系统，不过，服务工厂间进行私有调度算法设计实现过程中需考虑加入节点监控接口，避免在调度时发生服务雪崩。

以下增加具体实施方式：

步骤1，构建服务工厂联合体；

1.1.各厂商、工业机构、数据提供商等自然组织a…n等构建服务工厂联合体。服务工厂联合体统筹规划公共服务中心C的服务资源，成立公共开发资源池，用于相应公有服务池和调度算法、节点监控系统的开发维护，各自然组织可独自或合作组建一个或多个服务工厂 a…n,并依据业务类型和资源规模选择提供的服务，参考伪代码1服务中心发现与注册，形成如说明书附图1的服务工程模式架构。

1.2.对于任一服务工厂k，利用公共开发资源池和私有开发资源，参照说明书附图3 服务框架1，通过实例化服务调度工厂，实现与公共服务中心C的对接通信，完成服务工厂的接入。

1.3.各服务工厂a…n对其负责的应用或服务进行服务水平细分和服务垂直细分，细分为服务节点a-1,a-2,…,n-1,n-j，参考说明书附图2及伪代码2服务节点调度与性能监控，通过公共服务中心C实现调度算法接口的接入，同时，在调度算法的实例中，应确保对所有接入的服务节点能够进行性能监控。

1.4.各服务工厂a…n根据1.3对内进行服务分配，同时，将服务节点独自或组合进行封装，对外封装成服务节点接入公共服务中心C。

1.5.各自然组织a…n直接通过公共服务中心C根据需求调用服务、开发资源，对未能满足的需求，向公共服务中心提出需求。公共服务中心C根据需求的服务类型和规模对全体服务工厂进行意向征询，促进公开或私有合作。

1.6.服务需求者i通过公共服务中心C相应调度算法，实现对能满足需求的服务节点 (如a-1-1,b-2-1)进行定位和调用，调度算法同时实现同类服务节点的负载均衡，通过性能监控系统对公共服务中心的服务供需状况进行反馈(如反馈给服务工厂a和b)，进一步促进厂商间合作和资源共享。

步骤2，服务工厂任务调度。

2.1.各服务工厂a…n动态调整提供的服务，并根据公共服务中心的供需关系动态调整对应服务节点a-1,a-2,…,n-1,n-j的数量，实现调度算法的智能调度、资源的动态部署和弹性分配。

2.2.服务工厂模式全体参与者动态维护和开发调度算法，通过奖惩机制促进资源供需关系的满足，促进厂商间资源开放、业务合作、底层服务共享。

2.3.公共服务中心C定期对服务节点a-1,a-2,…,n-1,n-j情况汇总汇报，促进相似度较高的节点成立新的服务工厂便于后续维护以及规模的扩大；促进具有明显互补作用的不同服务工厂的服务节点部署的一致性，便于动态调整对应服务节点的规模。

Claims (3)

1.一种复杂软件耦合建模方法，其特征在于，包括以下步骤：

步骤1，构建服务工厂联合体；

步骤2，服务工厂任务调度。

2.如权利要求1所述一种复杂软件耦合建模方法，其特征在于，步骤1包括以下步骤：

步骤1.1各厂商、工业机构、数据提供商等自然组织a…n等构建服务工厂联合体；服务工厂联合体统筹规划公共服务中心C的服务资源，成立公共开发资源池，用于相应公有服务池和调度算法、节点监控系统的开发维护，各自然组织可独自或合作组建一个或多个服务工厂a…n,并依据业务类型和资源规模选择提供的服务，形成服务工程模式架构；

步骤1.2对于任一服务工厂k，利用公共开发资源池和私有开发资源，通过实例化服务调度工厂，实现与公共服务中心C的对接通信，完成服务工厂的接入；

步骤1.3各服务工厂a…n对其负责的应用或服务进行服务水平细分和服务垂直细分，细分为服务节点a-1,a-2,…,n-1,n-j，通过公共服务中心C实现调度算法接口的接入，同时，在调度算法的实例中，应确保对所有接入的服务节点能够进行性能监控；

步骤1.4各服务工厂a…n根据步骤1.3对内进行服务分配，同时，将服务节点独自或组合进行封装，对外封装成服务节点接入公共服务中心C；

步骤1.5各自然组织a…n直接通过公共服务中心C根据需求调用服务、开发资源，对未能满足的需求，向公共服务中心提出需求；公共服务中心C根据需求的服务类型和规模对全体服务工厂进行意向征询，促进公开或私有合作；

步骤1.6服务需求者i通过公共服务中心C相应调度算法，实现对能满足需求的服务节点(如a-1-1,b-2-1)进行定位和调用，调度算法同时实现同类服务节点的负载均衡，通过性能监控系统对公共服务中心的服务供需状况进行反馈(如反馈给服务工厂a和b)，进一步促进厂商间合作和资源共享。

3.如权利要求1所述一种复杂软件耦合建模方法，其特征在于，步骤2包括以下步骤：

步骤2.1各服务工厂a…n动态调整提供的服务，并根据公共服务中心的供需关系动态调整对应服务节点a-1,a-2,…,n-1,n-j的数量，实现调度算法的智能调度、资源的动态部署和弹性分配；

步骤2.2服务工厂模式全体参与者动态维护和开发调度算法，通过奖惩机制促进资源供需关系的满足，促进厂商间资源开放、业务合作、底层服务共享；

步骤2.3公共服务中心C定期对服务节点a-1,a-2,…,n-1,n-j情况汇总汇报，促进相似度较高的节点成立新的服务工厂便于后续维护以及规模的扩大；促进具有明显互补作用的不同服务工厂的服务节点部署的一致性，便于动态调整对应服务节点的规模。

Images