A microservice calling method, device and equipment based on a polymeric deployment

Abstract

The present invention discloses a microservice calling method, apparatus, and device based on aggregated deployment. The method comprises: responding to a local call request from a local microservice to a second microservice in a local virtual machine, reading, through the aggregated service call registrar used by the application entry class of the local microservice, whether the second package name of the second microservice is configured in the annotation of enabling aggregated service call client of the local microservice; wherein, at least two microservices are aggregated deployed in the virtual machine; each of the microservices has its own client; and returning corresponding information based on whether the second package name is configured in the annotation of enabling aggregated service call client. The embodiment of the present invention can adapt to the needs of microservice deployment in different situations by setting corresponding microservice call logic, taking into account both aggregated deployment and individual deployment of microservices.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of computers, and in particular to a microservice calling method, device and equipment based on aggregated deployment. BACKGROUND

[0002] In the prior art, each microservice is usually independently deployed, and multiple service instances can be run on the same host to maintain isolation between services. For sites with sufficient server resources, multiple microservices can be deployed individually, and resource utilization is efficient. However, for sites with insufficient server resources, the microservice individual deployment method will occupy a lot of resources, resulting in memory tension. The existing microservice deployment method cannot well meet the calling requirements of different application scenarios, and the microservice promotion efficiency is not high. SUMMARY

[0003] The present application provides a microservice calling method, device and equipment based on aggregated deployment, to solve the problem that the existing microservice deployment method cannot well meet the calling requirements of complex application scenarios.

[0004] According to an aspect of the present application, a microservice calling method based on aggregated deployment is provided, comprising:

[0005] In response to a local calling request of a local microservice in a local virtual machine to a second microservice, whether a second package name in which the second microservice is located is configured in an aggregated service calling client annotation of the local microservice is read through an aggregated service calling register used by an application program entry class of the local microservice; wherein at least two microservices are aggregated in the virtual machine; each of the microservices has its own client;

[0006] If the second package name is configured in the aggregated service calling client annotation, it is determined that the second microservice is not deployed, and a default value or an exception prompt information is returned;

[0007] If the second package name is not configured in the aggregated service calling client annotation, a second interface service responds to the local calling request to determine and feed back a response result.

[0008] According to another aspect of the present application, a microservice calling device based on aggregated deployment is provided, comprising:

[0009] The microservice reading module is configured to read, in response to a local call request of a local microservice in a local virtual machine to a second microservice, whether a second package name in which the second microservice is located is configured in an enabled aggregated service call client annotation of the local microservice through an aggregated service call register used by an application entry class of the local microservice; wherein at least two microservices are aggregated in the virtual machine; each of the microservices has its own client;

[0010] The return information module is configured to determine that the second microservice is not deployed if the second package name is configured in the enabled aggregated service call client annotation, and return a default value or return an exception prompt information.

[0011] The response result module is configured to determine and feed back a response result in response to the local call request through a second interface service if the second package name is not configured in the enabled aggregated service call client annotation.

[0012] According to another aspect of the present application, an electronic device is provided, which comprises at least one processor and a memory connected with the at least one processor in communication; wherein the memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor to enable the at least one processor to execute the microservice call method based on aggregated deployment according to any one of the embodiments of the present application.

[0013] The embodiments of the present application can deploy microservices according to actual sites and call the microservices in response to call requests. For the case of processing undeployed microservices, for example, microservice A calls microservice B in code, but the business of microservice B is not needed in the current site, it can be determined that microservice B is not deployed by determining that the package name in which microservice B is located is configured in the enabled aggregated service call client annotation, and specified default information or error prompt information is returned. For the case of processing deployed microservices, for example, microservice A calls microservice B in code, and the business of microservice B is needed in the current site, it can be determined that the package name in which microservice B is located is not configured in the enabled aggregated service call client annotation, and then a response result is determined and fed back in response to the local call request through the interface service of microservice B. Thus, the problem that the call demand of complex application scenarios can be flexibly met by setting the microservice call logic is solved.

[0014] It should be understood that the content described in this part is not intended to identify key or important features of the embodiments of the present application, nor is it used to limit the scope of the present application. Other features of the present application will become apparent from the following description. BRIEF DESCRIPTION OF DRAWINGS

[0015] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings needed in the embodiment description. Obviously, the drawings described below are only some embodiments of the present application, and for those skilled in the art, other drawings can also be obtained from these drawings without creative labor.

[0016] Figure 1 is a first flowchart of a microservice calling method based on an aggregated deployment provided by an embodiment of the present application;

[0017] Figure 2 is a microservice deployment schematic diagram of a microservice calling method based on an aggregated deployment provided by an embodiment of the present application;

[0018] Figure 3 is a second flowchart of a microservice calling method based on an aggregated deployment provided by an embodiment of the present application;

[0019] Figure 4 is an example flowchart of creating a stub object of a microservice calling method based on an aggregated deployment provided by an embodiment of the present application;

