A method and system for merging industrial software microservices

Abstract

The application discloses a kind of industrial software microservice merging method and system, comprising: each set industrial microservice business code is packed to form a single Jar package;Multiple single Jar packages formed are stored to single warehouse;In response to the service request of outside, the type and quantity of microservice required are determined;The single Jar package corresponding to the microservice is called from single warehouse by base application to combine, and the configuration of the microservice is merged into a configuration file, to realize the start of combined microservice.The industrial microservice business code is compiled as single jar package in the application, and is stored in single warehouse, and base application can call any single jar package in single warehouse according to need to combine, and configuration is flexible, and specific business code is not involved, and the consistency of scheme is relatively strong;The deployment cost of a large number of microservices and the development and maintenance cost of software are reduced.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of microservice merging, and in particular to a method and system for merging microservices of industrial software. BACKGROUND

[0002] The statements in this section merely provide background information related to the present application and do not necessarily constitute the prior art.

[0003] At present, enterprise-level application backends are mostly developed and deployed in the form of microservices, which brings unprecedented advantages in scalability, development complexity, and high availability, and thus is widely used in large projects or platforms.

[0004] In industrial software, there are different business lines, such as BOM, MOM, graphic documents, production process management, etc., and each business line is supported by one or several software products, and each software product is further divided into microservices according to functions, businesses, and technologies. In this way, there are several hundred or even thousands of microservices in a manufacturing enterprise to provide services, and each microservice needs to occupy a service deployment resource, which brings a great deployment and operation cost to the enterprise.

[0005] For software developers who develop industrial software, too many microservices also bring difficulties in development and service management. In the face of customers of different sizes, developers cannot provide the same mode of service to all customers through a set of codes, and need to write a large amount of repeated codes, which also increases the development and maintenance costs of developers. SUMMARY

[0006] To solve the above problems, the present application provides a method and system for merging microservices of industrial software, which realizes the running of a set of industrial software business codes in different scenarios in the form of different numbers of microservice combinations (the number of microservices is configurable) through a configurable mode, thereby greatly reducing the deployment cost of customers and the development and maintenance cost of software developers.

[0007] In some embodiments, the following technical solutions are adopted:

[0008] A method for merging microservices of industrial software, comprising:

[0009] packaging each set industrial microservice business code into a single Jar package;

[0010] storing the formed plurality of single Jar packages in a single warehouse;

[0011] determining the type and number of microservices required in response to a service request from the outside world;

[0012] The base application calls the monolithic Jar package corresponding to the microservice from the monolithic warehouse to combine the microservice, and merges the configuration of the microservice into a configuration file to realize the startup of the combined microservice.

[0013] As a further local plan, the industrial microservice business code is compiled into a monolithic jar package meeting the set requirements through a Gradle-based compilation plug-in.

[0014] As a further local plan, some configuration files of the microservice are removed from the monolithic Jar package, including but not limited to: startup class and configuration file.

[0015] As a further local plan, after the industrial microservice business code is compiled, the service name in the feign interface definition is changed to the base application, and the inter-service call is changed to the self-call of the base service.

[0016] As a further local plan, all monolithic jar packages are stored in a separate Group of the monolithic warehouse.

[0017] As a further local plan, the Gradle compilation plug-in can be turned on or off as needed, and when the plug-in is turned on, the industrial microservice business code is compiled into a monolithic jar package meeting the set requirements; when the plug-in is turned off, the industrial microservice business code is used as an independent microservice.

[0018] As a further local plan, the browser sends a service request to Nginx through the Internet, Nginx forwards the request to one or more gateway services in the background, the gateway service forwards the service request to the corresponding base application according to the request forwarding rule configured in Nacos, and the base application converts the original Feign call before the business service into a Feign call to itself when processing the request.

[0019] As a further local plan, by modifying the forwarding rule of the gateway service, the front end shields the changes of the back end interface, and the reuse of the front end function is realized.

[0020] In some other embodiments, the following technical solutions are adopted:

