Cross-service request processing method, device, equipment and system

Abstract

The present application provides a cross-service request processing method, device, equipment and system, which relates to communication technology; wherein the method is applied to a microservice architecture; the microservice architecture includes a first microservice, a second microservice, and a third microservice; the second microservice includes a sub-microservice A and a sub-microservice B, and the method includes: when any sub-instance of sub-microservice A receives a cross-service request transmitted from any first target instance in the first microservice, the cross-service request is routed to the second target instance in sub-microservice B according to the business keyword of the cross-service request; the target channel between the second target instance and the third microservice is obtained, and the cross-service request is sent to the third target instance corresponding to the target channel through the target channel, so that the third target instance processes the cross-service request. The method of the present application can achieve session state consistency and continuity, while ensuring high availability and high concurrency of the system.

Description

Technical Field

[0001] The present application relates to communication technology, and in particular to a method, apparatus, device and system for processing cross-service requests. Background Art

[0002] In modern system construction, microservice architecture is widely adopted due to its flexibility and scalability. Specifically, microservice architecture includes multiple independent microservices that work together to complete complex business operations.

[0003] It is understandable that in a microservice architecture, since services are independent, it becomes a challenge to maintain the consistency and continuity of session states in cross-service calls when processing cross-service requests. In the known technology, complex session management mechanisms are usually relied on when processing cross-service requests, or performance is sacrificed to achieve consistency.

[0004] However, achieving session state consistency and continuity through the above method is often difficult to cope with high concurrency and high availability requirements, which affects system performance and reliability. Summary of the invention

[0005] The present application provides a cross-service request processing method, apparatus, device and system for achieving session consistency and continuity across service requests while meeting the high concurrency and high availability requirements of the system, thereby effectively ensuring system performance and reliability.

[0006] In a first aspect, the present application provides a cross-service request processing method, which is applied to a microservice architecture; the microservice architecture includes a first microservice, a second microservice, and a third microservice, wherein the second microservice includes a sub-microservice A and a sub-microservice B, and the first microservice accesses the sub-microservice A through a stateless call, and the sub-microservice B accesses the third microservice through a stateful call; the method includes:

[0007] When any sub-instance of the sub-microservice A receives a cross-service request transmitted from any first target instance in the first microservice, the processed cross-service request is routed to the second target instance in the sub-microservice B according to the business keyword of the cross-service request, so that the second target instance processes the processed cross-service request;

[0008] Obtain a target channel between the second target instance and the third microservice, and send the cross-service request processed by the second target instance to the third target instance corresponding to the target channel through the target channel, so that the third target instance processes the cross-service request.

[0009] In another possible implementation manner, the acquiring a target channel between the second target instance and the third microservice includes:

[0010] Obtain a channel mapping table corresponding to the second target instance; the channel mapping table includes a predefined channel between the second target instance and the third microservice, and a business keyword corresponding to the predefined channel;

[0011] The target channel is determined according to the service keyword and the channel mapping table.

[0012] In another possible implementation, the second microservice includes middleware, and routing the processed cross-service request to the second target instance in the sub-microservice B according to the business keyword of the cross-service request includes:

[0013] Determining a business keyword of the cross-service request;

[0014] According to the business keyword, the cross-service request to be consumed is sent to the target partition in the middleware; the cross-service request to be consumed in the target partition is routed to the corresponding second target instance.

[0015] In another possible implementation, sending the cross-service request to be consumed to the target partition in the middleware according to the business keyword includes:

[0016] Performing hash calculation on the business keyword to obtain a hash value of the cross-service request;

[0017] A modulo operation is performed on the hash value and the preset partition quantity of the middleware to determine the target partition.

[0018] In another possible implementation, before performing a modulo operation on the hash value and the preset number of partitions of the middleware to determine the target partition, the method further includes:

[0019] If the hash value does not exist in the hash mapping table, performing a modulo operation on the hash value and the preset number of partitions to obtain the target partition;

[0020] If the hash value exists in the hash mapping table, the partition corresponding to the hash value is used as the target partition.

[0021] In another possible implementation, the method further includes:

[0022] A hash mapping table is updated according to the hash value and the target partition, wherein the hash mapping table includes at least one hash value and a partition corresponding to the at least one hash value.

[0023] In another possible implementation, the middleware is a message queue or an event bus.

[0024] In a second aspect, the present application provides a cross-service request processing device, which is applied to a microservice architecture; the microservice architecture includes a first microservice, a second microservice, and a third microservice, wherein the second microservice includes a sub-microservice A and a sub-microservice B, and the first microservice accesses the sub-microservice A through a stateless call, and the sub-microservice B accesses the third microservice through a stateful call; the device includes:

