CN112463147B - 一种针对通用化模型客制化需求开发方法 - Google Patents

Abstract

本发明公开了一种针对通用化模型客制化需求开发框架。本发明包括以下步骤：(1)首先，在服务器上对项目进行部署，包括主体模型和客制化代码的部署，部署需要按照框架来进行；(2)对部署好的项目进行客制化代码版本校验；(3)对客制化代码与主线模型进行适配校验；(4)检验主线模型的部署版本是否正确；(7)客制化代码在主线模型中生效。本发明对模型上线部署时，由于人为原因造成的版本部署错误和客制化代码与主体模型不匹配问题提供脚本。通过本发明可以提升模型的复用性，提升模型的部署效率，提升模型部署bug的查找效率，同时有利于规范和优化通用化模型开发流程。

Description

一种针对通用化模型客制化需求开发方法

技术领域

本发明属于软件工程开发技术领域，具体涉及一种开发通用化模型时所使用的模型客制化需求开发方法。

背景技术

在定制化模型开发中，模型开发是独立的，当用户提出新需求时，在用户已有模型的基础上，进行新需求的扩展。在定制化模型开发的过程中，不存在无法迭代的需求，所以在定制化模型开发过程是一个闭环流程。

但通用化模型的开发希望是面向多租户多场景的，在这种模型开发的过程中会存在主体模型可以提供固定的服务，但是无法满足所有租户的客制化需求的问题，这就需要使客制化需求迭代到主体模型中。在客制化代码积累的过程中，当客制化代码积累到一定程度时，多个租户下的多个场景就会有相似的可以整合的需求，可以将这一类客制化需求迭代到主体模型中，但是始终会存在无法迭代的需求，就会导致主体模型和客制化代码之间不能形成闭环的问题。

同时在模型开发时还会存在主体模型代码进行大版本更新，而客制化代码未能及时更新，导致项目在上线时出现报错。这种主体模型和客制化代码不匹配问题，也是通用化模型中经常出现的问题。

因此本发明针对这两个问题进行分析，设计出一套解决此问题的模型客制化需求开发框架，为通用化项目的开发提供稳定的技术支持。

发明内容

本发明的目的在于解决通用化模型开发中的客制化需求迭代和主体模型不能实现闭环问题，以及项目部署时客制化代码和主体模型不匹配的问题。

模型客制化需求开发框架，其可支持解决的问题类型包括：

类型1：在项目开发过程中，客制化需求迭代到主线时的闭环问题。

类型2：在项目部署阶段，项目主线代码和客制化代码的部署问题。

类型3：在项目部署完成后，主线代码部署版本是否正确问题。

类型4：在项目部署完成后，客制化代码版本部署是否正确问题。

类型5：在项目部署完成后，客制化代码和主线代码版本之间是否匹配的问题。

本发明解决通用化模型开发时客制化需求迭代到主体模型过程中存在闭环问题的具体逻辑如下：

步骤1：根据项目主体模型的基本构成，对主体模型进行解耦，将主体模型分为四个层级，在框架的src目录下放置主体模型的四层结构，主体模型四层结构具体如下：

第一层：application文件夹作为模型的appliction层，主要作用是用来存放主体模型的基本流程代码。

第二层：business_unit文件夹作为模型的business_unit层，是用来存放主体模型的业务逻辑代码，是存在依赖关系的类。

第三层：component文件夹作为模型的component层，用来存放主体模型的功能组件代码。

第四层：basic文件夹作为模型的basic层，用来存放模型数据读取代码，是对获取业务单体数据的封装类。

步骤2：构建框架下项目的客制化代码存放路径，客制化代码通过继承主体模型来对主体模型进行扩展；且在框架中，将放置客制化代码的文件夹extend_dev创建在src目录下。

步骤3：在通用化模型进行开发时，主体模型在四层结构的基础上进行版本的迭代和升级，客制化代码在文件夹extend_dev中通过继承的方式完成需求的开发。

