CN115562641A - 数据处理方法、装置、电子设备及计算机可读存储介质 - Google Patents

Abstract

本申请实施例提供了一种数据处理方法、装置、电子设备及计算机可读存储介质，涉及计算机技术领域。该方法应用于基于微服务开发平台实现的代码生成器中，基于微服务平台还实现有用于生成业务规范的规范设计器，包括：响应于接收到的业务开发请求，获取规范设计器生成的与业务开发请求对应的第一业务规范；根据第一业务规范中的设计规范对业务开发请求中的业务设计参数进行检查，得到第一检查结果；在第一检查结果表征业务设计参数的设计逻辑符合设计规范时，根据第一业务规范中的开发规范以及业务设计参数，生成业务开发代码。本申请实施例可以实现通过业务开发请求对应的第一业务规范对业务开发过程进行约束，保障第一业务规范的执行质量。

Description

数据处理方法、装置、电子设备及计算机可读存储介质

技术领域

本申请涉及计算机技术领域，具体而言，本申请涉及一种数据处理方法、装置、电子设备及计算机可读存储介质。

背景技术

在现有的系统开发场景中，通常是按照以下流程完成：需求提出→需求分析→系统设计→架构设计→规范设计→数据库设计→服务设计→业务编码→代码构建→服务部署。在整个过程中，规范设计、服务设计和业务编码的过程尤为重要，其中，服务设计过程可以认为是根据需求进行框架构建的过程，为业务编码奠定基础。业务编码过程可以认为是将设计结果转换为计算机可执行程序的过程，无论是服务设计过程和业务编码过程都需要满足相应的规范，即通常是基于“规范设计”步骤中生成的规范进行系统的业务代码的开发等，规范设计的执行质量直接影响系统的健壮性、可维护性和可扩展性等多方面特性。

而在基于相关技术进行规范设计、服务设计和业务编码过程中，各个步骤都需要人为干预，不稳定性较高，导致规范不能被执行或者不能完全、彻底地被执行，最后导致出现很多系统性问题。

发明内容

本申请实施例提供了一种数据处理方法、装置、电子设备及计算机可读存储介质，用于解决在业务开发过程中，不能有效遵循设计和/或开发规范进行业务开发的技术问题。

根据本申请实施例的一个方面，提供了一种数据处理方法，该方法应用于基于微服务开发平台实现的代码生成器中，基于微服务平台还实现有用于生成业务规范的规范设计器，该方法包括：

响应于接收到的业务开发请求，获取规范设计器生成的与业务开发请求对应的第一业务规范；其中，第一业务规范包括设计规范以及开发规范；

根据设计规范对业务开发请求中的业务设计参数进行检查，得到第一检查结果；第一检查结果表征业务设计参数的设计逻辑是否符合设计规范；

在第一检查结果表征业务设计参数的设计逻辑符合设计规范的情况下，根据开发规范以及业务设计参数，生成业务开发代码。

根据本申请实施例的另一个方面，提供了一种数据处理装置，该装置为基于微服务开发平台实现的代码生成器，基于微服务平台还实现有用于生成业务规范的规范设计器，包括：

业务规范获取模块，用于响应于接收到的业务开发请求，获取规范设计器生成的与业务开发请求对应的第一业务规范；其中，第一业务规范包括设计规范以及开发规范；

业务设计参数检查模块，用于根据设计规范对业务开发请求中的业务设计参数进行检查，得到第一检查结果；第一检查结果表征业务设计参数的设计逻辑是否符合设计规范；

代码生成模块，用于在第一检查结果表征业务设计参数的设计逻辑符合设计规范的情况下，根据开发规范以及业务设计参数，生成业务开发代码。

根据本申请实施例的又一个方面，提供了一种电子设备，该电子设备包括存储器、处理器及存储在存储器上的计算机程序，该处理器执行计算机程序以实现上述方法。

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

本申请实施例提供的技术方案带来的有益效果是：

在本申请实施例提供的数据处理方法中，该方法应用于基于微服务开发平台实现的代码生成器中，基于微服务平台还实现有用于生成业务规范的规范设计器，通过该方法可以实现在基于代码生成器接收到的业务开发请求，生成该业务开发请求对应的业务开发代码的过程中，利用与业务开发请求对应的第一业务规范中的设计规范，对业务开发请求中的业务设计参数中的设计逻辑进行检查，并在业务设计参数中的设计逻辑符合设计规范的情况下，再基于第一业务规范中的开发规范和业务设计参数生成业务开发代码，使得所生成的业务开发代码符合第一业务规范，实现通过业务开发请求对应的第一业务规范对业务开发代码的生成过程进行约束，从而有效保障设计规范和开发规范的执行质量，便于提高基于生成的业务开发代码开发得到的业务的规范性和稳定性。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对本申请实施例描述中所需要使用的附图作简单地介绍。

图1示出了相关技术中为本申请实施例提供的规范的设计和执行的系统架构示意图；

图2示出了本申请实施例提供的一种数据处理方法的流程示意图；

图3示出了本申请实施例提供的数据处理方法的应用场景示意图；

图4示出了本申请实施例提供的数据处理方法的另一应用场景示意图；