[0025] A first processing module is configured to, when any sub-instance of the sub-microservice A receives a cross-service request transmitted from any first target instance in the first microservice, route the processed cross-service request to the second target instance in the sub-microservice B according to the business keyword of the cross-service request, so that the second target instance processes the processed cross-service request;

[0026] The second processing module is used to obtain a target channel between the second target instance and the third microservice, and send the cross-service request processed by the second target instance to the third target instance corresponding to the target channel through the target channel, so that the third target instance processes the cross-service request.

[0027] In a third aspect, the present application provides an electronic device, including: at least one processor and a memory;

[0028] The memory stores computer-executable instructions;

[0029] The at least one processor executes the computer-executable instructions stored in the memory, so that the at least one processor performs the method as described in any one of the first aspects above.

[0030] In a fourth aspect, the present application provides a cross-service request processing system, wherein the system includes a microservice architecture as described in any one of the first aspects.

[0031] In a fifth aspect, the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are executed by a central processing unit, they are used to implement the method described in any one of the first aspects above.

[0032] In a sixth aspect, the present application provides a computer program product, including a computer program, which, when executed by a central processing unit, implements the method described in any one of the first aspects.

[0033] The present application provides a cross-service request processing method, device, equipment and system, wherein the method of the present application is applied to a microservice architecture; specifically, the second microservice in the microservice architecture of the present application includes a sub-microservice A and a sub-microservice B, wherein the first microservice accesses the sub-microservice A through a stateless call, and the sub-microservice B accesses the third microservice through a stateful call. In the method of the present application, for a cross-service request of any target business, the first target instance passes it to any sub-microservice A, and the sub-microservice A sends it to the second target instance of the corresponding sub-microservice B according to its corresponding business keyword. Further, the target channel is determined according to the business keyword, so that the second target instance passes it to the corresponding third target instance through the target channel, and the third target instance further processes it. Since the context information of the target business is cached in the local cache of the third target instance, the third target instance can process it in combination with the context information when processing the cross-service request, so as to maintain the consistency of the session state. At the same time, when processing cross-service requests, sub-microservice A and sub-microservice B do not have dependencies, so that they can be deployed independently to meet the requirements of high availability and high concurrency. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0035] Figure 1 A schematic diagram of an application scenario of a cross-service request processing method provided in an embodiment of the present application;

[0036] Figure 2 A schematic diagram of a cross-service request processing method provided in an embodiment of the present application Figure 1 ;

[0037] Figure 3 A schematic diagram of a cross-service request processing method provided in an embodiment of the present application Figure 2 ;

[0038] Figure 4 An example diagram of a process for processing a cross-service request provided in an embodiment of the present application;

[0039] Figure 5 A schematic diagram of the structure of a cross-service request processing device provided in an embodiment of the present application;

[0040] Figure 6 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application.

[0041] The above drawings have shown clear embodiments of the present application, which will be described in more detail later. These drawings and text descriptions are not intended to limit the scope of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0042] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0043] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant laws, regulations and standards, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0044] In modern system construction, microservice architecture is widely adopted due to its flexibility and scalability. Specifically, microservice architecture decomposes the application into multiple independent services, each of which is responsible for a specific function, and they work together to complete complex business operations.

[0045] Cross-service requests refer to situations in a microservice architecture where one service needs to communicate with another service to complete a task or obtain some data. Such requests usually involve network calls because the services may run in different servers or containers. Cross-service requests can be synchronous (for example, through HTTP calls) or asynchronous (for example, through message queues). When handling cross-service requests, the microservice architecture needs to consider issues such as network latency, fault handling, data consistency, and security. Currently, how to maintain the consistency and continuity of session state in cross-service calls has become a challenge.

[0046] In the known technology, when processing cross-service requests, it is usually necessary to rely on complex session management mechanisms or sacrifice performance to achieve session state consistency. For example, in the known technology, session sharing is used to maintain the consistency and continuity of session state. Specifically, a centralized data storage is used to save the session state, and all microservices can access this shared storage to obtain and update session information. Distributed transactions are also used in the known technology to ensure the consistency of cross-service session states.

[0047] It is understandable that when the above method is used to process cross-service requests to achieve session state consistency, due to the bottleneck of centralized storage and the coupling between microservices, the system often finds it difficult to cope with high concurrency and high availability scenarios, thereby affecting system performance and reliability. For example, when session sharing is used to maintain the consistency and continuity of session state, all microservices need to frequently access the same centralized storage, which may become a bottleneck of the system in high concurrency and high availability scenarios and increase the complexity of the system.

