Asynchronous-to-synchronous calling method and device based on distributed cross-container

Abstract

The present invention can be used in the field of big data technology. The present invention provides a distributed cross-container asynchronous to synchronous call method and device. The distributed cross-container asynchronous to synchronous call method includes: using the thread in the first container in the system to write the event ID and thread information of the current service call into a pre-generated waiting thread mapping table; calling the thread in the second container according to the event ID and the thread in the RPC service outside the system; the first container and the second container are both in the system; in response to the call result notification of the thread in the second container, the corresponding waiting thread information is searched in the waiting thread mapping table according to the thread in the first container. The present invention provides an implementation method for converting an asynchronous call service across containers in a distributed system into a synchronous call service, solving the problem of mutual communication between two processes and reducing the problem of waiting threads consuming system resources during the waiting process.

Description

Technical Field

[0001] The present invention belongs to the field of big data technology, and in particular to distributed system service calls, and specifically to a distributed cross-container-based asynchronous-to-synchronous call method and device. Background Art

[0002] In the prior art, the implementation method of converting an asynchronous call service into a synchronous call service is to block the current thread after calling the service, waiting for the callee to return a result or time out. Here, the callee must return valid information before the caller can proceed to the next step according to the returned information. However, at present, some services of the callee only provide an asynchronous mode, and the same result is returned regardless of success or failure, or even no result is returned, and the real processing result can only be informed by calling back another service of the caller. In a distributed system, the thread receiving the result and the thread waiting for the result are not on the same container. If the thread that wants to receive the result notifies the thread waiting for the result after receiving the result, there is a problem of mutual communication between the two threads, and there is also a problem of the waiting thread consuming system resources during the waiting process. If the two threads are not on the same server, it also involves the problem of cooperative communication between the two processes, thereby increasing the system resources consumed by the waiting thread during the waiting process. Summary of the invention

[0003] The present invention belongs to the field of big data technology. The asynchronous to synchronous calling method and device based on distributed cross-container provided by the present invention overcome the problem that the asynchronous calling service in the current distributed system also needs to synchronously return the result to the caller. The utilization rate of system resources is greatly improved. In addition, a timeout cleaner is introduced to clean up the timeout records to maintain the validity of the mapping table, improve the efficiency of the search, and wake up the sleeping thread to complete the business logic and release the thread as soon as possible to avoid system crashes. For the abnormal situation sent by the notification sender and the timeout cleaning situation of the timeout cleaner, the present method combines the monitoring system in the system to send an alarm in time, so that the application operation and maintenance personnel can grasp the service call situation of the system in time.

[0004] In order to solve the above technical problems, the present invention provides the following technical solutions:

[0005] In a first aspect, the present invention provides a distributed cross-container-based asynchronous to synchronous calling method, comprising:

[0006] Using the thread in the first container in the system, the event ID and thread information of the current service call are written into the waiting thread mapping table;

[0007] Calling a thread in a second container according to the event ID and a thread in an RPC service outside the system; both the first container and the second container are in the system;

[0008] In response to the call result notification of the thread in the second container, corresponding waiting thread information is searched in the waiting thread mapping table according to the thread in the first container.

[0009] In one embodiment, before the thread in the RPC service outside the system calls the thread in the second container and the first container and the second container are both in the system: the thread in the first container is in a sleeping state.

[0010] In one embodiment, in response to the call result notification of the thread in the second container, searching the waiting thread mapping table for corresponding waiting thread information according to the thread in the first container includes:

[0011] Write the call result and the event ID into the notification sending queue;

[0012] Notify the thread in the first container of the call result notification according to the notification sending queue;

[0013] The waiting thread information corresponding to the event ID is searched in the waiting thread mapping table.

[0014] In one embodiment, the distributed cross-container-based asynchronous-to-synchronous calling method further includes:

[0015] When the waiting thread information corresponding to the event ID is found in the waiting thread mapping table, the thread in the first container is woken up according to the waiting thread information.

[0016] In one embodiment, the distributed cross-container-based asynchronous-to-synchronous calling method further includes:

[0017] When no call result notification of the thread in the second container is received within a preset time period, the event ID and thread information in the waiting thread mapping table are deleted, and the thread in the first container is notified that the call has timed out.

[0018] In a second aspect, the present invention provides a distributed cross-container-based asynchronous-to-synchronous calling device, comprising:

[0019] A data writing module, used to write the event ID and thread information of the current service call into the waiting thread mapping table by using the thread in the first container in the system;

[0020] a thread calling module, configured to call a thread in a second container according to the event ID and a thread in an RPC service outside the system; the first container and the second container are both within the system;

[0021] A result notification module is used to respond to the call result notification of the thread in the second container and search the waiting thread mapping table for corresponding waiting thread information according to the thread in the first container.

[0022] In one embodiment, before calling the thread in the second container according to the thread in the RPC service outside the system; the first container and the second container are both in the system: the thread in the first container is in a sleeping state;

[0023] The result notification module includes:

[0024] A result writing unit, used for writing the call result and the event ID into the notification sending queue;

[0025] A notification unit, configured to notify the thread in the first container of the call result notification according to the notification sending queue;

[0026] The information searching unit is used to search the waiting thread information corresponding to the event ID in the waiting thread mapping table.

[0027] In one embodiment, the distributed cross-container-based asynchronous-to-synchronous calling device further includes:

[0028] A thread awakening module, configured to awaken the thread in the first container according to the waiting thread information when the waiting thread information corresponding to the event ID is found in the waiting thread mapping table;

[0029] A timeout notification module is used to delete the event ID and thread information in the waiting thread mapping table and notify the thread in the first container that the call has timed out when no call result notification of the thread in the second container is received within a preset time period.

[0030] In a third aspect, the present invention provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the steps of an asynchronous-to-synchronous calling method based on a distributed cross-container are implemented.

[0031] In a fourth aspect, the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of a distributed cross-container-based asynchronous-to-synchronous calling method.

[0032] From the above description, it can be seen that the asynchronous to synchronous call method and device based on distributed cross-container provided by the embodiment of the present invention first uses the thread in the first container in the system to write the event ID and thread information of the current service call into the pre-generated waiting thread mapping table; then, the thread in the second container is called according to the event ID and the thread in the RPC service outside the system; the first container and the second container are both in the system; finally, in response to the call result notification of the thread in the second container, the corresponding waiting thread information is searched in the waiting thread mapping table according to the thread in the first container. The present invention overcomes the problem that the asynchronous call service in the distributed system in the prior art needs to return the result to the caller synchronously. And the distributed message queue is used to solve the problem that cross-container and cross-database notification cannot be solved, and the thread lock is used to solve the thread cooperation problem in the same container, which greatly improves the utilization rate of system resources. In order to reduce the problem that the notification receiver has not received information for a long time due to network delay or system abnormality, the present invention also introduces a queue timeout cleaner to clean up the timeout record to maintain the validity of the mapping table, improve the efficiency of the search, and wake up the sleeping thread to complete the business logic and release the thread as soon as possible to avoid system crash. For abnormal situations sent by the notification sender and timeout cleaning situations of the timeout cleaner, the present invention combines the monitoring system in the system to send alarms in time, so that application operation and maintenance personnel can grasp the service call situation of the system in time. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0034] Figure 1 The following is a schematic diagram of the asynchronous to synchronous calling method based on distributed cross-container in an embodiment of the present invention. Figure 1 ;

[0035] Figure 2 It is an internal structure diagram of a waiting thread mapping table in an embodiment of the present invention;

[0036] Figure 3 This is a flow chart of step 300 in the distributed cross-container asynchronous to synchronous calling method in an embodiment of the present invention;

[0037] Figure 4 The following is a schematic diagram of the asynchronous to synchronous calling method based on distributed cross-container in an embodiment of the present invention. Figure 2 ;

[0038] Figure 5The following is a schematic diagram of the asynchronous to synchronous calling method based on distributed cross-container in an embodiment of the present invention. Figure 3 ;

[0039] Figure 6 It is a service call link diagram of the acquiring business in a specific application example of the present invention;

[0040] Figure 7 It is a structural diagram of the internal system of the acquiring system in a specific application example of the present invention;

[0041] Figure 8 The following is a schematic diagram of the asynchronous to synchronous calling method based on distributed cross-container in a specific application example of the present invention. Figure 1 ;

[0042] Fig. 9 It is a schematic diagram of asynchronous-to-synchronous service call across containers in a distributed system in a specific application example of the present invention;

[0043] Fig.10 It is a flow chart of the cleaning strategy of the timeout cleaner in a specific application example of the present invention;

[0044] Fig.11 The following is a schematic diagram of the asynchronous to synchronous calling method based on distributed cross-container in a specific application example of the present invention. Figure 2 ;

[0045] Fig.12 The structure of the asynchronous to synchronous calling device based on distributed cross-container in the specific application example of the present invention is shown as follows Figure 1 ;

[0046] Fig.13 It is a structural diagram of the result notification module 30 in a specific application example of the present invention;

[0047] Fig.14 The structure of the asynchronous to synchronous calling device based on distributed cross-container in the specific application example of the present invention is shown as follows Figure 2 ;

[0048] Fig.15 The structure of the asynchronous to synchronous calling device based on distributed cross-container in the specific application example of the present invention is shown as follows Figure 3 ;

[0049] Fig.16 It is a schematic diagram of the structure of an electronic device in an embodiment of the present invention. DETAILED DESCRIPTION

[0050] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0051] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods, systems, or computer program products. Therefore, the present invention may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0052] It should be noted that the terms "including" and "having" and any variations thereof in the specification and claims of the present application and the above-mentioned drawings are intended to cover non-exclusive inclusions. For example, a process, method, system, product or apparatus comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or apparatuses.