[0021] An industrial software microservice merging system comprises:

[0022] A code packaging module is configured to package each set of industrial microservice business code into a monolithic Jar package.

[0023] A monolithic Jar package storage module is configured to store the formed plurality of monolithic Jar packages in a monolithic warehouse.

[0024] The monomer jar package combination calling module is used for determining the required microservice type and quantity in response to a service request from the outside world, combining the monomer jar package corresponding to the microservice by calling the monomer jar package from the monomer warehouse through the base application, and merging the configurations of the microservice into a configuration file to realize the startup of the combined microservice.

[0025] In some other embodiments, the following technical solutions are adopted:

[0026] A terminal device comprises a processor and a memory, the processor is used to implement instructions, the memory is used to store a plurality of instructions, the instructions are suitable for being loaded and executed by the processor to implement the method for merging the industrial software microservice.

[0027] Compared with the prior art, the beneficial effects of the present application are:

[0028] (1) The industrial microservice business code is compiled into a monomer jar package and stored in a monomer warehouse, and the base application can call and combine any monomer jar package in the monomer warehouse as needed, so that the configuration is flexible, no specific business code is involved, the consistency of the scheme is relatively strong, and the deployment cost of a large number of microservices and the development and maintenance cost of software are reduced.

[0029] (2) The business developer only needs to introduce the monomer Jar packaging plug-in in the project configuration information, the business code is non-invasive, and the debugging cost of the developer is reduced.

[0030] (3) The monomer jar package and the microservice image used by the present application are compiled from the same set of codes, the developer only needs to maintain one set of codes to enable the business to run in different modes, the development complexity is not increased due to the increase of the running mode, and there is no problem of conflict between different versions of business codes.

[0031] Other features and additional aspects of the advantages of the present application will be partially given in the following description, partially will become obvious from the following description, or will be understood by the practice of the present application. BRIEF DESCRIPTION OF DRAWINGS

[0032] Figure 1 The figure is a process schematic diagram of the method for merging the industrial software microservice in the embodiment of the present application.

[0033] Figure 2 The figure is a working process schematic diagram of the running base application in the embodiment of the present application. DETAILED DESCRIPTION

[0034] It should be noted that the following detailed description is illustrative only, and is intended to provide further description in connection with the application. Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs.

[0035] It is to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments in accordance with the present application. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and / or "comprising," when used in this specification, specify the presence of stated features, steps, operations, elements, components, and / or groups thereof, but do not preclude the presence or addition of one or more other features, steps, operations, elements, components, and / or groups thereof.

[0036] Terminology:

[0037] Gradle: Gradle is a build tool based on JVM, which is a general and flexible build tool. It supports users to set their own build parameters, and even allows to add some custom build tasks.

[0038] Industrial microservice business code: Java source code that implements a certain business function in industrial software.

[0039] Configuration merging tool: a tool that can merge configuration items of multiple microservices into a configuration file.

[0040] Monolithic Jar: a Jar package that can be directly referenced by other applications, which is packaged by industrial microservice business code, and some feature files of microservices are removed (such as startup class, configuration file, etc.), and some key binary codes are modified; the directory structure in the Jar package is consistent with the directory structure for direct calling (which is different from the microservice image package structure).

[0041] Monolithic compilation plug-in (referred to as plug-in): a Gradle-based compilation plug-in, which can compile source code into a monolithic Jar package that meets the specified requirements.

[0042] Monolithic repository: a repository that stores monolithic Jar packages, which is a logically completely independent repository that is different from the ordinary microservice image repository.

[0043] Base application: a basic application for integrating all business monolithic Jar packages, which is configured with business services and versions contained in the current application; it can call any monolithic Jar package for combination, and finally, the base application will be packaged into a separate image for running.

[0044] Embodiment one

[0045] In one or more embodiments, a method for industrial software microservice merging is disclosed, in combination with Figure 1 , and specifically includes the following processes:

[0046] (1) Packaging each set of industrial microservice business code into a single Jar package;