[0020] Figure 5 is an example flowchart of creating a stub object of a microservice calling method based on an aggregated deployment provided by an embodiment of the present application;

[0021] Figure 6 is an example flowchart of a microservice calling method based on an aggregated deployment provided by an embodiment of the present application;

[0022] Figure 7 is an example flowchart of microservice injection dependency of a microservice calling method based on an aggregated deployment provided by an embodiment of the present application;

[0023] Figure 8 is a structural schematic diagram of a microservice calling device based on an aggregated deployment provided by an embodiment of the present application;

[0024] Figure 9 is a structural schematic diagram of an electronic device for implementing an embodiment of the present application. DETAILED DESCRIPTION

[0025] In order to make the person skilled in the art better understand the present application, the technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor should be within the scope of protection of the present application.

[0026] It is to be understood that the terminology "first", "second" and the like used in the specification and the claims of the application as well as the foregoing drawings is merely intended to distinguish between similar objects and not necessarily for describing a special sequential order. It is to be understood that the use of such terms can be interchanged, in appropriate instances, so that the embodiments of the application described herein can be practiced in the sequence other than that which has been set forth herein. Furthermore, the terms "comprise", "comprising", "include", "including", and the like, as used herein, are specifically intended to encompass the presence of stated steps or elements, but not to the exclusion of the presence or addition of one or more other steps or elements, whether or not the same, to the process, method, system, product, or apparatus specifically recited.

[0027] In the prior art, corresponding micro-service business modules are usually set for different businesses. For example, if the application scenario is energy management of a mansion or a park, different owners and projects of each energy business part of a park may be tendered to different manufacturers. For example, commonly used modules include administrator modules, device modules, alarm modules, and less commonly used modules include elevator management modules, lighting management modules, fire management modules, and parking lot management modules. Whether a certain module is used in a certain project cannot be predicted. However, when coding, the micro-services of each functional module cannot be completely divided; the dependency relationship between the modules is network-shaped in the design of the micro-services, micro-service A can call micro-service B, and micro-service B can also call micro-service A. Therefore, when the original micro-service code is aggregated and modified, the combination of the business modules of a certain site is not known; it is necessary to assume that all modules exist and each module can call each other. After bidding for a specific site, the business deployment of the site is known, and it is known which micro-service business modules actually exist; however, the micro-service code cannot be modified for each site, such as deleting the call of a non-existent micro-service, which will develop many possibilities. Therefore, a combination method needs to be researched: when coding, it is assumed that all micro-service modules exist; when deploying a site, different configurations are used to call the non-existent micro-services according to the situation, but the micro-service business code is not deleted.

[0028] The existing microservice call is divided into two cases: one case is that the microservice is deployed separately, and the microservice is called in the form of microservice, for example, microservice A and microservice B are two independent microservices, the service call client annotation (@EnableFeignClients) is enabled on the entry class of springboot, and the package representing microservice B needs to appear in the attribute of the annotation, at this time, the call is in accordance with the http call stub mode of springcloud openfeign, and the implementation of the java interface of the client (client) is the http call stub provided by OpenFeign; the other case is that the microservice is deployed in an aggregated manner, for example, microservice A and microservice B are aggregated into one microservice, and microservice A calls microservice B, and the service call client annotation (@EnableFeignClients) and the aggregated service call client annotation (@EnableMergeFeignClients) do not need to appear in the package representing microservice B in the entry class of springboot, at this time, the implementation of the java interface of the client (client) is a real existing java class. However, when all microservices are in the process of aggregated deployment, that is, part of the microservices have completed the aggregated deployment, and the remaining microservices are waiting for aggregated deployment, if there is a site that needs to call the microservice, the existing microservice call method cannot meet the call demand of the site.

[0029] If multiple microservices access a third-party middleware or database instance before aggregated deployment, it indicates that the microservices do not affect each other, and the microservice code does not need to be modified; if multiple microservices do not access a third-party middleware or database instance before aggregated deployment, but there is resource isolation between the microservices, for example, redis has a prefix of a key name, mysql has a prefix of a table name, and kafka has a prefix of a topic name, it indicates that the microservices do not affect each other, and the microservice code does not need to be modified.

[0030] Figure 1 It is a first flowchart of a microservice call method based on aggregated deployment provided by the embodiment of the application, and the embodiment can be applicable to the deployment of microservices. The deployment scenario of the microservice in the embodiment can be a microservice deployed separately or a microservice deployed in an aggregated manner. The embodiment is especially applicable to the case that a site needs to call a microservice before all microservices are deployed in an aggregated manner. The embodiment is applicable to the case that each microservice does not access an instance and there is no resource isolation between the microservices before aggregated deployment. The method can be executed by a microservice call device based on aggregated deployment. The device can be realized in the form of hardware and / or software, and the device can be configured in an electronic device with corresponding data processing capability.Figure 1 The method comprises:

[0031] S110, in response to a local call request of a local microservice in a local virtual machine to a second microservice, reading, by an application entry class of the local microservice, whether a second package name in which the second microservice is located is configured in an enabled merge service call client annotation of the local microservice through an aggregated service call register used by the application entry class of the local microservice; wherein at least two microservices are aggregated in a virtual machine; each of the microservices has its own client. If the second package name is configured in the enabled merge service call client annotation, S120 is executed; if the second package name is not configured in the enabled merge service call client annotation, S130 is executed.

[0032] In the microservice architecture, the application entry class is a core component of service startup and configuration, which has the functions of service initialization, configuration loading and dependency management. In the Spring Boot framework, the application entry class of the microservice is a class with an annotation @SpringBootApplication. The application entry class introduces an enabled merge service call client annotation (@EnableMergeFeignClient) through the annotation. The client of the microservice can be configured on the enabled merge service call client annotation, the corresponding interface is generated, and each microservice is uniformly managed. The application entry class is integrated with a merge service call register (MergeFeignClientsRegister), which can scan the enabled merge service call client annotation, obtain the package name of the microservice configured in the annotation and the interface in the package of the microservice. The package names of different microservices are different. For example, the microservice clientC and the microservice clientD are configured in the enabled merge service call client annotation, the package name of the microservice clientC is packageC, and the package name of the microservice clientD is packageD. There can be multiple interfaces in a package, for example, all interfaces in clientC are under the packageC package name. The microservices are aggregated in the virtual machine, that is, at least two microservices are deployed in the same virtual machine to realize resource sharing to improve utilization and simplify management.

[0033] S120, determining that the second microservice is not deployed, and returning a default value or returning an exception prompt information.

[0034] Specifically, the second package name in which the second microservice is located is configured in the enabled merge service call client annotation of the local microservice, which indicates that the second microservice is not actually deployed at this time and cannot successfully call the second microservice. A default value or an exception prompt information can be returned to inform the user of the result of the service call.

[0035] S130, determining and feeding back a response result in response to the local call request through the second interface service.

[0036] The second package name in which the second microservice is deployed is not configured in the enabled aggregation service call client annotation of the specific local microservice, indicating that the second microservice has been deployed. The second microservice is called through the second interface service, so that the second microservice determines and feeds back a response result after processing the local call request in response to the local call request. The second interface service is the interface service corresponding to the second microservice. For example, microservice 1 calls microservice 2, microservice 2 has been deployed, microservice 1 sends a local call request to the interface service of microservice 2, and the interface service of microservice 2 processes the request after receiving the local call request and returns a response result to microservice 1, as shown in the following table. Figure 2 The call mechanism for sending a local call request can be a jvm call, which refers to a method call executed within a Java virtual machine.

[0037] The at least two microservices deployed in an aggregation manner dynamically set the context path through a first variable. The value of the first variable in the controller of the microservice deployed in an aggregation manner is the context path of the corresponding microservice.

[0038] For the at least two microservices deployed in an aggregation manner, the context path is set in the controller of the microservice through a first variable. For example, the value of the context path variable in the controller of microservice A can be / serviceA, and the value of the context path variable in the controller of microservice B can be / serviceB. Instead of setting the context path by hard coding, the root path of the microservice is dynamically adjusted without modifying the code. The context path is the root path of the microservice, and all interfaces of the microservice use the root path of the microservice. When multiple microservices are deployed in the same virtual machine, the interface paths of each microservice can be distinguished by taking different values of the context path variable. For example, the value of the context path variable in the controller of microservice A can be / serviceA, and all interface paths corresponding to microservice A start with / serviceA.

[0039] The engineering name of the microservice is dynamically set through a second variable. In the case of aggregation of the microservice and other microservices, the value of the second variable is the engineering name of the aggregated microservice. In the case of separate deployment of the microservice, the value of the second variable is the engineering name of the microservice itself.

[0040] Specifically, one site can include microservices deployed in a manner of aggregation and can also include microservices deployed individually, and the engineering name of all microservices is dynamically set through a second variable, and the engineering name refers to the base package name of the engineering, and all base package names must be orthogonal, i.e., no conflict. For a microservice, in the case of aggregation of the microservice with other microservices, the value of the second variable of the microservice is the engineering name of the aggregated microservices; in the case of individual deployment of the microservice, the value of the second variable of the microservice is the engineering name of the microservice itself. For example, if the engineering name of a microservice itself is kunlun-demo-user, when the microservice is deployed individually, the value of the second variable of the microservice is kunlun-demo-user, and when the microservice is deployed in an aggregated manner with other microservices, the engineering name of the aggregated microservices is kunlun-demo-merge, and the value of the second variable of the microservice is kunlun-demo-merge.

[0041] The configuration module in the local virtual machine obtains a microservice combination to be deployed, and the microservice combination includes the at least two microservices to be deployed in an aggregated manner in the local virtual machine.