[0053] It should be noted that, in the absence of conflict, the embodiments and features in the embodiments of the present application can be combined with each other. The present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0054] The embodiment of the present invention provides a specific implementation of a distributed cross-container asynchronous to synchronous calling method, see Figure 1 , the method specifically includes the following contents:

[0055] Step 100: Using the thread in the first container in the system, the event ID and thread information of the current service call are written into the waiting thread mapping table.

[0056] Specifically, the thread of the first container stores the time ID and thread information of this service call into the waiting thread mapping table. The waiting thread mapping table is a hash table structure of KV key-value pairs. KEY stores the event ID, which actually means the unique serial number that can be generated for the current container at the current time in a distributed system. It can be generated using a snowflake algorithm, a UUID, or a custom rule. VALUE stores the information of the thread object, including the Condition object, timeout period, storage time, and thread input object. The Condition object refers to the condition object created by the current thread lock, which can make the thread sleep or wake up. The timeout period refers to how long the thread waits after this service call before it stops waiting. The storage time refers to the time stored in the mapping table, which is used to analyze problems after an exception occurs. The thread input object refers to the input content of this service call, which is used for subsequent processing after the thread wakes up, and can also be used to analyze problems. For details, see Figure 2 .

[0057] Step 200: Call a thread in a second container according to the event ID and a thread in an RPC service outside the system; both the first container and the second container are within the system.

[0058] On the basis of step 100, according to the time ID and the RPC service outside the system (RPC (Remote Procedure Call) is an inter-process communication method. It allows a program to call a procedure or function in another address space (usually on another machine in a shared network)), the thread in the second container is called, and then the thread in the first container is adjusted to a sleep state to wait for the subsequent step loop. It should be emphasized that the first container and the second container are both within the system, and the RPC service is outside the system. It can be understood that through this setting method, the utilization rate of system resources can be greatly improved.

[0059] Step 300: In response to the call result notification of the thread in the second container, searching the waiting thread mapping table for corresponding waiting thread information according to the thread in the first container.

[0060] Specifically, after the second container receives the callback service request initiated by the thread in the RPC service, it stores the result in the database and stores the event ID in the notification sending queue. The notification sender continuously scans the content of the notification sending queue and publishes the content to its topic. After the notification receiver of the first container receives the published information, it obtains the event ID. According to the event ID, the notification receiver searches for the waiting thread information from the waiting thread mapping table.

[0061] From the above description, it can be seen that the asynchronous to synchronous call method based on distributed cross-container provided by the embodiment of the present invention first uses the thread in the first container in the system to write the event ID and thread information of the current service call into the pre-generated waiting thread mapping table; then, the thread in the second container is called according to the event ID and the thread in the RPC service outside the system; the first container and the second container are both in the system; finally, in response to the call result notification of the thread in the second container, the corresponding waiting thread information is searched in the waiting thread mapping table according to the thread in the first container. The present invention overcomes the problem that the asynchronous call service in the distributed system in the prior art needs to return the result to the caller synchronously. And the distributed message queue is used to solve the problem that cross-container and cross-database notification cannot be solved, and the thread lock is used to solve the thread cooperation problem in the same container, which greatly improves the utilization rate of system resources. In order to reduce the problem that the notification receiver has not received information for a long time due to network delay or system abnormality, the present invention also introduces a queue timeout cleaner to clean up the timeout record to maintain the validity of the mapping table, improve the efficiency of the search, and wake up the sleeping thread to complete the business logic and release the thread as soon as possible to avoid system crash. For abnormal situations sent by the notification sender and timeout cleaning situations of the timeout cleaner, the present invention combines the monitoring system in the system to send alarms in time, so that application operation and maintenance personnel can grasp the service call situation of the system in time.

[0062] In one embodiment, after step 100 and before step 200, the thread in the first container is in a sleep state.

[0063] It can be understood that adjusting the thread in the first container to the sleep state is essentially to use the thread lock to solve the thread cooperation problem in the same container.

[0064] In one embodiment, see Figure 3 , step 300 further comprises:

[0065] Step 301: Write the call result and the event ID into the notification sending queue;

[0066] Step 302: Notify the thread in the first container of the call result notification according to the notification sending queue;

[0067] Step 303: Search the waiting thread information corresponding to the event ID in the waiting thread mapping table.

[0068] In step 301 to step 302, after the thread of the second container stores the call result in the database, it stores the time ID in the notification sending queue. The notification sender continuously scans the content of the notification sending queue and publishes the content to its topic. The notification receiver of the first container receives the published information and obtains the event ID. According to the event ID, the notification receiver searches for the corresponding waiting thread information from the waiting thread mapping table.

[0069] In one embodiment, see Figure 4 , the asynchronous-to-synchronous calling method based on distributed cross-container also includes:

[0070] Step 400: When the waiting thread information corresponding to the event ID is found in the waiting thread mapping table, the thread in the first container is woken up according to the waiting thread information.

[0071] In one embodiment, see Figure 5 , the asynchronous-to-synchronous calling method based on distributed cross-container also includes:

[0072] Step 500: When no call result notification of the thread in the second container is received within a preset time period, the event ID and thread information in the waiting thread mapping table are deleted, and the thread in the first container is notified that the call has timed out.

[0073] In step 400 and step 500, when the receiver of the first container finds the corresponding waiting thread information from the waiting thread mapping table, the waiting thread is awakened to inform it that the callback has been completed; if it cannot be found, the information is ignored.

[0074] When the notification receiver of the first container does not receive information for a long time, the timeout cleaner is used to clean up the records in the waiting thread mapping table, and the waiting thread is awakened to inform it of timeout. Finally, the waiting thread performs specific business processing according to the awakening type.

[0075] On the other hand, the timeout cleaner here refers to a delayed thread pool that cleans up the data in the waiting thread mapping table. The timeout cleaner can clean up abnormally timed waiting threads in time, maintain the validity of the data in the waiting thread mapping table, and prevent the threads from being unable to be recycled due to infinite waiting, thus achieving a system protection effect.

[0076] To further illustrate the present solution, the present invention takes the acquiring business between a bank and a merchant as an example to provide a specific application example of the asynchronous-to-synchronous calling method based on a distributed cross-container.

[0077] Figure 6 This is the service call chain diagram of the acquiring business. A service request call goes through five systems, namely merchant system 1, API system 2, acquiring system 3, external system 4, and UnionPay system 5.

[0078] The merchant system 1 refers to the merchant's own business processing system, which includes the front-end and back-end systems. After the merchant has processed its own business logic, it encrypts and signs the interface according to the API interface specification and calls the interface provided by the API system.

[0079] API system 2 refers to the unified entry system provided by ICBC for merchant access requests. API system 2 decrypts and verifies the API interface, verifies the legitimacy and security of the request, and converts the HTTPS request into a more efficient RPC request, calling the service of acquiring system 3 through the intranet.

[0080] Acquiring system 3 refers to the core system of ICBC's acquiring business processing. Acquiring system 3 provides a series of services for API system 2 to call, and provides different callback services for external connection system 4 to call. For details of the internal system structure of acquiring system 3, please refer to Figure 7 The system includes a registration center 3-1, a distributed message queue 3-2, a business server group 3-3-3, a business server group 3-3-4, a database server group 3-5, and a database server group 3-6. Specifically:

[0081] Registration center 3-1 refers to the registration center of the service, which records the mapping relationship between the service and the service address. It has functions such as service discovery, service configuration, and service health check. Common distributed registration centers include Zookeeper, Eureka, Consul, and Nacos. Registration center 3-1 is a highly available registration center cluster, which is deployed across campuses to ensure that when a catastrophic problem occurs in one campus, another campus can still operate normally. Or when a single registration center is abnormal, other registration centers can also provide stable functions to ensure stable operation of the system. In the acquiring system, each container will register the service to the registration center 3-1 when it starts. When a container goes offline, the registration center 3-1 will take all service providers of the container offline, and then notify consumers on other containers to remove the providers of the service to ensure the availability of service calls.

[0082] Distributed message queue 3-2 refers to a high-performance, high-availability, scalable and eventually consistent middleware that solves problems such as application coupling, asynchronous messages, and traffic clipping in a distributed scenario. Common distributed message queues include ActiveMQ, RabbitMQ, ZeroMQ, Kafka, MetaMQ, etc. Distributed message queue 3-2 solves the message synchronization problem between different containers, allowing the architecture to be loosely coupled. In the acquiring system, each container in the same business server group subscribes to the same topic, while containers in different business server groups do not subscribe to the same topic. For example, the topic subscribed to by each container in business server group 3-3 is the same, while the topics subscribed to by containers in business server group 3-3 and containers in business server group 3-4 are different. Each container can publish information to the distributed message queue 3-2, and other containers in the business server group where the container is located can receive the message. This can reduce the scope of the broadcast and reduce the consumption of system resources.

[0083] Business server group 3-3 and business server group 3-4 refer to two server groups that complete business processing in the acquiring system. Business server group 3-3 and business server group 3-4 contain 3 containers respectively, and the function of each container is the same, which makes the system more available. The containers in each business server group are dynamically scalable and can be adjusted in time according to the current resource usage and concurrency of the system, indicating that the system has scalability. If the business volume increases for a long time, the system can deploy multiple business server groups. RPC service calls can be made between different containers, and information can be produced and consumed through message queues. The containers of each business server group are connected to a database server group, and different business server groups are connected to different database server groups. For example, each container of business server group 3-3 is connected to database server group 3-5, and each container of business server group 3-4 is connected to database server group 3-6.

[0084] Database server group 3-5 and database server group 3-6 refer to a high-availability database cluster with one master and three backups. Under normal circumstances, the read and write operations of business server group 3-3 and business server group 3-4 are all performed on the master database. When an exception occurs, the system can switch between the master and the slave, and the read and write operations are all performed on the backup database. The data is synchronized between the master and the backup database in a semi-synchronous manner to ensure the real-time and eventual consistency of the data. Databases usually use relational databases to store data, such as MYSQL, ORACLE, DB2, etc.

