Patent Description:
Microservice is a software architecture that developes a single application using a set of small services each running in its own process and communicates by a lightweight mechanism. These services are constructed based on service capacity, and can be independently deployed with an automatic deployment mechanism. These services are implemented with different programming languages, stored by using different data storage technologies, and kept with the minimum centralized management.

A single application generally integrates all services together to realize coupling among the services, while microservice applications refer to an application consisting of a series of small services. However, with expanded services, the single application will confront problems such as low running speed, large volume, tight coupling, difficulty in upgrading and downgrading, complex operation and maintenance, and the like, while an application consisting of a large number of microservices will confront problems such as high deployment cost and high operation and maintenance cost.

<CIT> provides a system for automated lifecycle management of a computer implemented service, according to requirements, having a service model representing the service at a given development state in the lifecycle, and a transition model representing allowed operations to change the service model to a different one of the development states of the service, according to the requirements, and the transition model having a transparent structure suitable for automated inspection of the allowed operations, and suitable for automated adaptation of the allowed operations.

<CIT> provides a method for defining a version identifier of a service component, comprising: capturing user requirements for the set of service components, the user requirements corresponding to a set of predefined specification levels; and selecting the set of service components from the service components, the selection being performed based on the user requirements and a compound versioning scheme corresponding to the service components, the compound versioning scheme being based on the set of predefined specification levels and a predefined hierarchy.

<CIT> relates to a dynamic microservice editing method, device and server for multi-language cloud compilation.

The present disclosure is defined in the appended claims.

To make the objects, technical solutions, and advantages of the embodiments of the disclosure clearer, the technical solutions in the embodiments of this disclosure will now be described clearly and completely with reference to the accompanying drawings of the embodiments of the disclosure. Obviously, the described embodiments are only a part, not all, of the embodiments of the disclosure. All other embodiments obtained by the ordinarily skilled in the art based on the embodiments of the present invention without paying any creative effort shall be included in the protection scope of the present invention insofar encompassed within the scope thereof as defined by the appended claims.

For the convenience of understanding of the embodiments of the present disclosure, the following description will be further explained with reference to the accompanying drawings, which are not intended to limit the embodiments of the present disclosure.

<FIG> is a schematic flowchart of a method for generating a microservice application according to an embodiment of the present disclosure. As shown in <FIG>, the method includes the following steps S101 to S106.

At S101, determining a service set of microservices according to a first user requirement.

The method for generating a microservice application customizes the microservices according to a requirement of a user, and determine a service set of the microservices according to a first user requirement. The first user requirement includes at least one of: a project requirement, an application scenario requirement, or a service (business) requirement.

In an optional embodiment, the project requirement may be, but is not limited to: requirement of devices to be controlled by the user through a microservice , such as a router microservice, a switch microservice, a core network microservice or a PC simulation microservice, and the like; the application scenario requirement may be, but is not limited to: application scenarios of the device controlled by the user through the microservice, wherein in this implementation, the application scenario may be customized according to the user requirement in addition to being selected by the user based on his/her requirement; and the service requirement may be, but is not limited to: certain service functions of the device controlled by the user through the microservice application.

It should be noted that: in this embodiment, microservices may be customized according to one or more of the first user requirements. Referring to <FIG>, it is possible to customize a microservice according to a project requirement, such as to customize a router microservice (a), a switch microservice (b), a core network microservice (c) or a PC simulation microservice (d). When a service set of the microservices is determined according to the project requirement, the service set is a largest set of functions, equivalent to generating a single application version. That is, the microservice contains all service functions of a router, all service functions of a switch, all service functions of a core network, and all service functions of PC simulation. In this version, a user may select different forms of microservices according to the controlled device in different application scenarios.

Referring to <FIG>, the service set of the microservices may be determined according to a service requirement, e.g., to customize a microservice such as VPN, a data center service, or the like. When the service set of the microservices is determined according to the service requirement, the service set is a smallest set of functions, equivalent to generating a microservice version with a minimum granularity. The microservice of such version only includes VPN and data center services. By customizing the microservices according to the service requirement, it is possible to remove service functions unwanted by the user while remaining the desired service functions, thereby reducing complexity of the microservices, and simplifying the operation and maintenance cost.

In an optional embodiment, the service set of the microservices may be determined according to both the project requirement and the service requirement, which can be understood as: adding services of other service functions except the current project while customizing the version of microservices of a single application, thereby enriching the management function of the microservices.

The project requirement, the application scenario requirement, or the service requirement may be selected for customizing the microservices according to the actual requirement of the user; and in addition to the forms of customized microservices shown in <FIG> or <FIG>, other forms may also be used for customizing the microservices, which are not limited in this embodiment.

At S102, determining a deployment mode of devices controlled by the microservice application.