图5示出了本申请实施例提供的数据处理装置的结构示意图；

图6示出了本申请实施例所适用的一种电子设备的结构示意图。

具体实施方式

下面结合本申请中的附图描述本申请的实施例。应理解，下面结合附图所阐述的实施方式，是用于解释本申请实施例的技术方案的示例性描述，对本申请实施例的技术方案不构成限制。

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本申请实施例所使用的术语“包括”以及“包含”是指相应特征可以实现为所呈现的特征、信息、数据、步骤、操作、元件和/或组件，但不排除实现为本技术领域所支持其他特征、信息、数据、步骤、操作、元件、组件和/或它们的组合等。应该理解，当我们称一个元件被“连接”或“耦接”到另一元件时，该一个元件可以直接连接或耦接到另一元件，也可以指该一个元件和另一元件通过中间元件建立连接关系。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的术语“和/或”指示该术语所限定的项目中的至少一个，例如“A和/或B”可以实现为“A”，或者实现为“B”，或者实现为“A和B”。

下面通过对几个示例性实施方式的描述，对本申请实施例的技术方案以及本申请的技术方案产生的技术效果进行说明。需要指出的是，下述实施方式之间可以相互参考、借鉴或结合，对于不同实施方式中相同的术语、相似的特征以及相似的实施步骤等，不再重复描述。

相关技术中，如图1所示，进行规范设计、服务设计和业务编码的过程主要包括：步骤1：规范制定者(简称“制定者”)制定标准设计规范，形成“设计规范文档”；步骤2：系统/服务设计者(简称“设计者”)充分学习和了解“设计规范文档”；步骤3：设计者根据“设计规范文档”设计系统/服务，形成“设计文档”；步骤4：制定者根据“设计规范文档”，检查“设计文档”；步骤5：制定者向系统/服务设计者反馈检查结果，如有问题，督促其修改“设计文档”。步骤6：制定者制定标准开发规范，形成“开发规范文档”；步骤7：系统/服务开发者(简称“开发者”)充分学习和了解“设计文档”；步骤8：开发者充分学习和了解“开发规范文档”；步骤9：开发者根据“设计文档”和“开发规范文档”开发代码，形成代码；步骤10：制定者根据“开发规范文档”，检查“代码”；步骤11：制定者向系统/服务开发者反馈检查结果，如有问题，督促其修改“代码”。

可见，在基于该技术进行业务开发的过程的各步骤中，可能会由于规范传播不彻底(设计者未按设计规范形成“设计文档”、开发者未按开发规范形成“代码”等)、代码审查不严格、规范修改后未及时通知设计者或开发者等原因，导致规范不能被执行或者不能完全、彻底地被执行，即并不能有效遵循设计和/或开发规范进行业务开发，会导致开发得到的业务不够稳定。为了解决该技术问题，本申请实施例提供了以下数据处理方法：

图2示出了本申请实施例提供的一种数据处理方法的示意图。该方法应用于基于微服务开发平台实现的代码生成器中，该代码生成器可以具体为基于微服务开发平台实现的微服务器。该微服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN(Content Delivery Network，内容分发网络)、以及大数据和人工智能平台等基础云计算服务的云服务器或服务器集群。

本领域技术人员应能理解上述服务器仅为举例，其他现有的或今后可能出现的服务器如可适用于本申请，也应包含在本申请保护范围以内，并在此以引用方式包含于此。

如图2所示，该方法包括：

步骤S21：响应于接收到的业务开发请求，获取规范设计器生成的与业务开发请求对应的第一业务规范；其中，第一业务规范包括设计规范以及开发规范。其中，该规范设计器是基于上述微服务平台实现的用于生成业务规范的规范设计器。

业务开发请求中可以包括业务标识，可以通过该业务标识，确定出所要开发的业务。该业务可以包括但不限于系统、服务、平台等，其中，服务可以为任一服务、微服务等，本申请实施例对此不做限制。具体地，系统可以为应用系统(application，即app)，服务可以为银行服务，微服务可以为小程序等。

业务规范可以为开发业务所需用到的规范，可以包括但不限于架构规范、使用规范、设计规范(如上述“设计规范文档”)、开发规范(如上述“开发规范文档”)和运维规范等。其中，架构规范主要是指整个架构体系上的约定，如网络、服务注册与发现、集群部署等。使用规范主要是指系统建设过程中所用到的技术栈、中间件等的使用约定，如数据库、redis(一种数据存储机制)、mq(message queue，消息队列)、分布式序列等的用法和原则。设计规范主要是从系统、服务规划设计视角提供方法论和约定，如系统拆分、服务拆分、分库分表、服务命名等方面的约定。开发规范主要是从编码的视角提供约定和指导，如类名规范、包路径规范、属性规范、错误码规范、日志规范等。运维规范主要是从运维的视角提供约定和指导，如部署单元、扩缩容、服务监控等方面的约定。

在本申请实施例中，以业务规范中的设计规范和开发规范为例，对业务开发过程进行说明。其中，设计规范可以包括但不限于系统拆分规范、服务拆分规范、数据标准规范、服务命名规范、系统命名规范等。开发规范可以包括但不限于工程命名规范、包名规范、类名规范、错误码规范、属性命名规范、方法命名规范、数据库命名规范等。