[0085] To summarize, the relationship between the internal systems of the acquiring system is: the containers in the business server group 3-3 and the business server group 3-4 register the service registration and service subscription information through the registration center 3-1; publish and subscribe to each group's own topic information through the distributed message queue 3-2; complete data reading and writing through the database server group 3-5 and the database server group 3-6; and make service calls through the RPC protocol.

[0086] External Link System 4 refers to the basic system for ICBC to connect with card organizations. According to different services, External Link System 4 sends requests to corresponding card organizations through dedicated lines or the Internet, and provides callback interfaces to notify card organizations. It mainly implements basic functions such as certificate signature authentication and signature verification uninstallation.

[0087] The UnionPay system 5 refers to a business system related to UnionPay. The UnionPay system 5 accepts requests from various banks and transfers them to the corresponding acquiring organizations.

[0088] In summary, the relationship between the systems in the service call link diagram of the acquiring business is as follows: Merchant System 1 initiates an HTTPS request to API System 2 through the Internet, and synchronously waits for the result to be returned by API System 2. After receiving the request, API System 2 converts the HTTPS request into an RPC request, and then calls one of the services of Acquiring System 3 through the intranet, and synchronously waits for the result to be returned by Acquiring System 3. After receiving the request, Acquiring System 3 asynchronously calls the service of External System 4 through the intranet after business processing, and synchronously waits for the callback result of External System 4. External System 4 initiates an HTTPS or HTTP request to UnionPay System 5 through a dedicated line or the Internet. UnionPay System 5 notifies the callback result by initiating an HTTPS or HTTP request to External System 4 through a dedicated line or the Internet. After receiving the callback result, External System 4 converts it into an RPC request, and then calls one of the callback services of Acquiring System 3 through the intranet. After receiving the callback request, Acquiring System 3 returns the processing result to API System 2.

[0089] See also Figure 8 as well as Fig. 9 Based on the service call link diagram of the acquiring business, the asynchronous to synchronous call method based on distributed cross-container in this specific application example includes:

[0090] S1: Thread 1 of container A stores the event ID and thread information of this service call into waiting thread mapping table 2, then RPC service calls thread 5 to call thread 6, and finally enters sleep state and waits to be awakened.

[0091] S2: After receiving the request and processing the business, thread 5 calls the callback service. Thread 6 of container B receives the request for the callback service, stores the result in database 7, and stores the event ID in the notification sending queue 8.

[0092] S3: The notification sender 9 publishes the content to its topic by continuously scanning the content of the notification sending queue 8. The notification receiver 4 of container A receives the published information, that is, obtains the event ID.

[0093] S4: According to the event ID, the notification receiver 4 searches for the waiting thread information from the waiting thread mapping table 2. If found, the waiting thread 1 is woken up to inform it that the callback has been completed; if not found, the information is ignored.

[0094] S5: When the notification receiver 4 of container A does not receive any information for a long time, the timeout cleaner 3 cleans up the records in the waiting thread mapping table 2 and wakes up the waiting thread 1 to inform it of timeout.

[0095] S6: Waiting thread 1 performs specific business processing according to the type of wakeup.

[0096] Fig. 9 The figure is a schematic diagram of asynchronous-to-synchronous service calls across containers in a distributed system, including thread 1, waiting thread mapping table 2, timeout cleaner 3, notification receiver 4, thread 5, thread 6, database 7, notification sending queue 8, and notification sender 9.

[0097] Thread 1 refers to a thread in a container within the business server group (such as Figure 8 The thread 1 of container A shown in FIG. 1 ) specifically refers to the thread responsible for service call processing, such as a Dubbo thread. There are multiple threads in a container, and only one thread diagram in the service call is listed here. Before the service call, thread 1 will store its information in the waiting thread mapping table 2, then make an RPC call to thread 5, and finally enter the sleep state and wait for wake-up.

[0098] Waiting thread mapping table 2 refers to a mapping table of call event ID and waiting thread related information, which is a thread-safe hash table. Waiting thread mapping table 2 is created when the container is started. The KEY value is the call event ID, and the VALUE value is the related information of thread 1. For the specific structure, see Figure 2 .

[0099] The timeout cleaner 3 refers to a delayed thread pool that cleans the data in the waiting thread mapping table 2. The timeout cleaner 3 can clean up the abnormally timed waiting threads in time, maintain the validity of the data in the waiting thread mapping table 2, so that the threads will not be unable to be recycled due to infinite waiting, and obtain a protection system.

[0100] The notification receiver 4 refers to a thread that subscribes to a certain distributed message queue topic. By subscribing to the topic, the notification receiver 4 can receive the callback notification in time, and find the waiting thread from the waiting thread mapping table 2 according to the received event ID to wake it up.

[0101] Thread 5 refers to a thread in a container within the external system, specifically the thread responsible for service call processing, such as the Dubbo thread. This thread is the actual processor of the service provider. After receiving the request, it processes the business content and finally calls the callback service provided by the acquiring system.