[0048] Therefore, the present application provides a cross-service request processing method, device, equipment and system to solve the above problems. The method of the present application is applicable to processing the following cross-service requests: the cross-service request needs to be processed by the first microservice, the second microservice and the third microservice in sequence, wherein the first microservice accesses the second microservice through a stateless call, and the second microservice accesses the third microservice through a stateful call.

[0049] Accordingly, the method of the present application is applied to a microservice architecture including the above-mentioned first microservice, second microservice and third microservice. Specifically, in the method of the present application, the second microservice includes sub-microservice A and sub-microservice B. When any target instance of the first microservice receives a cross-service request of any business, the first microservice processes it and routes the processed cross-service request to any instance in sub-microservice A. The instance sends it to the second target instance corresponding to the current business in sub-microservice B according to the business keyword of the cross-service request, so that the second target instance further processes the processed cross-service request. Finally, the second target instance sends the processed cross-service request to the third target instance in the third microservice through the target channel corresponding to the current business, so that the third target instance further processes the cross-service request.

[0050] Through the above settings, multiple cross-service requests for each business are effectively guaranteed, and the context information of the previous cross-service request can be seamlessly used to achieve consistency of session state. At the same time, in the method of the present application, each microservice is independently set, and for the second microservice, each sub-microservice can also be independently expanded and deployed to meet high concurrency and high availability scenarios, and avoid unnecessary waste of resources, thereby effectively ensuring the performance and reliability of the system.

[0051] For example, Figure 1 A schematic diagram of an application scenario of a cross-service request processing method provided in an embodiment of the present application, such as Figure 1 As shown, the method of the present application can be applied to smart home scenarios. Specifically, the cross-service request is triggered by the user through a mobile terminal to view and update the energy usage of the home. Correspondingly, the microservice architecture in this scenario includes user management service, sensor management service and energy data service.

[0052] Among them, the user management service is used to verify the user's identity and permissions when receiving a cross-service request triggered by the user, and pass the cross-service request to the sensor management service through a stateless call. The sensor management service is used to determine the target sensor based on the cross-service request, and pass the cross-service request to the energy data service through a stateful call. The energy data service is used to obtain the energy usage corresponding to the target sensor when receiving a cross-service request and send it to the user's mobile terminal. Specifically, the sensor can be a water meter, gas meter, etc. at home.

[0053] Through the method of the present application, when the user management service receives a cross-service request from a user for any target sensor, the user management service routes the processed cross-service request to the target instance in the sensor management service, which processes it and further determines the target channel between the target instance and the energy data service, and passes the cross-service request to the corresponding instance in the energy data service through the target channel. Among them, the local cache of the corresponding instance caches the context information of the cross-service request previously triggered by the user for the target sensor, thereby ensuring the consistency and continuity of the session context.

[0054] At the same time, since the user management service, sensor management service and energy data service are set up independently, each microservice can be expanded and deployed independently, thus achieving high availability and high concurrency.

[0055] It will be appreciated that the method of the present application may be specifically executed in any suitable computing environment in a microservice architecture, such as a server, container, or computing node running a microservice, and this embodiment is not limited to a specific type of hardware device.

[0056] In the following, some embodiments of the present application are described in detail in conjunction with the accompanying drawings. In the case where the embodiments do not conflict with each other, the following embodiments and features in the embodiments can be combined with each other.

[0057] The present application provides a cross-service request processing method, which is applied to any microservice architecture including a first microservice, a second microservice and a third microservice, wherein the second microservice includes a sub-microservice A and a sub-microservice B, and the first microservice accesses the sub-microservice A through a stateless call, and the sub-microservice B accesses the third microservice through a stateful call.

[0058] It is worth noting that in this application, an electronic device is taken as an example to illustrate the cross-service request processing method of this application. Among them, the electronic device includes a centralized component or service for coordinating and managing the interaction between microservices.

[0059] Figure 2A schematic diagram of a cross-service request processing method provided in an embodiment of the present application Figure 1 ,like Figure 2 As shown, the method provided in this embodiment includes:

[0060] S201, when any sub-instance of sub-microservice A receives a cross-service request transmitted from any first target instance in the first microservice, the processed cross-service request is routed to the second target instance in sub-microservice B according to the business keyword of the cross-service request, so that the second target instance processes the processed cross-service request.

