A microservice configuration system, device, and medium

Abstract

The present application discloses a microservice configuration system, device and medium. The system includes: a microservice configuration architecture and a general service component architecture; wherein, the microservice configuration architecture is used for splitting and merging multiple microservices; the general service component architecture is used for communicating with the microservice configuration architecture through the call interface of the microservice call component, and calling any one of the multiple microservices after splitting or merging. In this way, it is possible to achieve fine-grained service division and split deployment according to specific services when resources are sufficient, and to deploy in the way of merging microservices when resources are tight, so as to flexibly select the deployment quantity and deployment method of microservices according to the actual resource environment. Moreover, when deploying services, there is no need to modify the code additionally, and it has no perception and impact on the specific business development.

Description

Technical Field

[0001] Embodiments of the present application relate to the field of microservice deployment, and particularly to a microservice configuration system, device, and medium. Background Art

[0002] A microservice is a distributed architecture system with loose coupling between services, high autonomy between each service, and communication using lightweight protocols for sustainable integrated deployment. However, microservice deployment has certain requirements for resources. For example, when the business splitting granularity is finer, the number of microservices gradually increases, resulting in a continuous increase in resource requirements, making it impossible to flexibly deploy the microservice system for operation. Summary of the Invention

[0003] Embodiments of the present application provide a microservice configuration system, device, and medium, which can, when resources are sufficient, perform fine-grained service division and split deployment according to specific services, and when resources are tight, perform deployment in a way of merging microservices, so as to flexibly select the number and deployment method of microservices according to the actual resource environment.

[0004] In a first aspect, embodiments of the present application further provide a microservice configuration system, which includes: a microservice configuration architecture and a general service component architecture;

[0005] The microservice configuration architecture is used to split and merge multiple microservices;

[0006] The general service component architecture is used to communicate with the microservice configuration architecture through the call interface of the microservice call component, and call any one of the multiple split or merged microservices.

[0007] Optionally, the microservice configuration architecture includes a microservice registration component;

[0008] When the multiple microservices are merged microservices, the microservice registration component is used to register the merged microservices to the registration center component in the general service component architecture according to the mapping relationship between the microservices;

[0009] When the multiple microservices are split microservices, the microservice registration component is used to register the microservice names corresponding to the split microservices to the registration center component in the general service component architecture.

[0010] Optionally, the microservice registration component is further used to determine the main service name among the microservice names of the multiple microservices, determine the remaining microservice names as the module interface names of the corresponding microservices, and generate a one-to-many mapping relationship according to the main service name and the module interface names;

[0011] Wherein, the remaining microservice names include all microservice names except the main service name in the microservice names.

[0012] Optionally, the microservice configuration architecture further includes a configuration file management component;

[0013] In the case where multiple microservices are merged microservices, the configuration file management component is used to manage the configuration files of each merged microservice in a multi-data source switching manner;

[0014] In the case where multiple microservices are split microservices, the configuration file management component is used to manage the configuration files of each split microservice separately.

[0015] Optionally, the microservice configuration architecture further includes a dynamic routing component;

[0016] In the case where multiple microservices are merged microservices, the dynamic routing component is used to find the corresponding module interface name or main service name in the registration center component of the general service component architecture according to the microservice name of the target microservice carried in the routing request, and determine the routing address of the target microservice according to the routing address of the module interface name or the routing address of the main service name;

[0017] In the case where multiple microservices are split microservices, the dynamic routing component is used to find the corresponding microservice name in the registration center component of the general service component architecture according to the microservice name of the target microservice carried in the routing request, and determine the routing address of the microservice name as the routing address of the target microservice;

[0018] Among them, the routing request is sent by the gateway service component in the general service component architecture to the microservice configuration architecture.

[0019] Optionally, the dynamic routing component is further used to find the mapping relationship corresponding to the module interface name in the registration center component according to the module interface name, find the main service name to which the module interface name belongs according to the mapping relationship, and determine the routing address corresponding to the main service name and the routing address of the module interface name as the routing address of the target microservice.

[0020] Optionally, the microservice configuration architecture further includes a service call component;

[0021] The service call component is used to call the target microservice according to the routing address of the target microservice.