[0102] Thread 6 is essentially the same as thread 1. The only difference is that it is not in the same container as thread 1 and is logically isolated. For example, thread 1 is in container A and thread 6 is in container B. After receiving the callback, thread 6 first stores the result in database 7 as a basis for subsequent queries and backup processing. Then the event ID is stored in the notification sending queue 8 to end the callback processing. The work content of thread 6 should be as small as possible to speed up the wake-up time of the waiting thread, which can reduce the total waiting time. It should be noted here that each component in container A where the waiting thread 1 is located and container B where the notification receiving thread 6 is located is the same, including the waiting thread mapping table 2, timeout cleaner 3, notification receiver 4, notification sending queue 8, and notification sender 9. The figure only illustrates the key process of asynchronous to synchronous calls across containers, so they are not listed one by one.

[0103] Database 7 refers to a relational database in the database server group, which is the same as the database of the database server group introduced above and will not be elaborated here.

[0104] The notification sending queue 8 is a chain structure queue storing the event ID to be sent. The notification sending queue 8 is a bounded, thread-safe queue. The purpose of introducing this queue is that the notification receiving thread 6 only needs to store the event ID in the queue, and does not need to worry about how to send or when to send, so as to achieve the effect of decoupling from the notification sender 9. At the same time, this can enable the notification receiving thread 6 to end quickly, release the thread, and improve system resource utilization.

[0105] The notification sender 9 is a thread that publishes a distributed message queue topic. The notification sender 9 continuously reads the content of the notification sending queue 8, then publishes the read event ID to its topic, and finally removes the event ID from the notification sending queue 8 after the sending is completed.

[0106] See also Fig.10 , step S5 further comprises:

[0107] Step S101: the timeout cleaner takes out a thread from the thread pool to start a cleaning operation.

[0108] Step S102: Search the waiting thread mapping table according to the event ID. If it can be found, it means that the waiting thread has not been awakened, and go to step S103; if it cannot be found, it means that the waiting thread has been awakened, and go to step S109.

[0109] Step S103: Take out the timeout time in the current record of the waiting thread mapping table, and determine whether the current time is greater than or equal to the timeout time. If so, it means that it has indeed timed out, and go to step S105; if not, it means that there is a gap between the delayed job start time and the actual recorded time, and it has not timed out, and go to step S104.

[0110] Step S104: If the timeout has not yet occurred, wait for another 5 milliseconds and go back to step S102 to repeat the process. This step is a compatibility processing step and is generally not performed.

[0111] Step S105: It has timed out, and an error message is printed out. The error message format is: "Current service is: XXX, event ID is: XXX, timeout period is: XXX, storage time is: XXX, service input content is: XXX, thread waiting has timed out.", where XXX needs to be instantiated according to the content recorded in the waiting thread mapping table.

[0112] Step S106: Send the above error information to a unified monitoring platform.

[0113] Step S107: Use the Condition object to wake up the waiting thread and inform it that the reason for this wake-up is timeout.

[0114] Step S108: remove the record from the waiting thread mapping table.

[0115] Step S109: the delayed job processing is completed and the thread is returned to the thread pool.

[0116] See also Fig.11 Based on step S101 to step S109, the present invention further provides more specific implementation steps of the distributed cross-container asynchronous to synchronous calling method:

[0117] Step S201: Before the RPC service calls a thread 2 (hereinafter referred to as thread 2) on container B of the external system, a thread 1 (hereinafter referred to as thread 1) on container A in the acquiring system first generates an event ID using the snowflake algorithm, and uses the event ID of this call as the KEY, and the Condition object, timeout time, storage time, and input object of this call as the VALUE to store them in the waiting thread mapping table. At the same time, a delayed job is set, which is scheduled by the queue timeout cleaner, and the delay time is consistent with the timeout time.

[0118] Step S202: Thread 1 asynchronously calls the service provided by Thread 2, and simultaneously sends in the event ID of this call, and requires Thread 2 to return the event ID as is when making a callback.

[0119] Step S203: The Condition object causes thread 1 to enter a sleep state, waiting to be awakened.

[0120] Step S204: After thread 2 is processed, RPC asynchronously calls the service of a thread 3 (hereinafter referred to as thread 3) on container C in the acquiring system, and returns the original event ID as it is.

[0121] Step S205: After receiving the callback, thread 3 stores the result in the database for subsequent query and analysis.

[0122] Step S206: Thread 3 sends the event ID to the notification sending queue and ends the process.

[0123] Step S207: The notification sender starts when the container starts, and continuously takes data from the notification sending queue. If the data is empty, wait for 5 milliseconds before taking it again; if there is a value, go to step S208.

[0124] Step S208: Use Kafka to publish information with the topic TOPIC_ASYNTOSYN_SETX (X is a number, indicating the number of the business server group). When the transmission is successful, the event ID is removed from the transmission queue; otherwise, retry 3 times. After 3 retries, if the transmission still fails, remove the event ID from the transmission queue, print and send the alarm information to the unified monitoring platform. The format of the alarm information is: "The current service is: XXX, the event ID is: XXX, and the information publishing failed", where XXX needs to be instantiated according to the service and event ID.