[0042] Specifically, the code of a microservice is stable and will not be modified according to different sites. After a site is determined, a configuration module is used to determine the microservice combination corresponding to the site, and the configuration module is used to configure the microservice combination of a specific site, select and obtain candidate microservices to be deployed from a microservice set. For example, microservice A and microservice B to be aggregated are obtained from a microservice set, the configurations of the two microservices can be combined with each other through the configuration module, the common configurations are copied together, the respective specific configurations are set separately, and the setting information is placed in the configuration module.

[0043] The local microservice in the local virtual machine calls the second microservice, whether the second microservice is deployed is determined by reading whether the second package name in which the second microservice is located is configured in the enabling aggregation service call client annotation of the local microservice, if the second microservice is not deployed, a default value or an exception prompt information is returned, otherwise, a response result is determined and fed back in response to the local call request through the second interface service. Thus, when the second microservice is unavailable, the system can remain robust and provide a clear fault handling path, realize the elastic setting of microservice deployment, ensure that part of the service is not deployed due to the actual on-site demand, even if part of the service is unavailable, the whole system can still continue to run, avoiding service failure. In the controller of the aggregated microservice, the context path of the microservice is dynamically set through the first variable, avoiding port occupation conflict, realizing the isolation of data and configuration, improving security and scalability, dynamic configuration can also make the microservice more easily extended, and the microservice is more flexible during deployment, without the need to modify the code. The microservice engineering name is dynamically set through the second variable, realizing flexible value taking in different deployment scenarios, without hard coding, improving code portability and deployment flexibility, and improving system maintainability. In the case of microservice and other microservice aggregation deployment, the value of the second variable of the microservice is the engineering name of the aggregated microservice, and the microservices in the aggregated deployment share some configurations. At this time, the unified engineering name can be beneficial to identification, effectively avoiding port or resource conflict. In the case of separate deployment of the microservice, the value of the second variable of the microservice is the engineering name of the microservice itself, which can maintain the independence of the microservice and avoid naming conflict with other microservices.

[0044] Figure 3 is a second flowchart of a microservice calling method based on aggregation deployment provided by the embodiment of the application, and the embodiment is optimized and improved on the basis of the above-mentioned embodiment. As shown in Figure 3 , the method comprises:

[0045] S210, in response to a local call request of a local microservice in a local virtual machine to a second microservice, whether a second package name in which the second microservice is located is configured in an enabling aggregation service call client annotation of the local microservice is read through an aggregation service call register used by an application program entry class of the local microservice; wherein at least two microservices are aggregated in the virtual machine; each microservice has its own client. If the second package name is configured in the enabling aggregation service call client annotation, S220 is continuously executed; if the second package name is not configured in the enabling aggregation service call client annotation, S250 is continuously executed.

[0046] S220, determining that the second microservice is not deployed, and determining whether there is a merge service invocation client annotation on the to-be-invoked interface. If there is a merge service invocation client annotation on the to-be-invoked interface, and the default implementation class referenced by the attribute of the annotation includes the to-be-invoked method, continue to execute S230; if there is a merge service invocation client annotation on the to-be-invoked interface, but the attribute of the annotation is not configured; or the default implementation class referenced by the attribute of the annotation does not include the to-be-invoked method, continue to execute S240.

[0047] Wherein, the merge service invocation client annotation is enabled to enable the merge service invocation client annotation. The merge service invocation client annotation (@MergeFeignClient) is used to define the merge service invocation client, including service name, configuration class and other information.

[0048] S230, reading the default implementation class in the merge service invocation client annotation by the merge service invocation method interceptor, and calling the to-be-invoked method in the default implementation class to return the default value.

[0049] Wherein, the merge service invocation method interceptor (MergeFeignMethodInterceptor) is used to intercept the method call of the merge service invocation client, which can be used to add additional processing logic, such as log recording, performance monitoring or custom error handling.

[0050] S240, returning exception prompt information that does not support operation.

