CN112433863A - Micro-service calling method and device, terminal equipment and storage medium - Google Patents
Micro-service calling method and device, terminal equipment and storage medium Download PDFInfo
- Publication number
- CN112433863A CN112433863A CN202011292776.7A CN202011292776A CN112433863A CN 112433863 A CN112433863 A CN 112433863A CN 202011292776 A CN202011292776 A CN 202011292776A CN 112433863 A CN112433863 A CN 112433863A
- Authority
- CN
- China
- Prior art keywords
- service
- node
- micro
- target
- address
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 50
- 238000003860 storage Methods 0.000 title claims abstract description 19
- 230000006870 function Effects 0.000 claims description 35
- 238000012545 processing Methods 0.000 claims description 23
- 238000004590 computer program Methods 0.000 claims description 14
- 238000012360 testing method Methods 0.000 claims description 6
- 238000010586 diagram Methods 0.000 description 15
- 238000005096 rolling process Methods 0.000 description 6
- 101150060298 add2 gene Proteins 0.000 description 4
- 101100108191 Vibrio parahaemolyticus serotype O3:K6 (strain RIMD 2210633) add gene Proteins 0.000 description 3
- 238000009826 distribution Methods 0.000 description 2
- 230000000977 initiatory effect Effects 0.000 description 2
- 238000004519 manufacturing process Methods 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- 238000003491 array Methods 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 238000007405 data analysis Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
- 238000009827 uniform distribution Methods 0.000 description 1
- 238000011144 upstream manufacturing Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/547—Remote procedure calls [RPC]; Web services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/71—Version control; Configuration management
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Hardware Redundancy (AREA)
Abstract
The embodiment of the application discloses a micro-service calling method, a micro-service calling device, terminal equipment and a storage medium. The method comprises the following steps: receiving a service calling request of a target first micro service node, wherein the service calling request is used for requesting to call a target micro service, the target first micro service node is one first micro service node in a first micro service cluster, and the target micro service is provided by a second micro service node in a second micro service cluster; determining a target node address from at least one node address, wherein one node address in the at least one node address corresponds to one second micro service node in the second micro service cluster; and forwarding the service calling request to a target second micro service node corresponding to the target node address so as to trigger the target second micro service node to provide the target micro service for the target first micro service node. By adopting the embodiment of the application, the updating without stopping can be realized under the condition of not increasing extra cost.
Description
Technical Field
The present application relates to the field of computer technologies, and in particular, to a method and an apparatus for invoking a micro service, a terminal device, and a storage medium.
Background
During the use of the software/program, bugs or bugs that have not been discovered before are gradually discovered, so to repair these bugs or add new functionality to enhance the customer experience, it is important that the software/program be updated throughout its entire life cycle. The early software update is a static update, namely the update is established on the basis of stopping external services firstly, namely, the update is stopped, and the external services can be provided online again after the stop update is completed. However, the early static update form cannot meet the requirement of software systems with larger and larger sizes, the scale of the software systems is enlarged along with the enlargement of the clusters, and once the halt update mode is adopted, the service audience groups cannot use the service, so that the user experience is reduced. Therefore, in order to implement updating without stopping, the prior art proposes a scheme that two sets of clusters with the same configuration are built to provide external services, and only one cluster is allowed to perform version updating in the same time period. That is, when one of the clusters is performing application update, the other cluster independently provides services to the outside, but this solution of deploying two clusters wastes hardware resources and is costly, so how to implement non-stop update without adding extra cost becomes a problem to be solved at present.
Disclosure of Invention
The embodiment of the application provides a micro-service calling method, a micro-service calling device, a terminal device and a storage medium, and updating without stopping can be achieved under the condition that extra cost is not increased.
In a first aspect, an embodiment of the present application provides a method for invoking a micro service, where the method includes:
receiving a service calling request of a target first micro service node, wherein the service calling request is used for requesting to call a target micro service, the target first micro service node is one first micro service node in a first micro service cluster, and the target micro service is provided by a second micro service node in a second micro service cluster;
determining a target node address from at least one node address, wherein one node address of the at least one node address corresponds to a second micro service node in the second micro service cluster;
and forwarding the service calling request to a target second micro service node corresponding to the target node address so as to trigger the target second micro service node to provide the target micro service for the target first micro service node.
With reference to the first aspect, in a possible implementation manner, before determining a target node address from at least one node address according to the service invocation request, the method further includes:
and acquiring a load balancing address list, wherein the node address included in the load balancing address list is the node address of an available second micro service node in the second micro service cluster, and the load balancing address list includes the at least one node address.
With reference to the first aspect, in one possible implementation, the method further includes:
and when receiving the micro-service shutdown update notification information sent by any one of the second micro-service nodes in the second micro-service cluster, determining the any one of the second micro-service nodes as an unavailable second micro-service node and deleting the node address corresponding to the any one of the second micro-service nodes from the load balancing address list.
With reference to the first aspect, in one possible implementation, the method further includes:
when receiving the micro-service completion update notification information sent by any one of the second micro-service nodes in the second micro-service cluster, determining the any one of the second micro-service nodes as an available second micro-service node and adding a node address corresponding to the any one of the second micro-service nodes to the load balancing address list.
With reference to the first aspect, in a possible implementation manner, the at least one node address includes a first type node address and a second type node address, where a second micro service node corresponding to the first type node address is configured to provide a micro service of a first function, and a second micro service node corresponding to the second type node address is configured to provide a micro service of a second function;
the determining a target node address from at least one node address includes:
when the service calling request comprises an internal user identification, randomly determining any first type address from the first type addresses included in the at least one node address as a target node address;
and when the service calling request does not comprise the internal user identification, randomly determining any second type node address from the second type node addresses contained in the at least one node address as a target node address.
With reference to the first aspect, in a possible implementation manner, the determining a target node address from at least one node address includes:
acquiring the number of to-be-processed requests of each second micro service node corresponding to each node address;
and determining a node address corresponding to the second micro service node with the minimum number of the requests to be processed as a target node address from the at least one node address.
With reference to the first aspect, in a possible implementation manner, the determining a target node address from at least one node address includes:
acquiring the processing speed of each second micro-service node corresponding to each node address;
and determining the node address corresponding to the second micro service node with the highest processing speed as a target node address from the at least one node address.
In a second aspect, an embodiment of the present application provides a micro service invoking device, where the device includes:
a service call request receiving module, configured to receive a service call request of a target first micro service node, where the service call request is used to request to call a target micro service, the target first micro service node is a first micro service node in a first micro service cluster, and the target micro service is provided by a second micro service node included in a second micro service cluster;
a destination node address determining module, configured to determine a destination node address from at least one node address, where one node address of the at least one node address corresponds to a second micro service node in the second micro service cluster;
and the service call request sending module is used for forwarding the service call request to a target second micro service node corresponding to the target node address so as to trigger the target second micro service node to provide the target micro service for the target first micro service node.
With reference to the second aspect, in a possible implementation manner, before determining a target node address from at least one node address according to the service invocation request, the method further includes:
and acquiring a load balancing address list, wherein the node address included in the load balancing address list is the node address of an available second micro service node in the second micro service cluster, and the load balancing address list includes the at least one node address.
With reference to the second aspect, in one possible implementation, the method further includes:
and when receiving the micro-service shutdown update notification information sent by any one of the second micro-service nodes in the second micro-service cluster, determining the any one of the second micro-service nodes as an unavailable second micro-service node and deleting the node address corresponding to the any one of the second micro-service nodes from the load balancing address list.
With reference to the second aspect, in one possible implementation, the method further includes:
when receiving the micro-service completion update notification information sent by any one of the second micro-service nodes in the second micro-service cluster, determining the any one of the second micro-service nodes as an available second micro-service node and adding a node address corresponding to the any one of the second micro-service nodes to the load balancing address list.
With reference to the second aspect, in a possible implementation manner, the at least one node address includes a first type node address and a second type node address, where a second micro service node corresponding to the first type node address is configured to provide a micro service of a first function, and a second micro service node corresponding to the second type node address is configured to provide a micro service of a second function;
the determining a target node address from at least one node address includes:
when the service calling request comprises an internal user identification, randomly determining any first type address from the first type addresses included in the at least one node address as a target node address;
and when the service calling request does not comprise the internal user identification, randomly determining any second type node address from the second type node addresses contained in the at least one node address as a target node address.
With reference to the second aspect, in a possible implementation manner, the determining a target node address from at least one node address includes:
acquiring the number of to-be-processed requests of each second micro service node corresponding to each node address;
and determining a node address corresponding to the second micro service node with the minimum number of the requests to be processed as a target node address from the at least one node address.
With reference to the second aspect, in a possible implementation manner, the determining a target node address from at least one node address includes:
acquiring the processing speed of each second micro-service node corresponding to each node address;
and determining the node address corresponding to the second micro service node with the highest processing speed as a target node address from the at least one node address.
In a third aspect, an embodiment of the present application provides a terminal device, where the terminal device includes a processor and a memory, and the processor and the memory are connected to each other. The memory is configured to store a computer program that supports the terminal device to execute the method provided by the first aspect and/or any one of the possible implementation manners of the first aspect, where the computer program includes program instructions, and the processor is configured to call the program instructions to execute the method provided by the first aspect and/or any one of the possible implementation manners of the first aspect.
In a fourth aspect, the present application provides a computer-readable storage medium, which stores a computer program, where the computer program includes program instructions, and the program instructions, when executed by a processor, cause the processor to execute the method provided by the first aspect and/or any one of the possible implementation manners of the first aspect.
In the embodiment of the application, a service call request of a target first micro service node is received, wherein the service call request is used for requesting to call a target micro service, the target first micro service node is one first micro service node in a first micro service cluster, and the target micro service is provided by a second micro service node included in a second micro service cluster; determining a target node address from at least one node address, wherein one node address in the at least one node address corresponds to one second micro service node in the second micro service cluster; and forwarding the service calling request to a target second micro service node corresponding to the target node address so as to trigger the target second micro service node to provide the target micro service for the target first micro service node. By adopting the embodiment of the application, the updating without stopping can be realized under the condition of not increasing extra cost. In other words, the present application, in one cluster, by adopting the scheme of rolling update in the micro-service cluster, can realize non-stop update of a certain service or several services without increasing hardware cost (i.e. without deploying two sets of the same clusters).
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.
FIG. 1a is a schematic diagram of a system architecture of a microservice system;
fig. 1b is a schematic system architecture diagram of a microservice system provided in an embodiment of the present application;
fig. 2a is a schematic flowchart of a method for invoking a micro service according to an embodiment of the present application;
fig. 2b is a schematic view of a scene of real-time refreshing of a load balancing address list according to an embodiment of the present application;
fig. 2c is a schematic view of an application scenario of gray scale publishing provided in an embodiment of the present application;
fig. 3 is a schematic structural diagram of a micro service invocation device provided in an embodiment of the present application;
fig. 4 is another schematic structural diagram of a micro service invocation device provided in an embodiment of the present application;
fig. 5 is a schematic structural diagram of a terminal device according to an embodiment of the present application.
Detailed Description
The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
Referring to fig. 1a, fig. 1a is a schematic diagram of a system architecture of a microservice system. Generally, the microservice system includes three main roles, which are: a service provider (hereinafter simply referred to as provider), a service consumer (hereinafter simply referred to as consumer), and a registry. As shown in fig. 1a, when activated, the provider and the consumer may register their own services with the registry and send their Internet Protocol (IP) addresses to the registry, which records them. Thus, when a consumer needs to invoke a service remotely, the registry can be requested for the IP address where the service is located. Furthermore, the consumer can select one IP address from the IP addresses and send a service calling request to the provider corresponding to the IP address so as to realize micro-service calling. It should be understood that the service provider and the service consumer are opposite, e.g., one system a may be a service provider (i.e., system a is a service provider and system B is a service consumer) with respect to system B and a service consumer (i.e., system a is a service consumer and system C is a service provider) with respect to system C. Alternatively, system a may also be interoperable with system B, i.e., system a is both the service provider of system B and the service consumer of system B, and accordingly system B is both the service provider of system a and the service consumer of system a.
It should be understood that computer clustering techniques collectively implement the capabilities of a system to provide uninterrupted service, reduce single point stress, perform high performance computing, etc., by organizing some computer hardware and software. Implementation by a cluster of computers is a cheaper way than implementing system performance by boosting the performance of stand-alone hardware. The stand-alone nodes in a computer cluster may be low performance devices, and even the individual nodes may differ in performance. Through a load balancing algorithm, the capacities of all nodes are distinguished, the uniform distribution of tasks is realized, the overall processing efficiency of the system is improved, and the condition of overlarge single-point pressure is reduced. In the micro service, a complete system is divided into independent subsystems according to service functions, and each subsystem is called as a service in the micro service structure. These subsystems can run independently in a web container, and communicate with each other by means of Remote Procedure Call Protocol (RPC). In order to ensure high availability of each microservice, one microservice may be implemented by multiple nodes, that is, one microservice corresponds to one microservice cluster. Each node included in the microservice cluster can independently complete a microservice call or run.
For example, assume that an online mall needs to be developed. According to the idea of microservices, we need to split into a plurality of independent services according to functional modules, such as: user services, product services, order services, background management services, data analysis services, and the like. The services are independent items and can be operated independently. If the various services have dependency relationships, the services can be called by means of RPC. For a certain service, for example, "user service", in order to implement high availability of "user service", a plurality of nodes (i.e., user service clusters) may be deployed for "user service", where each node in a user service cluster may implement a function of the user service independently. Generally, user services include user login and authentication, among others. For another example, for "order service", to implement high availability of "order service", a plurality of nodes (i.e., order service clusters) may be deployed for "order service", wherein each node in the order service cluster may independently perform a functional implementation of the order service. It is understood that when order service (for example, order placing of goods) is used, user service is usually required to be invoked (for example, confirmation of user identity information before order placing, etc.), and therefore, there is a dependency relationship between the user service and the order service, that is, the order service is required, and therefore, when a certain order service node needs to invoke the user service, one user service node can be selected from the user service cluster to provide the user service. That is, when a service is invoked, the service consumer may select a service provider from the list of service provider addresses obtained from the registry.
It will be appreciated that the network is stressed if a list of available remote services is pulled from the registry once for each remote invocation. Based on this, the registry adopts a cache mechanism, and as such, when there is a node in a micro-service cluster as a service provider that is performing a shutdown update, since the registry usually needs at least about 90s to refresh a cache, during this time, since the registry and an upstream caller (i.e. a service consumer) cannot know that the service is offline (i.e. the service is unavailable) for the first time, there is a case that the service consumer may send a user request to the node being updated if the user request comes in. It should be appreciated that the node being updated may fail this service invocation due to the unavailability of the service. Particularly, in a consumption finance (hereinafter referred to as money-eliminating) scene, a transaction failure may be caused by a service invocation failure, user experience is affected, financial loss may be caused, and the current business requirement of money-eliminating cannot be met.
Based on this, the present application proposes a micro service system, which adds a new role, namely a proxy server, to the existing micro service system. Typically, each service provider may correspond to a proxy server. Specifically, please refer to fig. 1b, where fig. 1b is a schematic system architecture diagram of a microservice system according to an embodiment of the present application. The micro-service system mainly comprises four roles, namely: service providers, service consumers, registries, and proxy servers. As shown in fig. 1b, the provider and the consumer can register their own services with the registry and send their Internet Protocol (IP) addresses to the registry, which records them when they start. Meanwhile, the proxy server also sends the corresponding IP address to the registry and informs the registry of which service the proxy server provides proxy service for. The proxy server shown in fig. 1b is a proxy server corresponding to a service provider. In the embodiment of the application, the proxy server is a server which builds an OpenResty platform. It should be appreciated that the proxy server of the present application may update the data state in the server in real time.
Generally, a microservice cluster (e.g., system B) may correspond to a proxy server, in other words, the proxy server may be used to provide proxy services for system B. Optionally, the system B may also correspond to a plurality of proxy servers (i.e. a proxy server cluster), that is, the proxy server cluster is used to provide proxy services for the system B. It should be appreciated that high availability of proxy servers may be achieved when one microservice cluster may correspond to one proxy server cluster. That is, when one proxy server in the proxy server cluster crashes, the proxy service can be continuously provided for the system B by other proxy servers in the proxy server cluster. For convenience of description, the following embodiments of the present application take an example in which one micro service cluster corresponds to one proxy server.
It should be understood that when the micro service system provided in the embodiment of the present application works, when a consumer needs to remotely invoke a certain service, the IP address where the service is located and the corresponding proxy server address may be requested from the registry. Furthermore, the consumer can send a service calling request to the proxy server corresponding to the proxy server address, so that the proxy server selects one IP address from the IP addresses capable of providing the service, and forwards the service calling request sent by the consumer to the provider corresponding to the IP address, so as to realize calling between the micro-services. It should be understood that, since the proxy server can dynamically update the data state in real time, when a node is performing a shutdown update in a micro service cluster as a service provider, the node can send a shutdown update notification message to the corresponding proxy server to enable the proxy server to update the stored IP address corresponding to the available node in real time. Thus, when a subsequent request by a user comes in, the proxy server will only send the request to the available nodes, and will not forward the request to the node that is being updated down.
The micro-service calling method provided by the embodiment of the application can be suitable for building or installing the proxy server of the OpenResty platform. Specifically, in the method in the embodiment of the present application, a proxy server receives a service invocation request of a target first micro service node, where the service invocation request is used to request invocation of a target micro service, the target first micro service node is one first micro service node in a first micro service cluster, and the target micro service is provided by a second micro service node included in a second micro service cluster; the proxy server can determine a target node address from at least one node address, wherein one node address in the at least one node address corresponds to one second micro service node in the second micro service cluster; and forwarding the service calling request to a target second micro service node corresponding to the target node address so as to trigger the target second micro service node to provide the target micro service for the target first micro service node. By adopting the embodiment of the application, the updating without stopping can be realized under the condition of not increasing extra cost. In other words, the present application, in one cluster, by adopting the scheme of rolling update in the micro-service cluster, can realize non-stop update of a certain service or several services without increasing hardware cost (i.e. without deploying two sets of the same clusters). That is to say, when a micro service node in the micro service cluster needs to be updated, the address of the micro service node only needs to be removed from the load balancing list of the openty platform, and the shutdown publishing can be performed after the request processing in the micro service node is completed.
The method and the related apparatus provided by the embodiments of the present application will be described in detail with reference to fig. 2a to 5, respectively.
Referring to fig. 2a, fig. 2a is a schematic flowchart of a micro service invocation method provided in the embodiment of the present application. The method provided by the embodiment of the application can comprise the following steps S101 to S103:
s101, the proxy server receives a service calling request of a target first micro service node.
In some possible embodiments, the proxy server receives a service invocation request of the target first microservice node, the service invocation request requesting invocation of the target microservice. The target first micro service node is one first micro service node in the first micro service cluster, and the target micro service is provided by a second micro service node in the second micro service cluster. Generally, the first micro service cluster includes a plurality of first micro service nodes, and the second micro service cluster includes a plurality of second micro service nodes. Here, the plurality of first micro service nodes are at least two first micro service nodes, and the plurality of second micro service nodes are also at least two second micro service nodes. The proxy server is a proxy server corresponding to the second micro-service cluster and is used for forwarding any received service invoking request for invoking the second micro-service to an available second micro-service node in the second micro-service cluster.
And the target first micro service node is the first micro service node which initiates the service calling request. For example, if the node X1 in the first micro service cluster X is the node initiating the service invocation request this time, the target first micro service node is the node X1, and if the node X2 in the first micro service cluster X is the node initiating the service invocation request this time, the target first micro service node is the node X2.
Each first micro service node can independently provide a first micro service, and each second micro service node can independently provide a second micro service. Generally, since one microservice is only interested in completing one task and well completing the task, and some functions in the system often need to be cooperatively realized by a plurality of microservices, assuming that there is a dependency relationship between a first microservice and a second microservice, a first microservice node can cooperatively realize a certain function by calling a second microservice node. It should be understood that a complete system may be comprised of multiple microservices. That is, a complete system may include a plurality of microservice clusters, for example, the microservice clusters may include a first microservice cluster, a second microservice cluster, a third microservice cluster, a fourth microservice cluster, and so on, without limitation. The micro-services provided by each micro-service cluster are different, for example, a first micro-service cluster is used for providing a first micro-service, a second micro-service cluster is used for providing a second micro-service, a third micro-service cluster is used for providing a third micro-service, a fourth micro-service cluster is used for providing a fourth micro-service, and the like. It should be understood that each node in the microservice cluster may be any form of computing device, such as a server, a terminal, etc., without limitation.
The target micro service is the micro service requested to be called by the service calling request. For example, if the target microservice is a request to invoke a second microservice node in a second microservice cluster, the target microservice is the second microservice. And if the target micro service is a request for calling a third micro service node in the third micro service cluster, the target micro service provides a third micro service for the third micro service node.
S102, the proxy server determines a target node address from at least one node address.
In some possible embodiments, the proxy server may determine the target node address from the at least one node address according to the service invocation request by receiving the service invocation request. Wherein one node address of the at least one node address corresponds to one second microservice node in the second microservice cluster. It should be appreciated that the at least one node address is included in a load balancing address list. And the node addresses included in the load balancing address list are all the node addresses of the available second micro service nodes in the second micro service cluster. Here, the available second microservice node is understood to be a second microservice node in the second microservice cluster that is capable of providing a service, i.e. a second microservice node in an operational state.
The proxy server can dynamically refresh the node address of the available second micro service node in the load balancing address list in real time. Specifically, when receiving micro-service shutdown update notification information sent by any one of the second micro-service nodes in the second micro-service cluster, determining the any one of the second micro-service nodes as an unavailable second micro-service node and deleting a node address corresponding to the any one of the second micro-service nodes from the load balancing address list. Correspondingly, when receiving micro-service completion update notification information sent by any one of the second micro-service nodes in the second micro-service cluster, determining any one of the second micro-service nodes as an available second micro-service node and adding a node address corresponding to any one of the second micro-service nodes to the load balancing address list.
Referring to fig. 2b, fig. 2b is a schematic view of a scene of real-time refreshing of a load balancing address list according to an embodiment of the present disclosure. As shown in fig. 2B, assume that system a is a service consumer, system B is a service provider, and the proxy server is a corresponding proxy server of system B. The system a includes 3 nodes, which are respectively a1, a2 and a3, and the 3 nodes a1, a2 and a3 can independently provide services corresponding to the system a. The system B also includes 3 nodes, namely, nodes B1, B2 and B3, and the 3 nodes B1, B2 and B3 can independently provide services corresponding to the system B. In the beginning, 3 nodes in the system B are all in a normal operating state, that is, the nodes B1, B2, and B3 are all available microserver nodes, so the load balancing address list of the proxy server includes the address add1 corresponding to the node B1, the address add2 corresponding to the node B2, and the address add3 corresponding to the node B3. At a later time, assuming that the system B is to be updated, each node in the system B may be updated in a rolling manner so as not to affect the normal use of the service provided by the user. That is, only part of the nodes in the system B are updated each time, so as to ensure that most of the nodes in the micro-service cluster always remain available. For example, only one node is updated at a time, assuming node b1 is about to enter the micro-service down update state, node b1 may send a micro-service down update notification message to the proxy server indicating that node b1 is unable to provide service because it is about to enter the down update state. As shown in fig. 2b, when the proxy server receives the micro-service outage update notification message, the node address add1 corresponding to the node b1 may be deleted from the load balancing address list to ensure that new requests are no longer forwarded to the address add 1. Generally, when the node b1 finishes processing the request of the inventory, the shutdown update can be performed. When the node B1 is in the process of shutdown update, and if a certain node (for example, the node a1) in the system a needs to call the service in the system B, the node a1 may send a service call request to the proxy server, so that the proxy server may randomly select an address, for example, the address add2, from the address add2 and the address add3 included in the load balancing address list, and forward the service call request to the node B2 corresponding to the address add 2. It should be appreciated that when the update is completed by the node b1 after a period of time, the node b1 may send micro-service completion update notification information to the proxy server indicating that the node b2 may re-accept the user request to service the user. As shown in fig. 2b, when the proxy server receives the micro service completion update notification information sent by the node b1, the node b1 may be determined as an available second micro service node and a node address corresponding to any second micro service node may be added to the load balancing address list. It can be seen that the address of the node that is performing the version update and cannot provide the second micro-service is not included in the load balancing address list. It should be understood that, when the node B1 completes the update, the node B2 or the node B3 may enter the micro-service shutdown update state, where the process that the node B2 or the node B3 enters the micro-service shutdown update refers to the process that the node B1 enters the micro-service shutdown update, which is not described herein again, until after each node in the system B completes the update, the system B completes the update of the service.
In some possible embodiments, to implement gray scale publishing, a small number of users may be selected to verify the new function in the production environment and user feedback and satisfaction may be gathered to determine whether the function is to be targeted to all users during the node rolling update process. That is to say, at least one node address included in the load balancing address list may include a first type node address and a second type node address, where a second micro service node corresponding to the first type node address is used to provide a micro service of the first function, and a second micro service node corresponding to the second type node address is used to provide a micro service of the second function. It should be understood that the first function may be an enhanced version of the second function (i.e., a second function with better performance) compared to the second function, for example, if the second micro service cluster is a micro service cluster providing user services (i.e., user authentication), if the nodes in the second micro service cluster can provide 1s for authentication through the password before updating, and only 0.5s is needed for authentication through the password after updating, then the password authentication taking 1s is the second function, and the password authentication taking 0.5s is the first function. Optionally, the updated first function may further include a second function and a third function. For example, assuming that the second micro service cluster is a micro service cluster providing user service (i.e., user authentication), assuming that a node in the second micro service cluster can provide authentication by a password before updating, the node can be authenticated by the password after updating, and can also be authenticated by a fingerprint, the password authentication is a second function, which can be both the password authentication and the fingerprint authentication as a first function.
When the service calling request comprises the internal user identification, any first type address can be randomly determined from the first type addresses included in at least one node address to serve as a target node address. And when the service calling request does not comprise the internal user identification, randomly determining any second type node address from the second type node addresses included in at least one node address as a target node address. By the method, the internal test user can experience the new function, and the non-internal test user can still normally use the original function. Optionally, when the service invocation request includes the internal test user identifier, the first type address corresponding to the second micro service node with the fastest node processing speed or the fewest number of requests to be processed may be selected from the first type addresses included in the at least one node address as the target node address. And when the service calling request does not comprise the internal test user identification, selecting a second type node address corresponding to a second micro service node with the highest node processing speed or the least number of requests to be processed from the second type node addresses comprised by at least one node address as a target node address.
Referring to fig. 2c, fig. 2c is a schematic view of an application scenario of gray scale publishing provided in the embodiment of the present application. As shown in fig. 2c, assume that system a is a service consumer, system B is a service provider, and the proxy server is a corresponding proxy server of system B. The system a includes 3 nodes, which are respectively a1, a2 and a 3. The system B also includes 3 nodes, which are respectively a node B1, a node B2 and a node B3, where the node B1 in the system B is a node after update, and the nodes B2 and B3 are nodes before update, an address add1 corresponding to a node B1 in the load balancing address list is a first type node address, and an address add2 corresponding to a node B2 and an address add3 corresponding to a node B3 are second type node addresses. Assuming that the node a2 in the system a sends a service invocation request to the proxy server at a certain time, wherein, assuming that the service invocation request includes the internal user identifier, when the proxy server receives the service invocation request, it can be determined whether the service invocation request includes the internal user identifier, and if so, the service invocation request is forwarded to the node corresponding to the first type node address, that is, the node b1 corresponding to the add 1.
Optionally, in some possible embodiments, if a scheme of gray scale publishing is not used, the target node address may be an address randomly selected from the load balancing address list, or may also be an address of a node that is relatively idle (for example, has the smallest number of requests to be processed) selected from the load balancing address list according to a resource occupation condition of the current second micro service cluster, or the target node address is an address of a node with the highest processing speed included in the load balancing address list, or the target node address is an address of a node with a smaller number of requests to be processed and a faster processing speed, or the target node address may also be an address specified from the load balancing address list, which is determined specifically according to an actual application scenario, and is not limited herein.
S103, the proxy server forwards the service calling request to a target second micro service node corresponding to the target node address.
In some possible embodiments, the target second micro service node may be triggered to provide the target micro service for the target first micro service node by forwarding the service invocation request to the target second micro service node corresponding to the target node address.
In the embodiment of the application, a service call request of a target first micro service node is received, wherein the service call request is used for requesting to call a target micro service, the target first micro service node is one first micro service node in a first micro service cluster, and the target micro service is provided by a second micro service node included in a second micro service cluster; determining a target node address from at least one node address, wherein one node address in the at least one node address corresponds to one second micro service node in the second micro service cluster; and forwarding the service calling request to a target second micro service node corresponding to the target node address so as to trigger the target second micro service node to provide the target micro service for the target first micro service node. By adopting the embodiment of the application, the updating without stopping can be realized under the condition of not increasing extra cost. In other words, in a large cluster, the scheme of rolling update of the nodes included in the micro-service cluster is adopted, so that non-stop update of a certain service or a plurality of services can be realized on the premise of not increasing hardware cost (i.e. not deploying two sets of same clusters). That is, when a micro service node in the micro service cluster needs to be updated, it is only necessary to remove the address of the micro service node from the load balancing list of the openResty platform, so as to ensure that a new request is not forwarded to the IP address any more, and after the micro service node completes its version, the address of the micro service node is reconfigured into the load balancing list of the openResty platform, so as to receive the user request again. The rolling update in the micro service cluster can realize non-stop update and save hardware cost.
Referring to fig. 3, fig. 3 is a schematic structural diagram of a micro service invocation device according to an embodiment of the present application. The micro-service calling device provided by the embodiment of the application comprises:
a service invocation request receiving module 31, configured to receive a service invocation request of a target first micro service node, where the service invocation request is used to request invocation of a target micro service, the target first micro service node is a first micro service node in a first micro service cluster, and the target micro service is provided by a second micro service node included in a second micro service cluster;
a destination node address determining module 32, configured to determine a destination node address from at least one node address, where one node address of the at least one node address corresponds to one second micro service node in the second micro service cluster;
a service invocation request sending module 33, configured to forward the service invocation request to a target second micro service node corresponding to the target node address, so as to trigger the target second micro service node to provide the target micro service for the target first micro service node.
Referring to fig. 4, fig. 4 is another schematic structural diagram of a micro service invocation device according to an embodiment of the present application.
In some possible embodiments, the apparatus further comprises:
an address list obtaining module, configured to obtain a load balancing address list, where a node address included in the load balancing address list is a node address of an available second micro service node in the second micro service cluster, and the load balancing address list includes the at least one node address.
In some possible embodiments, the apparatus further includes an address list updating module 34 configured to:
and when receiving the micro-service shutdown update notification information sent by any one of the second micro-service nodes in the second micro-service cluster, determining the any one of the second micro-service nodes as an unavailable second micro-service node and deleting the node address corresponding to the any one of the second micro-service nodes from the load balancing address list.
In some possible embodiments, the address list updating module 34 is further configured to:
when receiving the micro-service completion update notification information sent by any one of the second micro-service nodes in the second micro-service cluster, determining the any one of the second micro-service nodes as an available second micro-service node and adding a node address corresponding to the any one of the second micro-service nodes to the load balancing address list.
In some possible embodiments, the at least one node address includes a first type node address and a second type node address, where a second micro service node corresponding to the first type node address is used to provide a micro service of a first function, and a second micro service node corresponding to the second type node address is used to provide a micro service of a second function;
the target node address determining module 32 includes a gray scale distribution address determining unit 321, and the gray scale distribution address determining unit 321 includes:
a first address determining subunit 3210, configured to randomly determine, when the service invocation request includes an internal user identifier, any one of first type addresses included in the at least one node address as a target node address from the first type addresses;
the second address determining subunit 3211 is configured to randomly determine, when the service invocation request does not include an internal subscriber identity, any second-type node address from the second-type node addresses included in the at least one node address as a target node address.
In some possible embodiments, the target node address determining module further includes a first determining unit 322, where the first determining unit 322 includes:
a pending request quantity determining subunit 3220, configured to obtain a pending request quantity of each second microservice node corresponding to each node address;
the first node address determining subunit 3221 is configured to determine, from the at least one node address, a node address corresponding to the second micro service node with the smallest number of requests to be processed as a target node address.
In some possible embodiments, the target node address determining module further includes a second determining unit 323, and the second determining unit 323 includes:
a processing speed determination subunit 3230, configured to obtain a processing speed of each second micro service node corresponding to each node address;
and the second node address determination subunit 3231 element is used for determining a node address corresponding to the second micro service node with the highest processing speed from the at least one node address as a target node address.
Referring to fig. 5, fig. 5 is a schematic structural diagram of a terminal device provided in an embodiment of the present application. As shown in fig. 5, the terminal device in this embodiment may include: one or more processors 401, memory 402, and a transceiver 403. The processor 401, memory 402 and transceiver 403 are connected by a bus 404. The memory 402 is used for storing a computer program comprising program instructions, and the processor 401 is used for executing the program instructions stored by the memory 402, in particular:
the transceiver 403 is configured to receive a service invocation request of a target first micro service node, where the service invocation request is used to request invocation of a target micro service, the target first micro service node is a first micro service node in a first micro service cluster, and the target micro service is provided by a second micro service node included in a second micro service cluster;
the processor 401 is configured to determine a target node address from at least one node address, where one node address of the at least one node address corresponds to a second micro service node in the second micro service cluster;
the transceiver 403 is further configured to forward the service invocation request to a target second micro service node corresponding to the target node address, so as to trigger the target second micro service node to provide the target micro service for the target first micro service node.
In some possible embodiments, the processor 401 is configured to:
and acquiring a load balancing address list, wherein the node address included in the load balancing address list is the node address of an available second micro service node in the second micro service cluster, and the load balancing address list includes the at least one node address.
In some possible embodiments, the processor 401 is configured to:
and when receiving the micro-service shutdown update notification information sent by any one of the second micro-service nodes in the second micro-service cluster, determining the any one of the second micro-service nodes as an unavailable second micro-service node and deleting the node address corresponding to the any one of the second micro-service nodes from the load balancing address list.
In some possible embodiments, the processor 401 is configured to:
when receiving the micro-service completion update notification information sent by any one of the second micro-service nodes in the second micro-service cluster, determining the any one of the second micro-service nodes as an available second micro-service node and adding a node address corresponding to the any one of the second micro-service nodes to the load balancing address list.
In some possible embodiments, the at least one node address includes a first type node address and a second type node address, where a second micro service node corresponding to the first type node address is used to provide a micro service of a first function, and a second micro service node corresponding to the second type node address is used to provide a micro service of a second function;
the processor 401 is configured to:
when the service calling request comprises an internal user identification, randomly determining any first type address from the first type addresses included in the at least one node address as a target node address;
and when the service calling request does not comprise the internal user identification, randomly determining any second type node address from the second type node addresses contained in the at least one node address as a target node address.
In some possible embodiments, the processor 401 is configured to:
acquiring the number of to-be-processed requests of each second micro service node corresponding to each node address;
and determining a node address corresponding to the second micro service node with the minimum number of the requests to be processed as a target node address from the at least one node address.
In some possible embodiments, the processor 401 is configured to:
acquiring the processing speed of each second micro-service node corresponding to each node address;
and determining the node address corresponding to the second micro service node with the highest processing speed as a target node address from the at least one node address.
It should be appreciated that in some possible implementations, the processor 401 may be a Central Processing Unit (CPU), and the processor may be other general purpose processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, and the like. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The memory 402 may include both read-only memory and random access memory, and provides instructions and data to the processor 401. A portion of the memory 402 may also include non-volatile random access memory. For example, the memory 402 may also store device type information.
In a specific implementation, the terminal device may execute the implementation manners provided in the steps in fig. 2a to fig. 2c through the built-in functional modules, which may specifically refer to the implementation manners provided in the steps, and are not described herein again.
An embodiment of the present application further provides a computer-readable storage medium, where a computer program is stored in the computer-readable storage medium, where the computer program includes program instructions, and when the program instructions are executed by a processor, the method for invoking the micro-services provided in each step in fig. 2a to 2c is implemented.
The computer-readable storage medium may be the micro service invocation device provided in any of the foregoing embodiments or an internal storage unit of the terminal device, such as a hard disk or a memory of an electronic device. The computer readable storage medium may also be an external storage device of the electronic device, such as a plug-in hard disk, a Smart Memory Card (SMC), a Secure Digital (SD) card, a flash card (flash card), and the like, which are provided on the electronic device. Further, the computer readable storage medium may also include both an internal storage unit and an external storage device of the electronic device. The computer-readable storage medium is used for storing the computer program and other programs and data required by the electronic device. The computer readable storage medium may also be used to temporarily store data that has been output or is to be output.
The terms "first", "second", "third", "fourth", and the like in the claims and in the description and drawings of the present application are used for distinguishing between different objects and not for describing a particular order. Furthermore, the terms "include" and "have," as well as any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, article, or apparatus that comprises a list of steps or elements is not limited to only those steps or elements listed, but may alternatively include other steps or elements not listed, or inherent to such process, method, article, or apparatus.
Reference herein to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the application. The appearances of the phrase in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. It is explicitly and implicitly understood by one skilled in the art that the embodiments described herein can be combined with other embodiments. The term "and/or" as used in this specification and the appended claims refers to and includes any and all possible combinations of one or more of the associated listed items. Those of ordinary skill in the art will appreciate that the elements and algorithm steps of the examples described in connection with the embodiments disclosed herein may be embodied in electronic hardware, computer software, or combinations of both, and that the components and steps of the examples have been described in a functional general in the foregoing description for the purpose of illustrating clearly the interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.
The method and the related apparatus provided by the embodiments of the present application are described with reference to the flowchart and/or the structural diagram of the method provided by the embodiments of the present application, and each flow and/or block of the flowchart and/or the structural diagram of the method, and the combination of the flow and/or block in the flowchart and/or the block diagram can be specifically implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block or blocks of the block diagram. These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block or blocks of the block diagram. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block or blocks.
Claims (10)
1. A method for invoking a microservice, the method comprising:
receiving a service calling request of a target first micro service node, wherein the service calling request is used for requesting to call a target micro service, the target first micro service node is one first micro service node in a first micro service cluster, and the target micro service is provided by a second micro service node in a second micro service cluster;
determining a target node address from at least one node address, wherein one node address of the at least one node address corresponds to one second micro service node in the second micro service cluster;
and forwarding the service calling request to a target second micro service node corresponding to the target node address so as to trigger the target second micro service node to provide the target micro service for the target first micro service node.
2. The method of claim 1, wherein before determining the destination node address from the at least one node address based on the service invocation request, the method further comprises:
and acquiring a load balancing address list, wherein the node address included in the load balancing address list is the node address of an available second micro service node in the second micro service cluster, and the load balancing address list includes the at least one node address.
3. The method of claim 2, further comprising:
when receiving micro-service shutdown update notification information sent by any one of the second micro-service nodes in the second micro-service cluster, determining the any one of the second micro-service nodes as an unavailable second micro-service node and deleting a node address corresponding to the any one of the second micro-service nodes from the load balancing address list.
4. The method of claim 2, further comprising:
when receiving micro-service completion update notification information sent by any one of the second micro-service nodes in the second micro-service cluster, determining the any one of the second micro-service nodes as an available second micro-service node and adding a node address corresponding to the any one of the second micro-service nodes to the load balancing address list.
5. The method according to claim 1, wherein the at least one node address includes a first type node address and a second type node address, wherein a second micro service node corresponding to the first type node address is used for providing a micro service of a first function, and a second micro service node corresponding to the second type node address is used for providing a micro service of a second function;
the determining the target node address from the at least one node address includes:
when the service calling request comprises an internal test user identifier, randomly determining any first type address from the first type addresses included in the at least one node address as a target node address;
and when the service calling request does not comprise the internal test user identification, randomly determining any second type node address as a target node address from the second type node addresses comprised by the at least one node address.
6. The method of claim 1, wherein determining the destination node address from the at least one node address comprises:
acquiring the number of to-be-processed requests of each second micro service node corresponding to each node address;
and determining a node address corresponding to the second micro service node with the minimum number of the requests to be processed as a target node address from the at least one node address.
7. The method of claim 1, wherein determining the destination node address from the at least one node address comprises:
acquiring the processing speed of each second micro-service node corresponding to each node address;
and determining a node address corresponding to the second micro service node with the highest processing speed as a target node address from the at least one node address.
8. An apparatus for micro-service invocation, the apparatus comprising:
the system comprises a service calling request receiving module, a service calling request receiving module and a service calling request sending module, wherein the service calling request is used for requesting to call a target micro service, the target first micro service node is one first micro service node in a first micro service cluster, and the target micro service is provided by a second micro service node in a second micro service cluster;
a target node address determining module, configured to determine a target node address from at least one node address, where one node address of the at least one node address corresponds to one second micro service node in the second micro service cluster;
and the service calling request sending module is used for forwarding the service calling request to a target second micro service node corresponding to the target node address so as to trigger the target second micro service node to provide the target micro service for the target first micro service node.
9. A terminal device, comprising a processor and a memory, the processor and the memory being interconnected;
the memory for storing a computer program comprising program instructions, the processor being configured to invoke the program instructions to perform the method of any of claims 1-7.
10. A computer-readable storage medium, characterized in that the computer-readable storage medium stores a computer program comprising program instructions that, when executed by a processor, cause the processor to carry out the method according to any one of claims 1-7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011292776.7A CN112433863A (en) | 2020-11-18 | 2020-11-18 | Micro-service calling method and device, terminal equipment and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011292776.7A CN112433863A (en) | 2020-11-18 | 2020-11-18 | Micro-service calling method and device, terminal equipment and storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112433863A true CN112433863A (en) | 2021-03-02 |
Family
ID=74693172
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011292776.7A Pending CN112433863A (en) | 2020-11-18 | 2020-11-18 | Micro-service calling method and device, terminal equipment and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112433863A (en) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114416224A (en) * | 2022-03-25 | 2022-04-29 | 共道网络科技有限公司 | Method and device for calling micro service under multi-micro service environment |
| CN114422602A (en) * | 2021-12-29 | 2022-04-29 | 中国电信股份有限公司 | Method and device for calling micro-service based on K8S cluster, electronic equipment and storage medium |
| CN114785798A (en) * | 2022-04-08 | 2022-07-22 | 南方电网数字电网研究院有限公司 | Node calling method and device, computer equipment and storage medium |
| CN115174657A (en) * | 2022-06-13 | 2022-10-11 | 青岛中科曙光科技服务有限公司 | Micro-service application calling method and device, computer equipment and storage medium |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102821000A (en) * | 2012-09-14 | 2012-12-12 | 乐视网信息技术（北京）股份有限公司 | Method for improving usability of PaaS platform |
| US20170222950A1 (en) * | 2014-04-17 | 2017-08-03 | Go Daddy Operating Company, LLC | Allocating and accessing hosting server resources via continuous resource availability updates |
| CN108681461A (en) * | 2018-05-07 | 2018-10-19 | 广东电网有限责任公司 | A kind of clustered software system does not shut down newer method, system and relevant apparatus |
| CN109120717A (en) * | 2018-09-26 | 2019-01-01 | 中国平安人寿保险股份有限公司 | Reverse proxy method, apparatus and storage medium, distributed system |
| CN110795120A (en) * | 2019-09-24 | 2020-02-14 | 万翼科技有限公司 | Software upgrading method and related device |
-
2020
- 2020-11-18 CN CN202011292776.7A patent/CN112433863A/en active Pending
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102821000A (en) * | 2012-09-14 | 2012-12-12 | 乐视网信息技术（北京）股份有限公司 | Method for improving usability of PaaS platform |
| US20170222950A1 (en) * | 2014-04-17 | 2017-08-03 | Go Daddy Operating Company, LLC | Allocating and accessing hosting server resources via continuous resource availability updates |
| CN108681461A (en) * | 2018-05-07 | 2018-10-19 | 广东电网有限责任公司 | A kind of clustered software system does not shut down newer method, system and relevant apparatus |
| CN109120717A (en) * | 2018-09-26 | 2019-01-01 | 中国平安人寿保险股份有限公司 | Reverse proxy method, apparatus and storage medium, distributed system |
| CN110795120A (en) * | 2019-09-24 | 2020-02-14 | 万翼科技有限公司 | Software upgrading method and related device |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114422602A (en) * | 2021-12-29 | 2022-04-29 | 中国电信股份有限公司 | Method and device for calling micro-service based on K8S cluster, electronic equipment and storage medium |
| CN114416224A (en) * | 2022-03-25 | 2022-04-29 | 共道网络科技有限公司 | Method and device for calling micro service under multi-micro service environment |
| CN114785798A (en) * | 2022-04-08 | 2022-07-22 | 南方电网数字电网研究院有限公司 | Node calling method and device, computer equipment and storage medium |
| CN115174657A (en) * | 2022-06-13 | 2022-10-11 | 青岛中科曙光科技服务有限公司 | Micro-service application calling method and device, computer equipment and storage medium |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112000348A (en) | Control method and device for service gray release and computer equipment | |
| CN112433863A (en) | Micro-service calling method and device, terminal equipment and storage medium | |
| US10033816B2 (en) | Workflow service using state transfer | |
| CN115328663B (en) | Method, device, equipment and storage medium for scheduling resources based on PaaS platform | |
| CN112118565A (en) | Multi-tenant service gray level publishing method and device, computer equipment and storage medium | |
| US20200314168A1 (en) | Distributed code execution involving a serverless computing infrastructure | |
| US9766927B1 (en) | Data flow management in processing workflows | |
| CN109783151B (en) | Method and device for rule change | |
| CN111221550B (en) | Rule updating method and device for streaming computing and streaming computing system | |
| CN113220433B (en) | Agent program operation management method and system | |
| CN111200606A (en) | Deep learning model task processing method, system, server and storage medium | |
| CN112787999A (en) | Cross-chain calling method, device, system and computer readable storage medium | |
| CN115757611A (en) | Big data cluster switching method and device, electronic equipment and storage medium | |
| US10348814B1 (en) | Efficient storage reclamation for system components managing storage | |
| US20200310828A1 (en) | Method, function manager and arrangement for handling function calls | |
| US10176059B2 (en) | Managing server processes with proxy files | |
| CN111240760B (en) | Application publishing method, system, storage medium and equipment based on registry | |
| US12026562B2 (en) | Industry opinionated API managed service | |
| CN110545328A (en) | Non-invasive service function expansion enhancing method and device and server | |
| CN112565340B (en) | Service scheduling method, device, computer system and medium for distributed application | |
| US20220276901A1 (en) | Batch processing management | |
| CN110324425B (en) | Hybrid cloud transaction route processing method and device | |
| CN115686813A (en) | Resource scheduling method and device, electronic equipment and storage medium | |
| CN110321250B (en) | Disaster recovery method and device for application | |
| CN111258873A (en) | Test method and device |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| WD01 | Invention patent application deemed withdrawn after publication |
Application publication date: 20210302 |