所述的版本的迭代和升级具体实现如下：

主体模型版本迭代升级具体有：主体模型需求的扩展、主体模型功能优化、主体模型结构优化、客制化需求迭代到主体模型以及主体模型中存在bug的修复。客制化代码迭代升级具体有：租户需求增加、客制化代码bug修复以及客制化代码根据主体模型进行匹配修改。

当客制化需求开发完成后，将客制化代码保存在各个租户对应的客制化代码仓库中。主体模型中不保留客制化代码。

步骤4：对框架下项目进行部署时，首先将对应租户的客制化代码部署在src目录的extend_dev文件夹下，再将项目部署在对应租户的云服务器上为租户提供服务。

步骤5：对完成项目部署的框架进行测试，解决存在的主体模型/客制化代码版本异常问题和客制化代码与主体模型不匹配问题。具体实现如下：

针对人为原因导致部署的主体模型代码和项目的主体模型代码版本不一致问题，通过提供主体模型版本校验脚本解决。具体：在项目部署时对主体模型代码进行MD5加密，并生成该版本对应的MD5码，同时项目上的主体模型代码也会生成一份对应的MD5码；对比两份MD5码来判断主体模型代码版本的一致性，若不一致，则重新部署主体模型代码。

针对人为原因导致客制化代码的部署出现版本部署错误，针通过提供客制化代码版本校验脚本解决。由于客制化代码并没有对应的版本信息，因此对客制化代码版本的校验，具体：针对部署的客制化代码和客制化代码仓库对应分支的最新客制化代码进行对比，判断部署的客制化代码是否与对应分支的最新客制化代码保持一致，若不一致则重新部署客制化代码。

针对客制化代码与主体模型不匹配问题，通过提供客制化代码与主体模型代码匹配校验脚本解决，在开发中会存在由于主体模型更新而客制化代码没有及时更新适配主体模型，导致产品模型报错；该脚本针对客制化代码中的类和主体模型中的类进行匹配校验，通过动态加载类匹配、函数匹配来解决该问题，并输出日志。

所述的客制化代码与主体模型匹配校验脚本的校验实现如下：

①：动态加载客制化代码，验证客制化代码中的import导入模块是否存在错误，如果存在错误则说明当前客制化代码和主线模块代码存在差异，需要进行检验。

②：对类继承关系进行校验，因为客制化代码继承主体模型中的模块，所以获取客制化代码中的类名和客制化代码继承的父类类名以及主体模型中类的类名，判断客制化代码的父类是否存在于主体模型，若不存在进行检查。

③：对函数进行校验，验证客制化代码中的函数是否在主体模型中存在。

步骤6：框架测试无异常后，执行项目。

将客制化代码加载到主体模型，通过客制化代码加载脚本实现项目运行：执行到src路径下的产品模型时，根据python语言的特性优先执行src路径下的__init__.py文件。客制化代码加载组件的入口函数在__init__.py文件中，所以主体模型运行前会将客制化代码加载到主体模型中。

所述的加载的过程实现包括：

加载python内置的sys.module。

获取客制化代码文件路径。

动态加载客制化代码，并将加载的客制化代码信息存放到列表。

生成客制化代码类和所继承的对应的主体模型的类的映射关系。

在sys.module中查找对应的主体模型的类映射关系。

将sys.module中的主体模型的类映射关系改为客制化代码类的映射关系。

完成客制化代码加载到主线。

步骤6：随着模型的研发，当客制化需求积累到指定阈值时，将这种客制化需求迭代到主体模型。

所述的框架脚本运行方法及运行结果日志存放位置:

执行方式1：在部署完成后可以通过shell命令执行，上述几个验证中的某一个脚本或全部脚本。

执行方式2：可以将验证脚本集成在Airflow调度中，在项目上线部署完成后，在Airflow调度中通过执行对应的脚本，对项目进行校验。