[0061] In this embodiment, the first microservice, sub-microservice A, sub-microservice B and the third microservice are independently deployed with multiple instances. When a cross-service request is triggered, any instance of the first microservice receives the cross-service request and processes the cross-service request.

[0062] Specifically, in this embodiment, when any first target instance of the first microservice receives a cross-service request of any target business, the electronic device sends it to any instance in the sub-microservice A. After processing it, the instance obtains the business keyword carried in the cross-service request, and according to the business keyword, the instance routes the processed cross-service request to the second target instance in the sub-microservice B, so that the second target instance further processes the cross-service request. More specifically, the first target instance passes the processed cross-service request to the sub-microservice A through an HTTP stateless call.

[0063] It is understandable that the same target service corresponds to the same service keyword. Through the above configuration, different cross-service requests of the same target service can be routed to the same second target instance.

[0064] It can be understood that the target service may specifically refer to a payment service, an inquiry service, etc., such as the inquiry service for any sensor in the aforementioned content, which is not limited in this embodiment.

[0065] As a preferred example, when the electronic device obtains the service keyword, it performs a hash calculation on the service keyword to obtain a hash value of the cross-service request. Further, the electronic device determines the second target instance according to the hash value. It is understandable that for the device communication service, the service keyword carried by the cross-service request is specifically the device serial number.

[0066] Through the above settings, routing rules can be flexibly adjusted according to business needs to adapt to different load and performance requirements.

[0067] In practical applications, the electronic device may also maintain a relationship table between a service keyword and a second target instance. Based on this, after obtaining the service keyword, the electronic device determines the second target instance by searching the service keyword in the relationship table. In this embodiment, the method of determining the second target instance is not limited, as long as it can ensure that multiple cross-service requests for the same target service are processed by the same second target instance.

[0068] S202, obtaining a target channel between the second target instance and the third microservice, and sending the cross-service request processed by the second target instance to the third target instance corresponding to the target channel through the target channel, so that the third target instance processes the cross-service request.

[0069] In this embodiment, when the second target instance completes further processing of the cross-service request, the electronic device obtains the target channel between the second target instance and the third microservice. Specifically, the local cache of the second target instance maintains a correspondence between the business keyword and the target channel, and the electronic device obtains the correspondence through the local cache of the second target instance to obtain the target channel between the second target instance and the third microservice, and the target channel is used to pass the cross-service request to the third target instance in the third microservice. More specifically, the target channel can be a TCP connection channel.

[0070] Further, the electronic device sends the cross-service request processed by the second target instance to the corresponding third target instance through the target channel, so that the third target instance processes the cross-service request. It should be understood that the third target instance caches the context information of the historical cross-service request corresponding to the target business.

[0071] As a preferred example, the electronic device obtains the target channel between the second target instance and the third microservice through the following process: obtaining a channel mapping table corresponding to the second target instance, and determining the target channel according to the service keyword and the channel mapping table.

[0072] Specifically, the channel mapping table includes a predefined channel between the second target instance and the third microservice, and a business keyword corresponding to the predefined channel.

[0073] Through this setting, the second target instance only needs to cache the corresponding relationship of the third target instance, without caching the corresponding relationship of all third target instances of the third microservice, which reduces the cache requirement of the second target instance, thereby facilitating the performance of the second target instance. In addition, the target channel is determined by the channel mapping table and the business keyword, and since the channel mapping table only contains the third target instance corresponding to the second target instance, it is conducive to quickly and accurately determining the target channel.

[0074] In practical applications, the corresponding relationships of all third target instances may also be cached in the second target instance, which is not limited in this embodiment.

[0075] In the method provided in this embodiment, for any cross-service request of a target service, the electronic device enables the first target instance to pass it to the corresponding second target instance according to the corresponding service keyword. Further, the target channel is determined according to the service keyword, and the second target instance passes it to the corresponding third target instance through the target channel, and the third target instance further processes it.

[0076] Through the method of this embodiment, multiple cross-service requests for the same target business can be processed by the same second target instance and third target instance, and because the cache of the third target instance contains cache information of multiple cross-service requests, the subsequent cross-service request can seamlessly use the context information of the previous cross-service request, thereby ensuring the consistency and continuity of the session state, and effectively maintaining the session state even in complex business processes across multiple microservices. At the same time, in the method of this embodiment, the two sub-microservices included in the second microservice are independently set, so that the two sub-microservices can be flexibly and independently expanded and deployed, meeting the high availability and high concurrency requirements of the system, and effectively avoiding resource waste.

