一种微服务代码生成方法及系统与流程

1.本发明涉及电数字数据处理领域，特别是涉及一种微服务代码生成方法及系统。


背景技术：

2.微服务是一种设计策略，把一个大型的单个应用程序和服务拆分为数十个的支持微服务。由于一个微服务只解决一个业务问题，将一个大型的单体应用程序拆分为数个甚至数十个微服务，导致服务数量的井喷，且服务与服务之间的各种关系错综复杂、相互依赖且难以调试，不利于微服务的进一步提升。


技术实现要素：

3.本发明的一个目的是要提供一种快捷地微服务代码生成方法。
4.本发明一个进一步的目的是要简化微服务之间的关系以实现快速微服务代码生成方法。
5.本发明另一个进一步的目的是要提供一种快捷地微服务代码生成系统。
6.特别地，本发明提供了一种微服务代码生成方法，包括以下步骤：
7.接收用户输入的模板信息以及架构图；
8.解析架构图，根据解析架构图的结果获得架构信息；
9.根据架构信息以及模板信息，通过调用相应的标识对应的代码块生成代码；其中代码块存放于数据库中，且代码块与相应的标识进行映射。
10.进一步地，在接收用户输入的模板信息以及架构图步骤中，用户提供的架构图以框图形式表示架构信息的信息流方向。
11.进一步地，所述架构信息包括：服务类型、服务数量、中间件类型、服务调用关系和自定义组件，其中，服务调用关系包括每个服务对应的网关、数据库和主题。
12.进一步地，在根据架构信息以及模板信息，通过调用相应的标识对应的代码块生成代码步骤中，包括如下步骤：
13.根据用户提供的架构图获取目标信息；
14.根据目标信息检索并调用数据库中的代码块；
15.组合数据库的代码块形成基础代码；
16.对基础代码进行测试，将通过测试后打包代码。
17.进一步地，在根据目标信息检索并调用数据库中的代码块步骤中，包括如下步骤：
18.根据服务调用关系，检索并调用服务调用层代码块；
19.根据中间件层信息，检索并调用中间层代码块；
20.根据服务之间的逻辑关系，检索并调用逻辑代码块；
21.根据服务之间消息收发关系，检索并调用消费代码块。
22.进一步地，在组合数据库的代码块步骤时，将多个类型的服务通过网关进行广播以便于实现多个服务之间调用关系，在广播时调用连接相应数据库的逻辑代码块以及消费
代码块。
23.进一步地，在根据架构信息以及模板信息，通过调用相应的标识对应的代码块生成代码步骤前，首先生成微服务骨架。。
24.特别地，本发明还公开了一种微服务代码生成系统，包括控制装置，所述控制装置包括存储器和处理器，所述存储器内存储有控制程序，所述控制程序被所述处理器执行时用于实现所述的微服务代码生成方法。
25.本发明的代码生成方法是基于微服务生态的一个构建平台，通过接收用户输入的模板信息以及架构图，并对架构图进行解析，从而得到搭建微服务所需要的信息，进而可以快速搭建整个微服务，解决了在项目初期，需要手动创建多个服务，解决了服务依赖，用户不再需要花费大量时间解决各种中间件组件接入以及处理服务与服务之间的调用关系。
26.进一步地，本发明的代码生成方法中，创造性的采用图形建模方式，通过识别架构图进而最终生成一套微服务体系核心代码，使得用户只需关注业务层处理逻辑，建模方式和日常工作中系统架构图比较类似，学习成本较低。
27.进一步地，本发明的代码生成方法并不仅仅生成一个服务的代码，而是生成整套微服务框架代码，同时用户可以通过对模板进行diy的方法维护自身的代码风格，符合用户使用习惯。
28.根据下文结合附图对本发明具体实施例的详细描述，本领域技术人员将会更加明了本发明的上述以及其他目的、优点和特征。
附图说明
29.后文将参照附图以示例性而非限制性的方式详细描述本发明的一些具体实施例。附图中相同的附图标记标示了相同或类似的部件或部分。本领域技术人员应该理解，这些附图未必是按比例绘制的。附图中：
30.图1是本发明一个或多个实施例的元数据信息映射关系图；
31.图2是本发明一个或多个实施例的框图形式的架构图；
32.图3是本发明一个或多个实施例的微服务代码生成方法步骤图。
具体实施方式
33.图1是根据本发明一个实施例的微服务代码生成方法框图。本实施例所提供的微服务代码生成方法并非针对某一个特殊的工程项目，而是面向普通的微服务开发项目，使用本实施例所提供的方法，能够自动生成一套初始代码，从而减少代码开发的时间。微服务代码生成方法一般性地可包括如下步骤：
34.s1、在数据库中存储多种代码块。
35.s2、接收用户根据数据源类型选择的模板信息。
36.s3、将数据库与相应的标识进行映射以便于调用。
37.s4、接收用户提供的架构图并解析架构图，根据解析架构图的结果获得架构信息。
38.s5、根据架构信息以及用户提供的模板信息，通过相应的标识调用代码块以生成代码。
39.具体地，在步骤s1中，需要由运维模块统一配置项目相关数据源。其中数据源指的
是具有共性的代码，该种代码一般指的是中间件产品，可以是数据库(mysql,db2,oracle)，可以是分布式缓存(redis)，可以是消息中间件(kafka,rocketmq等中间件产品)，或分布式微服务框架。
40.更加具体地，以mysql数据库的使用场景为例，在传统的配置方法中，包括如下步骤：
41.s1.1、在spring boot项目添加依赖和mysql驱动。
42.s1.2、配置application.properties文件，以对一些默认配置的配置值进行修改。
43.s1.3、新建实体类，与数据库字段对应，该实体类可以优化代码，减少不必要的代码量。
44.s1.4、新建mapper(xml)映射文件。
45.s1.5、新建dao(数据库访问对象)接口，继而新建dao层。
46.s1.6、新建controller层：
47.而在本发明的一个或多个实施例中，通过制定一个简洁的模板，把可变的部分抽离出来通过mustache模板引擎的方式，通过结合变量，最终加载出来需要的代码。
48.图1是一个元数据信息映射关系图。根据本发明的一个实施例，步骤s3中，将数据库与相应的标识进行映射以便于调用，具体是将元数据信息与相应的标识，元数据信息指的是服务所使用的中间件产品的属性，这部分信息维护在系统后台，通过对每套资源打标，定义具体的资源信息，如mysql,资源信息有用户名，密码，连接地址，驱动等，并同时标识某个具体含义的tag,当某个服务有用到mysql,只需要在界面上引入mysql模型，并标识tag,系统能够自动识别，并生成操作mysql相关的代码。图1中servicea，需要用到db-b数据库，那么当执行代码生成时，会自动生成操作该库中相关表的逻辑。serviceb，生成访问db-c数据库代码逻辑。servicec，生成访问db-a数据库代码逻辑。本实施例中，mysql是数据库领域常用的一种关系型数据库管理系统，关系数据库将数据保存在不同的数据库中，而不是将所有数据放在一个大数据库内，这样就增加了速度并提高了灵活性。本实施例中，servicea、serviceb和servicec是不同的服务。本实施例中bd-a数据库、bd-b数据库、bd-c数据库是不同数据库。
49.根据本发明的一个实施例，步骤s4中，接收用户提供的架构图并解析架构图，根据解析架构图的结果获得架构信息。其中，用户提供的架构图中，包括的信息有：服务类型、服务数量、中间件类型、消息收发、服务依赖关系、服务调用关系和自定义组件，其中，服务调用关系包括每个服务对应的网关、数据库和主题。其中，用户提供的架构图为框图形式，更加具体的，该种框图形式的架构图标记各个服务之间关系以及相关技术的类型，例如，使用矩形图形表示服务，使用横圆柱体图形表示逻辑，使用箭头在服务上表示a和b服务的关系，或者使用箭头用在消息上表示消息发送和消费。本实施例中，中间件是指是介于数据库和操作平台之间的一类软件。
50.图2是一个典型的框图形式的架构图，根据本发明的一个实施例，其中，servicea服务生成的代码包含：提供dubbo接口服务给网关层，提供dubbo接口给serviceb调用，生成连接db-a数据库层操作，同时消费topicc消息。serviceb服务生成的代码包含：调用servicea服务逻辑，发送消息给topicb,访问db-b数据库层操作。serviceb服务生成的代码包含：提供dubbo接口服务给网关层，消费topicb消息。发送消息给topicc,生成连接db-c数
据库层操作。通过分析上述步骤，系统可以自动为用户生成大部分代码，从使用角度上来说，用户只需要关注实现业务代码，同时对不需要的功能，接口做一些调整即可。
51.根据本发明的一个实施例，步骤s3中，将数据库与相应的标识进行映射以便于调用。而数据库中存储的是各种代码块，因此步骤s3实际上是通过相应的标识调用代码块，其具体包括如下步骤：
52.s3.1、根据用户提供的架构图信息获取服务数量、中间件类型、服务调用关系和自定义组件。该步骤中解析架构图使用的方法一般是自动解析度，也可以是人工解析。现有技术中，自动解析的架构图可以使用基于uml的可视化建模工具，例如rational rose，在此不再赘述。
53.s3.2、检索并调用数据库中的代码块。该步骤中，以步骤3.1中的解析结果为关键词自动编辑检索式进行检索。
54.s3.3、组合数据库的代码块形成基础代码。
55.s3.4、对基础代码进行测试，通过测试后打包代码。
56.根据本发明的一个实施例，在上述步骤s3,2中，在数据库中检索并调用相关的代码块时，包括如下步骤：
57.s3.2.1、根据服务调用关系，检索并调用服务调用层代码块。
58.s3.2.2、根据中间件层信息，检索并调用中间层代码块。
59.s3.2.3、根据服务之间的逻辑关系，检索并调用逻辑代码块。
60.s3.2.4、根据服务之间消息收发关系，检索并调用消费代码块。
61.更加具体地，在一个具体实施场景中，使用java语言进行项目开发，并使用阿里巴巴公司规约对java语言进行分层，本发明中上述实施例对常见的中间件产品进行抽象，把共用的部分抽离出来以便于生成代码。在步骤s3.3中，组合数据库的代码块形成基础代码时，包括以下步骤：
62.s3.3.1、生成微服务中涉及到的多个服务代码、pom文件、包等，以形成整个微服务代码骨架。需要说明的是，此阶段不涉及到代码的具体生成。
63.s3.3.1、生成dao层和manager层代码。
64.s3.3.1、中间件层相关组件代码生成kafka、redis、oss等。
65.s3.3.1、服务之间dubbo调用，生成逻辑代码。
66.s3.3.1、服务之间消息发送，生成消费代码。
67.s3.3.1、生成单元测试代码。
68.s3.3.1、打包。
69.s3.3.1、输出下载。
70.需要说明的是，上述步骤中，pom文件、包、dao层、mmanager层、kafka、redis、oss、dubbo均是java开发领域常见的一些名词。pom文件是maven工程的工作基础，以pom.xml的形式存在于项目中，在本实施例中配置构建工程的详细信息。它为大多数项目都预先配置了一些默认值，如构建目录build，源码目录src/main/java，测试源码目录src/test/java等等。kafka是一种开源的消息中间件产品。redis是一种开源的分布式缓存产品。oss是阿里云oss上传组件。dubbo是分布式服务框架。manager层负责将dao层中的数据库操作组合复用，主要是一些缓存方案，中间件的处理，以及对第三方平台封装的层。service层是业务
处理层，更加关注业务逻辑，将manager组合过的操作和业务逻辑组合在一起，再封装成业务操作。biz层包含service层，service层注重基础业务的处理，biz层是复杂应用层的业务层。
71.至此，本领域技术人员应认识到，虽然本文已详尽示出和描述了本发明的多个示例性实施例，但是，在不脱离本发明精神和范围的情况下，仍可根据本发明公开的内容直接确定或推导出符合本发明原理的许多其他变型或修改。因此，本发明的范围应被理解和认定为覆盖了所有这些其他变型或修改。