[0022] Optionally, the microservice configuration architecture further includes a configuration management component;

[0023] The configuration management component supports manual configuration mode and automatic configuration mode.

[0024] In a second aspect, an embodiment of the present application further provides a computer device, including: a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, the functions of the microservice configuration system provided in any embodiment of the present application are implemented.

[0025] In a third aspect, an embodiment of the present application further provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the functions of the microservice configuration system provided in any embodiment of the present application are implemented.

[0026] An embodiment of the present application provides a microservice configuration system, device, and medium. The system includes: a microservice configuration architecture and a general service component architecture; wherein, the microservice configuration architecture is used to split and merge multiple microservices; the general service component architecture is used to communicate with the microservice configuration architecture through the call interface of the microservice call component, and call any one of the multiple microservices after splitting or merging. In this way, it is possible to achieve fine-grained service division and split deployment according to specific services when resources are sufficient, and to deploy in the way of merging microservices when resources are tight, so as to flexibly select the deployment quantity and deployment method of microservices according to the actual resource environment, and when deploying services, there is no need to modify the code additionally, and it has no perception and impact on specific business development. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] Figure 1 It is a schematic diagram of a microservice configuration system in an embodiment of the present application;

[0028] Figure 2 It is a schematic structural diagram of the computer device in an embodiment of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0029] The present application will be further described in detail below with reference to the drawings and embodiments. It can be understood that the specific embodiments described herein are only used to explain the present application, rather than limiting the present application. In addition, it should be noted that, for the sake of description, only some parts related to the present application are shown in the drawings, not all the structures.

[0030] In addition, in the embodiments of the present application, words such as "optionally" or "exemplarily" are used to represent examples, illustrations, or explanations. Any embodiment or design solution described as "optionally" or "exemplarily" in the embodiments of the present application should not be construed as being more preferred or having more advantages than other embodiments or design solutions. Exactly speaking, the use of words such as "optionally" or "exemplarily" is intended to present relevant concepts in a specific manner.

[0031] Figure 1A microservice configuration system provided by an embodiment of the present application. This system is designed based on the traditional general service component architecture, with some extended functions added, enabling flexible splitting and merging of multiple microservices according to the actual resource environment in specific business scenarios. For example Figure 1 As shown, the system may include a microservice configuration architecture 101 and a general service component architecture 102;

[0032] Among them, the microservice configuration architecture is used to split and merge multiple microservices. For example, when resources are sufficient, fine-grained microservice partitioning can be performed according to specific business, splitting a complex microservice into multiple microservices for operation; when resources are scarce and more microservices cannot be deployed, multiple microservices can be merged into one service for operation. As Figure 1 shown, the splitting and merging of multiple microservices by the above microservice configuration architecture can be achieved through the various components in this architecture.

[0033] The general service component architecture is used to communicate with the microservice configuration architecture through the call interface of the microservice call component and call any one of the multiple microservices after splitting or merging. That is, the above microservice configuration architecture is used to merge or split multiple microservices according to the actual resource situation. On this basis, the general service component architecture can communicate with external applications and call the target microservice among the multiple microservices after splitting or merging based on the communication content. For example, the gateway service component in the general service component architecture is used to determine the target microservice that the user needs to call according to the content of the interaction with the external application (for example, the microservice access address input by the user), and then communicate with the microservice configuration architecture based on the communication interface of the gateway service component. For example, interact with the dynamic routing component to determine the routing address of the target microservice in the service after splitting or merging. Furthermore, the microservice call component in the general service component architecture communicates with the service call component in the microservice configuration architecture to call the target microservice that needs to be called based on the determined routing address.

[0034] In an embodiment of the present application, the above-designed microservice configuration system is obtained by expanding the functions on the basis of the traditional general service component architecture. It can perform fine-grained service partitioning and split deployment according to specific business when resources are sufficient, and can be deployed in the way of merging microservices when resources are scarce, realizing flexible selection of the deployment quantity and deployment method of microservices according to the actual resource environment. And when deploying services, there is no need to modify the code additionally, and it has no perception and no impact on specific business development.

[0035] In one example, the above microservice configuration architecture may specifically include a microservice registration component, which can be used to perform microservice registration in a corresponding manner when multiple microservices are merged or split.

