CN113190624B

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

Info

Publication number: CN113190624B
Application number: CN202110556705.1A
Authority: CN
Inventors: 苏志康; 孙韶; 徐惠珊; 陈兴
Original assignee: Industrial and Commercial Bank of China Ltd ICBC
Current assignee: Industrial and Commercial Bank of China Ltd ICBC
Priority date: 2021-05-21
Filing date: 2021-05-21
Publication date: 2025-05-09
Anticipated expiration: 2041-05-21
Also published as: CN113190624A

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

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

Technical Field

The invention belongs to the technical field of big data, in particular to a distributed system service call, and particularly relates to a distributed cross-container based asynchronous-to-synchronous call method and device.

Background

In the prior art, the realization mode of converting the asynchronous call service into the synchronous call service is to block the current thread after the call service is called, and wait for the called party to return the result or overtime. Here, the called party is required to return effective information, and the calling party can perform the next processing according to the returned information. However, some called party services only provide asynchronous mode, and the same result is returned no matter success or failure, even the result is not returned, and the true processing result can be informed only through another service of the callback calling party. In the distributed system, the thread receiving the result and the thread waiting for the result are not in the same container, if the thread desiring to receive the result notifies the thread waiting for the result after receiving the result, the problem of mutual communication between the two threads occurs, and meanwhile, the problem of consuming system resources by the waiting thread in the waiting process also exists. If the two threads are not on the same server, the problem of cooperative communication between the two processes is also involved, so that the system resources consumed by the waiting threads in the waiting process are increased.

Disclosure of Invention

The invention belongs to the technical field of big data, and provides a distributed cross-container based asynchronous-to-synchronous call method and a device thereof, which solve the problem that asynchronous call service in the existing distributed system also needs to synchronously return results to a caller. The utilization rate of system resources is greatly improved. And a timeout cleaner is introduced to clean the record of the timeout so as to maintain the validity of the mapping table, provide searching efficiency, and wake the sleeping thread to finish the service logic release thread as soon as possible so as to avoid system breakdown. For the abnormal condition sent by the notification sender and the overtime cleaning condition of the overtime cleaner, the method combines the monitoring system in the system to send an alarm in time, so that an application operation and maintenance personnel can grasp the service calling condition of the system in time.

In order to solve the technical problems, the invention provides the following technical scheme:

In a first aspect, the present invention provides a distributed cross-container based asynchronous-to-synchronous call method, including:

writing an event ID of a current service call and thread information into a waiting thread mapping table by using a thread in a first container in a system;

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

Responding to the call result notification of the thread in the second container, and searching corresponding waiting thread information in the waiting thread mapping table according to the thread in the first container.

In one embodiment, the thread in the second container is invoked according to a thread within an RPC service outside the system; the first container and the second container are both in front of the system, the threads in the first container being in a sleep state.

In an embodiment, the responding to the notification of the call result of the thread in the second container searches the corresponding waiting thread information in the waiting thread mapping table according to the thread in the first container, and includes:

Writing the calling result and the event ID into a notification transmission queue;

notifying a thread in the first container of the call result notification according to the notification sending queue;

and searching waiting thread information corresponding to the event ID in the waiting thread mapping table.

In one embodiment, the asynchronous transfer synchronous call method based on the distributed cross-container further comprises the following steps:

when waiting thread information corresponding to the event ID is found in the waiting thread mapping table, waking up a thread in the first container according to the waiting thread information.

and deleting the event ID and the thread information in the waiting thread mapping table when the notification of the calling result of the thread in the second container is not received within a preset time period, and notifying that the calling of the thread in the first container is overtime.

In a second aspect, the present invention provides an asynchronous-to-synchronous call device based on distributed cross-container, including:

The data writing module is used for writing the event ID and the thread information of the current service call into the waiting thread mapping table by using the thread in the first container in the system;

The thread calling module is used for calling threads in a second container according to the event ID and threads in the RPC service outside the system, wherein the first container and the second container are both in the system;

and the result notification module is used for responding to the call result notification of the thread in the second container and searching corresponding waiting thread information in the waiting thread mapping table according to the thread in the first container.

In one embodiment, the thread in the second container is invoked according to a thread within an RPC service outside the system; the first container and the second container are in front of the system, wherein the thread in the first container is in a sleep state;

The result notification module includes:

The result writing unit is used for writing the calling result and the event ID into the notification sending queue;

a notification notifying unit, configured to notify, according to the notification sending queue, the thread in the first container of the notification of the call result;

and the information searching unit is used for searching the waiting thread information corresponding to the event ID in the waiting thread mapping table.