[0125] Step S209: The receiver is notified that it has subscribed to the information with the subject TOPIC_ASYNTOSYN_SETX. After receiving the information, the event ID is used as the KEY value to search in the waiting thread mapping table. If found, the process jumps to step S211; otherwise, the process proceeds to step S210.

[0126] Step S210: If the record corresponding to the event ID cannot be found, there are two situations: one is that the time of receiving the information is later than the waiting time, and the record has been removed by the queue timeout cleaner; the other is that there are multiple containers subscribing to the same topic, and this service call does not occur on this container. In this case, the event ID can be directly ignored.

[0127] Step S211: Find the record corresponding to the event ID, take out the Condition object of the record from VALUE, use the Condition object to wake up thread 1, and inform that the reason for this wake-up is that the callback has been completed, and finally remove the record from the waiting thread mapping table.

[0128] Step S212: This step is an independent step. The queue timeout cleaner is started when the container is started. Whenever the delay time is reached, the queue timeout cleaner takes out a thread from the thread pool to call the job. Fig.10 Same as described.

[0129] From the above description, it can be seen that the present invention provides a method for implementing the transformation of asynchronous call services across containers in a distributed system into synchronous call services, using a distributed message queue to solve the communication problem between two processes, reducing the problem of waiting threads consuming system resources during the waiting process, and blocking and waking up waiting threads through inter-thread collaboration, so that system resources are released.

[0130] Based on the same inventive concept, the embodiments of the present application also provide an asynchronous-to-synchronous call device based on a distributed cross-container, which can be used to implement the method described in the above embodiments, such as the following embodiments. Since the principle of solving the problem based on the asynchronous-to-synchronous call device based on a distributed cross-container is similar to the asynchronous-to-synchronous call method based on a distributed cross-container, the implementation of the asynchronous-to-synchronous call device based on a distributed cross-container can refer to the implementation of the asynchronous-to-synchronous call method based on a distributed cross-container, and the repeated parts will not be repeated. As used below, the terms "unit" or "module" can be a combination of software and / or hardware that implements predetermined functions. Although the system described in the following embodiments is preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and conceived.

[0131] The embodiment of the present invention provides a specific implementation of a distributed cross-container-based asynchronous-to-synchronous call device that can implement a distributed cross-container-based asynchronous-to-synchronous call method, see Fig.12 The asynchronous-to-synchronous calling device based on distributed cross-container specifically includes the following contents:

[0132] A data writing module 10 is used to write the event ID and thread information of the current service call into the waiting thread mapping table by using the thread in the first container in the system;

[0133] A thread calling module 20, configured to call a thread in a second container according to the event ID and a thread in an RPC service outside the system; both the first container and the second container are within the system;

[0134] The result notification module 30 is used to respond to the call result notification of the thread in the second container and search the waiting thread mapping table for corresponding waiting thread information according to the thread in the first container.

[0135] In one embodiment, before calling the thread in the second container according to the thread in the RPC service outside the system; the first container and the second container are both in the system: the thread in the first container is in a sleeping state;

[0136] In one embodiment, see Fig.13 , the result notification module 30 includes:

[0137] A result writing unit 301 is used to write the call result and the event ID into the notification sending queue;

[0138] A notification unit 302, configured to notify the thread in the first container of the call result notification according to the notification sending queue;

[0139] The information searching unit 303 is used to search the waiting thread information corresponding to the event ID in the waiting thread mapping table.

[0140] In one embodiment, see Fig.14 The distributed cross-container asynchronous to synchronous calling device also includes:

[0141] A thread awakening module 40 is configured to awaken the thread in the first container according to the waiting thread information when the waiting thread information corresponding to the event ID is found in the waiting thread mapping table;

[0142] In one embodiment, see Fig.15 The distributed cross-container asynchronous to synchronous calling device also includes:

[0143] The timeout notification module 50 is used to delete the event ID and thread information in the waiting thread mapping table and notify the thread in the first container that the call has timed out when no call result notification of the thread in the second container is received within a preset time period.

[0144] From the above description, it can be seen that the asynchronous-to-synchronous calling device based on distributed cross-container provided in the embodiment of the present invention first receives the native load balancing model and the target image version of the application to be upgraded; determines the pod list corresponding to the native load balancing model; and modifies the image file in the pod file to the target image version according to the pod list. The present invention can perform in-place upgrades of containers based on Kubernetes native workloads, without the need to migrate applications deployed based on Kubernetes native load models to custom load models, saving the workload of application migration and avoiding the risks brought by migration. On the other hand, the present invention saves the time of rescheduling pods and speeds up upgrades.

[0145] Reference below Fig.16, which shows a schematic structural diagram of an electronic device 600 suitable for implementing an embodiment of the present application.