[0077] Figure 3 A schematic diagram of a cross-service request processing method provided in an embodiment of the present application Figure 2 Based on the above embodiment, this embodiment describes in detail the process of routing the cross-service request to the second target instance in the second microservice in the above embodiment.

[0078] It should be noted that in the method of this implementation, the second microservice in the microservice architecture specifically includes a sub-microservice A, a middleware, and a sub-microservice B. Among them, the middleware can be a message queue or an event bus. In this embodiment, the middleware is an example of a message queue, and the method of this embodiment is further described in detail. Figure 3 As shown, the method of this embodiment includes:

[0079] S301: When any instance of the sub-microservice A receives a cross-service request processed by the first target instance, a business keyword of the cross-service request is determined.

[0080] Among them, the first target instance accesses the child microservice A through a stateless call.

[0081] S302, according to the business keyword, the cross-service request to be consumed is sent to the target partition in the middleware; the cross-service request to be consumed in the target partition is routed to the corresponding second target instance, and the second target instance is the target instance in the child microservice B.

[0082] In this embodiment, sub-microservice A faces the first microservice, provides an HTTP interface, processes the cross-service request from the first microservice, and encapsulates the cross-service request and sends it to the target partition of the message queue. After receiving the cross-service request from the target partition of the message queue, sub-microservice B accesses the third microservice through the target connection channel, processes the response of the third microservice and returns the result to sub-microservice B.

[0083] Specifically, in this embodiment, the electronic device performs hash calculation on the service keyword to obtain a hash value of the cross-service request, and performs a modulo operation on the hash value and the number of preset partitions of the middleware to determine the target partition.

[0084] It is understandable that the business keywords of the same target business are consistent, and the corresponding hash values ​​are consistent, so that the corresponding cross-service requests can be divided into the same target partition, which is conducive to achieving the consistency and continuity of the session state. In addition, through hashing and modulo operations, cross-service requests can be evenly distributed to different partitions of the message queue to avoid overloading a partition and affecting the overall system performance. At the same time, when the number of partitions increases, the hash modulo strategy can dynamically adjust the distribution of messages, thereby supporting the expansion of the system and meeting the requirements of high availability and high concurrency of the system.

[0085] Further, as a preferred example, before the electronic device performs a modulo operation on the hash value and the preset number of partitions of the middleware to determine the target partition, if the hash value does not exist in the hash mapping table, it determines to perform a modulo operation on the hash value and the preset number of partitions to obtain the target partition; if the hash value exists in the hash mapping table, the partition corresponding to the hash value is used as the target partition. Accordingly, the second microservice needs to maintain a hash mapping table to indicate the mapping relationship between the hash value and the message queue partition.

[0086] Specifically, the hash mapping table stores at least one hash value and its corresponding partition. After the electronic device performs hash calculation on the service keyword to obtain the hash value of the cross-service request and determines the target partition according to the hash value, the electronic device updates the hash mapping table according to the hash value and the corresponding target partition to ensure the accuracy of the hash mapping table.

[0087] The above settings are helpful to ensure the accuracy of partitions, thereby improving the consistency and stability of cross-service request allocation. On the other hand, after the electronic device determines the hash value, it first determines whether the target partition corresponding to the hash value exists by searching the hash mapping table. Based on this, when the target partition exists in the hash mapping table, there is no need to perform modulo operations, thereby avoiding repeated modulo operations, which can effectively reduce the computational burden and improve response speed in a high-concurrency environment.

[0088] It can be seen from the consumption principle of the message queue that messages in the same partition will be routed to the same consumer for processing. Therefore, it should be understood that the cross-service request placed in the target partition will be consumed by the same target instance in the sub-microservice B. Based on this, multiple cross-service requests for the same target business can be processed by the same target instance in the sub-microservice B. Among them, the target instance in the sub-microservice B is equivalent to the second target instance in the aforementioned embodiment.

[0089] Furthermore, the instance cache in the sub-microservice B has its corresponding channel mapping table, and the electronic device obtains the channel mapping table to obtain the target channel corresponding to the target instance that receives the cross-service request, and enables the target instance to send the cross-service request to the corresponding third target instance through the target channel.

[0090] It can be understood that when a cross-service request for the same target business is received subsequently, the same second target instance, target channel and corresponding third target instance can be determined based on the business key value. When the third target instance processes it, it can obtain the context information of the request from the cache and process it in combination with the context information, thereby achieving consistency and continuity of the session state.