In one embodiment, the asynchronous transfer synchronous call device based on the distributed cross-container further comprises:

the thread awakening module is used for awakening 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;

And the overtime notification module is used for deleting the event ID and the thread information in the waiting thread mapping table and notifying that the calling of the thread in the first container is overtime when the calling result notification of the thread in the second container is not received within the preset time period.

In a third aspect, the present invention provides an electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, the processor implementing the steps of a distributed cross-container based asynchronous to synchronous call method when executing the program.

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

As can be seen from the above description, the asynchronous transfer synchronous call method and device based on distributed cross-container provided by the embodiment of the invention firstly write the event ID and the thread information of the current service call into the pre-generated waiting thread mapping table by using the thread in the first container in the system, then call 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, and finally respond to the call result notification of the thread in the second container, and search the corresponding waiting thread information in the waiting thread mapping table according to the thread in the first container. The invention solves the problem that the asynchronous call service in the distributed system in the prior art needs to synchronously return the result to the caller. And the problem that the cross-container and cross-database cannot be notified is solved by using the distributed message queue, the problem of thread cooperation in the same container is solved by using the thread lock, and the utilization rate of system resources is greatly improved. In order to reduce the problem that the notification receiver does not receive information for a long time due to network delay or system abnormality, the invention also introduces a record of the overtime of the queue overtime cleaner to maintain the validity of the mapping table, provides searching efficiency, and wakes the sleep thread to complete the service logic release thread as soon as possible so as to avoid system breakdown. For the abnormal condition sent by the notification sender and the overtime cleaning condition of the overtime cleaner, the invention combines the monitoring system in the system to send an alarm in time, so that an application operation and maintenance personnel can grasp the service calling condition of the system in time.

Drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings that are required in the embodiments or the description of the prior art will be briefly described, and it is obvious that the drawings in the following description are some embodiments of the present invention, and other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a schematic diagram of a flow chart of an asynchronous transfer synchronous call method based on a distributed cross-container in an embodiment of the invention;

FIG. 2 is an internal block diagram of a waiting thread map in an embodiment of the present invention;

FIG. 3 is a flowchart illustrating a step 300 in a distributed cross-container based asynchronous to synchronous call method according to an embodiment of the present invention;

FIG. 4 is a schematic diagram of a second flow chart of an asynchronous-to-synchronous call method based on a distributed cross-container in an embodiment of the invention;

FIG. 5 is a flowchart of an asynchronous-to-synchronous call method based on a distributed cross-container in an embodiment of the present invention;

FIG. 6 is a service invocation link diagram of the order service in the specific application example of the present invention;

FIG. 7 is a diagram illustrating the internal system configuration of the order receiving system in an embodiment of the present invention;

FIG. 8 is a flowchart of a method for asynchronous to synchronous call based on distributed cross-container in an embodiment of the present invention;

FIG. 9 is a schematic diagram of asynchronous to synchronous service call across containers in a distributed system in an embodiment of the invention;

FIG. 10 is a flowchart of a timeout cleaner cleaning strategy in an embodiment of the present invention;

FIG. 11 is a second schematic flow chart of an asynchronous-to-synchronous call method based on distributed cross-container in an embodiment of the present invention;

FIG. 12 is a schematic diagram of a distributed cross-container asynchronous-to-synchronous call device according to an embodiment of the present invention;

fig. 13 is a schematic structural diagram of a result notification module 30 in a specific application example of the present invention;

FIG. 14 is a second schematic structural diagram of an asynchronous-to-synchronous call device based on a distributed cross-container in an embodiment of the present invention;

FIG. 15 is a third schematic structural diagram of an asynchronous-to-synchronous call device based on a distributed cross-container in an embodiment of the present invention;

Fig. 16 is a schematic structural diagram of an electronic device in an embodiment of the invention.

Detailed Description

For the purpose of making the objects, technical solutions and advantages of the embodiments of the present invention more apparent, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention, and it is apparent that the described embodiments are some embodiments of the present invention, but not all embodiments of the present invention. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.

It will be appreciated by those skilled in the art that embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

It is noted that the terms "comprises" and "comprising," and any variations thereof, in the description and claims of the present application and in the foregoing figures, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed or inherent to such process, method, article, or apparatus.

It should be noted that, without conflict, the embodiments of the present application and features of the embodiments may be combined with each other. The application will be described in detail below with reference to the drawings in connection with embodiments.

The embodiment of the invention provides a specific implementation manner of an asynchronous transfer synchronous call method based on distributed cross-container, and referring to fig. 1, the method specifically comprises the following steps:

And 100, writing the event ID of the current service call and the thread information into a waiting thread mapping table by using the thread in the first container in the system.

Specifically, the thread of the first container stores the time ID of the service call and the thread information in the waiting thread mapping table. The waiting thread mapping table is a hash table structure of KV key value pairs. The KEY stores an event ID, and the actual meaning of the event ID is a unique serial number which can be generated by a current container at the current time under a distributed system, and the event ID can be generated by using a snowflake algorithm, or a UUID, or a custom rule can be applied. The VALUE holds information of the thread object, which includes Condition object, timeout time, deposit time, thread input object. Condition objects refer to Condition objects created by a current thread lock that enable a thread to go to sleep or wake. The timeout time refers to how long the thread waits after the service call is made, and the thread does not wait any more. The time of storing refers to the time of storing the mapping table, and is used for analyzing the problem after the abnormality occurs. The thread input object refers to the input content of the service call, is used for subsequent processing after the thread wakes up, and can also be used as an analysis problem, and the details are shown in fig. 2.

Step 200, calling a thread in a second container according to the event ID and the thread in the RPC service outside the system, wherein the first container and the second container are both in the system.

Based on step 100, it is allowed for a program to call a thread in a second container to call a thread in a first container, then the thread in the first container is adjusted to a sleep state, waiting for subsequent steps to be looped, based on the time ID and the RPC service (RPC (Remote Procedure Call) is an inter-process communication mode) external to the system, and it is emphasized that the first container and the second container are both within the system, and the RPC service is external to the system, as will be appreciated that by this arrangement, the utilization of system resources can be greatly improved.

And 300, responding to the call result notification of the thread in the second container, and searching corresponding waiting thread information in the waiting thread mapping table according to the thread in the first container.

Specifically, after receiving a callback service request initiated by a thread within the RPC service, the second container stores the result in the database and stores the event ID in the notification send queue. The notification transmitter publishes the content to its topic by continually scanning the content of the notification transmission queue. The event ID is obtained after the notification receiver of the first container receives the published information. And according to the event ID, notifying the receiver to search the waiting thread information from the waiting thread mapping table.

As can be seen from the above description, the asynchronous transfer synchronous call method based on the distributed cross-container provided by the embodiment of the invention firstly uses the thread in the first container in the system to write the event ID and the thread information of the current service call into the pre-generated waiting thread mapping table, then calls 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, and finally responds to the call result notification of the thread in the second container, and searches the corresponding waiting thread information in the waiting thread mapping table according to the thread in the first container. The invention solves the problem that the asynchronous call service in the distributed system in the prior art needs to synchronously return the result to the caller. And the problem that the cross-container and cross-database cannot be notified is solved by using the distributed message queue, the problem of thread cooperation in the same container is solved by using the thread lock, and the utilization rate of system resources is greatly improved. In order to reduce the problem that the notification receiver does not receive information for a long time due to network delay or system abnormality, the invention also introduces a record of the overtime of the queue overtime cleaner to maintain the validity of the mapping table, provides searching efficiency, and wakes the sleep thread to complete the service logic release thread as soon as possible so as to avoid system breakdown. For the abnormal condition sent by the notification sender and the overtime cleaning condition of the overtime cleaner, the invention combines the monitoring system in the system to send an alarm in time, so that an application operation and maintenance personnel can grasp the service calling condition of the system in time.

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

It will be appreciated that adjusting the threads in the first container to a sleep state is essentially the use of thread locks to solve the problem of thread collaboration within the same container.

In one embodiment, referring to fig. 3, step 300 further comprises:

Step 301, writing the calling result and the event ID into a notification transmission queue;

Step 302, notifying the thread in the first container of the call result notification according to the notification transmission queue;

step 303, searching the waiting thread information corresponding to the event ID in the waiting thread mapping table.

After the thread of the second container stores the call result in the database, the time ID is stored in the notification transmission queue in steps 301 to 302. The notification transmitter publishes the content to its topic by continually scanning the content of the notification transmission queue. The notification receiver of the first container receives the published information and obtains the event ID. And according to the event ID, notifying the receiver to search the corresponding waiting thread information from the waiting thread mapping table.

In one embodiment, referring to fig. 4, the asynchronous transfer synchronous call method based on the distributed cross-container further includes:

Step 400, when waiting thread information corresponding to the event ID is found in the waiting thread mapping table, waking up a thread in the first container according to the waiting thread information.

In one embodiment, referring to fig. 5, the asynchronous transfer synchronous call method based on the distributed cross-container further includes:

And 500, deleting the event ID and the thread information in the waiting thread mapping table and notifying that the thread call in the first container is overtime when the call result notification of the thread in the second container is not received within a preset time period.

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 receiver wakes up the waiting thread to inform that the callback is completed, and if the receiver cannot find the corresponding waiting thread information, the receiver ignores the information.

When the notification receiver of the first container does not receive information for a long time, a timeout cleaner is used for cleaning records in a waiting thread mapping table, and a waiting thread is awakened to notify that the waiting thread has timed out. And finally, carrying out specific business processing by the waiting thread according to the awakening type.

On the other hand, a timeout cleaner herein refers to a pool of delay threads that cleans up data in a waiting thread map. The overtime cleaner can timely clean the overtime waiting thread, and keep the validity of the data in the waiting thread mapping table, so that the data cannot be recycled due to infinite waiting of the thread, and the function of a protection system is achieved.

In order to further explain the scheme, the invention takes the order-receiving service between the bank and the merchant as an example, and provides a specific application example of the asynchronous transfer synchronous call method based on distributed cross-container.

Fig. 6 is a service call link diagram of the order receiving service, and one service request call passes through 5 systems, namely a merchant system 1, an API system 2, an order receiving system 3, an external connection system 4 and a banking system 5.

The merchant system 1 refers to a merchant's own business processing system, which includes a front-end and a back-end system. After the merchant processes the business logic, the interface is encrypted and signed according to the specification of the API interface, and the interface provided by the API system is called.

API system 2 refers to a unified entry system provided by the industry to access merchant requests. The API system 2 carries out decryption and signature verification processing on the API interface, verifies the validity and the safety of the request, converts the HTTPS request into an RPC request with higher efficiency, and invokes the service of the order receiving system 3 through the intranet.

The order receiving system 3 is a core system for processing the order receiving service of the industry. The acquiring system 3 provides a series of services to the API system 2 call and provides different callback services to the foreign system 4 call. The internal system structure of the order receiving system 3 is shown in fig. 7. The system comprises a registry 3-1, a distributed message queue 3-2, a service server group 3-3-3, a service server group 3-3-4, a database server group 3-5 and a database server group 3-6, and specifically:

The registry 3-1 is a service registry, and records the mapping relationship between services and service addresses. The system has the functions of service discovery, service configuration, service health check and the like, and a common distributed registry is Zookeeper, eureka, consul, nacos. The registry 3-1 is a highly available registry cluster for cross-campus deployment, ensuring that one campus can still operate properly when it has a catastrophic problem. Or when the single registry is abnormal, other registries can provide stable functions to ensure the stable operation of the system. In the order receiving system, each container will register a service to the registry 3-1 at start-up. When a container is offline, the registry 3-1 will offline all service providers of the container, and then notify consumers on other containers to reject the service provider, thereby ensuring the availability of service call.

The distributed message queue 3-2 refers to a high-performance, high-availability, scalable and final-consistency middleware which is realized by solving the problems of application coupling, asynchronous message, flow cutting and the like in a distributed scene, and common distributed message queues comprise ActiveMQ, rabbitMQ, zeroMQ, kafka, metaMQ and the like. The distributed message queue 3-2 solves the problem of message synchronization between different containers so that the architecture can be loosely coupled. In order receiving systems, each container of the same service server group subscribes to the same topic, while containers of different service server groups subscribe to different topics. As the subject matter of each container subscription within the service server group 3-3 is the same, while the subject matter of the container subscription within the service server group 3-3 is different from the container subscription within the service server group 3-4. Each container can issue information into the distributed message queue 3-2, and other containers of the service server group in which the container is located can receive the information. Thus, the broadcasting range can be reduced, and the consumption of system resources can be reduced.

The service server groups 3-3 and 3-4 refer to two server groups in the order receiving system for completing service processing. The service server groups 3-3 and 3-4 respectively comprise 3 containers, and the functions of each container are the same, so that the usability of the system is higher. The containers in each service server group are dynamically scalable and can be timely adjusted according to the current resource use condition and concurrency number of the system, so that the scalability of the system is indicated. If the traffic increases for a long period of time, the system may further deploy multiple service server groups. RPC service call can be carried out among different containers, and consumption information can be produced through a message queue. The containers of each service server group are connected with one database server group, and the database server groups connected with different service server groups are different. For example, each container of the service server group 3-3 is connected to the database server group 3-5, and each container of the service server group 3-4 is connected to the database server group 3-6.