[0047] In this embodiment, the Gradle-based compilation plug-in compiles the industrial microservice business code into single jar packages that meet the set requirements, and these single jar packages can be directly called by the base application.

[0048] Each single Jar package is called as a normal jar package in the base application, and will not be started as an independent microservice (microservice jar package), so it only needs to be packaged as a simple jar, so that the Jars commonly used between different microservices are shared, thereby greatly reducing the size of the base application.

[0049] When packaging, the Gradle-based compilation plug-in deletes files that are not needed as simple jar packages, including the startup class of the microservice and the configuration file related to the microservice.

[0050] After the industrial microservice business code is compiled, the service name in the feign interface definition is changed to the base application, and the inter-service call is changed to self-call of the base service.

[0051] At the same time, the plug-in supports a switch, when the plug-in is turned on, the industrial microservice business code is compiled into single jar packages that meet the set requirements; when the plug-in is turned off, the industrial microservice business code can run as an independent microservice. The single Jar package and the microservice image used in this embodiment are compiled from the same set of code, and the business personnel only need to control the packaging mode through the switch to realize multiple mode running of a set of code, avoiding repeated testing work; without increasing the complexity of development due to the increase of the running mode, there is also no problem of conflict between different versions of business code.

[0052] (2) Storing the formed multiple single Jar packages in a single warehouse;

[0053] In this embodiment, a single warehouse for storing single jar packages is set, so that the single package is finally published to a separate single warehouse. By setting a single warehouse for storing single jar packages, the running resources of the microservice and the single jar package are completely isolated.

[0054] (3) In response to a service request from the outside world, determining the type and quantity of microservices needed;

[0055] (4) The base application calls the monolithic Jar package corresponding to the microservice from the monolithic warehouse for combination, and merges the configurations of the microservice into a configuration file to realize the startup of the combined microservice.

[0056] Specifically, in combination with Figure 2 The working process of the running state base application is as follows:

[0057] The browser sends a request to Nginx through the Internet, Nginx forwards the request to one or more gateway services in the background, the gateway service forwards the request to the corresponding base application according to the request forwarding rule configured in Nacos (a service registration and discovery and configuration tool), and the base application converts the Feign call before the original business service into a Feign call to itself when processing the request.

[0058] In this embodiment, the configuration items of multiple microservices can be merged into a configuration file by a configuration merging tool. The base application will introduce all the jar packages required for the operation of related services, and then start up through the startup class of the base application to expose the union of all service interfaces to the outside.

[0059] Now large websites all adopt the front-end and back-end separation development method, if the back-end interface does not change, the front-end system does not need to change; based on this, the front-end browser and the back-end base application are isolated through the gateway in the embodiment, by modifying the forwarding rule of the gateway service (gateway service), the change of the back-end is shielded, which can achieve the purpose of sharing a set of front-end for two deployment modes of the back-end, and realizes the reuse of the front-end function.

[0060] The output device is still in the form of microservices, and still solves the high availability and high performance problems of services through distributed deployment.

[0061] The microservices and versions, middleware and versions, base service names and other information covered by the base application in the embodiment can be configured as needed, without changing the existing development process, but only by performing simple configuration in the project, the business code is not intruded.

[0062] Embodiment two

[0063] In one or more embodiments, a system for industrial software microservice merging is disclosed, comprising:

[0064] A code packaging module for packaging each set of industrial microservice business code into a monolithic Jar package;

[0065] Wherein, the industrial microservice business code is compiled into a monolithic jar package meeting the set requirements through a Gradle-based compilation plug-in.

[0066] a monomer Jar package storage module, configured to store the formed plurality of monomer Jar packages in a monomer warehouse;

[0067] a monomer Jar package combination calling module, configured to determine a type and a number of microservices required in response to a service request from outside, call monomer Jar packages corresponding to the microservices from the monomer warehouse through a base application, and combine configurations of the microservices into one configuration file to start the combined microservices.

[0068] It should be noted that the specific implementation of the above process has been described in detail in Embodiment One, and here is the same as in Embodiment One, and will not be described in detail.