执行结束后运行结果日志存放在项目log文件中，用户可以查看运行结果。结果主要包括，主体模型版本校验结果、客制化代码版本校验结果，以及客制化代码和主体模型匹配校验结果等信息，使用者可以直观的发现项目主体模型和客制化代码之间存在的问题。

本发明的有益效果：

本发明对通用化模型中存在的问题进行分析，设计出一种解决客制化需求迭代到主体模型闭环问题的方案。并对模型上线部署时，由于人为原因造成的版本部署错误和客制化代码与主体模型不匹配问题提供脚本。通过本发明可以提升模型的复用性，提升模型的部署效率，提升模型部署bug的查找效率，同时有利于规范和优化通用化模型开发流程。本框架适用于基于通用化模型，能够实现客制化需求迭代到主线的闭环，同时能够校验客制化代码和主线模型之间的问题，规避开发流程中的许多错误，提升开发效率。

附图说明

图1是本发明中框架的基本结构图，包含项目主体代码的目录，客制化代码目录extend_dev，以及动态加载入口文件__init__.py。

图2 是模型客制化需求框架图。

图3 是客制化需求积累并迭代到主线流程图。

图4 是客制化代码需求迭代到主体模型流程图。

图5 是动态加载客制化代码到主线流程图。

图6 是本发明框架整体执行流程图。

实施方式

下面结合附图详细的描述本发明，本发明的目的和结果将变得更加清晰。本实例是本发明在真实项目开发过程中的一个具体应用。通过真实的项目开发过程中存在的问题，来验证框架对通用化项目的适用性和解决问题的能力。

如图1-6所示，一种针对通用化模型客制化需求开发方法，具体实现如下：

步骤1：项目开发，拉取项目主体模型代码和客制化需求代码，主体模型使用客制化需求开发框架构建，对主体模型进行开发。将客制化需求代码放入extend_dev文件夹，对客制化需求进行开发。项目目录如图1所示。

步骤2：部署项目，将项目的主线代码部署到对应的application、business_unit、component、basic目录中，并将客制化代码部署到extend_dev目录下，其中客制化代码和主体模型存在继承关系，例如客制化代码继承主线代码中的repeat_order中的RepeatOrder类，客制化代码中的子类为RepeatOrderCoustmer,如图2所示。

步骤3：将客制化需求迭代到主体模型模型，当客制化需求积累到一定程度时，租户之间会有很多相似的需求，将这些相似的需求合并到主体模型，如图4所示。

步骤4：运行模型客制化需求开发框架中的代码验证脚本，分别对主体模型版本、客制化代码版本、客制化代码和主体模型匹配进行校验，验证模型部署是否正确，主体模型和客制化需求之间是否存在不匹配问题。若模型部署无误，代码校验结束。

步骤5：开始运行项目模型，执行客制化代码加载脚本，将客制化代码动态加载到主线中。项目执行后会将所有的类存放到sys.module中，动态加载会将客制化代码的类和属性加载到sys.module字典映射中，通过修改主体模型的映射为主体模型中的类到客制化代码中的类映射，使客制化代码生效替换主体模型，如图5所示。

步骤6：该部分是一个周期性的工作，随着项目的开发，客制化需求积累到一定程度时，多租户的客制化需求可以迭代到主线中。将这部分需求添加到当前主线的组件库中，增强主体模型的通用性，如图3所示。

模型客制化需求开发框架整体流程图如图6所示。

本发明不仅局限于上述具体实施方式，本领域一般技术人员根据 本发明公开的内容，可以采用其它多种具体实施方案实施本发明。因 此，凡是采用本发明的设计结构和思路，做一些简单的变化或更改的 设计，都落入本发明保护范围。

Claims (4)

1.一种针对通用化模型客制化需求开发方法，其特征在于包括如下步骤：

步骤1：根据项目主体模型的基本构成，对主体模型进行解耦，将主体模型分为四个层级，在框架的src目录下放置主体模型的四层结构，主体模型四层结构具体如下：

第一层：application文件夹作为模型的appliction层，主要作用是用来存放主体模型的基本流程代码；