Database server set 3-5, database server set 3-6 refers to a master three-standby high availability database cluster. Normally, the read and write operations of the service server group 3-3 and the service server group 3-4 are performed on the main database. When an abnormality occurs, the system can perform master-slave switching, and the read-write operation is performed in the standby library. And the data are synchronized in a semi-synchronous mode between the main library and the standby library, so that the real-time performance and the final consistency of the data are ensured. Databases typically use relational databases to hold data, such as MYSQL, ORACLE, DB < 2 >.

In summary, the relationship between the internal systems of the order receiving system is that the service server group 3-3 and the containers in the service server group 3-4 register the information of service registration and service subscription through the registration center 3-1, publish and subscribe the topic information of each group through the distributed message queue 3-2, complete the reading and writing of data through the database server group 3-5 and the database server group 3-6, and call the service through the RPC protocol.

The external connection system 4 refers to a basic system for unified interfacing of the industry with the card organization. The external connection system 4 sends the request to the corresponding card organization through a special line or the Internet according to different services, and provides a callback interface for the card organization to inform, and the external connection system mainly realizes the basic functions of certificate signature authentication, signature verification unloading and the like.

The banking system 5 refers to a business system associated with banking. The banking system 5 receives the request from each bank and switches to the corresponding order receiving organization.

In summary, the relationship between the systems in the service call link diagram of the order receiving service is that the merchant system 1 initiates an HTTPS request to the API system 2 through the internet, and synchronously waits for the API system 2 to return a result. After receiving the request, the API system 2 converts the HTTPS request into an RPC request, and then invokes one of the services of the order receiving system 3 through the intranet, and synchronously waits for the order receiving system 3 to return a result. After receiving the request, the order receiving system 3 performs service processing, asynchronously calls the service of the external connection system 4 through the intranet, and synchronously waits for the callback result of the external connection system 4. The external connection system 4 initiates an HTTPS or HTTP request to the banking system 5 through a dedicated line or the internet. The UnionPay system 5 sends an HTTPS or HTTP request to the Extranet system 4 to inform the callback result through a special line or the Internet, the Extranet system 4 converts the received callback result into an RPC request, and one callback service of the acquiring system 3 is called through the intranet. After receiving the callback request, the acquiring system 3 returns the processing result to the API system 2.

Referring to fig. 8 and fig. 9, based on the service call link diagram of the above-mentioned order receiving service, the asynchronous transfer synchronous call method based on distributed cross-container in this specific application example includes:

S1, the thread 1 of the container A stores the event ID and the thread information of the service call in the waiting thread mapping table 2, the RPC service calls the thread 5 to call the thread 6, and finally the sleeping state waits for awakening.

And S2, after the thread 5 receives the service processing request, calling callback service. Thread 6 of container B receives the request for callback service, stores the result in database 7, and stores the event ID in notification send queue 8.

The notification transmitter 9 issues the content to its topic by constantly scanning the content of the notification transmission queue 8. The notification receiver 4 of the container a receives the published information, i.e. the event ID is obtained.

S4, according to the event ID, notifying the receiver 4 to search waiting thread information from the waiting thread mapping table 2, if so, waking up the waiting thread 1 to notify that callback is completed, and if not, ignoring the information.

S5, when the notification receiver 4 of the container A does not receive information for a long time, the timeout cleaner 3 cleans up records in the waiting thread mapping table 2 and wakes up the waiting thread 1 to notify that the waiting thread has timed out.

And S6, the waiting thread 1 performs specific business processing according to the awakening type.

FIG. 9 is a schematic diagram of an asynchronous to synchronous service call across containers in a distributed system, including thread 1, a waiting thread map 2, a timeout cleaner 3, a notification receiver 4, thread 5, thread 6, a database 7, a notification send queue 8, and a notification sender 9.

Thread 1 refers to a thread in a certain container within a service server group (e.g., thread 1 of container a shown in fig. 8), and particularly refers to a thread responsible for service call processing, such as Dubbo threads. There will be multiple threads within a container, here only one thread schematic in a service call is enumerated. Before service call, the thread 1 stores own information into the waiting thread mapping table 2, then carries out RPC call thread 5, and finally enters a sleep state to wait for awakening.

The waiting thread mapping table 2 refers to a mapping relation table of calling event ID and information related to the waiting thread, and is a thread safe hash table. Waiting for the thread map 2 to be created with the container started, the KEY VALUE is the call event ID, and the VALUE is the related information of thread 1, and the specific structure is shown in fig. 2.

The timeout cleaner 3 refers to a pool of delayed threads that cleans up the data in the waiting thread map 2. The overtime cleaner 3 can timely clean the waiting thread with abnormal overtime, and keep the validity of the data in the waiting thread mapping table 2, so that the data cannot be recycled due to infinite waiting of the thread, and the function of a protection system is achieved.