[0051] Specifically, the package name in the enabled aggregation service call client annotation is read through the aggregation service call register, all interfaces in the package name are obtained, if the second package name where the second microservice is located is configured in the enabled aggregation service call client annotation, it is determined that the second microservice is not deployed, and it is determined whether any interface of the second package name exists the aggregation service call client annotation. If there is no aggregation service call client annotation on the interface to be called, the error information is that the Spring container has no components of this type. If there is an aggregation service call client annotation on the interface to be called, the annotation has an attribute, and the default class of the attribute has a method to be called, the default value of the method is returned, for example, the method 1 of the interface A is called. If there is an aggregation service call client annotation on the interface to be called, the annotation has no attribute; or there is an aggregation service call client annotation on the interface to be called, the annotation has an attribute, but the default class of the attribute has no implementation of the method to be called, an unsupported operation exception UnSupportOperationException is returned. For example, if an interface has 5 methods, a default implementation class only specifies one method, and the aggregation service call client annotation provides a default implementation class of the i-th method of the interface, the i-th method in the default implementation class is called, and the default value corresponding to the i-th method is returned. Wherein, whether any interface has a default implementation class is an attribute in the aggregation service call client annotation. For example, the BusinessIF interface in a certain clientC has three methods methodA, methodB, and methodC. If the attribute in the @MergeFeignClient annotation on the BusinessIF interface indicates that the default implementation class of the BusinessIF interface only implements the methodA method, when the BusinessIF interface is called, the return value of the methodA method is in the default implementation class, and the methodB and the methodC all throw errors. If the attribute in the @MergeFeignClient does not indicate the default implementation class, the methodA, the methodB, and the methodC all throw errors. That is, if the interface implements a non-existent class, an exception is thrown, and an exception prompt information is generated; if the interface exists a default implementation class, and the default implementation class exists a method with a default value, the default value set in advance will be returned, that is, the implementation class of the interface is a subclass of the default implementation class, not the default implementation class itself.

[0052] If there is a certain site, the site has a certain microservice C that does not need to be called, a stub object can be generated for the microservice C, and the stub of the microservice C is obtained through the interface corresponding to the microservice C in the Spring container. Any method of the object is called, and an exception prompt information is returned, such as Figure 4For example, in the test environment, the error code is found to call microservice C, but this situation should not occur in the field, and an exception reminder message is returned. If there is a specific field that calls microservice D, but does not need to implement the function of microservice D, only needs to return a fixed value, a subclass can be configured for microservice D, the fixed value to be returned is set as the default value returned by the subclass, a stub object is generated, and the stub object is put into the Spring container through the interface corresponding to microservice D, so that when the method implemented by the object is called subsequently, the preset default value is returned, such as Figure 5 as shown; if other methods are called, an exception reminder message is thrown. The stub of the microservice is a stub for the Spring container, which is used to simulate the Bean in the Spring container, and by using the stub for the Spring container, the required Bean can be manually created and configured, thereby isolating the dependency.

[0053] In this embodiment, the application program entry class is a class with the annotation @SpringBootApplication, and the application program entry class imports the aggregated service call client annotation. The aggregated service call client annotation imports the aggregated service call registrar. The aggregated service call registrar reads the package names of the aggregated service call client annotation, obtains all interfaces in the package names, scans the interfaces, and if the aggregated service call client annotation exists on any interface, the corresponding stub object can be created by the aggregated service call client factory Bean according to the demand and put into the Spring container. There are two situations for creating the stub object, and the specific situations are as shown in Figure 4 and Figure 5 The aggregated service call client factory Bean can define the behavior of the stub of the microservice based on the general Bean definition, and the aggregated service call method interceptor specifies the intercepting behavior for the stub of the microservice. The behavior information can be the default implementation class in the aggregated service call client annotation, and the default implementation class returns the default value or an exception reminder message. The above process is as shown in Figure 6 .

[0054] The MergeFeignClientFactoryBean is used to create an instance of the aggregated service calling client, which can be responsible for the configuration, initialization and provision of the client instance to the Spring container. The GenericBeanDefinition is a class used to define the general properties of the Bean, which can be used to dynamically create and configure the Bean, specify the class name, scope, properties and the like of the Bean, and define the Bean behavior for the stub for the SpringContainer of the microservice.

[0055] S250, determining and feeding back a response result in response to the local calling request through the second interface service.

[0056] Optionally, the method further comprises: in response to a remote calling request of a local microservice in the local virtual machine to a third microservice, sending a remote calling request to the third microservice deployed in another virtual machine through a third client, making the third client forward the remote calling request to a third interface service, and determining and feeding back a response result in response to the remote calling request by the third interface service, as shown in Figure 2 The calling mechanism for sending the remote calling request can be an rpc call, which is a protocol for remote procedure calling, allowing a program on one computer to call a subprogram on another computer through a network.

[0057] The third client is a client of the third microservice, and the third interface service is an interface service of the third microservice. Specifically, the local microservice is deployed locally, and the third microservice is deployed in another virtual machine. When the local microservice sends a remote calling request to the third microservice, the client of the third microservice receives the request and forwards the remote calling request to the interface service of the third microservice, which determines and feeds back a response result in response to the remote calling request.

[0058] In the case that different microservices in the local virtual machine depend on different external service instances corresponding to any external service, each microservice injects the dependent external service instance through the name of the dependent object; wherein the external service includes at least one of the following: a database, a message queue, a cache component, a log component or a monitoring component.