第二层：business_unit文件夹作为模型的business_unit层，是用来存放主体模型的业务逻辑代码，是存在依赖关系的类；

第三层：component文件夹作为模型的component层，用来存放主体模型的功能组件代码；

第四层：basic文件夹作为模型的basic层，用来存放模型数据读取代码，是对获取业务单体数据的封装类；

步骤2：构建框架下项目的客制化代码存放路径，客制化代码通过继承主体模型来对主体模型进行扩展；且在框架中，将放置客制化代码的文件夹extend_dev创建在src目录下；

步骤3：在通用化模型进行开发时，主体模型在四层结构的基础上进行版本的迭代和升级，客制化代码在文件夹extend_dev中通过继承的方式完成需求的开发；

步骤4：对框架下项目进行部署时，首先将对应租户的客制化代码部署在src目录的extend_dev文件夹下，再将项目部署在对应租户的云服务器上为租户提供服务；

步骤5：对完成项目部署的框架进行测试，解决存在的主体模型/客制化代码版本异常问题和客制化代码与主体模型不匹配问题；

步骤6：框架测试无异常后，执行项目；

将客制化代码加载到主体模型，通过客制化代码加载脚本实现项目运行：执行到src路径下的产品模型时，根据python语言的特性优先执行src路径下的__init__.py文件；客制化代码加载组件的入口函数在__init__.py文件中，所以主体模型运行前会将客制化代码加载到主体模型中。

2.根据权利要求1所述的一种针对通用化模型客制化需求开发方法，其特征在于步骤5的不匹配问题具体解决如下：

针对人为原因导致部署的主体模型代码和项目的主体模型代码版本不一致问题，通过提供主体模型版本校验脚本解决；具体：在项目部署时对主体模型代码进行MD5加密，并生成该版本对应的MD5码，同时项目上的主体模型代码也会生成一份对应的MD5码；对比两份MD5码来判断主体模型代码版本的一致性，若不一致，则重新部署主体模型代码；

针对人为原因导致客制化代码的部署出现版本部署错误，针通过提供客制化代码版本校验脚本解决；由于客制化代码并没有对应的版本信息，因此对客制化代码版本的校验，具体：针对部署的客制化代码和客制化代码仓库对应分支的最新客制化代码进行对比，判断部署的客制化代码是否与对应分支的最新客制化代码保持一致，若不一致则重新部署客制化代码；

针对客制化代码与主体模型不匹配问题，通过提供客制化代码与主体模型代码匹配校验脚本解决，在开发中会存在由于主体模型更新而客制化代码没有及时更新适配主体模型，导致产品模型报错；该脚本针对客制化代码中的类和主体模型中的类进行匹配校验，通过动态加载类匹配、函数匹配来解决该问题，并输出日志。

3.根据权利要求1或2所述的一种针对通用化模型客制化需求开发方法，其特征在于步骤5所述的客制化代码与主体模型匹配校验脚本的校验实现如下：

①：动态加载客制化代码，验证客制化代码中的import导入模块是否存在错误，如果存在错误则说明当前客制化代码和主线模块代码存在差异，需要进行检验；

②：对类继承关系进行校验，因为客制化代码继承主体模型中的模块，所以获取客制化代码中的类名和客制化代码继承的父类类名以及主体模型中类的类名，判断客制化代码的父类是否存在于主体模型，若不存在进行检查；

③：对函数进行校验，验证客制化代码中的函数是否在主体模型中存在。

4.根据权利要求3所述的一种针对通用化模型客制化需求开发方法，其特征在于步骤6所述的加载的过程实现包括：

加载python内置的sys.module；

获取客制化代码文件路径；

动态加载客制化代码，并将加载的客制化代码信息存放到列表；

生成客制化代码类和所继承的对应的主体模型的类的映射关系；

在sys.module中查找对应的主体模型的类映射关系；

将sys.module中的主体模型的类映射关系改为客制化代码类的映射关系；

完成客制化代码加载到主线。

Images