[0091] In the method provided in this embodiment, the communication mechanism between services is optimized. By introducing the message queue, the stability and response speed of the system are enhanced, and the dependency between services is simplified, so that each microservice can be independently deployed as a multi-instance cluster according to demand to ensure high availability and high concurrency. At the same time, the partition mechanism of the message queue also supports the efficient expansion of the system and handles high concurrent requests.

[0092] In addition, the target channel can be reused in the above process to reduce the resource consumption of the connection establishment server, and at the same time it is beneficial to improve the response efficiency.

[0093] For example, Figure 4 This is an example diagram of a process for processing cross-service requests provided by an embodiment of the present application. Figure 4 As shown in the figure, the microservice architecture includes three microservices: O, P, and Q. Among them, the O service accesses the P service through a stateless call, and the P service accesses the Q service through a stateful call. The P service is divided into sub-microservices P1 and P2, and a message queue is introduced. Specifically, the O service accesses the sub-microservice P1 through a stateless call, and the sub-microservice P1 sends the request received from the O service to the message queue. The sub-microservice P2 obtains the request from the message queue and accesses the Q service through a stateful call, and sends the request to the Q service.

[0094] On this basis, if Figure 4As shown in the figure, for the two target businesses X and Y, it is assumed that each business has made two request calls, sending message 1 and message 2 respectively, and the message contents are different. The two businesses need to perform related business logic processing and calculation through the three services O, P, and Q to complete the complete business, and the three services O, P, and Q are all highly available, and each service is deployed in a cluster.

[0095] Since the stateless call http is used between the O service and the P service, the requests for services X and Y will be routed to different sub-microservices P1. Sub-microservice P1 performs corresponding original business processing and calculation processing, and obtains the keyword attribute of the business from the message body of the http request. It can be understood that if the business is a device communication business, the keyword attribute of the business keyword is the device serial number.

[0096] The electronic device performs partition hash calculation by itself or causes the MQ producer (sub-microservice P1) according to the extracted business keyword to obtain a hash value, and performs a modulo operation between the hash value and the preset number of partitions of the message queue to obtain the target partition. Specifically, the value after the modulo operation between the hash value and the preset number of partitions is the number corresponding to the target partition.

[0097] It is understandable that since the business keywords corresponding to the two requests of business X are the same, the values ​​obtained by hash operation and modulus operation are consistent, so the two requests will be assigned to the same target partition, thereby ensuring that the two requests of the same target business can be routed to the target partition of the same message queue. Similarly, the two requests of business Y will also be assigned to the same target partition.

[0098] Furthermore, sub-microservice P2 acts as a consumer of the message queue, and messages of the same target partition will be routed to the same instance in sub-microservice P2. For example, message 1 of business X is routed to partition 1 on Topic 1 of the message queue, and is consumed by the P2_2 instance of sub-microservice P2. P2_2 initiates a TCP connection to the Q service cluster to send message 1 of business X, and at the same time maintains the mapping relationship between the business keyword and the TCP connection channel channel in the cache. When the subsequent message 2 of business X arrives, the TCP connection channel channel is obtained from the local cache according to the business keyword, and message 2 is sent to the Q service through the channel without establishing a TCP connection again. It can be understood that Topic 1 in the message queue is used to correspond to the same business logic.

[0099] When the Q service receives message 1 sent by business X, it performs corresponding business logic processing and caches the message in the channel. When message 2 of business X arrives later, it will be routed to the same Q service instance Q_2 according to the established stateful request TCP channel. Q_2 can perform corresponding business logic processing based on the contents of message 1 and message 2, and seamlessly utilize the context information of business X, thereby achieving session state consistency and continuity across stateful and stateless service requests.

[0100] It is understandable that the above-mentioned O, P, Q services and message queues can be independently deployed as needed to meet the high availability and high concurrency requirements of the system.

[0101] It should be noted that, for the aforementioned method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the present application is not limited by the described order of actions, because according to the present application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily required by the present application.

[0102] It should be further noted that, although the various steps in the flowchart are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence in the order indicated by the arrows. Unless there is a clear description in this article, the execution of these steps is not strictly limited in order, and these steps can be executed in other orders. Moreover, at least a portion of the steps in the flowchart may include multiple sub-steps or multiple stages, and these sub-steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these sub-steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a portion of the sub-steps or stages of other steps.

[0103] The above embodiment introduces a cross-service request processing method from the perspective of method flow, and the following embodiment introduces a cross-service request processing device from the perspective of a virtual module or a virtual unit. Please refer to the following embodiment for details.

