CN112751761A - Transaction routing switching method, intermediate system and service processing system - Google Patents
Transaction routing switching method, intermediate system and service processing system Download PDFInfo
- Publication number
- CN112751761A CN112751761A CN202011583697.1A CN202011583697A CN112751761A CN 112751761 A CN112751761 A CN 112751761A CN 202011583697 A CN202011583697 A CN 202011583697A CN 112751761 A CN112751761 A CN 112751761A
- Authority
- CN
- China
- Prior art keywords
- transaction
- route
- service cluster
- load balancing
- service
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 26
- 230000002159 abnormal effect Effects 0.000 claims description 10
- 230000009286 beneficial effect Effects 0.000 description 5
- 238000010586 diagram Methods 0.000 description 4
- 230000003993 interaction Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/38—Flow based routing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1004—Server selection for load balancing
- H04L67/1008—Server selection for load balancing based on parameters of servers, e.g. available memory or workload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
- H04L67/63—Routing a service request depending on the request content or context
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The application provides a back-switch method of transaction routing, an intermediate system and a transaction processing system, wherein the method comprises the following steps: and under the condition that the service route management system receives the transaction request sent by the foreground system, determining the transaction route corresponding to the transaction type indicated by the transaction request according to the preset corresponding relation between the preset transaction type and the configurable multiple transaction routes, and obtaining the target transaction route. Sending the information of the target transaction route to the API gateway; and the API gateway distributes a server site for the transaction request according to the load balancing strategy indicated by the target transaction route. And (3) representing a load balancing strategy: in the original service cluster and the upgraded service cluster, the number of the server sites respectively allocated for responding to the transaction request corresponding to the target transaction route is the same as the number of the server sites under the corresponding service cluster indicated by the target transaction route. The method and the device provide possibility for simple, flexible and efficient transaction routing switchback.
Description
Technical Field
The present application relates to the field of data processing, and in particular, to a transaction routing cutback method, an intermediate system, and a service processing system.
Background
In modern large commercial banks, the request flow of transactions generally includes: the foreground system accesses the middle station system, the middle station system controls and forwards the request to the background system, and the response flow direction is the opposite direction of the request, namely the middle station system is used as a pivot for the connection between the foreground and the background, so that the important function is achieved.
The middle platform system includes a service cluster, and in order to upgrade the middle platform system, an upgrade service cluster having the same function as the original service cluster is developed, for example, the original service cluster in the middle platform system is an a service cluster, and an upgrade service cluster of the a service cluster is developed, which may be referred to as a B service cluster for short.
In order to ensure that the middle platform system can stably transit after being upgraded, namely, in the use process of ensuring that the B service cluster in the middle platform system is stable in performance from the initial performance to the performance, the normal response of the middle platform system to the transaction request is not influenced. How to switch back to the A service cluster from the B service cluster simply, efficiently and flexibly under the condition that the B service cluster is abnormal is a key problem to be solved. For example, the current routing flow of a certain transaction T is a foreground system, a middle station system B service cluster and a background system, when the B service cluster fails, the routing flow of the transaction T needs to be switched back to the foreground, a middle station system a service cluster and a background, and the switching back process needs to have the characteristics of simplicity, high efficiency, stability and the like.
Disclosure of Invention
The application provides a transaction routing cutback method, an intermediate system and a service processing system, and aims to provide a simple, flexible and efficient transaction routing cutback scheme.
In order to achieve the above object, the present application provides the following technical solutions:
the application provides a back-switching method of transaction routing, which is applied to an intermediate system; the intermediate system includes: a middle platform system and a service route management system; the middle station system comprises an API gateway and a service cluster formed by an original service cluster and an upgrading service cluster, and the method comprises the following steps:
the service route management system is used for determining a transaction route corresponding to the transaction type indicated by the transaction request according to a preset corresponding relation between a preset transaction type and a plurality of configurable transaction routes under the condition of receiving the transaction request sent by the foreground system, so as to obtain a target transaction route; transaction routing indication corresponding to any transaction type: the transaction request of the transaction type is allocated to the ratio of the number of the server sites under the original service cluster, and the transaction request of the transaction type is allocated to the ratio of the number of the server sites under the upgraded service cluster.
The service route management system is also used for sending the information of the target transaction route to the API gateway;
the API gateway is used for distributing server sites for the transaction requests according to the load balancing strategy indicated by the target transaction routing; the load balancing strategy is characterized in that: and in the original service cluster and the upgraded service cluster, the number of the server sites respectively allocated for responding to the transaction request corresponding to the target transaction route is the same as the number of the server sites under the corresponding service cluster indicated by the target transaction route.
Optionally, the API gateway is further configured to, when a response of the upgrade service cluster to all types of transaction requests is abnormal, allocate a server site to the transaction request according to a preset load balancing policy.
Optionally, the preset load balancing policy is characterized by: and in the original service cluster and the upgrading service cluster, only the server sites in the original service cluster are allocated to respond to all transaction requests.
Optionally, the service route management system is further configured to update the transaction route corresponding to the transaction type in the preset corresponding relationship to the transaction route indicated by the configuration update information when the configuration update information of the transaction route corresponding to any transaction type is received.
Optionally, the API gateway is further configured to update the load balancing policy corresponding to the transaction route to the load balancing policy indicated by the configuration update information when the configuration update information of the load balancing policy corresponding to any transaction route is received.
The present application further provides an intermediate system, comprising: a middle platform system and a service route management system; the middle platform system comprises an API gateway and a service cluster formed by an original service cluster and an upgrading service cluster;
the service route management system is used for determining a transaction route corresponding to the transaction type indicated by the transaction request according to a preset corresponding relation between a preset transaction type and a plurality of configurable transaction routes under the condition of receiving the transaction request sent by the foreground system, so as to obtain a target transaction route; transaction routing indication corresponding to any transaction type: the transaction of the transaction type is allocated to the ratio of the number of the server sites under the original service cluster, and the transaction of the transaction type is allocated to the ratio of the number of the server sites under the upgraded service cluster;
the service route management system is also used for sending the information of the target transaction route to the API gateway;
the API gateway is used for distributing server sites for the transaction requests according to the load balancing strategy indicated by the target transaction routing; the load balancing strategy is characterized in that: and in the original service cluster and the upgraded service cluster, the number of the server sites respectively allocated for responding to the transaction request corresponding to the target transaction route is the same as the number of the server sites under the corresponding service cluster indicated by the target transaction route.
Optionally, the API gateway is further configured to, when a response of the upgrade service cluster to all types of transaction requests is abnormal, allocate a server site to the transaction request according to a preset load balancing policy.
Optionally, the service route management system is further configured to update the transaction route corresponding to the transaction type in the preset corresponding relationship to the transaction route indicated by the configuration update information when the configuration update information of the transaction route corresponding to any transaction type is received.
Optionally, the API gateway is further configured to update the load balancing policy corresponding to the transaction route to the load balancing policy indicated by the configuration update information when the configuration update information of the load balancing policy corresponding to any transaction route is received.
The application also provides a transaction processing system, which comprises a foreground system, an intermediate system and a background system;
the foreground system is used for sending the transaction request to the intermediate system under the condition of receiving the transaction request to be responded;
the intermediate system is any one of the intermediate systems described above;
and the background system is used for receiving the transaction request forwarded by the middle station system and returning a response result to the middle station system.
According to the switching method of the transaction route, the intermediate system and the business processing system, under the condition that the service route management system receives the transaction request sent by the foreground system, the service route management system determines the transaction route corresponding to the transaction type indicated by the transaction request according to the preset corresponding relation between the preset transaction type and the configurable multiple transaction routes, and obtains the target transaction route; sending the information of the target transaction route to the API gateway; and the API gateway distributes a server site for the transaction request according to the load balancing strategy indicated by the target transaction route.
In the present application, the transaction routing indication corresponding to any transaction type is: the transaction of the transaction type is assigned to the ratio of the number of server sites under the original service cluster, and the transaction of the transaction type is assigned to the ratio of the number of server sites under the upgraded service cluster. And, the specific content of the transaction route is configurable. Therefore, under the condition that the response of the upgrading service cluster to a certain transaction is abnormal, the method and the device provide possibility for simply, flexibly and efficiently switching the transaction back to the original service cluster by modifying the transaction route of the transaction.
Also, in the present application, the load balancing policy indicated by the target transaction route characterizes: in the original service cluster and the upgraded service cluster, the ratio of the number of the server sites which are respectively allocated to respond to the transaction request corresponding to the target transaction route is the same as the ratio of the number of the server sites under the corresponding service cluster indicated by the target transaction route. Namely, the API gateway realizes the response to the transaction request according to the occupation ratio of the number of the server sites under each service cluster indicated by the target route. Therefore, under the condition that the transaction route is changed, the API gateway can respond according to the load balancing strategy indicated by the changed transaction route, and therefore the back-cut is realized.
In summary, the scheme provided by the application provides possibility for flexibly, efficiently and conveniently switching back to the original service cluster from the upgraded service cluster.
Drawings
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts.
FIG. 1 is a block diagram of an intermediate system disclosed in an embodiment of the present application;
FIG. 2 is a flow chart of a process for responding to a transaction request by an intermediary system as disclosed in an embodiment of the present application;
FIG. 3 is a schematic diagram of a server site for responding to a transaction request corresponding to a target transaction route according to an embodiment of the present disclosure;
fig. 4 is a schematic structural diagram of a transaction processing system according to an embodiment of the present disclosure.
Detailed Description
The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
Fig. 1 is a schematic structural diagram of an intermediate system according to an embodiment of the present application, including: a middle station system and a service route management system. The middle platform system comprises an API gateway and a service cluster formed by an original service cluster and an upgrading service cluster.
In this embodiment, a configurable routing list is stored in advance in the service routing management system, where the routing list includes a preset correspondence between a preset transaction type and multiple transaction routes.
In this embodiment, in order to visually display the content of the transaction Route, the following four transaction routes are provided, which are respectively denoted as Route1, Route2, Route3, and Route4, and the specific content includes:
route 1: 0% traffic to B service cluster and 100% traffic to A service cluster
Route 2: 10% traffic to B service cluster and 90% traffic to A service cluster
Route 3: 50% traffic to B service cluster and 50% traffic to A service cluster
Route 4: 100% traffic to B service cluster and 0% traffic to A service cluster
Wherein, the 'B service cluster' represents an upgrade service cluster, and the 'A service cluster' represents an original service cluster. For convenience of description, the meaning of the content of the transaction route is introduced by taking any transaction route as an example. For example, in Route1, "0% traffic to B service cluster, 100% traffic to a service cluster" means: for the transaction request of the transaction type corresponding to Route1, the percentage of the number of server sites allocated to the B service cluster is 0%, and the percentage of the number of server sites allocated to the a service cluster is 100%. That is, the number of server sites in the service cluster B for responding to the transaction request of the transaction type corresponding to Route1 accounts for 0% of the total number of server sites for responding to the transaction request of the transaction type. The number of server sites in the service cluster a for responding to the transaction request of the transaction type corresponding to Route1 accounts for 100% of the total number of server sites for responding to the transaction request of the transaction type.
It should be noted that, in this embodiment, the content of the transaction route corresponding to each transaction type may be configured according to the actual situation.
Specifically, the service route management system updates the transaction route corresponding to the transaction type in the preset correspondence to the transaction route indicated by the configuration update information, when receiving the configuration update information of the transaction route corresponding to any transaction type.
In this embodiment, when receiving a transaction request sent by a foreground system, a response process to the transaction request by an intermediate system, as shown in fig. 2, may include the following steps:
s201, under the condition that the service route management system receives a transaction request sent by a foreground system, the service route management system determines a transaction route corresponding to the transaction type indicated by the transaction request according to a preset corresponding relation between a preset transaction type and a plurality of configurable transaction routes, and obtains a target transaction route.
In this embodiment, the transaction routing indication corresponding to any transaction type is: the transaction request of the transaction type is allocated to the ratio of the number of the server sites under the original service cluster, and the transaction request of the transaction type is allocated to the ratio of the number of the server sites under the upgraded service cluster. For the specific example and the specific meaning of the transaction route, reference may be made to the above explanation of the transaction route example and meaning, which is not described herein again.
In this step, for convenience of description, the transaction route determined in this step is referred to as a target transaction route.
S202, the service routing management system sends the information of the target transaction routing to the API gateway.
In this embodiment, after determining the target transaction route, the service route management system sends the target transaction route to the API gateway.
S203, the API gateway distributes server sites for the transaction requests according to the load balancing strategy indicated by the target transaction routing.
In this embodiment, the API gateway stores an access list, where the access list includes a preset correspondence between a transaction route and a load balancing policy. Wherein, the load balancing strategy corresponding to any transaction route is characterized: in the original service cluster and the upgraded service cluster, the number of the server sites respectively allocated for responding to the transaction request corresponding to the transaction route is the same as the number of the server sites under the corresponding service cluster indicated by the target transaction route.
Also taking round 1 as an example, the meaning of the load balancing policy corresponding to round 1 is: in the service cluster B, the ratio of the number of the server sites allocated for responding to the transaction request corresponding to the target transaction route to the total number of the server sites allocated for responding to the transaction request corresponding to the target transaction route in the service cluster B and the service cluster A is 0%. The number of the server sites allocated for responding to the transaction request corresponding to the target transaction route in the service cluster A accounts for 100% of the total number of the server sites allocated for responding to the transaction request corresponding to the target transaction route in the service cluster B and the service cluster A.
As shown in fig. 3, each cylinder represents a server site, wherein the cylinder labeled "a" represents a server site in the a service cluster that is assigned to route the corresponding transaction request in response to the target transaction, and the cylinder labeled "B" represents a server site in the B service cluster that is assigned to route the corresponding transaction request in response to the target transaction.
As can be seen from fig. 3, the number of cylinders marked with "a" is 9, the number of cylinders marked with "B" is 1, and the total number of server sites is 10, that is, the total number of server sites for responding to the transaction request corresponding to the target transaction route is 10. The API gateway distributes the transaction requests from these 10 server sites using load balancing, so that the ratio of the number of server sites (total number of cylinders marked "a") used for responding to the transaction request corresponding to the target transaction route in the a service cluster to the total number of server sites (10) used for responding to the transaction request corresponding to the target transaction route is 90%. In the service cluster B, the ratio of the number of server sites (1 total number of cylinders marked with 'B') used for responding to the transaction request corresponding to the target transaction route to the total number (10) of service sites used for responding to the transaction request corresponding to the target transaction route is 10%.
In this embodiment, when the upgrade service cluster may have a fault, in one case, the response of the upgrade service cluster to a certain transaction is abnormal, and the user may set a transaction route corresponding to the transaction by using the correspondence between the transaction type and the transaction route. And under the condition that the service route management system receives the update message of the transaction route content corresponding to the transaction, updating the transaction route corresponding to the transaction in the corresponding relationship. Therefore, the method provides possibility for flexible, convenient and efficient back-cut of transaction routing.
In practice, another situation where the upgrade service cluster fails is: the upgrade service cluster responds to the exception of the transaction request corresponding to each transaction type, and in this case, the transaction route can be switched back to the original service cluster by modifying the content of the transaction route corresponding to each transaction type in the service route management system. In order to facilitate switching back the transaction route to the original service cluster, in this embodiment, a preset load balancing policy may be configured in the API gateway, and the API gateway allocates a server site for the transaction request according to the preset load balancing policy when the response of the upgrade service cluster to all types of transaction requests fails, specifically, the operation shown in S204.
And S204, under the condition that the response of the upgrading service cluster to all types of transaction requests is abnormal, the API gateway distributes server sites for the transaction requests according to a preset load balancing strategy.
In this embodiment, the preset load balancing content needs to be configured according to the actual content. Optionally, in this embodiment, the preset load balancing policy may characterize: in the original service cluster and the upgraded service cluster, only the server sites in the original service cluster are allocated for responding to the transaction request. I.e. the API gateway distributes the transaction request only to the server sites in the original service cluster.
In this embodiment, the preset load balancing content may be updated according to an actual situation, and optionally, the preset load balancing updating manner may include: and under the condition that the configuration updating information of the load balancing strategy corresponding to the transaction route is received, the API gateway updates the load balancing strategy corresponding to the transaction route into the load balancing strategy indicated by the configuration updating information. After the updating is completed, the API gateway distributes server sites for the transaction requests according to the updated load balancing strategy under the condition that the upgrading service cluster is abnormal for all types of transaction requests.
Fig. 4 is a transaction processing system provided in an embodiment of the present application, including: foreground system, intermediate system and backstage system.
In this embodiment, the foreground system is configured to receive a transaction request to be responded, and send the received transaction request to the intermediate system. In this embodiment, the foreground system may be any one of a palm bank, an internet bank and a telephone bank.
The components included in the intermediate system are as in the embodiment corresponding to fig. 1, and are not described again here. The interaction process between the components included in the intermediate system may refer to the response process to the transaction request corresponding to fig. 2, which is not described herein again.
The background system is used for receiving the transaction request forwarded by the middle station system and returning a response result to the middle station system.
The embodiment of the application has the following beneficial effects:
the beneficial effects are that:
in the embodiment of the present application, the transaction routing indication corresponding to any transaction type is: the transaction of the transaction type is assigned to the ratio of the number of server sites under the original service cluster, and the transaction of the transaction type is assigned to the ratio of the number of server sites under the upgraded service cluster. And, the specific content of the transaction route is configurable. Therefore, under the condition that the response of the upgrading service cluster to a certain transaction is abnormal, the method and the device provide possibility for simply, flexibly and efficiently switching the transaction back to the original service cluster by modifying the transaction route of the transaction.
Also, in the present application, the load balancing policy indicated by the target transaction route characterizes: in the original service cluster and the upgraded service cluster, the ratio of the number of the server sites which are respectively allocated to respond to the transaction request corresponding to the target transaction route is the same as the ratio of the number of the server sites under the corresponding service cluster indicated by the target transaction route. Namely, the API gateway realizes the response to the transaction request according to the occupation ratio of the number of the server sites under each service cluster indicated by the target route. Therefore, under the condition that the transaction route is changed, the API gateway can respond according to the load balancing strategy indicated by the changed transaction route, and therefore the back-cut is realized.
In summary, the embodiment of the present application provides a possibility for flexibly, efficiently and conveniently switching back to the original service cluster from the upgraded service cluster.
The beneficial effects are that:
in the embodiment of the application, under the condition that the upgrading service cluster has a fault, namely the upgrading service cluster has a problem in response to the transaction request of each transaction type, a configurable preset load balancing strategy is provided, so that the possibility is provided for a user to switch the transaction request back to the original service cluster only by configuring the content of the preset load balancing strategy. Therefore, compared with the mode of modifying the transaction route corresponding to each type of transaction in the service route management system, the mode of modifying the preset load balancing strategy is more convenient for users.
The beneficial effects are three:
in the embodiment of the application, the service routing management system is added between the foreground system and the middle platform system, and the middle platform system comprises the API gateway, so that the API gateway can distribute and respond to the transaction request under the condition that the foreground system is attacked maliciously, and therefore the background system is buffered to some extent when being attacked maliciously, and the embodiment of the application has the beneficial effects of safety and controllability.
The embodiments are described in a progressive manner, each embodiment focuses on differences from other embodiments, and the same or similar parts among the embodiments are referred to each other.
In the above description of the disclosed embodiments, features described in various embodiments in this specification can be substituted for or combined with each other to enable those skilled in the art to make or use the present application.
The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the application. Thus, the present application is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Claims (10)
1. A back-cut method of transaction routing is characterized in that the method is applied to an intermediate system; the intermediate system includes: a middle platform system and a service route management system; the middle station system comprises an API gateway and a service cluster formed by an original service cluster and an upgrading service cluster, and the method comprises the following steps:
the service route management system is used for determining a transaction route corresponding to the transaction type indicated by the transaction request according to a preset corresponding relation between a preset transaction type and a plurality of configurable transaction routes under the condition of receiving the transaction request sent by the foreground system, so as to obtain a target transaction route; transaction routing indication corresponding to any transaction type: the transaction request of the transaction type is allocated to the ratio of the number of the server sites under the original service cluster, and the transaction request of the transaction type is allocated to the ratio of the number of the server sites under the upgraded service cluster;
the service route management system is also used for sending the information of the target transaction route to the API gateway;
the API gateway is used for distributing server sites for the transaction requests according to the load balancing strategy indicated by the target transaction routing; the load balancing strategy is characterized in that: and in the original service cluster and the upgraded service cluster, the number of the server sites respectively allocated for responding to the transaction request corresponding to the target transaction route is the same as the number of the server sites under the corresponding service cluster indicated by the target transaction route.
2. The method of claim 1,
the API gateway is further used for distributing server sites for the transaction requests according to a preset load balancing strategy under the condition that the responses of the upgrading service cluster to all types of transaction requests are abnormal.
3. The method of claim 2, wherein the preset load balancing policy characterizes: and in the original service cluster and the upgrading service cluster, only the server sites in the original service cluster are allocated to respond to all transaction requests.
4. The method of claim 1,
the service route management system is further configured to update the transaction route corresponding to the transaction type in the preset correspondence to the transaction route indicated by the configuration update information, when the configuration update information of the transaction route corresponding to any transaction type is received.
5. The method of claim 1,
the API gateway is further configured to update the load balancing policy corresponding to any transaction route to the load balancing policy indicated by the configuration update information when the configuration update information of the load balancing policy corresponding to the transaction route is received.
6. An intermediate system, comprising: a middle platform system and a service route management system; the middle platform system comprises an API gateway and a service cluster formed by an original service cluster and an upgrading service cluster;
the service route management system is used for determining a transaction route corresponding to the transaction type indicated by the transaction request according to a preset corresponding relation between a preset transaction type and a plurality of configurable transaction routes under the condition of receiving the transaction request sent by the foreground system, so as to obtain a target transaction route; transaction routing indication corresponding to any transaction type: the transaction of the transaction type is allocated to the ratio of the number of the server sites under the original service cluster, and the transaction of the transaction type is allocated to the ratio of the number of the server sites under the upgraded service cluster;
the service route management system is also used for sending the information of the target transaction route to the API gateway;
the API gateway is used for distributing server sites for the transaction requests according to the load balancing strategy indicated by the target transaction routing; the load balancing strategy is characterized in that: and in the original service cluster and the upgraded service cluster, the number of the server sites respectively allocated for responding to the transaction request corresponding to the target transaction route is the same as the number of the server sites under the corresponding service cluster indicated by the target transaction route.
7. Intermediate system according to claim 6,
the API gateway is further used for distributing server sites for the transaction requests according to a preset load balancing strategy under the condition that the responses of the upgrading service cluster to all types of transaction requests are abnormal.
8. Intermediate system according to claim 6,
the service route management system is further configured to update the transaction route corresponding to the transaction type in the preset correspondence to the transaction route indicated by the configuration update information, when the configuration update information of the transaction route corresponding to any transaction type is received.
9. Intermediate system according to claim 6,
the API gateway is further configured to update the load balancing policy corresponding to any transaction route to the load balancing policy indicated by the configuration update information when the configuration update information of the load balancing policy corresponding to the transaction route is received.
10. A transaction processing system is characterized by comprising a foreground system, an intermediate system and a background system;
the foreground system is used for sending the transaction request to the intermediate system under the condition of receiving the transaction request to be responded;
the intermediate system is the intermediate system of any one of the preceding claims 6 to 9;
and the background system is used for receiving the transaction request forwarded by the middle station system and returning a response result to the middle station system.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011583697.1A CN112751761A (en) | 2020-12-28 | 2020-12-28 | Transaction routing switching method, intermediate system and service processing system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011583697.1A CN112751761A (en) | 2020-12-28 | 2020-12-28 | Transaction routing switching method, intermediate system and service processing system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112751761A true CN112751761A (en) | 2021-05-04 |
Family
ID=75646410
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011583697.1A Pending CN112751761A (en) | 2020-12-28 | 2020-12-28 | Transaction routing switching method, intermediate system and service processing system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112751761A (en) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113515349A (en) * | 2021-07-28 | 2021-10-19 | 中国工商银行股份有限公司 | High-performance emergency back-switch method and device |
| CN113905094A (en) * | 2021-12-07 | 2022-01-07 | 航天云网数据研究院(广东)有限公司 | Industrial Internet integration method, device and system |
| CN114567551A (en) * | 2022-02-25 | 2022-05-31 | 中国农业银行股份有限公司 | Cluster upgrading method and device, electronic equipment and storage medium |
| WO2024056042A1 (en) * | 2022-09-16 | 2024-03-21 | 中兴通讯股份有限公司 | Load balancing processing method and apparatus, storage medium and electronic apparatus |
Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101938502A (en) * | 2009-07-14 | 2011-01-05 | 北京邮电大学 | Server cluster system and load balancing method |
| US20130198319A1 (en) * | 2012-01-31 | 2013-08-01 | Vmware, Inc. | Elastic allocation of computing resources to software applications |
| CN103618804A (en) * | 2013-12-16 | 2014-03-05 | 北京航空航天大学 | Performance difference-based load balancing method for distributed key value storage system |
| CN103945000A (en) * | 2014-05-05 | 2014-07-23 | 安徽科大讯飞信息科技股份有限公司 | Load balance method and load balancer |
| CN104954470A (en) * | 2015-06-19 | 2015-09-30 | 中国工商银行股份有限公司 | On-line transaction processing system and method |
| CN105450757A (en) * | 2015-12-02 | 2016-03-30 | 联动优势电子商务有限公司 | Service management method and system |
| CN107766175A (en) * | 2017-09-07 | 2018-03-06 | 中国光大银行股份有限公司信用卡中心 | A kind of data handling system for bank |
| CN109949135A (en) * | 2019-03-20 | 2019-06-28 | 江苏满运软件科技有限公司 | High concurrent transaction request processing method, system, equipment and storage medium |
| CN111144854A (en) * | 2019-12-06 | 2020-05-12 | 北京中交兴路信息科技有限公司 | Distributed intelligent payment routing method and system |
| CN111600930A (en) * | 2020-04-09 | 2020-08-28 | 网宿科技股份有限公司 | Micro-service request traffic management method, device, server and storage medium |
-
2020
- 2020-12-28 CN CN202011583697.1A patent/CN112751761A/en active Pending
Patent Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101938502A (en) * | 2009-07-14 | 2011-01-05 | 北京邮电大学 | Server cluster system and load balancing method |
| US20130198319A1 (en) * | 2012-01-31 | 2013-08-01 | Vmware, Inc. | Elastic allocation of computing resources to software applications |
| CN103618804A (en) * | 2013-12-16 | 2014-03-05 | 北京航空航天大学 | Performance difference-based load balancing method for distributed key value storage system |
| CN103945000A (en) * | 2014-05-05 | 2014-07-23 | 安徽科大讯飞信息科技股份有限公司 | Load balance method and load balancer |
| CN104954470A (en) * | 2015-06-19 | 2015-09-30 | 中国工商银行股份有限公司 | On-line transaction processing system and method |
| CN105450757A (en) * | 2015-12-02 | 2016-03-30 | 联动优势电子商务有限公司 | Service management method and system |
| CN107766175A (en) * | 2017-09-07 | 2018-03-06 | 中国光大银行股份有限公司信用卡中心 | A kind of data handling system for bank |
| CN109949135A (en) * | 2019-03-20 | 2019-06-28 | 江苏满运软件科技有限公司 | High concurrent transaction request processing method, system, equipment and storage medium |
| CN111144854A (en) * | 2019-12-06 | 2020-05-12 | 北京中交兴路信息科技有限公司 | Distributed intelligent payment routing method and system |
| CN111600930A (en) * | 2020-04-09 | 2020-08-28 | 网宿科技股份有限公司 | Micro-service request traffic management method, device, server and storage medium |
Non-Patent Citations (8)
| Title |
|---|
| "Istio v1.5 官方文档中文版" * |
| CRYSTONESC: "ServieMesh框架Istio案例学习-1" * |
| FRANK BUDINSJY: "多集群服务网格中的分版本路由", pages 207 - 210, Retrieved from the Internet <URL:https://istio.io/latest/zh/blog/2019/multicluster-version-routing/> * |
| H. JIANG ET AL.: "Load Balancing for SIP Server Clusters", IEEE INFOCOM 2009 * |
| JONES SHI: "\"Kubernetes Istio VirtualService\"" * |
| 李国;申亚坤;李永华;曲文丽;: "一种面向多类型服务的动态负载均衡算法", 现代电子技术, no. 12 * |
| 杨不易呀: "负载均衡Robbin之不同服务使用不同的策略" * |
| 程智凌: "面向机载SAR诊测的数字仿真平台设计与实现", pages 165 - 167 * |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113515349A (en) * | 2021-07-28 | 2021-10-19 | 中国工商银行股份有限公司 | High-performance emergency back-switch method and device |
| CN113905094A (en) * | 2021-12-07 | 2022-01-07 | 航天云网数据研究院(广东)有限公司 | Industrial Internet integration method, device and system |
| CN114567551A (en) * | 2022-02-25 | 2022-05-31 | 中国农业银行股份有限公司 | Cluster upgrading method and device, electronic equipment and storage medium |
| CN114567551B (en) * | 2022-02-25 | 2023-08-29 | 中国农业银行股份有限公司 | Cluster upgrading method and device, electronic equipment and storage medium |
| WO2024056042A1 (en) * | 2022-09-16 | 2024-03-21 | 中兴通讯股份有限公司 | Load balancing processing method and apparatus, storage medium and electronic apparatus |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112751761A (en) | Transaction routing switching method, intermediate system and service processing system | |
| CN108595207B (en) | Gray scale publishing method, rule engine, system, terminal and storage medium | |
| CN1649324B (en) | Method and apparatus for operating an open API network having a proxy | |
| CN109151807B (en) | Method and system for binding main card and auxiliary card of dual-card dual-standby mobile terminal | |
| CN110149392A (en) | A kind of management method and device of PUSH message | |
| KR20000004988A (en) | Method and apparatus for client managed flow control on a limited memorycomputer system | |
| CN104079630A (en) | Business server side load balancing method, client side, server side and system | |
| CN102137014A (en) | Resource management method, system and resource manager | |
| WO2019237594A1 (en) | Session persistence method and apparatus, and computer device and storage medium | |
| US20130311424A1 (en) | Distributed database | |
| CN102447734B (en) | Cloud service method for taxation cloud computing network billing IM (Instant Messaging) online customer system | |
| CN105472002A (en) | Session synchronization method based on instant copying among cluster nodes | |
| CN109597643A (en) | Using gray scale dissemination method, device, electronic equipment and storage medium | |
| CN102647335B (en) | Data routing method, device and system | |
| CN104718737A (en) | Methods, apparatuses, system, related computer program product for routing and processing policy requests related to group subscription | |
| CN105068755A (en) | Data duplicate storage method facing cloud computing content distribution network | |
| CN114364031B (en) | Service providing method, device and storage medium | |
| JP4459999B2 (en) | Non-stop service system using voting and information updating and providing method in the system | |
| CN112671928A (en) | Equipment centralized management architecture, load balancing method, electronic equipment and storage medium | |
| CN112351077B (en) | Application service operation method, system, device and storage medium | |
| CN105516238A (en) | Data request method and device, node server, and CDN system | |
| WO2017128713A1 (en) | Method and device for publishing subscription message | |
| CN113301079A (en) | Data acquisition method, system, computing device and storage medium | |
| CN105975614B (en) | Cluster configuration device, and method and device for updating data | |
| CN109388655A (en) | A kind of method and apparatus of dynamic control of data access |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20210504 |