The notification receiver 4 refers to a thread subscribing to a distributed message queue topic. The notification receiver 4 can timely receive callback notification through subscribing the theme, and searches the waiting thread mapping table 2 according to the received event ID to wake up the waiting thread.

Thread 5 refers to a thread in a certain container in the inline system, and particularly refers to a thread responsible for service call processing, such as Dubbo threads. The thread is an actual processor of the service provider, processes the service content after receiving the request, and finally invokes the callback service provided by the acquiring system.

Thread 6 is essentially the same as thread 1. The only difference is that it is not in the same container as thread 1, but is logically isolated. If thread 1 is in container A, thread 6 is in container B. After receiving the callback, the thread 6 firstly stores the result into the database 7 to be used as a basis for subsequent inquiry and spam processing. Then, the event ID is stored in the notification transmission queue 8, and the callback processing is ended. The work content of the thread 6 should be as small as possible, so that the wake-up time of the waiting thread is increased, and the total waiting time can be reduced. It should be noted here that each component in the container a in which the waiting thread 1 is located and the container B in which the receiving notification thread 6 is located is identical, and includes a waiting thread mapping table 2, a timeout cleaner 3, a notification receiver 4, a notification transmission queue 8, and a notification transmitter 9. Only the key flow of asynchronous-to-synchronous calls across containers is illustrated in the figure and is not listed one by one.

Database 7 is a relational database within the database server farm, and is the same as the database of the database server farm described above, and is not described here.

The notification transmission queue 8 refers to a chain structure queue storing event IDs to be transmitted. The notification send queue 8 is a bounded, thread-safe queue that is introduced to accept that the notification thread 6 only needs to store the event ID in the queue, and does not care about how to send and when to send, thereby decoupling from the notification sender 9. Meanwhile, the receiving notification thread 6 can be quickly ended, the thread is released, and the utilization rate of system resources is provided.

The notification sender 9 refers to a thread that issues a topic of a distributed message queue. The notification transmitter 9 issues the read event ID to its topic by constantly reading the contents of the notification transmission queue 8, and finally removes the event ID from the notification transmission queue 8 after transmission is completed.

Referring to fig. 10, step S5 further includes:

in step S101, the timeout cleaner takes out a thread from the thread pool to call up cleaning operation.

Step S102, searching a waiting thread mapping table according to the event ID, if the waiting thread mapping table can be found, the step S103 is performed, and if the waiting thread mapping table can not be found, the step S109 is performed, the waiting thread is performed.

Step S103, taking out the timeout time in the current record of the waiting thread mapping table, judging whether the current time is larger than or equal to the timeout time, if yes, judging that the timeout is actually performed, and proceeding to step S105, if not, indicating that the delay operation starting time is different from the actual record time, and not exceeding the timeout, proceeding to step S104.

Step S104, when the time-out is not yet over, waiting for 5 ms, and returning to step S102 to repeat the process. This step is a compatibility processing step and is typically not walked to.

Step S105, printing out error information after overtime, wherein the error information format is that the current service is XXX, the event ID is XXX, the overtime time is XXX, the storage time is XXX, the service input content is XXX, and the thread waits for overtime. ", where XXX needs to be instantiated according to the contents of the waiting thread map record.

And step S106, the error information is sent to a unified monitoring platform.

And S107, waking up the waiting thread by using the Condition object, and informing that the waking reason is overtime.

Step S108, removing the record from the waiting thread mapping table.

Step S109, the completion of the operation processing is delayed to exit, and the thread is returned to the thread pool.

Referring to fig. 11, based on steps S101 to S109, the present invention further provides more specific implementation steps of the asynchronous transfer synchronous call method based on distributed cross-container:

Step S201, before a certain thread 1 (hereinafter referred to as thread 1) on a container A in the order receiving system calls a certain thread 2 (hereinafter referred to as thread 2) on a container B in the external system by RPC service, generating an event ID by using a snowflake algorithm, and storing the event ID of the call as a KEY, a Condition object, a timeout time, a storing time and an input object of the call as a VALUE into a waiting thread mapping table. And setting a delay job, and scheduling by a queue timeout cleaner, wherein the delay time is consistent with the timeout time.

Step S202, the thread 1 asynchronously calls the service provided by the thread 2, and simultaneously sends in the calling event ID, and also requests the thread 2 to return the event ID as it is when callback is performed.

In step S203, the Condition object makes thread 1 enter a sleep state and wait for waking up.