步骤S22：根据设计规范对业务开发请求中的业务设计参数进行检查，得到第一检查结果；第一检查结果表征业务设计参数的设计逻辑是否符合设计规范。

其中，业务设计参数(如上述“设计文档”)可以直接通过业务开发请求获取，也可以在获取到业务开发请求之后，基于业务标识重新获取业务设计参数，本申请实施例对此不做限制。

业务设计参数可以包括但不限于接口参数、流程配置参数、服务命名参数等。通过该业务设计参数，可以进一步进行业务设计、业务开发等操作。

在获取到业务设计参数之后，在基于设计规范对该业务设计参数的设计逻辑进行检查时，业务设计参数的设计逻辑符合设计规范，即业务设计参数的设计方式与设计规范中规定的设计逻辑一致/相同。例如，可以在确定业务设计参数中的语法规则与设计规范中规定的语法规则一致时，确定业务设计参数的设计逻辑符合设计规范。

具体地，可以基于设计规范中的数据标准规范、服务命名规范、系统命名规范等，确定业务设计参数中的接口参数的正确性与合理性。可以基于设计规范中的系统拆分规范、服务拆分规范、数据标准规范等，确定业务设计参数中的流程配置参数的正确性与合理性。

需要说明的是，在该实现方式中，基于设计规范对业务设计参数进行检查的方式仅为示例，在实际应用过程中，可以根据实际情况选择具体地设计规范对相应的业务设计参数进行检查。

步骤S23：在第一检查结果表征业务设计参数的设计逻辑符合设计规范的情况下，根据开发规范以及业务设计参数，生成业务开发代码。

在根据设计规范，确定业务设计参数的设计逻辑符合设计规范的情况下，可以根据开发规范及业务设计参数，生成业务开发代码。

其中，在根据设计规范，确定业务设计参数不符合设计规范的情况下，可以发出相应的提示信息，以指示执行重新获取业务设计参数、对业务设计参数进行修改等操作，直至获取到符合设计规范的业务设计参数，再根据开发规范及符合设计规范的业务设计参数，生成业务开发代码。

在本申请实施例提供的数据处理方法中，可以实现在基于代码生成器接收到的业务开发请求，生成该业务开发请求对应的业务开发代码的过程中，利用与业务开发请求对应的第一业务规范中的设计规范，对业务开发请求中的业务设计参数中的设计逻辑进行检查，并在业务设计参数中的设计逻辑符合设计规范的情况下，再基于第一业务规范中的开发规范和业务设计参数生成业务开发代码，使得所生成的业务开发代码符合第一业务规范，实现通过业务开发请求对应的第一业务规范对业务开发代码的生成过程进行约束，从而有效保障设计规范和开发规范的执行质量，便于提高基于生成的业务开发代码开发得到的业务的规范性和稳定性。

并且，在该方法中，可以自动化地利用与业务开发请求对应的第一业务规范中的设计规范和开发规范对业务开发代码的生成过程进行约束，不需要设计者和开发者强制学习和牢记设计规范和开发规范，减少业务开发中所需的人力成本和时间成本。

在一种可能的实现方式中，上述方法还可以包括：

在上述第一检查结果表征上述业务设计参数的设计逻辑不符合上述设计规范的情况下，生成第一指示信息；

其中，上述第一指示信息指示重新获取业务设计参数，并在确定重新获取的业务设计参数的设计方式符合上述设计规范的情况下，根据上述开发规范以及上述重新获取的业务设计参数，生成业务开发代码。

上述第一指示信息可以为约束提示(如“请重新获取符合设计规范的业务设计参数”)或错误提示(如“当前业务开发请求中的业务设计参数不符合业务规范”)。

通过该方式，在业务设计参数的设计逻辑不符合设计规范的情况下，生成第一指示信息(即约束或错误提示)，并基于该提示信息重新获取业务设计参数，直至获取的业务设计参数的设计方式符合设计规范，可以获取到符合设计规范的业务设计参数，从而在基于开发规范以及符合设计规范的业务设计参数，生成业务开发代码，并基于该业务开发代码进行业务开发时，可以提高所开发的业务的规范性。

在一种可能的实现方式中，上述根据上述开发规范以及上述业务设计参数，生成业务开发代码，可以包括：

根据上述开发规范中的接口规范和错误码规范，对上述业务设计参数进行编译，得到业务设计源代码；以及根据上述开发规范中的实现类命名规范和包路径命名规范，对上述业务设计参数进行编译，得到业务开发源代码；

根据上述业务设计源代码和上述业务开发源代码，得到上述业务开发代码。

在该实现方式中，对得到业务设计源代码的过程和得到业务开发源代码的过程的执行顺序不做限制，可以先根据接口规范和错误码规范，对业务设计参数进行编译(具体来讲，编译过程即低代码生成过程)，得到业务设计源代码；再根据实现类命名规范和包路径命名规范，对业务设计参数进行编译，得到业务开发源代码。也可以先根据实现类命名规范和包路径命名规范，对业务设计参数进行编译，得到业务开发源代码；再根据接口规范和错误码规范，对业务设计参数进行编译，得到业务设计源代码。当然，也可以并行执行得到业务设计源代码的过程和得到业务开发源代码的过程。