[0146] like Fig.16 As shown, electronic device 600 includes a central processing unit (CPU) 601, which can perform various appropriate operations and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage portion 608 into a random access memory (RAM) 603. In RAM 603, various programs and data required for the operation of system 600 are also stored. CPU 601, ROM 602, and RAM 603 are connected to each other via a bus 604. An input / output (I / O) interface 605 is also connected to bus 604.

[0147] The following components are connected to the I / O interface 605: an input section 606 including a keyboard, a mouse, etc.; an output section 607 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN card, a modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the I / O interface 605 as needed. A removable medium 611, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 610 as needed, so that a computer program read therefrom is installed as needed as the storage section 608.

[0148] In particular, according to an embodiment of the present invention, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present invention includes a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the steps of the above-mentioned method for determining the distance between people in a data center scenario are implemented, and the steps include:

[0149] Step 100: Receive the native load balancing model and target image version of the application to be upgraded;

[0150] Step 200: Determine a pod list corresponding to the native load balancing model;

[0151] Step 300: modify the image file in the pod file to the target image version according to the pod list.

[0152] In such an embodiment, the computer program may be downloaded and installed from a network via the communication section 609 , and / or installed from the removable medium 611 .

[0153] For the convenience of description, the above device is described in various units according to their functions. Of course, when implementing the present application, the functions of each unit can be implemented in the same or multiple software and / or hardware.

[0154] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0155] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0156] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, an element defined by the sentence "comprises a ..." does not exclude the existence of other identical elements in the process, method, commodity or device including the element.

[0157] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0158] The above are only embodiments of the present application and are not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.

Claims

1. A distributed cross-container asynchronous to synchronous calling method, characterized in that: include: Using the thread in the first container in the system, the event ID and thread information of the current service call are written into the waiting thread mapping table; Adjusting the thread in the first container to a sleep state; Calling a thread in a second container according to the event ID and a thread in an RPC service outside the system; both the first container and the second container are in the system; In response to the call result notification of the thread in the second container, corresponding waiting thread information is searched in the waiting thread mapping table according to the thread in the first container.

2. The distributed cross-container-based asynchronous to synchronous calling method according to claim 1 is characterized in that: Before the thread in the RPC service outside the system calls the thread in the second container and the first container and the second container are both in the system: the thread in the first container is in a sleeping state.

3. The distributed cross-container-based asynchronous to synchronous calling method according to claim 1 is characterized in that: The step of responding to the call result notification of the thread in the second container and searching the waiting thread mapping table for corresponding waiting thread information according to the thread in the first container includes: Write the call result and the event ID into the notification sending queue; Notify the thread in the first container of the call result notification according to the notification sending queue; The waiting thread information corresponding to the event ID is searched in the waiting thread mapping table.

4. The distributed cross-container-based asynchronous to synchronous calling method according to claim 3 is characterized in that: Also includes: When the waiting thread information corresponding to the event ID is found in the waiting thread mapping table, the thread in the first container is woken up according to the waiting thread information.

5. The distributed cross-container-based asynchronous to synchronous calling method according to claim 1, characterized in that: Also includes: When no call result notification of the thread in the second container is received within a preset time period, the event ID and thread information in the waiting thread mapping table are deleted, and the thread in the first container is notified that the call has timed out.

6. A distributed cross-container asynchronous to synchronous calling device, characterized in that: include: A data writing module, used to write the event ID and thread information of the current service call into the waiting thread mapping table by using the thread in the first container in the system; and adjusting the thread in the first container to a sleep state; a thread calling module, configured to call a thread in a second container according to the event ID and a thread in an RPC service outside the system; the first container and the second container are both within the system; A result notification module is used to respond to the call result notification of the thread in the second container and search the waiting thread mapping table for corresponding waiting thread information according to the thread in the first container.

7. The distributed cross-container-based asynchronous-to-synchronous calling device according to claim 6 is characterized in that: Before calling the thread in the second container according to the thread in the RPC service outside the system; and before both the first container and the second container are in the system: the thread in the first container is in a sleeping state; The result notification module includes: A result writing unit, used for writing the call result and the event ID into the notification sending queue; A notification unit, configured to notify the thread in the first container of the call result notification according to the notification sending queue; The information searching unit is used to search the waiting thread information corresponding to the event ID in the waiting thread mapping table.

8. The distributed cross-container-based asynchronous-to-synchronous calling device according to claim 7, characterized in that: Also includes: A thread awakening module, configured to awaken the thread in the first container according to the waiting thread information when the waiting thread information corresponding to the event ID is found in the waiting thread mapping table; A timeout notification module is used to delete the event ID and thread information in the waiting thread mapping table and notify the thread in the first container that the call has timed out when no call result notification of the thread in the second container is received within a preset time period.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the program, the steps of the distributed cross-container-based asynchronous to synchronous calling method according to any one of claims 1 to 5 are implemented.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the distributed cross-container-based asynchronous to synchronous calling method according to any one of claims 1 to 5 are implemented.

Images