[0059] The related process of microservice injection dependency is shown in Figure 7As shown. For example, if three different microservices access three different cache components (redis) respectively before being deployed in an aggregated manner, the microservice injects the dependency on the cache in the form of ByType, that is, by the type of the dependent object, and after the three different microservices are deployed in an aggregated manner, the three different cache components (redis) still need to be accessed, and there are three instances of the same type in the Spring container, which correspond to the same Bean, causing an exception. The cache component (redis) corresponds to an AutoConfiguration, which automatically configures the required Bean according to the conditions such as dependencies in the class path, environment variables, and configuration files. Thus, the microservice injects the dependency by the name of the dependent object, that is, byName, which can explicitly specify the instance of the dependency and avoid exceptions. The injection of the dependency by the name of the dependent object can be specified by the @Qualifier annotation. Among them, dependency injection is one of the core concepts in microservice architecture, which is used to decouple components; through dependency injection, microservices can flexibly manage various dependencies, such as databases, message queues, external services for providing specific business functions; and other components such as cache components (such as redis), log components, monitoring components, and the like.

[0060] Optionally, the method further comprises: in the case where the third-party component in the local virtual machine injects the external service by the type of the dependent object, obtaining a target external service instance specified in advance from different external service instances of the external service from a configuration module of the local virtual machine, so that the third-party component preferentially selects the target external service instance for injection. For example, if the dependent component only needs to be bound to the virtual machine (for example, jvm) and can be unbound from the microservice, such as the calculation of the workerid by the snowflake algorithm, the cache component (redis) can continue to be accessed in the ByType manner, and since it is unknown whether a certain field is deployed and whether a certain microservice exists, one of the multiple cache component (redis) instances can be selected as a preferentially used instance, and the Bean corresponding to the preferentially used instance is declared as Primary in the configuration module.

[0061] The embodiment of the application determines whether the second microservice is not deployed, determines whether there is an aggregated service calling client annotation on the interface to be called and whether the aggregated service calling client annotation has an attribute, returns corresponding information, and in the case that a certain microservice does not need to be called in a certain field, the microservice can be set up in a way that the microservice returns an abnormal prompt information or a default value when called, thereby avoiding the problem that the system fails to start due to the absence of a corresponding Bean. The dependency injection mode of the third-party component is modified, which can ensure that the components in the service are quickly and accurately identified, and the confusion and conflict problems in the calling process are avoided. The technical scheme of the application is applicable to the case that there are both separately deployed microservices and aggregated deployed microservices, and is especially applicable to the case that the microservice needs to be called in the field before all microservices are aggregated and deployed. Without changing the business code, the specific architecture of the microservice deployment can be flexibly adjusted according to the specific business required by the actual field, the business is freely combined, the microservice that is not required in the actual field is not deployed, which is conducive to the promotion of the microservice among different departments and improves the user experience.

[0062] Figure 8 is a structural schematic diagram of a microservice calling device based on aggregated deployment provided by the embodiment of the application. As shown in Figure 8 the device comprises:

[0063] The microservice reading module 310 is configured to read, in response to a local calling request of a local microservice to a second microservice in a local virtual machine, whether a second package name in which the second microservice is located is configured in an aggregated service calling client annotation enabled for the local microservice through an aggregated service calling register used by an application program entry class of the local microservice; wherein at least two microservices are aggregated and deployed in the virtual machine; and each microservice has its own client.

[0064] The return information module 320 is configured to determine that the second microservice is not deployed and return a default value or return an abnormal prompt information if the second package name is configured in the aggregated service calling client annotation enabled.

[0065] The response result module 330 is configured to determine and feed back a response result through a second interface service in response to the local calling request if the second package name is not configured in the aggregated service calling client annotation enabled.

[0066] Optionally, the return information module 320 comprises:

[0067] The attribute determining unit is configured to determine that the second microservice is not deployed and determine whether there is an aggregated service calling client annotation on the interface to be called if the second package name is configured in the aggregated service calling client annotation enabled.

[0068] The first return information unit is configured to read the default implementation class in the aggregated service invocation client annotation through an aggregated service invocation method interceptor if the to-be-invoked interface has the aggregated service invocation client annotation and the to-be-invoked method is included in the default implementation class referenced by the attribute of the annotation, and to return a default value of the to-be-invoked method in the default implementation class.

[0069] The second return information unit is configured to return an exception prompt information of an unsupported operation if the to-be-invoked interface has the aggregated service invocation client annotation but the annotation is not configured with an attribute, or the to-be-invoked method is not included in the default implementation class referenced by the attribute of the annotation.

[0070] Optionally, the apparatus further includes a microservice remote invocation module configured to, in response to a remote invocation request of a local microservice in a local virtual machine to a third microservice, send the remote invocation request to the third microservice deployed in another virtual machine through a third client, make the third client forward the remote invocation request to a third interface service, and determine and feed back a response result by the third interface service in response to the remote invocation request.

[0071] Optionally, in a case where different microservices in the local virtual machine depend on different external service instances of any external service, each of the microservices injects a dependent external service instance through a name of a dependent object, and the external service includes at least one of a database, a message queue, a cache component, a log component, or a monitoring component.