以业务设计参数为接口参数为例，在获取相应的业务开发代码过程中，在基于接口规范和错误码规范，对当前业务中各接口参数进行编译，得到当前业务中各接口设计源代码的过程可以视为确定用来指示当前业务中各接口的定义的代码的过程。在根据实现类命名规范和包路径规范，对当前业务中各接口参数进行编译，得到接口开发源代码的过程可以视为确定用来指示当前业务中各接口之间的关系的代码的过程。

考虑到在不同的业务开发过程中，不同的业务所需的业务设计源代码和业务开发源代码可能是相同的。在该实现方式中，在得到业务设计源代码和业务开发源代码之后，还可以通过对业务设计源代码和业务开发源代码进行打包，并上传至云端，以节省后续开发过程中，生成相同的业务设计源代码和业务开发源代码的时间。

以通过maven工具(一种项目管理工具)进行打包为例，可以根据接口规范和错误码规范，对业务设计参数进行编译，通过执行mvn install命令，在本地repository(仓库)中构建生成jar包(Java Archive，Java归档文件，一种软件包文件格式)，得到业务设计源代码。并通过执行mvn deploy命令(即，发布项目)，将生成的jar包上传到maven私服(一种远程仓库，例如，nexus)进行管理。

在一种可能的实现方式中，上述根据上述开发规范中的接口规范和错误码规范，对上述业务设计参数进行编译，得到业务设计源代码，可以包括：

根据上述接口规范，对上述业务设计参数中的接口参数进行编译，得到接口定义源代码；以及根据上述错误码规范，对上述业务设计参数中的流程配置参数进行编译，得到配置文件；

根据上述接口定义源代码和上述配置文件，得到上述业务设计源代码。

在该实现方式中，对得到接口定义源代码的过程和得到配置文件的过程执行顺序不做限制，可以先根据接口规范，对接口参数进行编译，得到接口定义源代码；再根据错误码规范，对流程配置参数进行编译，得到配置文件。也可以先根据错误码规范，对流程配置参数进行编译，得到配置文件；再根据接口规范，对接口参数进行编译，得到接口定义源代码。当然，也可以并行执行得到接口定义源代码的过程和得到配置文件的过程。

在具体实现过程中，可以根据接口规范对接口参数进行编译，生成java设计源代码(如接口类、输入输出对象类等)。可以根据错误码规范对流程配置参数进行编译，得到pom配置文件(Project Object Model，项目对象模型)，通过在java设计源代码和pom配置文件的基础上，执行mvn install命令构建生成jar包。

可以根据实现类命名规范和包路径命名规范，对业务设计参数进行编译，生成java开发源代码(如springboot工程结构代码)，生成zip压缩包，得到业务开发源代码。并通过执行mvn deploy命令，将生成的jar包上传到maven私服进行管理。由于可以直接在业务开发源代码的基础上进行代码开发，在本申请实施例中，也可以将“业务开发源代码”称为“工程脚手架代码”。

在一种可能的实现方式中，上述根据上述开发规范中的实现类命名规范和包路径命名规范，对上述业务设计参数进行编译，得到业务开发源代码，可以包括：

根据上述实现类命名规范和上述包路径命名规范，对上述业务设计参数中的接口参数进行编译，得到上述业务开发源代码。

对于一业务设计参数，其对应的业务设计源代码和业务开发源代码中对应相同的标识信息，例如，jar包中的maven坐标和zip压缩包中maven坐标相同，可以基于二者对应的maven坐标，从maven私服中确定出各自对应的业务设计源代码或业务开发源代码。

其中，maven坐标包括group Id(组织标识，包名)、artifact Id(项目名称)、version(版本号)、packaging(打包方式)和classifier(分类器，主要用来帮助定义构建输出的一些附件)。在具体实施过程中，各业务设计源代码和业务开发源代码中，必须定义group Id、artifact Id和version，可以实际情况确定packaging，需要结合插件使用classfier。

在得到业务设计源代码和业务开发源代码之后，可以在业务设计源代码和业务开发源代码的基础上，对相应的接口等业务设计参数再次进行编码，得到业务开发代码。

以上述业务设计参数为接口参数为例，在得到当前业务中各接口进行定义的代码，以及当前业务中各接口之间的关系的代码之后，可以在二者的基础上，设置接口实现的具体代码，得到业务开发代码。

在具体实施过程中，在通过该方法的执行主体得到业务设计源代码和业务开发源代码，可以直接基于该执行主体，在业务设计源代码和业务开发源代码的基础上进行编码，得到业务开发代码。也可以将所得到的业务设计源代码和业务开发源代码导入到具体的业务开发环境【例如IDE(Integrated Development Environment，集成开发环境)】中，在该业务开发环境中，进行相关的代码开发过程，得到业务开发代码。

其中，在将下载的工程脚手架代码导入IDE中时，可以基于一般的springboot+maven项目的导入方式进行导入。其中，springboot+maven项目是指基于Maven工程使用SpringBoot(一种java框架)，其中，maven表示一种项目管理工具，包括一个pom项目对象模型，一组标准集合(Project Lifecycle)，一个依赖管理系统(Dependency ManagementSystem)，和用来运行定义在生命周期阶段(phase)中插件(plugin)目标(goal)的逻辑。