In step S204, after the thread 2 is processed, the RPC asynchronously calls the service of a certain thread 3 (hereinafter referred to as thread 3) on a container C in the order receiving system, and returns the original event ID as it is.

Step S205, after the thread 3 receives the callback, the result is stored in the database for subsequent inquiry and analysis of the problem.

In step S206, the thread 3 sends the event ID into the notification transmission queue, and the process is ended.

Step S207, the notification transmitter is started along with the container start, and continuously takes out data from the notification transmission queue. When the fetch is empty, the fetch is waited for 5 ms and when the fetch has a value, the process goes to step S208.

Step S208, using Kafka to issue information with the topic TOPIC _ ASYNTOSYN _ SETX (X is a number and represents the number of the service server group). And removing the event ID from the transmission queue after successful transmission, otherwise, retrying for 3 times. And after retrying for 3 times, if the transmission still fails, removing the event ID from the transmission queue, printing and transmitting alarm information to the unified monitoring platform. The alarm information format is that the current service is XXX, the event ID is XXX, and the information release fails, wherein XXX needs to be instantiated according to the service and the event ID.

Step S209, notifying the receiver to subscribe to the information with the theme TOPIC _ ASYNTOSYN _ SETX, and after receiving the information, searching in the waiting thread mapping table by using the event ID as a KEY value. If yes, go to step S211, otherwise go to step S210.

Step S210, the record corresponding to the event ID can not be found, and the two cases are that firstly, the time of receiving the information is later than the waiting time, the record is removed by a queue timeout cleaner, and secondly, a plurality of containers subscribing to the same theme are provided, and the service call does not occur on the containers. At this time, the event ID is directly ignored.

Step S211, finding the record corresponding to the event ID, taking out the Condition object of the record from the VALUE, waking up the thread 1 by using the Condition object, informing that the wake-up reason is callback completion, and finally removing the record from the waiting thread mapping table.

Step S212, which is an independent step, the queue timeout cleaner starts up along with the container, and the queue timeout cleaner fetches the thread call job from the thread pool every time the delay time arrives. The specific cleaning strategy is as set forth in fig. 10.

As can be seen from the above description, the present invention provides a method for implementing the transition from the cross-container asynchronous call service to the synchronous call service in the distributed system, which uses the distributed message queue to solve the communication problem between two processes, and reduces the problem that the waiting thread consumes the system resource in the waiting process. And blocking and waking up the waiting thread in a cooperative manner among threads, so that system resources are liberated.

Based on the same inventive concept, the embodiment of the application also provides an asynchronous transfer synchronous call device based on distributed cross-container, which can be used for realizing the method described in the above embodiment, such as the following embodiment. Because the principle of solving the problem of the asynchronous transfer synchronous call device based on the distributed cross-container is similar to that of the asynchronous transfer synchronous call method based on the distributed cross-container, the implementation of the asynchronous transfer synchronous call device based on the distributed cross-container can be implemented by referring to the asynchronous transfer synchronous call method based on the distributed cross-container, and the repetition is omitted. As used below, the term "unit" or "module" may be a combination of software and/or hardware that implements the intended function. While the system described in the following embodiments is preferably implemented in software, implementation in hardware, or a combination of software and hardware, is also possible and contemplated.

The embodiment of the invention provides a specific implementation mode of an asynchronous transfer synchronous call device based on a distributed cross-container, which can realize the asynchronous transfer synchronous call method based on the distributed cross-container, and referring to fig. 12, the asynchronous transfer synchronous call device based on the distributed cross-container specifically comprises the following contents:

A data writing module 10, configured to write an event ID and thread information of a current service call into a waiting thread mapping table by using a thread in a first container in the system;

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, where the first container and the second container are both inside the system;

And the result notification module 30 is configured to respond to the notification of the call result of the thread in the second container, and search corresponding waiting thread information in the waiting thread mapping table according to the thread in the first container.

in one embodiment, referring to fig. 13, the result notification module 30 includes:

a result writing unit 301, configured to write the calling result and the event ID into a notification transmission queue;

a notification notifying unit 302, configured to notify, according to the notification sending queue, the thread in the first container of the notification of the call result;

And an information searching unit 303, configured to search the waiting thread information corresponding to the event ID in the waiting thread mapping table.

In one embodiment, referring to fig. 14, the asynchronous transfer synchronous call device based on the distributed cross-container further includes:

a thread wake-up module 40, configured to wake up a 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;

In one embodiment, referring to fig. 15, the asynchronous transfer synchronous call device based on the distributed cross-container further includes:

And a timeout notifying module 50, configured to delete the event ID and the thread information in the waiting thread mapping table and notify that the thread call in the first container has timed out when the notification of the call result of the thread in the second container is not received within a preset period of time.