[0104] The embodiment of the present application provides a cross-service request processing device, which is applied to a microservice architecture; the microservice architecture includes a first microservice, a second microservice, and a third microservice, wherein the second microservice includes a sub-microservice A and a sub-microservice B, and the first microservice accesses the sub-microservice A through a stateless call, and the sub-microservice B accesses the third microservice through a stateful call; Figure 5 A schematic diagram of the structure of a cross-service request processing device provided in an embodiment of the present application, such as Figure 5 As shown, the device comprises:

[0105] The first processing module 51 is used for routing the processed cross-service request to the second target instance in the sub-microservice B according to the business keyword of the cross-service request when any sub-instance of the sub-microservice A receives a cross-service request transmitted from any first target instance in the first microservice, so that the second target instance processes the processed cross-service request;

[0106] The second processing module 52 is used to obtain the target channel between the second target instance and the third microservice, and route the cross-service request processed by the second target instance to the third target instance corresponding to the target channel, so that the third target instance processes the cross-service request.

[0107] In another possible implementation of the embodiment of the present application, the second processing module 52 is specifically configured to:

[0108] Obtain a channel mapping table corresponding to the second target instance; the channel mapping table includes a predefined channel between the second target instance and the third microservice, and a business keyword corresponding to the predefined channel;

[0109] Determine the target channel based on the service keyword and the channel mapping table.

[0110] In another possible implementation manner of the embodiment of the present application, the second microservice further includes middleware, and the first processing module 51 is specifically used for:

[0111] Identify business keywords across service requests;

[0112] According to the business keyword, the cross-service request to be consumed is sent to the target partition in the middleware; the cross-service request to be consumed in the target partition is routed to the corresponding second target instance.

[0113] In another possible implementation manner of the embodiment of the present application, the first processing module 51 is specifically used to:

[0114] Perform hash calculation on the business keyword to obtain the hash value of the cross-service request;

[0115] Perform a modulo operation on the hash value and the preset number of partitions of the middleware to determine the target partition.

[0116] In another possible implementation of the embodiment of the present application, the first processing module 51 is further configured to:

[0117] If the hash value does not exist in the hash mapping table, the hash value is modulo-calculated with the preset number of partitions to obtain the target partition;

[0118] If there is a hash value in the hash map, the partition corresponding to the hash value is used as the target partition.

[0119] In another possible implementation of the embodiment of the present application, the first processing module 51 is further configured to:

[0120] The hash mapping table is updated according to the hash value and the target partition, where the hash mapping table includes at least one hash value and at least one partition corresponding to the hash value.

[0121] In another possible implementation manner of the embodiment of the present application, the middleware is a message queue or an event bus.

[0122] An inter-service request processing device provided in an embodiment of the present application is applicable to the above-mentioned method embodiment and will not be described in detail here.

[0123] An electronic device is provided in an embodiment of the present application. Figure 6 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application is shown in FIG. Figure 6 As shown, Figure 6 The electronic device shown includes: a processor 61 and a memory 62. The processor 61 and the memory 62 are connected, such as through a bus 63. Optionally, the electronic device may further include a transceiver 64. It should be noted that in actual applications, the transceiver 64 is not limited to one, and the structure of the electronic device does not constitute a limitation on the embodiments of the present application.

[0124] The processor 61 may be a central processing unit (CPU), a general processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, transistor logic devices, hardware components or any combination thereof. It may implement or execute various exemplary logic blocks, modules and circuits described in conjunction with the disclosure of this application. The processor 61 may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, etc.

[0125] The bus 63 may include a path to transmit information between the above components. The bus 63 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. The bus 63 may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 6Although only one thick line is used in the figure, it does not mean that there is only one bus 63 or only one type of bus 63.

[0126] The memory 62 may be a read-only memory (ROM) or other types of static storage devices that can store static information and instructions, a random access memory (RAM) or other types of dynamic storage devices that can store information and instructions, or an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited to these.

[0127] The memory 62 is used to store the application code for executing the solution of the present application, and the execution is controlled by the processor 61. The processor 61 is used to execute the application code stored in the memory 62 to implement the content shown in the above method embodiment.

[0128] The present application also provides a computer-readable storage medium, which may include: a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a disk or an optical disk, and other media that can store program codes. Specifically, the computer-readable storage medium stores program instructions, and the program instructions are used to implement the methods in the above-mentioned embodiments.

[0129] A computer program product is also provided in an embodiment of the present application, including a computer program. When the computer program is executed by a processor, the technical solution of the above-mentioned method embodiment is implemented. The implementation principle and technical effect are similar and will not be repeated here.