通过上述方式，可以实现在业务设计和开发过程中，利用业务规范中的设计规范和开发规范对业务设计参数和业务开发代码进行强约束，有效保障设计规范和开发规范的执行质量。

在一种可能的实现方式中，上述业务规范包括上述第一业务规范，规范设计器是通过以下方式获取生成所述第一业务规范的：

响应于针对业务规范的输入操作，接收待生成的业务规范；

获取第二业务规范；其中，第二业务规范是规范设计器在接收到所述待生成的业务规范之前已生成的符合逻辑的业务规范；

基于第二业务规范，对待生成的业务规范进行检查，得到第二检查结果；第二检查结果表征待生成的业务规范的逻辑是否与第二业务规范的逻辑相符；

基于第二检查结果以及待生成的业务规范，确定第三业务规范；

对第二业务规范和第三业务规范进行合并操作，得到第一业务规范。

其中，在第二业务规范中的语法规则与第三业务规范中的语法规则一致时，可以视为第二业务规范的逻辑与第三业务规范的逻辑相符。

通过在规范设计器接收到针对业务规范的输入操作后，基于通过规范设计器已生成且符合逻辑的业务规范(即第二业务规范)对未生成的业务规范(即待生成的业务规范)进行检查，可以使得在先获取到的业务规范的逻辑与在后获取到的业务规范的逻辑一致，避免在基于第一业务规范中的设计规范和开发规范进行基于业务开发请求进行业务开发时，出现逻辑混乱的情况。

需要说明的是，在需要更改已生成的业务规范时，例如，在需要全新的业务规范对业务开发过程进行约束时，可以直接将在先获取到的业务规范替换为新的业务规范，而不必基于在先获取到的业务规范对在后获取到的业务规范进行检查。

在具体实施过程中，上述基于上述第二检查结果以及待生成的业务规范，确定第三业务规范，可以包括：

在上述第二检查结果表征上述待生成的业务规范的逻辑与上述第二业务规范的逻辑相符的情况下，将上述待生成的业务规范确定为第三业务规范；

在上述第二检查结果表征上述待生成的业务规范的逻辑与上述第二业务规范的逻辑不符的情况下，生成第二指示信息；其中，上述第二指示信息指示重新输入业务规范，并将重新接收的、与上述第二业务规范的逻辑相符的业务规范确定为第三业务规范。

通过在规范设计器接收到针对业务规范的输入操作后，在确定通过规范设计器未生成的业务规范(即待生成的业务规范)的逻辑与已生成且符合逻辑的业务规范(即第二业务规范)的逻辑不符的情况下，发出相应的第二指示信息，以指示重新输入业务规范，并将重新接收的、与第二业务规范的逻辑相符的业务规范确定为新的业务规范(即在后获取到的业务规范、第三业务规范)，可以使得在先获取到的业务规范与在后获取到的业务规范逻辑一致，提高最终生成的业务规范的规范性。

为了更清楚地说明本申请实施例提供的数据处理方法，以下以业务为待开发的系统为例，结合图3和图4示出的应用场景，对该数据处理方法作进一步说明。其中，在图4中，微服务开发平台通过前端，后端和持久层组成。

前端可以基于web实现，即web前端，包括Nginx、Vue.js和Element ui等组件。其中，Nginx，一种负载均衡服务器。Vue.js是一套构建用户界面的渐进式框架。Element ui(element，组件，user interface，用户接口)就是基于vue的一个ui框架,该框架基于vue开发了很多相关组件，方便我们快速开发页面。

后端可以包括规范设计器和代码生成器，规范设计器用于辅助业务规范的实现，代码生成器用于辅助业务开发代码的实现。

持久层可以包括数据库和远程仓库等，用来存储开发过程中需要用到的数据。

具体地，可以通过以下步骤实现：

步骤1’：响应于规范制定者在微服务开发平台触发的针对“设计规范”和“开发规范”的录入操作，通过基于微服务开发平台实现的用于生成业务规范的规范生成器获取“设计规范”和“开发规范”。

如图4所示，在该步骤中，可以响应于规范制定者在微服务开发平台中的“规范设计器”对应的录入界面的录入操作，接收“设计规范”和“开发规范”。

该微服务开发平台中的“规范设计器”可以在规范录入过程中，可以根据在先录入的规范的逻辑，对在后录入的规范的逻辑进行检查，核对前后录入的规范的逻辑是否一致，并将核对完成的设计规范和开发规范保存到数据库中。并在在后录入的规范与在先录入的规范的逻辑不符的情况下，生成第二指示信息，重新接收业务规范。从而保证在先录入的规范和在后录入的规范的逻辑都是相符的，便于后续基于所录入的全部规范对所设计的业务的设计逻辑和所开发的业务的开发逻辑进行检查。

步骤2’：响应于系统设计者在微服务开发平台触发的针对系统设计信息的录入操作，通过微服务开发平台设计系统(即业务设计参数)获取并核对所录入的系统设计信息。