[0072] Optionally, in a case where a third-party component in the local virtual machine injects the external service through a type of a dependent object, a target external service instance is obtained from a configuration module of the local virtual machine, the target external service instance being specified in advance from different external service instances of the external service, and the third-party component preferentially selects the target external service instance for injection.

[0073] Optionally, at least two microservices deployed in an aggregation manner dynamically set a context path through a first variable, and a value of the first variable in a controller of the microservices deployed in the aggregation manner is the context path of a corresponding microservice.

[0074] Optionally, an engineering name of a microservice is dynamically set through a second variable, and a value of the second variable is an engineering name of an aggregated microservice in a case where the microservice is deployed in an aggregation manner, and the value of the second variable is an engineering name of the microservice itself in a case where the microservice is deployed alone.

[0075] Optionally, the apparatus further comprises a microservice combination obtaining module configured to obtain, by the configuration module in the local virtual machine, a microservice combination to be deployed, the microservice combination comprising the at least two microservices to be deployed in an aggregated manner in the local virtual machine.

[0076] The apparatus for calling microservices based on aggregated deployment provided in the embodiments of the present application can execute the method for calling microservices based on aggregated deployment provided in any of the embodiments of the present application, and has the corresponding function modules and beneficial effects of the execution method.

[0077] Figure 9 A structural schematic diagram of an electronic device 40 that can be used to implement embodiments of the present application is shown. The electronic device is intended to represent various forms of digital computers, such as laptops, desktops, tablets, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular telephones, smart phones, wearable devices (e.g., headsets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions, are meant to be examples only, and are not intended to limit the implementations of the present application described and / or claimed in this document.

[0078] As shown in Figure 9 The electronic device 40 includes at least one processor 41, and a memory, such as a read-only memory (ROM) 42, a random access memory (RAM) 43, etc., connected to the at least one processor 41 in communication, wherein the memory stores a computer program executable by the at least one processor 41, and the processor 41 can perform various appropriate actions and processes according to the computer program stored in the read-only memory (ROM) 42 or loaded from the storage unit 48 into the random access memory (RAM) 43. In the RAM 43, various programs and data required for the operation of the electronic device 40 can also be stored. The processor 41, the ROM 42, and the RAM 43 are connected to each other through a bus 44. An input / output (I / O) interface 45 is also connected to the bus 44.

[0079] The plurality of components in the electronic device 40 are connected to the I / O interface 45, including: an input unit 46, such as a keyboard, a mouse, etc.; an output unit 47, such as various types of displays, speakers, etc.; a storage unit 48, such as a magnetic disk, an optical disk, etc.; and a communication unit 49, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 49 allows the electronic device 40 to exchange information / data with other devices through a computer network, such as the Internet, and / or various telecommunications networks.

[0080] The processor 41 can be various general-purpose and / or special-purpose processing components having processing and computing capabilities. Some examples of the processor 41 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various specialized artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any appropriate processor, controller, microcontroller, and the like. The processor 41 performs various methods and processes described above, such as the microservice invocation method based on aggregated deployment.

[0081] In some embodiments, the microservice invocation method based on aggregated deployment can be implemented as a computer program tangibly embodied in a computer readable storage medium, such as the storage unit 48. In some embodiments, part or all of the computer program can be loaded and / or installed onto the electronic device 40 via the ROM 42 and / or the communication unit 49. When the computer program is loaded onto the RAM 43 and executed by the processor 41, one or more steps of the microservice invocation method based on aggregated deployment described above can be performed. Alternatively, in other embodiments, the processor 41 can be configured to perform the microservice invocation method based on aggregated deployment by any other appropriate means, such as by means of firmware.

[0082] The various implementations of the systems and techniques described above can be realized in digital electronic circuitry, integrated circuitry, a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), a system on a chip (SOC), a programmable logic device (CPLD), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include implementation in one or more computer programs that are executable and / or interpretable on a programmable system including at least one programmable processor, which can be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.

[0083] Computer programs used to implement the methods of the application can be written in any combination of one or more programming languages. These computer programs can be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the computer program, when executed, implements the functions / acts specified in the flowcharts and / or block diagrams. The computer program can be executed entirely on a machine, partially on a machine, partially on a machine as a stand-alone software package, and partially on a machine or a remote machine or a server.

[0084] In the context of the present invention, a computer-readable storage medium may be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, device, or apparatus. A computer-readable storage medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or apparatus, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media may include an electrical connection based on one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0085] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device that has: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, the feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including acoustic input, voice input, or tactile input).

[0086] The systems and techniques described herein can be implemented in a computing system that includes back-end components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes front-end components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such back-end components, middleware components, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: a local area network (LAN), a wide area network (WAN), a blockchain network, and the Internet.

[0087] The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a host product in the cloud computing service system, to solve the defects of large management difficulty and weak business scalability in traditional physical host and VPS service.

[0088] It should be understood that the various forms of flow shown above can be used to reorder, add or delete steps. For example, each step described in the present application can be executed in parallel, sequentially or in a different order, as long as the desired results of the technical solutions of the present application can be achieved, which is not limited herein.

