Transaction request processing system and method based on microservice architecture
By introducing a load server and a post-server in the trading system, the transaction request and business request are separated, and the problems of low timeliness, high data concurrency and transaction request processing in the existing trading system are solved, and efficient and reliable transaction request processing is achieved.
Patent Information
- Application Number
- CN202210509955.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-05-11
- Publication Date
- 2025-03-04
- Estimated Expiration
- 2042-05-11
AI Technical Summary
The existing trading system based on microservice architecture has problems such as low timeliness, high data concurrency, unavailability of the system, mixed processing of forward and counter-trading requests, low reliability of forward transactions, confusing call relationships, and redeployment of all codes when modifying the entire transaction process.
The transaction request is separated by means of business separation, and the transaction request type is judged through the load server and distributed to the corresponding corridor or rear server for processing. Each corridor is independent of each other to realize diversion processing, and the service requests with low correlation with the transaction request are uniformly processed on the rear server.
It improves the timeliness of transaction requests, ensures the availability of the system in high concurrency situations, distinguishes between processing positive transactions and counter transaction requests to ensure the reliability of positive transactions, simplifies the call relationship, and reduces resource waste when trading process modifications.
Smart Images

Figure CN114881779B_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of transaction request processing, and in particular to a transaction request processing system and method based on a microservice architecture. Background Art
[0002] The current trading system uses a microservice architecture, and each service uses a cluster mode. Microservices divide the entire trading system into multiple small, independent services, which call and cooperate with each other to complete the entire trading process. Figure 4 All services share a database. The request will first reach the load server, which will select a service instance to handle the request. After the request enters the trading system, the trading system will process the verification parameters, upstream requests, risk control checks, billing, account splitting and other services, and return the results to the downstream after the processing is completed. At the same time, the request does not distinguish between types, and all requests will enter the trading system.
[0003] At present, the transaction system based on microservice architecture guarantees data consistency and availability to a certain extent, but the following problems still exist:
[0004] ①Transaction is a special business scenario that has very high requirements for request / response timeliness. In the existing design, a lot of time is spent on processing non-important transactions, which results in an overall increase in the time it takes to process requests.
[0005] ② Multiple services share the same data. In the case of high concurrency, the database may become unavailable, which may cause the system to be unable to provide services;
[0006] ③ The trading system includes two types of transactions: positive transactions and reverse transactions. The existing technology does not distinguish between the two. All requests will enter the trading system, which may cause the positive transaction to be delayed due to the processing of reverse transactions, and the reliability of the positive transaction cannot be well guaranteed;
[0007] ④Each service is clustered, and multiple modules will call each other, but the calling relationship is confusing;
[0008] ⑤ The entire transaction process is in one system. When modifying a certain function, all the codes need to be redeployed and put into production, which wastes resources. Summary of the invention
[0009] The purpose of the present invention is to adopt a business separation approach based on a microservice architecture, with high timeliness requirements for transaction request processing and solve the problem of high data concurrency scenarios, and to provide a transaction request processing system and method based on a microservice architecture, which separates the positive transaction request, the reverse transaction request, and the business request in the transaction request.
[0010] In order to achieve the above-mentioned object of the invention, the embodiment of the present invention provides the following technical solutions:
[0011] The transaction request processing system based on microservice architecture includes:
[0012] The load server is used to determine whether the transaction request sent by the downstream institution is a positive transaction request or a reverse transaction request. If it is a positive transaction request, the positive transaction request is sent to any channel; if it is a reverse transaction request, the reverse transaction request is sent to the back-end server; and the transaction request processed by the channel or the back-end server is sent to the upstream institution;
[0013] A plurality of corridors, each of which is independent of the other, for processing positive transaction requests sent by the load server, and sending the business request carried in the positive transaction request to the back-end server for processing; and processing the reverse transaction request sent by the back-end server, which does not carry the business request;
[0014] The back-end server is used to process the business request carried in the positive transaction request sent by the channel; and to process the business request carried in the reverse transaction request sent by the load server, and send the reverse transaction request to any channel for processing.
[0015] The load server includes a judgment interface, and the judgment interface is used to judge whether the transaction request sent by the downstream institution is a positive transaction request or a negative transaction request.
[0016] Each of the corridors includes a transaction system and a transaction channel, wherein:
[0017] The transaction system is used to determine whether the received transaction request is a positive transaction request sent by the load server or a reverse transaction request sent by the back-end server; if it is a positive transaction request sent by the load server, the positive transaction request is sent to the transaction channel for processing, and the service request carried in the positive transaction request is sent to the back-end server; if it is a reverse transaction request sent by the back-end server, the reverse transaction request is sent to the transaction channel for processing, and the reverse transaction request does not carry the service request;
[0018] The transaction channel is used to process a positive transaction request or a negative transaction request sent by the transaction system.
[0019] Each of the channels also includes a message queue and a first database; the message queue is used to temporarily store unprocessed positive transaction requests sent by the load server and unprocessed reverse transaction requests sent by the back-end server in order of reception time; the first database is used to store the processing process of the transaction channel for positive transaction requests and reverse transaction requests.
[0020] The business request carried in the positive transaction request and the business request carried in the counter-transaction request include a billing request, an account splitting request, and a risk control request.
[0021] The transaction system is also used to receive the response returned by the back-end server after processing the business request carried in the main transaction request, and the response returned by the transaction channel after processing the main transaction request; and send the returned response to the load server, so that the load server sends the processed main transaction request and the business request it carries to the upstream institution.
[0022] The post-server is also used to generate a response after processing the business request carried in the counter-transaction request, and to receive a response returned after the channel processes the counter-transaction request; and to send the returned response to the load server, so that the load server sends the processed counter-transaction request and the business request it carries to the upstream organization.
[0023] The load server is also connected to a first gateway interface, and the first gateway interface is used to select any channel to send a positive transaction request.
[0024] The backend server is also connected to a second gateway interface, and the second gateway interface is used to select any channel to send a reverse transaction request.
[0025] The transaction request processing method based on the microservice architecture includes the following steps:
[0026] Step S1, the load server receives a transaction request sent by a downstream institution, determines whether the transaction request is a positive transaction request or a negative transaction request, and if it is a positive transaction request, sends the positive transaction request to any corridor; if it is a negative transaction request, sends the negative transaction request to the back-end server;
[0027] Step S2, the transaction system in the channel determines whether the received transaction request is a positive transaction request sent by the load server or a reverse transaction request sent by the back-end server; if it is a positive transaction request sent by the load server, the positive transaction request is sent to the transaction channel for processing, and the business request carried in the positive transaction request is sent to the back-end server for processing; if it is a reverse transaction request sent by the back-end server, the reverse transaction request is sent to the transaction channel for processing;
[0028] The post-server determines whether the received transaction request is a reverse transaction request sent by the load server or a service request carried in a positive transaction request sent by the channel; if it is a reverse transaction request sent by the load server, the service request carried in the reverse transaction request is processed and sent to the channel for processing; if it is a service request carried in a positive transaction request sent by the channel, the service request is processed;
[0029] Step S3, the transaction system in the corridor sends the response returned by the transaction channel after processing the positive transaction request and the response returned by the post-server after processing the business request carried in the positive transaction request to the load server;
[0030] The post-server sends the response generated after processing the business request carried in the counter-transaction request and the response returned after the channel processes the counter-transaction request to the load server;
[0031] The load server sends the processed positive transaction request and the business request it carries, and the counter-transaction request and the business request it carries to the upstream institution.
[0032] Compared with the prior art, the present invention has the following beneficial effects:
[0033] (1) This solution separates transaction requests when processing them, which can ensure that transaction requests are not affected by other factors to the greatest extent and meet the high real-time requirements; and business requests that are not highly related to transaction requests are uniformly placed on the back-end server for processing, which can shorten the processing time of the transaction channel for transaction requests, allowing it to respond as quickly as possible and improve user experience;
[0034] (2) This solution has several corridors, and each corridor is independent of each other, which can effectively realize the diversion of transaction requests and share the pressure between corridors;
[0035] (3) This solution can play a role in disaster recovery. When a channel fails, other channels can continue to accept its transaction requests through the message queue of the channel and continue to process the transaction requests without affecting the processing of transaction requests, thereby improving the high reliability of the system.
[0036] (4) When faced with a sudden increase in transaction requests, this solution uses a diversion approach to distribute transaction requests to other channels when one channel reaches the transaction volume. BRIEF DESCRIPTION OF THE DRAWINGS
[0037] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required for use in the embodiments are briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present invention and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without creative work.
[0038] Figure 1 It is a schematic diagram of the system structure of the present invention;
[0039] Figure 2 A schematic diagram of a processing flow for a positive transaction request according to an embodiment of the present invention;
[0040] Figure 3 A schematic diagram of a processing flow for a counter-transaction request according to an embodiment of the present invention;
[0041] Figure 4 This is an existing trading system in the background technology. DETAILED DESCRIPTION
[0042] The technical solutions 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 only a part of the embodiments of the present invention, rather than all the embodiments. The components of the embodiments of the present invention generally described and shown in the drawings here can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present invention provided in the drawings is not intended to limit the scope of the claimed invention, but merely represents the selected embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without making creative work belong to the scope of protection of the present invention.
[0043] It should be noted that similar reference numerals and letters represent similar items in the following drawings, so once an item is defined in one drawing, it does not need to be further defined and explained in the subsequent drawings. At the same time, in the description of the present invention, the terms "first", "second", etc. are only used to distinguish the description, and cannot be understood as indicating or implying relative importance, or implying any such actual relationship or order between these entities or operations.
[0044] Example:
[0045] The present invention is implemented through the following technical solutions, a transaction request processing system based on microservice architecture, see Figure 1 , connects and communicates with upstream and downstream institutions. When receiving a transaction request sent by a downstream institution, it determines whether the transaction request is a positive transaction request or a reverse transaction request. There are different processing methods for positive transaction requests and reverse transaction requests, such as Figure 1 The dotted lines between the medium-load server, the back-end server, and the corridor represent the positive transaction request processing flow, and the solid lines represent the reverse transaction request processing flow, which are sent to the upstream institution after processing. The downstream institution can be a service provider, etc., and the upstream institution can be a UnionPay / NetsPay clearing institution, etc.
[0046] This system includes a load server, a back-end server, and several corridors; each corridor is independent of each other, and each corridor includes a message queue, a transaction system, a transaction channel, and a first database; the load server is connected to a judgment interface and a first gateway; the back-end server is connected to a second gateway.
[0047] See also Figure 2 , as a way to handle positive transaction requests:
[0048] The load server receives a transaction request sent by a downstream institution. After the judgment interface judges that the transaction request is a positive transaction request, it selects any channel through the first gateway to send the positive transaction request to the channel.
[0049] The message queue in the channel temporarily stores the unprocessed active transaction requests sent by the load server. After the trading system determines that the active transaction request in the message queue is sent by the load server, it sends the active transaction request to the trading channel for processing, and at the same time sends the business request carried in the active transaction request to the back-end server for processing.
[0050] After processing the positive transaction request sent by the transaction system, the transaction channel returns a response to the transaction system, and the first database stores the processing process of the positive transaction request by the transaction channel. After processing the business request carried in the positive transaction request, the back-end server returns a response to the transaction system. The transaction system sends the returned response to the load server, so that the load server sends the processed positive transaction request and the business request carried by it to the upstream institution.
[0051] It is easy to understand that the positive transaction request is a positive transaction from a downstream institution to an upstream institution, such as a means of payment. The business requests carried in the positive transaction request include billing requests, account splitting requests, and risk control requests, but not all positive transaction requests carry business requests, so the transaction system needs to judge and separate the positive transaction request and the business request carried therein.
[0052] See also Figure 3 , as a way to handle positive transaction requests:
[0053] The load server receives the transaction request sent by the downstream institution, and after the judgment interface judges that the transaction request is a counter-transaction request, the counter-transaction request is sent to the back-end server.
[0054] The post-server determines that the received transaction request is a counter-transaction request sent by the load server, selects any channel through the second gateway to send the counter-transaction request to the channel for processing, and divides the business request carried in the counter-transaction request for self-processing before sending.
[0055] The message queue of this channel temporarily stores the anti-trading request sent by the back-end server. After the trading system determines that the anti-trading request in the message queue is sent by the back-end server, it sends the anti-trading request to the trading channel for processing.
[0056] After processing the anti-trading request sent by the trading system, the trading channel returns a response to the trading system, and the first database stores the processing process of the anti-trading request by the trading channel, and the trading system sends the response returned by the trading channel to the back-end server.
[0057] After processing the business request carried in the counter-trading request, the back-end server generates a response and sends the response sent by the trading system to the load server, so that the load server sends the processed counter-trading request and the business request it carries to the upstream institution.
[0058] It is easy to understand that the anti-trading request is an anti-trading request by the downstream institution against the upstream institution, such as return, order closing, cancellation, etc. of the positive transaction. The business requests carried in the anti-trading request include billing request, account splitting request, and risk control request, but not all anti-trading requests carry business requests, so the back-end server is required to judge and separate the anti-trading request and the business request carried therein.
[0059] Based on the above system, this solution also proposes a transaction request processing method based on microservice architecture, including the following steps:
[0060] Step S1, the load server receives the transaction request sent by the downstream institution, determines whether the transaction request is a positive transaction request or a reverse transaction request, and if it is a positive transaction request, sends the positive transaction request to any channel; if it is a reverse transaction request, sends the reverse transaction request to the back-end server.
[0061] Step S2, the transaction system in the channel determines whether the received transaction request is a positive transaction request sent by the load server or a reverse transaction request sent by the back-end server; if it is a positive transaction request sent by the load server, the positive transaction request is sent to the transaction channel for processing, and the business request carried in the positive transaction request is sent to the back-end server for processing; if it is a reverse transaction request sent by the back-end server, the reverse transaction request is sent to the transaction channel for processing;
[0062] The post-server determines whether the received transaction request is a reverse transaction request sent by the load server or a business request carried in the positive transaction request sent by the channel; if it is a reverse transaction request sent by the load server, the business request carried in the reverse transaction request is processed and the reverse transaction request is sent to the channel for processing; if it is a business request carried in the positive transaction request sent by the channel, the business request is processed.
[0063] Step S3, the transaction system in the corridor sends the response returned by the transaction channel after processing the positive transaction request and the response returned by the post-server after processing the business request carried in the positive transaction request to the load server;
[0064] The post-server sends the response generated after processing the business request carried in the counter-transaction request and the response returned after the channel processes the counter-transaction request to the load server;
[0065] The load server sends the processed positive transaction request and the business request it carries, and the counter-transaction request and the business request it carries to the upstream institution.
[0066] The above is only a specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any person skilled in the art can easily think of changes or substitutions within the technical scope disclosed by the present invention, which should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention should be based on the protection scope of the claims.
Claims
1. A transaction request processing system based on a microservice architecture, characterized by: include: The load server is used to determine whether the transaction request sent by the downstream institution is a positive transaction request or a reverse transaction request. If it is a positive transaction request, the positive transaction request is sent to any channel; if it is a reverse transaction request, the reverse transaction request is sent to the back-end server; and the transaction request processed by the channel or the back-end server is sent to the upstream institution; Several corridors, each independent of the other, are used to process the positive transaction requests sent by the load server, and send the business requests carried in the positive transaction requests to the back-end server for processing; and processing the anti-transaction request sent by the back-end server, which does not carry a business request; The backend server is used to process the business request carried in the transaction request sent by the channel; and processing the business request contained in the anti-transaction request sent by the load server, and sending the anti-transaction request to any corridor for processing; Each of the corridors includes a transaction system and a transaction channel, wherein: The transaction system is used to determine whether the received transaction request is a positive transaction request sent by the load server or a reverse transaction request sent by the back-end server; if it is a positive transaction request sent by the load server, the positive transaction request is sent to the transaction channel for processing, and the service request carried in the positive transaction request is sent to the back-end server; if it is a reverse transaction request sent by the back-end server, the reverse transaction request is sent to the transaction channel for processing, and the reverse transaction request does not carry the service request; The transaction channel is used to process a positive transaction request or a negative transaction request sent by the transaction system.
2. The transaction request processing system based on microservice architecture according to claim 1, characterized in that: The load server includes a judgment interface, and the judgment interface is used to judge whether the transaction request sent by the downstream institution is a positive transaction request or a negative transaction request.
3. The transaction request processing system based on microservice architecture according to claim 1, characterized in that: Each of the channels also includes a message queue and a first database; the message queue is used to temporarily store unprocessed positive transaction requests sent by the load server and unprocessed reverse transaction requests sent by the back-end server in order of reception time; the first database is used to store the processing process of the transaction channel for positive transaction requests and reverse transaction requests.
4. The transaction request processing system based on microservice architecture according to claim 1, characterized in that: The business request carried in the positive transaction request and the business request carried in the counter-transaction request include a billing request, an account splitting request, and a risk control request.
5. The transaction request processing system based on microservice architecture according to claim 2, characterized in that: The transaction system is also used to receive the response returned by the back-end server after processing the business request carried in the main transaction request, and the response returned by the transaction channel after processing the main transaction request; and send the returned response to the load server, so that the load server sends the processed main transaction request and the business request it carries to the upstream institution.
6. The transaction request processing system based on microservice architecture according to claim 2, characterized in that: The post-server is also used to generate a response after processing the business request carried in the counter-transaction request, and to receive a response returned after the channel processes the counter-transaction request; and to send the returned response to the load server, so that the load server sends the processed counter-transaction request and the business request it carries to the upstream organization.
7. The transaction request processing system based on microservice architecture according to claim 1, characterized in that: The load server is also connected to a first gateway interface, and the first gateway interface is used to select any channel to send a positive transaction request.
8. The transaction request processing system based on microservice architecture according to claim 1, characterized in that: The backend server is also connected to a second gateway interface, and the second gateway interface is used to select any channel to send a reverse transaction request.
9. A transaction request processing method based on a microservice architecture, characterized in that: The following steps are involved: Step S1, the load server receives a transaction request sent by a downstream institution, determines whether the transaction request is a positive transaction request or a negative transaction request, and if it is a positive transaction request, sends the positive transaction request to any corridor; if it is a negative transaction request, sends the negative transaction request to the back-end server; Step S2, the transaction system in the channel determines whether the received transaction request is a positive transaction request sent by the load server or a reverse transaction request sent by the back-end server; if it is a positive transaction request sent by the load server, the positive transaction request is sent to the transaction channel for processing, and the business request carried in the positive transaction request is sent to the back-end server for processing; if it is a reverse transaction request sent by the back-end server, the reverse transaction request is sent to the transaction channel for processing; The post-server determines whether the received transaction request is a reverse transaction request sent by the load server or a service request carried in a positive transaction request sent by the channel; if it is a reverse transaction request sent by the load server, the service request carried in the reverse transaction request is processed and sent to the channel for processing; if it is a service request carried in a positive transaction request sent by the channel, the service request is processed; Step S3, the transaction system in the corridor sends the response returned by the transaction channel after processing the positive transaction request and the response returned by the post-server after processing the business request carried in the positive transaction request to the load server; The post-server sends the response generated after processing the business request carried in the counter-transaction request and the response returned after the channel processes the counter-transaction request to the load server; The load server sends the processed positive transaction request and the business request it carries, and the counter-transaction request and the business request it carries to the upstream institution.
Citation Information
Patent Citations
Online transaction method and device, program product, readable medium and electronic equipment
CN114092256A