如图4所示，在该步骤中，可以响应于系统设计者在微服务开发平台中的“规范设计器”对应的录入界面的录入操作，接收“系统设计信息”。该微服务开发平台中的“代码生成器”可以在“系统设计信息”的录入过程中，获取规范制定者录入的设计规范，根据设计规范检查系统设计信息的合理性和正确性，将满足设计规范的系统设计信息保存到数据库中。并在“系统设计信息”不满足设计规范的情况下，生成第一指示信息，重新接收“系统设计信息”。

步骤3’：响应于系统设计者在微服务开发平台触发的针对已设计的系统的打包操作，微服务开发平台的“代码生成器”会根据录入的规范信息生成java源代码，并编译成jar包。

如图4所示，在该步骤中，响应于系统设计者在微服务开发平台触发的针对已设计的系统的打包操作，微服务开发平台中的“代码生成器”读取数据库中录入的开发规范信息和“系统设计信息”，根据该开发规范信息和“系统设计信息”，生成java设计源代码和pom配置文件，通过执行mvn install命令构建生成jar包，并执行通过mvn deploy命令，将生成的jar包上传到nexus进行管理。所生成的jar包的第一标识信息符合开发规范，标识信息包括分组、命名、版本号等。

步骤4’：响应于系统开发者在微服务开发平台触发的针对工程脚手架代码的下载操作，通过微服务开发平台根据规范信息，生成相应的代码和工程脚手架代码。

如图4所示，在该步骤中，通过微服务开发平台中的“代码生成器”读取数据库中录入的开发规范信息以及系统设计信息，根据开发规范信息以及系统设计信息，生成java开发源代码，并将java开发源代码压缩成zip压缩包，得到工程脚手架代码。

步骤5’：响应于系统开发者根据待开发的系统的分组、命名和版本号，触发的针对对应的工程脚手架代码的下载操作，将下载的工程脚手架代码导入IDE(独立于微服务开发平台的集成开发环境，图4中未示出)中。

步骤6’：响应于系统开发者触发的针对jar包的下载操作，通过maven工具以及待开发的系统的分组、命名和版本号，从nexus中下载对应的jar包。

步骤7’：响应于系统开发者根据所下载的设计jar包中的接口，触发的针对业务逻辑代码的编码操作，输出待开发的系统的业务开发代码。

可见，通过在微服务开发平台中，使得规范的制定过程与执行过程相结合，在系统设计和业务逻辑编码的过程是直接基于满足规范的jar包和工程脚手架代码实现的，即在系统设计和业务逻辑编码的过程，规范是一种强约束，能有效的保证规范的执行效果。且在规范的制定过程与执行过程中，可以通过微服务开发平台监督规范的制定与执行，不需要大量的人力成本和时间成本来检查和督促，不会造成遗漏和错误等情况发生。

并且，在需要更新规范时，重新基于微服务开发平台生成jar包和工程脚手架代码即可，只需要开发者重新核对业务逻辑代码即可，不需要工作人员对jar包和工程脚手架代码重新核对，通过该方式也可以提高效率，降低设计者和开发者学习规范和设计信息的成本和难度。

基于与本申请实施例提供的数据处理方法相同的原理，本申请实施例中还提供了一种数据处理装置。图5示出了本申请实施例提供的一种数据处理装置的示意图。如图5所示，该装置为基于微服务开发平台实现的代码生成器，基于微服务平台还实现有用于生成业务规范的规范设计器，包括：

业务规范获取模块510，用于响应于接收到的业务开发请求，获取规范设计器生成的与业务开发请求对应的第一业务规范；其中，第一业务规范包括设计规范以及开发规范；

业务设计参数检查模块520，用于根据设计规范对业务开发请求中的业务设计参数进行检查，得到第一检查结果；第一检查结果表征业务设计参数的设计逻辑是否符合设计规范；

代码生成模块530，用于在第一检查结果表征业务设计参数的设计逻辑符合设计规范的情况下，根据开发规范以及业务设计参数，生成业务开发代码。

在一种可能的实现方式中，上述代码生成模块530在根据上述开发规范以及上述业务设计参数，生成业务开发代码时，可以具体用于：

根据上述开发规范中的接口规范和错误码规范，对上述业务设计参数进行编译，得到业务设计源代码；以及根据上述开发规范中的实现类命名规范和包路径命名规范，对上述业务设计参数进行编译，得到业务开发源代码；

根据上述业务设计源代码和上述业务开发源代码，得到上述业务开发代码。

在一种可能的实现方式中，上述代码生成模块530在根据上述开发规范中的接口规范和错误码规范，对上述业务设计参数进行编译，得到业务设计源代码时，可以具体用于：

根据上述接口规范，对上述业务设计参数中的接口参数进行编译，得到接口定义源代码；以及根据上述错误码规范，对上述业务设计参数中的流程配置参数进行编译，得到配置文件；

根据上述接口定义源代码和上述配置文件，得到上述业务设计源代码。

在一种可能的实现方式中，上述代码生成模块530在根据上述开发规范中的实现类命名规范和包路径命名规范，对上述业务设计参数进行编译，得到业务开发源代码时，可以具体用于：