A deployment mode of the devices controlled by the microservice application is determined according to the first user requirement, which may include determining a deployment mode of the devices controlled by the microservice application according to a project requirement in the first user requirement, for example, selecting a corresponding deployment mode according to requirements of a project on the memory and/or security, wherein the deployment mode includes: physical location deployment and process architecture deployment; wherein the physical location deployment includes at least one of: a centralized mode, a distributed mode, or a hybrid mode; and the process architecture deployment includes: a compact mode and/or a safe mode.

For example, devices in a cloud environment may be deployed in a centralized mode, Rack-type physical devices may be deployed in a distributed mode, and devices in a more complex environment may be deployed in a hybrid mode. For some miniaturized devices with a small memory, a compact mode may be adopted for deployment to reduce the memory consumption, while for some large-scale devices, a safe mode may be adopted for deployment to enable different service processes to restart independently.

At S103, determining parameter information of the microservice application according to a second user requirement.

Parameter information of the microservice application is a determined according to a second user requirement, wherein the second user requirement may include: a running requirement of a user for running the microservice application, and the parameter information includes at least one of: a running environment, a CPU type, or an operating system.

By determining parameter information of the microservice application according to the second user requirement, it is ensured that when the user uses the microservice application in person, the running environment, the CPU type or the operating system of the microservice application is matched with a carrier supporting running of the microservice application, thereby avoiding the problem of compatibility. That is, in this embodiment, microservices can be customized in accordance with a version requirement of the user, or, customized microservices with the same version may provide capabilities in various running environments for selection by the user.

For example, referring to <FIG>, according to the second user requirement, versions based on different operating systems such as LINUX, CGSL, or the like, may be customized; versions based on <NUM>-bit, <NUM>-bit CPUs may be customized; versions with GCC <NUM>. <NUM>, GCC <NUM>. <NUM> may be customized; and versions of debug, release, or the like, may also be customized.

At S104, generating the microservice application according to the service set, the deployment mode and the running parameters (the parameter information).

In this embodiment, a display interface of the microservices may be embodied in the form of a list, which may include various service interfaces; and during development of the microservice application, services, functions, components, elements, relations, and the like of the microservice application need to be defined.

In an optional embodiment, functions of individual services in the microservice application, components contained in the functions, elements used in the components, instances corresponding to the elements and relations among the services are defined in the list of the various service interfaces.

In an optional embodiment, when the above definition is completed, the microservice application is generated based on the above definition and according to the service set, the deployment mode and the parameter information.

At S105, testing the microservice application with a testing tool, and issuing the microservice application after the testing.

At S <NUM>, deploying the devices controlled by the microservice application.

In this embodiment, after the microservice application is generated, a DEVOPS tool may be used for testing and issuing the microservice application, and after the test and the issuance are completed, the devices controlled by the microservice application may be deployed according to the microservice application.

In the solution for generating a microservice application provided in the embodiments of this disclosure, by determining a service set of microservices according to a first user requirement application; determining a deployment mode of devices controlled by the microservice application; determining parameter information of the microservice application according to a second user requirement; and generating the microservice application according to the service set, the deployment mode and the parameter information, various service functions of the microservice application can be determined according to the user requirements so that the microservices can be customized in accordance with actual requirements of the user, and the deployment mode of the devices is determined according to the characteristics of the microservices, thereby reducing the complexity of application deployment, and simplifying later operation and maintenance processes.

<FIG> is a schematic structural diagram of an apparatus for generating a microservice application according to the present invention. As shown in <FIG>, the apparatus includes: a determination module <NUM> configured to determine a service set of microservices according to a first user requirement, the determination module <NUM> being further configured to determine a deployment mode of devices controlled by the microservice application, and the determination module <NUM> being further configured to determine parameter information of the microservice application according to a second user requirement; and a generation module <NUM> configured to generate the microservice application according to the service set, the deployment mode and the running parameters.

In an optional embodiment, the first user requirement includes at least one of: a project requirement, an application scenario requirement, or a service requirement; and the second user requirement includes: a running requirement of a user for running the microservice application.

The deployment mode includes: physical location deployment and process architecture deployment; wherein the physical location deployment includes at least one of: a centralized mode, a distributed mode, or a hybrid mode; and the process architecture deployment includes: a compact mode and/or a safe mode.

In an optional embodiment, the parameter information includes at least one of: a running environment, a CPU type, or an operating system.

In an optional embodiment, the microservices includes various service interfaces generated in the form of a list.

In an optional embodiment, the apparatus further includes a definition module <NUM> which is configured to define functions of individual services in the microservices, components contained in the functions, elements used in the components, instances corresponding to the elements and relations among the services in the list of the various service interfaces.

In an optional embodiment, the apparactus further includes a test module <NUM> which is configured to test the microservice with a testing tool, and issue the microservice after the testing; and a deployment module <NUM> configured to deploy the devices controlled by the microservice.

The apparauts for generating a microservice provided in this embodiment may be the apparatus for generating a microservice shown in <FIG>, and may perform all steps of the method for generating a microservice shown in <FIG>, so as to achieve the technical effect of the method for generating a microservice shown in <FIG>. Reference may be made to related description of <FIG>, which, for brevity, is not repeated here.