[0036] For example, when multiple microservices are merged microservices, the microservice registration component is used to register the merged microservices to the registration center component in the general service component architecture according to the mapping relationship between the microservices. Further, when the microservice registration component registers microservices, generating the mapping relationship specifically includes: determining the main service name among the microservice names of multiple microservices, determining the remaining microservice names as the module interface names of the corresponding microservices, and generating a one-to-many mapping relationship according to the main service name and the module interface names, where the remaining microservice names include all microservice names except the main service name in the microservice names. For example, assuming there are microservices A, B, and C, then the main service in multiple microservices can be determined by methods such as according to the weight of each microservice, randomly selecting the main service among multiple microservices, or manually selecting the main service by the user among multiple microservices, and the microservice name of the main service is determined as the main service name (for example, microservice A is the main service), the remaining microservices B and C are regarded as the remaining microservices, and the microservices B and C are introduced into the main service A in the form of modules. It can be understood that although when multiple microservices are merged, multiple microservices can only share one main service name, and other microservices are modules introduced under the main service name, other microservices also need to be registered in the registration center component, that is, the microservice names of other microservices are determined as module interface names, and the main service name and the multiple module interface names are registered in the registration center component in a one-to-many mapping relationship, so as to realize the registration of multiple microservices to the registration center component when merged. For example, the mapping relationships between the main service name A and the module interface names B and C are registered and saved to the registration center component, so as to realize the merger of microservices A, B, and C and share a main service name A. Exemplarily, the mapping relationship can be that the microservice name of the main service A is used as the prefix of the main service uniform resource locator (URL) path address. For each microservice introduced in the form of a module, its path address can be the corresponding module interface name after the main service URL path address. This can not only avoid the problem of interface call confusion caused by the same interface path when multiple microservices are deployed in combination, but also ensure that after multiple microservices are merged, the corresponding microservices can be accurately called according to the specific routing address.

[0037] In the case where multiple microservices are un-split microservices, a microservice registration component is used to register each of the split microservices and their corresponding microservice names to the registration center component in the general service component architecture. That is, when resources are sufficient and microservice merging is not required, microservices can be split into fine-grained ones according to the actual resource situation, and each of the split microservices can be registered separately. For example, the microservice names corresponding to each microservice are registered to the registration center component in the general service component architecture.

[0038] In one example, the above microservice configuration architecture further includes a configuration management component, which can support both manual configuration and automatic configuration, facilitating users to select a suitable microservice configuration method according to the actual situation. For example, during the above microservice registration process, the method of selecting the main service according to the weight of each microservice or randomly selecting the main service from multiple microservices can be understood as an implementation method in the automatic configuration process, and the method of manually selecting the main service by the user from multiple microservices can be understood as an implementation method in the manual configuration process.

[0039] Furthermore, in the case of adopting automatic configuration, the merged microservices will automatically scan when starting, intercept all URL prefixes, and compare them with the service name of this service. If they are inconsistent, it means that the service name corresponding to the URL prefix is the module interface name. In this way, the module interface names that have a mapping relationship with the main service name can be automatically obtained and entered through the program. In the case of adopting manual configuration, the user needs to manually enter the microservice names corresponding to each microservice to be merged through the page.

[0040] In one example, the above microservice configuration architecture further includes a configuration file management component, which is used to manage the configuration files of multiple microservices. Exemplarily, in the case where multiple microservices are merged microservices, the configuration file management component is used to manage the configuration files of the merged microservices in the way of multi-data source switching. For example, the configuration files of multiple microservices may have the same configuration parameters (with different parameter values), such as application ports, port numbers, data connection parameters, etc. Using the method of multi-data source switching to manage the configuration files of the merged microservices can ensure that when any of the merged microservices is called, the configuration file of this service itself is still read. In the case where multiple microservices are split microservices, the configuration file management component is used to manage the configuration files of each of the split microservices separately.