根据上述实现类命名规范和上述包路径命名规范，对上述业务设计参数中的接口参数进行编译，得到上述业务开发源代码。

在一种可能的实现方式中，上述业务设计参数检查模块520还可以用于：

在上述第一检查结果表征上述业务设计参数不符合上述设计规范的情况下，生成第一指示信息；

其中，上述第一指示信息指示重新获取业务设计参数，并在确定重新获取的业务设计参数符合上述设计规范的情况下，根据上述开发规范以及上述重新获取的业务设计参数，生成业务开发代码。

在一种可能的实现方式中，上述业务规范包括上述第一业务规范，上述规范设计器是通过以下方式生成第一业务规范的：

响应于针对业务规范的输入操作，接收待生成的业务规范；

获取第二业务规范；其中，第二业务规范是规范设计器在接收到所述待生成的业务规范之前已生成的符合逻辑的业务规范；

基于第二业务规范，对待生成的业务规范进行检查，得到第二检查结果；第二检查结果表征待生成的业务规范的逻辑是否与第二业务规范的逻辑相符；

基于第二检查结果以及待生成的业务规范，确定第三业务规范；

对第二业务规范和第三业务规范进行合并操作，得到第一业务规范。

在一种可能的实现方式中，上述规范设计器在基于上述第二检查结果以及待生成的业务规范，确定第三业务规范时，可以具体用于：

在上述第二检查结果表征上述待生成的业务规范的逻辑与上述第二业务规范的逻辑相符的情况下，将上述待生成的业务规范确定为第三业务规范；

在上述第二检查结果表征上述待生成的业务规范的逻辑与上述第二业务规范的逻辑不符的情况下，生成第二指示信息；其中，上述第二指示信息指示重新输入业务规范，并将重新接收的、与上述第二业务规范的逻辑相符的业务规范确定为第三业务规范。

本申请实施例的装置可执行本申请实施例所提供的方法，其实现原理相类似，本申请各实施例的装置中的各模块所执行的动作是与本申请各实施例的方法中的步骤相对应的，对于装置的各模块的详细功能描述具体可以参见前文中所示的对应方法中的描述，此处不再赘述。

基于与本申请实施例提供的数据处理方法及装置相同的原理，本申请实施例中还提供了一种电子设备(如服务器)，该电子设备可以包括存储器、处理器及存储在存储器上的计算机程序，该处理器执行上述计算机程序以实现本申请任一可选实施例中提供的方法。

可选地，图6示出了本申请实施例所适用的一种电子设备的结构示意图，如图6所示，图6所示的电子设备6000包括：处理器6001和存储器6003。其中，处理器6001和存储器6003相连，如通过总线6002相连。可选地，电子设备6000还可以包括收发器6004，收发器6004可以用于该电子设备与其他电子设备之间的数据交互，如数据的发送和/或数据的接收等。需要说明的是，实际应用中收发器6004不限于一个，该电子设备6000的结构并不构成对本申请实施例的限定。

处理器6001可以是CPU(Central Processing Unit，中央处理器)，通用处理器，DSP(Digital Signal Processor，数据信号处理器)，ASIC(Application SpecificIntegrated Circuit，专用集成电路)，FPGA(Field Programmable Gate Array，现场可编程门阵列)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器6001也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等。

总线6002可包括一通路，在上述组件之间传送信息。总线6002可以是PCI(Peripheral Component Interconnect，外设部件互连标准)总线或EISA(ExtendedIndustry Standard Architecture，扩展工业标准结构)总线等。总线6002可以分为地址总线、数据总线、控制总线等。为便于表示，图6中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

存储器6003可以是ROM(Read Only Memory，只读存储器)或可存储静态信息和指令的其他类型的静态存储设备，RAM(Random Access Memory，随机存取存储器)或者可存储信息和指令的其他类型的动态存储设备，也可以是EEPROM(Electrically ErasableProgrammable Read Only Memory，电可擦可编程只读存储器)、CD-ROM(Compact DiscRead Only Memory，只读光盘)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质、其他磁存储设备、或者能够用于携带或存储计算机程序并能够由计算机读取的任何其他介质，在此不做限定。

存储器6003用于存储执行本申请实施例的计算机程序，并由处理器6001来控制执行。处理器6001用于执行存储器6003中存储的计算机程序，以实现前述方法实施例所示的步骤。

本申请实施例提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时可实现前述方法。

本申请实施例还提供了一种计算机程序产品，包括计算机程序，计算机程序被处理器执行时可实现前述方法。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”、“1”、“2”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除图示或文字描述以外的顺序实施。

应该理解的是，虽然本申请实施例的流程图中通过箭头指示各个操作步骤，但是这些步骤的实施顺序并不受限于箭头所指示的顺序。除非本文中有明确的说明，否则在本申请实施例的一些实施场景中，各流程图中的实施步骤可以按照需求以其他的顺序执行。此外，各流程图中的部分或全部步骤基于实际的实施场景，可以包括多个子步骤或者多个阶段。这些子步骤或者阶段中的部分或全部可以在同一时刻被执行，这些子步骤或者阶段中的每个子步骤或者阶段也可以分别在不同的时刻被执行。在执行时刻不同的场景下，这些子步骤或者阶段的执行顺序可以根据需求灵活配置，本申请实施例对此不限制。