[0130] An embodiment of the present application also provides a cross-service request processing system. Specifically, the system includes any microservice architecture as described in the aforementioned embodiments.

[0131] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the invention disclosed herein. The present application is intended to cover any modification, use or adaptation of the present application, which follows the general principles of the present application and includes common knowledge or customary techniques in the art that are not disclosed in the present application. The specification and examples are intended to be exemplary only, and the true scope and spirit of the present application are indicated by the claims.

[0132] It should be understood that the present application is not limited to the precise structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

Claims

1. A cross-service request processing method, characterized in that: Applied to microservice architecture; The microservice architecture includes a first microservice, a second microservice, and a third microservice, wherein the second microservice includes a sub-microservice A and a sub-microservice B, and the sub-microservice A and the sub-microservice B are deployed independently of each other and have no dependency relationship; the first microservice accesses the sub-microservice A through a stateless call, and the sub-microservice B accesses the third microservice through a stateful call; the method includes: When any sub-instance of the sub-microservice A receives a cross-service request for a target business transmitted from any first target instance in the first microservice, the processed cross-service request is routed to the second target instance in the sub-microservice B according to the business keyword of the cross-service request, so that the second target instance processes the processed cross-service request; Obtain a target channel between the second target instance and the third microservice, and send the cross-service request processed by the second target instance to the third target instance corresponding to the target channel through the target channel, so that the third target instance processes the cross-service request based on the context information of the target business cached in the local cache.

2. The method according to claim 1, characterized in that: The obtaining of a target channel between the second target instance and the third microservice includes: Obtain a channel mapping table corresponding to the second target instance; the channel mapping table includes a predefined channel between the second target instance and the third microservice, and a business keyword corresponding to the predefined channel; The target channel is determined according to the service keyword and the channel mapping table.

3. The method according to claim 1 or 2, characterized in that: The second microservice further includes a middleware, and the processing cross-service request is routed to the second target instance in the sub-microservice B according to the business keyword of the cross-service request, including: Determining a business keyword of the cross-service request; According to the business keyword, the cross-service request to be consumed is sent to the target partition in the middleware; the cross-service request to be consumed in the target partition is routed to the corresponding second target instance.

4. The method according to claim 3, characterized in that The step of sending the cross-service request to be consumed to the target partition in the middleware according to the business keyword includes: Performing hash calculation on the business keyword to obtain a hash value of the cross-service request; A modulo operation is performed on the hash value and the preset partition quantity of the middleware to determine the target partition.

5. The method according to claim 4, characterized in that Before performing a modulo operation on the hash value and the preset partition quantity of the middleware to determine the target partition, the method further includes: If the hash value does not exist in the hash mapping table, performing a modulo operation on the hash value and the preset number of partitions to obtain the target partition; If the hash value exists in the hash mapping table, the partition corresponding to the hash value is used as the target partition.

6. The method according to claim 4, characterized in that The method further comprises: A hash mapping table is updated according to the hash value and the target partition, wherein the hash mapping table includes at least one hash value and a partition corresponding to the at least one hash value.

7. The method according to claim 3, characterized in that The middleware is a message queue or an event bus.

8. A cross-service request processing device, characterized in that: Applied to microservice architecture; The microservice architecture includes a first microservice, a second microservice, and a third microservice, wherein the second microservice includes a sub-microservice A and a sub-microservice B, and the sub-microservice A and the sub-microservice B are deployed independently of each other and have no dependency relationship; the first microservice accesses the sub-microservice A through a stateless call, and the sub-microservice B accesses the third microservice through a stateful call; the device includes: A first processing module is configured to route the processed cross-service request to a second target instance in the sub-microservice B according to a business keyword of the cross-service request when any sub-instance of the sub-microservice A receives a cross-service request of a target business transmitted from any first target instance in the first microservice, so that the second target instance processes the processed cross-service request; The second processing module is used to obtain a target channel between the second target instance and the third microservice, and send the cross-service request processed by the second target instance to the third target instance corresponding to the target channel through the target channel, so that the third target instance processes the cross-service request based on the context information of the target business cached in the local cache.

9. An electronic device, characterized in that: include: at least one processor and memory; The memory stores computer-executable instructions; The at least one processor executes the computer-executable instructions stored in the memory, so that the at least one processor performs the method according to any one of claims 1 to 7.

10. A cross-service request processing system, characterized in that: The system comprises the microservice architecture as described in any one of claims 1 to 7.

Images