[0069] Embodiment Three

[0070] In one or more embodiments, a terminal device is disclosed, comprising a server, the server comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, the processor implementing the method of industrial software microservice combination in Embodiment One when executing the program. For brevity, this will not be repeated here.

[0071] It should be understood that in the embodiments, the processor can be a central processing unit CPU, and the processor can also be other general-purpose processors, digital signal processors DSP, application-specific integrated circuits ASIC, ready-to-program gate arrays FPGA, or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor.

[0072] The memory can include read-only memory and random access memory, and provide instructions and data to the processor, and a portion of the memory can also include non-volatile random access memory. For example, the memory can also store device type information.

[0073] In the implementation process, each step of the above method can be completed by integrated logic circuits of hardware in the processor or instructions in the form of software.

[0074] The above describes the specific embodiments of the application in conjunction with the accompanying drawings, but is not a limitation on the scope of protection of the application. Those skilled in the art should understand that various modifications or variations made by those skilled in the art on the basis of the technical solutions of the application without inventive labor are still within the scope of protection of the application.

Claims

1. A method of industrial software microservice consolidation, characterized in that, The method comprises the following steps: packaging each set of industrial microservice business code into a single Jar package; compiling the industrial microservice business code into a single jar package meeting the set requirements through a Gradle-based compilation plug-in; the Gradle compilation plug-in can be turned on or off as needed, and when the plug-in is turned on, the industrial microservice business code is compiled into a single jar package meeting the set requirements; when the plug-in is turned off, the industrial microservice business code is used as an independent microservice; after the industrial microservice business code is compiled, the service name in the feign interface definition is changed to a base application, and the inter-service call is changed to self-call of the base service; storing the formed multiple single Jar packages in a single warehouse; in response to a service request from the outside world, determining the type and quantity of microservices required; combining the single Jar packages corresponding to the microservices through the base application from the single warehouse, and merging the configurations of the microservices into a configuration file to realize the startup of the combined microservices.

2. The method of claim 1, wherein, Some set files of the microservices are removed from the single Jar package, including but not limited to: startup class and configuration file.

3. The method of claim 1, wherein, All single jar packages are stored in an independent Group of the single warehouse.

4. The method of claim 1, wherein, The browser sends a service request to Nginx through the Internet, Nginx forwards the request to one or more gateway services in the background, the gateway service forwards the service request to the corresponding base application according to the request forwarding rule configured in Nacos, and the base application converts the Feign call before the original business service into a Feign call to itself when processing the request.

5. The method of claim 1, wherein, By modifying the forwarding rule of the gateway service, the front end shields the changes of the back end interface, and the front end function is reused.

6. A system for industrial software microservice consolidation, characterized in that, The method comprises the following steps: a code packaging module is configured to package each set of industrial microservice business code into a single Jar package; a Gradle-based compilation plug-in is used to compile the industrial microservice business code into a single jar package meeting the set requirements; the Gradle compilation plug-in can be turned on or off as needed, and when the plug-in is turned on, the industrial microservice business code is compiled into a single jar package meeting the set requirements; when the plug-in is turned off, the industrial microservice business code is used as an independent microservice; after the industrial microservice business code is compiled, the service name in the feign interface definition is changed to a base application, and the inter-service call is changed to self-call of the base service; a single Jar package storage module is configured to store the formed multiple single Jar packages in a single warehouse; a single Jar package combination calling module is configured to, in response to a service request from the outside world, determine the type and quantity of microservices required; the single Jar packages corresponding to the microservices are combined through the base application from the single warehouse, and the configurations of the microservices are merged into a configuration file to realize the startup of the combined microservices.

7. A terminal device comprising a processor and a memory, the processor being configured to implement instructions; the memory being configured to store a plurality of instructions, wherein the terminal device is configured to perform the method according to any one of claims 1-6. The instructions are adapted to be loaded and executed by the processor to implement the method for merging industrial software microservices according to any one of claims 1-5.

Images