以上所述仅是本申请部分实施场景的可选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请的方案技术构思的前提下，采用基于本申请技术思想的其他类似实施手段，同样属于本申请实施例的保护范畴。

Claims (10)

1.一种数据处理方法，其特征在于，所述方法应用于基于微服务开发平台实现的代码生成器中，基于所述微服务平台还实现有用于生成业务规范的规范设计器，所述方法包括：

响应于接收到的业务开发请求，获取所述规范设计器生成的与所述业务开发请求对应的第一业务规范；其中，所述第一业务规范包括设计规范以及开发规范；

根据所述设计规范对所述业务开发请求中的业务设计参数进行检查，得到第一检查结果；所述第一检查结果表征所述业务设计参数的设计逻辑是否符合所述设计规范；

在所述第一检查结果表征所述业务设计参数的设计逻辑符合所述设计规范的情况下，根据所述开发规范以及所述业务设计参数，生成业务开发代码。

2.根据权利要求1所述的方法，其特征在于，所述根据所述开发规范以及所述业务设计参数，生成业务开发代码，包括：

根据所述开发规范中的接口规范和错误码规范，对所述业务设计参数进行编译，得到业务设计源代码；以及根据所述开发规范中的实现类命名规范和包路径命名规范，对所述业务设计参数进行编译，得到业务开发源代码；

根据所述业务设计源代码和所述业务开发源代码，得到所述业务开发代码。

3.根据权利要求2所述的方法，其特征在于，所述根据所述开发规范中的接口规范和错误码规范，对所述业务设计参数进行编译，得到业务设计源代码，包括：

根据所述接口规范，对所述业务设计参数中的接口参数进行编译，得到接口定义源代码；以及根据所述错误码规范，对所述业务设计参数中的流程配置参数进行编译，得到配置文件；

根据所述接口定义源代码和所述配置文件，得到所述业务设计源代码。

4.根据权利要求2所述的方法，其特征在于，所述根据所述开发规范中的实现类命名规范和包路径命名规范，对所述业务设计参数进行编译，得到业务开发源代码，包括：

根据所述实现类命名规范和所述包路径命名规范，对所述业务设计参数中的接口参数进行编译，得到所述业务开发源代码。

5.根据权利要求1所述的方法，其特征在于，所述方法还包括：

在所述第一检查结果表征所述业务设计参数的设计逻辑不符合所述设计规范的情况下，生成第一指示信息；

其中，所述第一指示信息指示重新获取业务设计参数，并在确定重新获取的业务设计参数符合所述设计规范的情况下，根据所述开发规范以及所述重新获取的业务设计参数，生成业务开发代码。

6.根据权利要求1所述的方法，其特征在于，所述业务规范包括所述第一业务规范，所述规范设计器是通过以下方式生成所述第一业务规范的：

响应于针对业务规范的输入操作，接收待生成的业务规范；

获取第二业务规范；其中，所述第二业务规范是所述规范设计器在接收到所述待生成的业务规范之前已生成的符合逻辑的业务规范；

基于所述第二业务规范，对所述待生成的业务规范进行检查，得到第二检查结果；所述第二检查结果表征所述待生成的业务规范的逻辑是否与所述第二业务规范的逻辑相符；

基于所述第二检查结果以及所述待生成的业务规范，确定第三业务规范；

对所述第二业务规范和所述第三业务规范进行合并操作，得到所述第一业务规范。

7.根据权利要求6所述的方法，其特征在于，所述基于所述第二检查结果以及所述待生成的业务规范，确定第三业务规范，包括：

在所述第二检查结果表征所述待生成的业务规范的逻辑与所述第二业务规范的逻辑相符的情况下，将所述待生成的业务规范确定为所述第三业务规范；

在所述第二检查结果表征所述待生成的业务规范的逻辑与所述第二业务规范的逻辑不符的情况下，生成第二指示信息；其中，所述第二指示信息指示重新输入业务规范，并将重新接收的、与所述第二业务规范的逻辑相符的业务规范确定为所述第三业务规范。

8.一种数据处理装置，其特征在于，所述装置为基于微服务开发平台实现的代码生成器，基于所述微服务平台还实现有用于生成业务规范的规范设计器，包括：

业务规范获取模块，用于响应于接收到的业务开发请求，获取所述规范设计器生成的与所述业务开发请求对应的第一业务规范；其中，所述第一业务规范包括设计规范以及开发规范；

业务设计参数检查模块，用于根据所述设计规范对所述业务开发请求中的业务设计参数进行检查，得到第一检查结果；所述第一检查结果表征所述业务设计参数的设计逻辑是否符合所述设计规范；

代码生成模块，用于在所述第一检查结果表征所述业务设计参数的设计逻辑符合所述设计规范的情况下，根据所述开发规范以及所述业务设计参数，生成业务开发代码。

9.一种电子设备，包括存储器、处理器及存储在存储器上的计算机程序，其特征在于，所述处理器执行所述计算机程序以实现如权利要求1至7中任一项所述的方法。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至7中任一项所述的方法。

Images