[0041] In one example, the above microservice configuration architecture may further include a dynamic routing component, which is used to determine the routing address of the target microservice to be called. Exemplarily, in the case where multiple microservices are merged microservices, the dynamic routing component is used to find the corresponding module interface name or main service name in the registration center component of the general service component architecture according to the microservice name of the target microservice carried in the routing request, and determine the routing address of the target microservice according to the routing address of the module interface name or the routing address of the main service name. It can be understood that in the case where multiple microservices are merged, the above target microservice may be the main service, or it may be a microservice incorporated in the form of a module under the main service. Therefore, when looking up the target microservice in the registration center component, the corresponding main service name may be found, or the corresponding module interface name may be found, and then the routing address of the target microservice can be determined according to the routing address of the module interface name or the routing address of the main service name.

[0042] It should be noted that since the routing address of the microservice will change after the microservice is merged, or it can be understood that the specific form of its routing address will change. For example, the routing address of a separate microservice before the merger may become the routing address of a module attached to a certain main service after the merger. Therefore, the dynamic routing component can also find the mapping relationship corresponding to the module interface name in the registration center component according to the found module interface name, and query the main service name to which the module interface name belongs according to the mapping relationship, and determine the routing address corresponding to the main service name and the routing address of the module interface name under the main service as the routing address of the target microservice, that is, determine the routing address of the target microservice according to the logic of the main service name and the module interface name under the main service.

[0043] It can be understood that in the case where the target microservice is the main service after the merger, the routing address of the main service can be directly determined as the routing address of the target microservice.

[0044] In the case where multiple microservices are split microservices, the dynamic routing component is used to find the corresponding microservice name in the registration center component of the general service component architecture according to the microservice name of the target microservice carried in the routing request, and determine the routing address of the found microservice name as the routing address of the target microservice;

[0045] Among them, the above routing request is sent by the gateway service component in the general service component architecture to the microservice configuration architecture. Specifically, it can be sent to the dynamic routing component in the microservice configuration architecture.

[0046] Further, the above microservice configuration architecture may further include a service call component, which is used to call a target microservice according to the routing address of the target microservice. More specifically, the microservice call component in the general service component architecture may communicate with the service call component in the microservice configuration architecture to call the target microservice that needs to be called based on the routing address determined by the above dynamic routing component. For example, after the dynamic routing component determines the routing address of the target microservice, it returns the routing address of the target microservice to the gateway service component, and the gateway service component forwards the routing address to the microservice call component. The microservice call component communicates with the service call component based on the routing address of the target microservice to implement the call of the target microservice, ensuring that external applications can successfully make a seamless call to the target microservice in the case of merging or splitting multiple microservices.

[0047] As Figure 1 shown, in addition to the registration center component, the gateway service component, and the microservice call component, the above general service component architecture may further include a permission center component, a configuration center component, a log center component, a link tracing component, etc. Since the general service component architecture belongs to an existing architecture, the embodiments of the present application perform functional expansion on the basis of this architecture to design the microservice configuration architecture. Therefore, in the embodiments of the present application, the functions of each component in the general service component architecture will not be introduced in detail.

[0048] Figure 2 The following is a schematic structural diagram of a computer device provided by an embodiment of the present application. As Figure 2 shown, the computer device includes a controller 201, a memory 202, an input device 203, and an output device 204. The number of controllers 201 in the computer device may be one or more. Figure 2 In this example, one controller 201 is taken as an example. The controller 201, the memory 202, the input device 203, and the output device 204 in the computer device may be connected through a bus or other means. Figure 2 In this example, connection through a bus is taken as an example.

[0049] The memory 202, as a computer-readable storage medium, can be used to store software programs, computer-executable programs, and modules, such as Figure 1 the program instructions corresponding to the microservice configuration system in the embodiments. The controller 201 executes various functions and data processing of the computer device by running the program instructions stored in the memory 202, that is, implements the functions of the above microservice configuration system.

[0050] The memory 202 may mainly include a program storage area and a data storage area. Among them, the program storage area may store an operating system and application programs required for at least one function; the data storage area may store data created according to the use of the computer, etc. In addition, the memory 202 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one magnetic disk storage device, a flash memory device, or other non-volatile solid-state storage devices. In some embodiments, the memory 202 may further include a memory remotely provided relative to the controller 201, and these remote memories may be connected to the terminal / server through a network. Examples of the above network include but are not limited to the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0051] The input device 203 can be used to receive input digital or character information, and generate key signal inputs related to the user settings and function controls of the computer device. The output device 204 may include a display device such as a display screen.