<FIG> is a schematic diagram showing a hardware structure of an device for generating a microservice according to an embodiment of the present disclosure. As shown in <FIG>, the device includes a processor <NUM>, a memory <NUM>, and a transceiver <NUM>.

The processor <NUM> may be a Central Processing Unit (CPU), or a combination of a CPU and a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The PLD may be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

The memory <NUM> is configured to store various applications, operating systems and data. The memory <NUM> may transmit the stored data to the processor <NUM>. The memory <NUM> may include a volatile memory, a nonvolatile random access memory (NVRAM), a phase change RAM (PRAM), a magetoresistive RAM (MRAM), and the like, such as at least one magnetic disk memory device, electrically erasable programmable read-only memory (EEPROM), flash memory device such as NOR flash memory or NAND flash memory, semiconductor device such as a solid state disk (SSD), and the like. The memory <NUM> may include a combination of the memories as described above.

The transceiver <NUM> is configured to transmit and/or receive data, and may be an antenna, or the like.

The working process of each device is as follows: the processor <NUM> is configured to determine a service set of microservices according to a first user requirement; determine a deployment mode of devices controlled by the microservice; and determine parameter information of the microservices according to a second user requirement; and generate the microservice according to the service set, the deployment mode and the parameter information.

In an optional embodiment, the processor <NUM> is configured to configure the first user requirement and the second user requirement, the first user requirement including at least one of: a project requirement, an application scenario requirement, or a service requirement; and the second user requirement including: a running requirement of a user for running the microservice.

The processor <NUM> is configured to configure the deployment mode including: physical location deployment and process architecture deployment; wherein the physical location deployment includes at least one of: a centralized mode, a distributed mode, or a hybrid mode; and the process architecture deployment includes: a compact mode and/or a safe mode.

In an optional embodiment, the processor <NUM> is configured to configure the parameter information including at least one of: a running environment, a CPU type, or an operating system.

In an optional embodiment, the processor <NUM> is configured to configure the microservices including various service interfaces generated in the form of a list.

In an optional embodiment, the processor <NUM> is further configured to define functions of individual services in the microservices, components contained in the functions, elements used in the components, instances corresponding to the elements and relations among the services in the list of the various service interfaces.

In an optional embodiment, the processor <NUM> is further configured to test the microservice application with a testing tool, issue the microservice application after the testing; and deploy the devices controlled by the microservice application.

The device for generating a microservice application provided in this embodiment may be the device for generating a microservice application shown in <FIG>, and may perform all steps of the method for generating a microservice application shown in <FIG>, so as to achieve the technical effect of the method for generating a microservice application shown in <FIG>. Reference may be made to related description of <FIG>, which, for brevity, is not repeated here.

In an optional embodiment of the present disclosure, there is further provided a storage medium (computer-readable storage medium). The storage medium has one or more programs stored thereon. The storage medium may include a volatile memory such as a random access memory. The memory may include a nonvolatile memory, such as a read only memory, a flash memory, a hard disk, or a solid state disk. The memory may include a combination of memories as described above.

The one or more programs on the storage medium may be executed by one or more processors to cause the method for generating a microservice application to be implemented at the side of the device for generating a microservice application.

The processor is configured to execute a microservice application generation program stored on the memory to implement the following steps of the method for generating a microservice application to be implemented at the side of the device for generating a microservice application: determining a service set of microservices according to a first user requirement; determining a deployment mode of devices controlled by the microservice; determining parameter information of the microservice application according to a second user requirement; and generating the microservice application according to the service set, the deployment mode and the parameter information.

In an optional embodiment, functions of individual services in the microservices, components contained in the functions, elements used in the components, instances corresponding to the elements and relations among the services are defined in the list of the various service interfaces.

In an optional embodiment, the microservice application is tested with a testing tool, and issued after the testing; and then the devices controlled by the microservice application are deployed.

Those skilled in the art will further appreciate that the units and algorithm steps of various examples described in combination with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or a combination of the two, and that the components and steps of the various examples have been described above generally in terms of their functionality to clearly illustrate the interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends on the particular application and design constraints imposed on the technical solution. Those skilled in the art may implement the described functionality in varying ways for each particular application. The scope of the present invention is however defined by the appended claims.

Claim 1:
A method for generating a microservice application, comprising:
determining (S <NUM>) a service set of microservices according to a first user requirement;
determining (S102) a deployment mode of devices to be controlled by the microservice application;
determining (S <NUM>) parameter information of the microservice application according to a second user requirement; and
generating (S104) the microservice application according to the service set, the deployment mode and the parameter information,
wherein the deployment mode comprises: physical location deployment and process architecture deployment;
wherein the physical location deployment comprises at least one of: a centralized mode, a distributed mode, or a hybrid mode; and
wherein the process architecture deployment comprises: a compact mode and/or a safe mode.