[0089] The above detailed description does not constitute a limitation on the scope of protection of the present application. Those skilled in the art should understand that various modifications, combinations, sub-combinations and substitutions can be made according to design requirements and other factors. Any modifications, equivalent replacements and improvements made within the spirit and principles of the present application shall be included in the scope of protection of the present application.

Claims

1. A microservice calling method based on aggregated deployment, characterized in that: include: In response to a local call request from a local microservice to a second microservice in a local virtual machine, the aggregated service call registrar used by the application entry class of the local microservice reads whether the second package name of the second microservice is configured in the annotation of enabling the aggregated service call client of the local microservice; wherein at least two microservices are aggregatedly deployed in the local virtual machine, the local virtual machine is a JVM; and each of the microservices has its own client; If the second package name is configured in the annotation for enabling the aggregated service call client, it is determined that the second microservice is not deployed, and a default value or an abnormal reminder message is returned; If the second package name is not configured in the annotation for enabling the aggregated service call client, determining and feeding back a response result in response to the local call request through the second interface service; The enabling of the aggregated service call client annotation is used to configure the client of the microservice, generate the corresponding interface, and uniformly manage the microservice.

2. The method according to claim 1, characterized in that If the second package name is configured in the annotation for enabling the aggregated service call client, determining that the second microservice is not deployed, and returning a default value or returning an abnormal reminder message, includes: If the second package name is configured in the annotation for enabling the aggregate service call client, it is determined that the second microservice is not deployed, and whether there is an annotation for the aggregate service call client on the interface to be called; If there is an aggregate service call client annotation on the interface to be called, and the default implementation class referenced by the attributes of the annotation includes the method to be called, the aggregate service call method interceptor reads the default implementation class in the aggregate service call client annotation, calls the method to be called in the default implementation class and returns the default value; If there is an aggregate service call client annotation on the interface to be called, but the annotation is not configured with attributes; or the default implementation class referenced by the attributes of the annotation does not include the method to be called, an exception reminder message indicating that the operation is not supported is returned.

3. The method according to claim 1, characterized in that The method further comprises: In response to a remote call request from a local microservice in a local virtual machine to a third microservice, a remote call request is sent to a third microservice deployed in another virtual machine through a third client, so that the third client forwards the remote call request to a third interface service, and the third interface service determines and feeds back a response result in response to the remote call request.

4. The method according to any one of claims 1 to 3, characterized in that When different microservices in the local virtual machine depend on any external service corresponding to different external service instances, each microservice injects the dependent external service instance through the name of the dependent object; wherein the external service includes at least one of the following: a database, a message queue, a cache component, a log component or a monitoring component.

5. The method according to claim 4, characterized in that When a third-party component in the local virtual machine injects the external service through the type of the dependent object, the target external service instance pre-specified from different external service instances of the external service is obtained from the configuration module of the local virtual machine, so that the third-party component gives priority to the target external service instance for injection.

6. The method according to claim 1, characterized in that At least two microservices deployed in an aggregated manner dynamically set a context path through a first variable, and in a controller of the microservice deployed in an aggregated manner, a value of the first variable is the context path of the corresponding microservice.

7. The method according to claim 1, characterized in that The project name of the microservice is dynamically set through a second variable. When the microservice is deployed in an aggregated manner with other microservices, the value of the second variable is the project name of the aggregated microservice. When the microservice is deployed separately, the value of the second variable is the project name of the microservice itself.

8. The method according to claim 1, characterized in that The method further comprises: A microservice combination that needs to be deployed is obtained through a configuration module in the local virtual machine, where the microservice combination includes the at least two microservices that need to be deployed in an aggregated manner in the local virtual machine.

9. A microservice calling device based on aggregated deployment, characterized in that: The device comprises: The microservice reading module is configured to respond to a local call request from a local microservice in a local virtual machine to a second microservice by reading, through an aggregated service call registrar used by an application entry class of the local microservice, whether the local microservice's annotation for enabling an aggregated service call client is configured with the second package name of the second microservice; wherein at least two microservices are aggregatedly deployed in the local virtual machine, the local virtual machine being a JVM; and each of the microservices having its own client; a return information module, configured to determine that the second microservice is not deployed and return a default value or an exception reminder message if the second package name is configured in the annotation for enabling the aggregated service call client; a response result module, configured to determine and feed back a response result in response to the local call request through a second interface service if the second package name is not configured in the annotation for enabling the aggregated service call client; The enabling of the aggregated service call client annotation is used to configure the client of the microservice, generate the corresponding interface, and uniformly manage the microservice.

10. An electronic device, characterized in that: The electronic device comprises: at least one processor; and a memory communicatively coupled to the at least one processor; The memory stores a computer program that can be executed by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the microservice calling method based on aggregated deployment described in any one of claims 1-8.

Images