[0052] The embodiments of the present application also provide a storage medium containing computer-executable instructions, and these computer-executable instructions are used to execute Figure 1 the functions of the microservice configuration system shown.

[0053] From the above description of the embodiments, those skilled in the art can clearly understand that the present application can be implemented by means of software and necessary general hardware. Of course, it can also be implemented by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as a floppy disk, a read-only memory (ROM), a random access memory (RAM), a flash memory (FLASH), a hard disk, or an optical disc of a computer, etc., and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the methods described in various embodiments of the present application.

[0054] Note that the above is only a preferred embodiment of the present application and the applied technical principles. Those skilled in the art will understand that the present application is not limited to the specific embodiments described here. Various obvious changes, re-adjustments, and substitutions can be made by those skilled in the art without departing from the protection scope of the present application. Therefore, although the present application has been described in more detail through the above embodiments, the present application is not limited to the above embodiments. Without departing from the concept of the present application, it may also include more other equivalent embodiments, and the scope of the present application is determined by the scope of the appended claims.

Claims

1. A microservice configuration system, characterized in that, Including: A microservice configuration architecture and a general service component architecture; The microservice configuration architecture is used to split and merge multiple microservices; The general service component architecture is used to communicate with the microservice configuration architecture through the call interface of the microservice call component and call any one of the multiple microservices after splitting or merging; The microservice configuration architecture further includes a configuration file management component; When the multiple microservices are merged microservices, the configuration file management component is used to manage the configuration files of the merged microservices in the way of multi-data source switching; When the multiple microservices are split microservices, the configuration file management component is used to manage the configuration files of the split microservices respectively; Wherein, the microservice configuration architecture includes: a microservice registration component and a dynamic routing component; The general service component architecture includes: a microservice call component and a gateway service component.

2. The system according to claim 1, wherein When the multiple microservices are merged microservices, the microservice registration component is used to register the merged microservices to the registration center component in the general service component architecture according to the mapping relationship between the microservices; When the multiple microservices are split microservices, the microservice registration component is used to register the microservice names corresponding to the split microservices to the registration center component in the general service component architecture; The microservice registration component is further used to determine the main service name among the microservice names of the multiple microservices, determine the remaining microservice names as the module interface names of the corresponding microservices, and generate a one-to-many mapping relationship according to the main service name and the module interface names; Wherein, the remaining microservice names include all microservice names except the main service name in the microservice names.

3. The system according to any one of claims 1-2, wherein When the multiple microservices are merged microservices, the dynamic routing component is used to find the corresponding module interface name or main service name in the registration center component of the general service component architecture according to the microservice name of the target microservice carried in the routing request, and determine the routing address of the target microservice according to the routing address of the module interface name or the routing address of the main service name; When the multiple microservices are split microservices, the dynamic routing component is used to find the corresponding microservice name in the registration center component of the general service component architecture according to the microservice name of the target microservice carried in the routing request, and determine the routing address of the microservice name as the routing address of the target microservice; Wherein, the routing request is sent by the gateway service component in the general service component architecture to the microservice configuration architecture.

4. The system according to claim 3, characterized in that, The dynamic routing component is further configured to find the mapping relationship corresponding to the module interface name in the registration center component according to the module interface name, find the main service name to which the module interface name belongs according to the mapping relationship, and determine the routing address corresponding to the main service name and the routing address of the module interface name as the routing address of the target microservice.

5. The system according to claim 3, characterized in that, The microservice configuration architecture further includes a service call component; The service call component is configured to call the target microservice according to the routing address of the target microservice.

6. The system according to claim 1, characterized in that The microservice configuration architecture further includes a configuration management component; The configuration management component is configured to select a suitable microservice configuration method; wherein, the microservice configuration methods include: a manual configuration method and an automatic configuration method.

7. A computer device, characterized in that, including: a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein when the processor executes the computer program, the functions of the microservice configuration system according to any one of claims 1-6 are implemented.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, the functions of the microservice configuration system according to any one of claims 1-6 are implemented.

Images