From the above description, it can be seen that the asynchronous transfer synchronous call device based on distributed cross-container provided by the embodiment of the invention firstly receives a native load balancing model and a target mirror version of an application to be upgraded, determines a pod list corresponding to the native load balancing model, and modifies the mirror file in the pod file into the target mirror version according to the pod list. The method can upgrade the container in situ based on the Kubernetes native workload, does not need to migrate the application deployed based on the Kubernetes native load model to the custom load model, saves the workload of application migration and avoids the risk brought by migration. On the other hand, the invention saves the time of rescheduling the pod and accelerates the upgrading speed.

Referring now to fig. 16, a schematic diagram of an electronic device 600 suitable for use in implementing embodiments of the present application is shown.

As shown in fig. 16, the electronic apparatus 600 includes a Central Processing Unit (CPU) 601, which can perform various appropriate works and processes according to a program stored in a Read Only Memory (ROM) 602 or a program loaded from a storage section 608 into a Random Access Memory (RAM)) 603. In the RAM603, various programs and data required for the operation of the system 600 are also stored. The CPU601, ROM602, and RAM603 are connected to each other through a bus 604. An input/output (I/O) interface 605 is also connected to bus 604.

Connected to the I/O interface 605 are an input section 606 including a keyboard, a mouse, and the like, an output section 607 including a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, a speaker, and the like, a storage section 608 including a hard disk, and the like, and a communication section 609 including a network interface card such as a LAN card, a modem, and the like. The communication section 609 performs communication processing via a network such as the internet. The drive 610 is also connected to the I/O interface 605 as needed. Removable media 611 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on drive 610 as needed, so that a computer program read therefrom is mounted as needed as storage section 608.

In particular, according to embodiments of the present invention, the processes described above with reference to flowcharts may be implemented as computer software programs. For example, an embodiment of the present invention includes a computer-readable storage medium having stored thereon a computer program which, when executed by a processor, implements the steps of the above-described person distance determination method in a data room-based scenario, the steps comprising:

step 100, receiving a native load balancing model of an application to be upgraded and a target mirror version;

step 200, determining a pod list corresponding to the native load balancing model;

And 300, modifying the image files in the pod files into target image versions according to the pod list.

In such an embodiment, the computer program may be downloaded and installed from a network through the communication portion 609, and/or installed from the removable medium 611.

For convenience of description, the above devices are described as being functionally divided into various units, respectively. Of course, the functions of each element may be implemented in the same piece or pieces of software and/or hardware when implementing the present application.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

In this specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment mainly describes differences from other embodiments. In particular, for system embodiments, since they are substantially similar to method embodiments, the description is relatively simple, as relevant to see a section of the description of method embodiments.

The above is only an example of the present application and is not intended to limit the present application. Various modifications and variations of the present application will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement, etc. which come within the spirit and principles of the application are to be included in the scope of the claims of the present application.

Claims

1. An asynchronous-to-synchronous call method based on distributed cross-container, which is characterized by comprising the following steps:

adjusting the thread in the first container to a sleep state;

2. The asynchronous transfer synchronous call method based on distributed cross-container according to claim 1, wherein the thread in the first container is in a sleep state before the first container and the second container are both in the system.

3. The asynchronous transfer synchronous call method based on distributed cross-container according to claim 1, wherein the responding to the call result notification of the thread in the second container, searching the corresponding waiting thread information in the waiting thread mapping table according to the thread in the first container, comprises:

4. The distributed cross-container based asynchronous to synchronous call method of claim 3, further comprising:

5. The distributed cross-container based asynchronous to synchronous call method of claim 1, further comprising:

6. An asynchronous-to-synchronous call device based on distributed cross-container, comprising:

The system comprises a data writing module, a waiting thread mapping table, a data processing module and a data processing module, wherein the data writing module is used for writing an event ID and thread information of a current service call into the waiting thread mapping table by using a thread in a first container in the system;

7. The asynchronous transfer synchronous call device based on distributed cross-container according to claim 6, wherein the thread in the first container is in a sleep state before the first container and the second container are both in the system;

The result notification module includes:

8. The distributed cross-container based asynchronous transfer synchronous call apparatus of claim 7, further comprising:

9. An electronic device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements the steps of the distributed cross-container based asynchronous to synchronous call method of any one of claims 1 to 5 when the program is executed by the processor.

10. A computer readable storage medium having stored thereon a computer program, which when executed by a processor implements the steps of the asynchronous transfer synchronous call method based on distributed cross-container according to any of claims 1 to 5.