City-wide active-active framework construction method based on bank distributed core

Abstract

The invention discloses a city-wide active-active framework construction method based on a bank distributed core. The city-wide active-active framework construction method specifically comprises the following steps: constructing a transaction flow forwarding system; based on the premise of single-center deployment of the current bank distributed core system, double-center data synchronization is carried out; in an active-active framework, active-active high-availability guarantee is adopted. And the availability and the reliability of the system are improved.

Description

Technical Field

[0001] The present invention relates to the core system field of banking business, and in particular to a method for constructing a same-city active-active framework based on a bank's distributed core. Background Art

[0002] The banking core generally refers to the core system of banking business. It is the most critical part of the bank's daily operations and is responsible for processing and managing the bank's core business functions.

[0003] As the financial industry continues to flourish, the performance pressure brought by increasingly complex business scenarios and the massive data they generate continues to concentrate on the core systems of banks.

[0004] Given the importance and irreplaceability of banking core systems in modern banks, it is impossible to ignore the various irreversible or even catastrophic impacts that may arise after sudden disasters cause damage to them.

[0005] In order to meet performance requirements and respond to sudden disasters, existing technical solutions mostly focus on exploring how to enhance the reliability and availability of single systems. The methods adopted include: expanding the capacity of hardware and network facilities and redundant backup, regular backup and data recovery, establishing monitoring and early warning systems, specifying disaster recovery plans, and conducting regular drills and tests.

[0006] Although the existing technical solutions have improved the reliability and availability of the core system to a certain extent, the limitation of the monolithic architecture means that it is destined to be unable to fundamentally avoid the various bottlenecks of the monolithic architecture, and can only delay reaching the upper limit. Moreover, the cost of software and hardware expansion is high, and the gains generated are gradually reduced. Summary of the invention

[0007] In view of the above problems, the present invention is proposed to provide a method for constructing a same-city active-active framework based on a bank's distributed core, which overcomes the above problems or at least partially solves the above problems.

[0008] According to one aspect of the present invention, a method for constructing a same-city active-active framework based on a bank distributed core is provided, and the method for constructing a same-city active-active framework specifically includes:

[0009] Build a transaction traffic forwarding system;

[0010] Based on the premise of the current single-center deployment of the bank's distributed core system, dual-center data synchronization is carried out;

[0011] In the active-active architecture, active-active high availability is guaranteed.

[0012] Optionally, the step of constructing a transaction traffic forwarding system specifically includes:

[0013] Nacos configuration center transformation;

[0014] Routing platform transformation;

[0015] Gateway transaction forwarding.

[0016] Optionally, the transformation of the nacos configuration center specifically includes:

[0017] Add active-active forwarding switches in the two data centers. If a major disaster occurs in one data center and the entire data center cannot continue to provide services, developers need to manually turn off the active-active switch and change the switch in the nacos configuration center to prevent transactions from being continuously sent to the unavailable center.

[0018] Add the F5 address of another data center to the nacos configuration center of the current data center. If transaction forwarding is required, forward it to the corresponding data center;

[0019] Add the logo of the current data center to the nacos configuration center of the current data center. The transaction forwarding strategy is based on the transaction type currently entering the data center and whether the current data center is suitable to determine whether forwarding is required.

[0020] Optionally, the routing platform transformation specifically includes:

[0021] Before the active-active transformation, the transaction link of the distributed core system is initially matched and forwarded by the gateway. After the transaction enters the gateway, the routing information of the corresponding transaction is obtained. The routing information of the routing platform is configured on the routing platform before the transaction is initiated.

[0022] The routing is modified, and a transaction type field is added to the routing table structure to distinguish transactions. Since the classification of different types of transactions is only for the distributed core, transactions sent to the AS400 core system are not distinguished.

[0023] Optionally, the gateway transaction forwarding specifically includes:

[0024] Transaction diversion and forwarding are performed in the gateway's processing filter chain;

[0025] First, obtain the switch of the nacos configuration center, the logo of this center, and the F5 address of another data center in the custom filter, and obtain the transaction routing information corresponding to the corresponding transaction code and channel;

[0026] After the forwarding conditions are ready, the forwarding judgment logic begins. First, the forwarding operation is required only when the active-active switch is on. If the switch is off, no forwarding is required and the transaction is handled by the center. Then, the specific content of the transaction type field in the transaction route is determined. If the transaction is sent to AS400, it is released without forwarding. If it is a distributed core transaction, the transaction is forwarded based on the current data center's processing capacity and the high and low performance of the transaction.

[0027] If forwarding is required, asynchronous non-blocking forwarding is required. Due to the premise that the distributed core system connects to a large number of channels and guarantees high performance and high concurrency of transactions, asynchronous non-blocking forwarding is used. Since the center does not need to process the transaction after forwarding, the processing result of the other data center is promptly fed back to the caller, and the original gateway filter chain is interrupted. The webclient client is used to send asynchronous non-blocking http requests. Combined with the Spring WebFlux responsive programming framework, the response data stream of the other data center is processed and customized and packaged in time and returned to the caller. The asynchronous non-blocking forwarding method ensures that high performance and high concurrency processing can be maintained when large quantities of transactions enter, and responsive programming supports timely notification and feedback of the return results of each transaction information.

[0028] Optionally, based on the premise that the current bank's distributed core system is deployed in a single center, the dual-center data synchronization specifically includes:

[0029] The underlying database of the active-active architecture adopts the OceanBase cluster deployment mode, and is dual-center dual deployment. When a transaction enters a certain center for processing, the data required for each transaction may be distributed in another central database, and data synchronization is required. The OBProxy proxy tool officially provided by OceanBase is used to implement request routing and load balancing. OBproxy receives client requests and routes them to the corresponding storage nodes.

[0030] Responsible for achieving load balancing of requests and ensuring that the loads of each node in the cluster are relatively balanced;

[0031] Through OBproxy, quickly request the target exchange's database and obtain the corresponding data; and OBproxy uses mechanisms such as automatic failover, load balancing adjustment, request retry and timeout processing;

[0032] If a database in a data center goes down, OBproxy automatically adjusts the request routing strategy based on the cluster load.

[0033] Optionally, in the active-active architecture, adopting active-active high availability guarantee specifically includes:

[0034] The transformation of the active-active architecture includes the deployment of redis, kafka and nacos in a dual-center dual-cluster manner. When a major catastrophic accident occurs in a data center and it is unable to continue to provide services, each middleware is deployed in a dual-center dual-cluster manner. The failure of one data center does not affect the other data center's continued external services, and each middleware continues to output internally.

[0035] The present invention provides a method for constructing a same-city active-active framework based on a bank's distributed core. The method specifically includes: constructing a transaction flow forwarding system; performing dual-center data synchronization based on the premise of a single-center deployment of the current bank's distributed core system; and adopting active-active high-availability guarantee in the active-active architecture, thereby improving the availability and reliability of the system.

[0036] The above description is only an overview of the technical solution of the present invention. In order to more clearly understand the technical means of the present invention, it can be implemented according to the contents of the specification. In order to make the above and other purposes, features and advantages of the present invention more obvious and easy to understand, the specific implementation methods of the present invention are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0038] Figure 1 A diagram of the active-active system architecture provided by an embodiment of the present invention;

[0039] Figure 2 A transaction forwarding flow chart provided for an embodiment of the present invention. DETAILED DESCRIPTION

[0040] The exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although the exemplary embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments set forth herein. On the contrary, these embodiments are provided to enable a more thorough understanding of the present disclosure and to fully convey the scope of the present disclosure to those skilled in the art.

[0041] The terms "comprises" and "having" and any variations thereof in the description embodiments, claims and drawings of the present invention are intended to cover non-exclusive inclusions, for example, including a series of steps or units.

[0042] The technical solution of the present invention is further described in detail below in conjunction with the accompanying drawings and embodiments.

[0043] Transaction flow forwarding

[0044] 1.1 Function Introduction

[0045] Based on the transformation plan of the existing single-master data center of the core distributed system of the bank to dual-active in the same city, the large-volume transactions conducted by the bank's docking channels can no longer be processed by only a single data center, but can be processed by two data centers in the same city; at the same time, due to the complexity and diversity of channel transactions, different data centers need to handle different types of transactions. For the distributed core system, transactions have a series of types such as high performance and low performance, high frequency and low frequency, and the processing performance of different data centers is also quite different. Therefore, it is necessary to divert the various transactions connected to the two centers, introduce important and high-performance transactions to the center with high processing capabilities, and transfer other transactions to another center for processing. Therefore, the current distributed core system is transformed in the following aspects:

[0046] 1) Nacos configuration center transformation

[0047] 1. It is necessary to add a dual-active forwarding switch in the two data centers. If a major disaster occurs in a data center and the entire data center cannot continue to provide services to the outside world, the developer needs to manually turn off the dual-active switch, that is, change the switch in the nacos configuration center to prevent transactions from being continuously sent to the unavailable center; 2. It is necessary to add the F5 address of another data center to the nacos configuration center of the current data center. If transaction forwarding is required, it needs to be forwarded to the corresponding data center; 3. It is necessary to add the flag of the current data center to the nacos configuration center of the current data center. Due to the difference in processing capabilities of the two data centers, the transaction forwarding strategy is determined by the type of transactions currently entering the data center and whether the current data center is adapted to determine whether forwarding is required.

[0048] 2) Routing platform transformation

[0049] Before the active-active transformation, the transaction link of the distributed core system was initially matched and forwarded by the gateway. After the transaction entered the gateway, it was still necessary to obtain the routing information of the corresponding transaction. The routing information of the routing platform was configured on the routing platform before the transaction was initiated. Due to the current active-active architecture and transaction forwarding transformation plan, it is necessary to distinguish the transaction types. Because the routing information in the routing platform is for specific transactions of a certain channel, the routing is transformed and a transaction type field is added to the routing table structure to distinguish transactions. Since the division of different types of transactions is only for the distributed core, transactions sent to the AS400 core system are not distinguished.

[0050] 3) Gateway transaction forwarding

[0051] Due to the existence of the original distributed core system, the transaction is initially received and processed by the distributed gateway, so the transaction is diverted and forwarded in the gateway's processing filter chain; first, the switch of the nacos configuration center, the logo of this center, and the F5 address of another data center need to be obtained in the custom filter, and then the transaction routing information corresponding to the corresponding transaction code and channel needs to be obtained.

[0052] After the forwarding conditions are ready, the forwarding judgment logic begins. First, the forwarding operation is required only when the active-active switch is on. If the switch is off, no forwarding is required and the transaction will be processed by this center. Then, the specific content of the transaction type field in the transaction route is determined. If the transaction is sent to AS400, it is released without forwarding. If it is a distributed core transaction, the transaction is forwarded based on the processing capability of the current data center and the high and low performance of the transaction: 1. High-performance transactions are sent to a data center with high processing capability or low-performance transactions are sent to a data center with low processing capability. They do not need to be forwarded and are directly processed by the data center that receives the transaction. 2. High-performance transactions are sent to a data center with poor processing capability or low-performance transactions are sent to a data center with strong processing capability. In this case, the transaction needs to be forwarded to another data center for processing.

[0053] If forwarding is required, asynchronous non-blocking forwarding is required. Since the distributed core system is connected to a large number of channels and must ensure high performance and high concurrency of transactions, asynchronous non-blocking forwarding is required. Since the center does not need to process the transaction after forwarding, it only needs to promptly feedback the processing results of the other data center to the caller, and interrupt the original gateway filter chain because it does not need to be processed by the center. Based on the above conditions, the webclient client is used to send asynchronous non-blocking http requests, and the Spring WebFlux responsive programming framework is combined to promptly process the response data stream of the other data center and customize the encapsulation and return it to the caller. The asynchronous non-blocking forwarding method ensures that high performance and high concurrency processing can be maintained when large quantities of transactions enter, and responsive programming supports timely notification and feedback of the return results of each transaction information.

[0054] 1.2 Active-Active System Architecture Diagram, Figure 1 As shown in the transaction forwarding flow chart, Figure 2 shown.

[0055] Dual-center data synchronization and high availability technology guarantee

[0056] 2.1 Dual-center data synchronization

[0057] Based on the premise of the current single-center deployment of the bank's distributed core system, that is, the current system only needs one master database to meet the underlying data storage and call requirements, so how to ensure the consistency of dual-center processing data when carrying out the active-active architecture transformation is also a very important issue.

[0058] The underlying database of the active-active architecture adopts the OceanBase cluster deployment mode, and it is dual-center dual deployment. Because when a transaction enters a certain center for processing, the data required for each transaction may be distributed in another central database, so data synchronization is required. Therefore, the OBProxy proxy tool officially provided by OceanBase is used to implement request routing and load balancing. OBproxy receives client requests and routes them to the corresponding storage nodes. It is responsible for implementing the load balancing of requests, ensuring that the load of each node in the cluster is relatively balanced, and improving the overall performance and reliability of the system. Therefore, through OBproxy, you can quickly request to the database where the target exchange is located and obtain the corresponding data; and OBproxy can effectively improve the processing capacity during failures and ensure the availability and stability of the system through mechanisms such as automatic failover, load balancing adjustment, request retry and timeout processing. If the database in a data center goes down, OBproxy will automatically adjust the request routing strategy according to the load of the cluster to ensure that the load of each storage node is relatively balanced and avoid excessive pressure at a single point.

[0059] 2.2 Active-Active High Availability Guarantee

[0060] In the active-active architecture, providing high availability and stability of the system is also a transformation point that cannot be ignored. At present, the bank's distributed core system adopts a series of middleware deployment methods such as single-center redis sentinel deployment, kafka cluster deployment, nacos single-center cluster deployment, etc. to ensure the high availability of the single center.

[0061] The modifications made in the active-active architecture are as follows: redis, kafka, and nacos are all deployed in a dual-center dual-cluster manner. When a major catastrophic accident occurs in the data center and it is unable to continue to provide services, because each middleware is deployed in a dual-center dual-cluster manner, the failure of one data center will not affect the other data center's continued external services, and each middleware can continue to output internally.

[0062] Beneficial effects: In order to adapt to the financial industry's ever-increasing requirements for bank core systems and give full play to the potential of distributed system services, this technical solution is no longer limited to a single system deployment architecture. It makes organizational adjustments at the architectural level and implements an active-active system deployment architecture of equal status, thereby subversively giving the bank's core transaction system traffic distribution, data synchronization, fault transfer and disaster recovery capabilities, breaking through the various bottlenecks of the single system, maximizing the cost of investing in resource expansion, and improving the system's availability and reliability.

[0063] The above specific implementation methods further illustrate the objectives, technical solutions and beneficial effects of the present invention in detail. It should be understood that the above are only specific implementation methods of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A method for constructing a dual-active framework in the same city based on a bank's distributed core, characterized in that: The method for constructing a dual-active framework in the same city specifically includes: Build a transaction traffic forwarding system; Based on the premise of the current single-center deployment of the bank's distributed core system, dual-center data synchronization is carried out; In the active-active architecture, active-active high availability is guaranteed.

2. According to claim 1, a method for constructing a dual-active framework in the same city based on a bank distributed core is characterized in that: The construction of the transaction traffic forwarding system specifically includes: Nacos configuration center transformation; Routing platform transformation; Gateway transaction forwarding.

3. According to claim 2, a method for constructing a dual-active framework in the same city based on a bank distributed core is characterized in that: The transformation of the nacos configuration center specifically includes: Add active-active forwarding switches in the two data centers. If a major disaster occurs in one data center and the entire data center cannot continue to provide services, developers need to manually turn off the active-active switch and change the switch in the nacos configuration center to prevent transactions from being continuously sent to the unavailable center. Add the F5 address of another data center to the nacos configuration center of the current data center. If transaction forwarding is required, forward it to the corresponding data center; Add the logo of the current data center to the nacos configuration center of the current data center. The transaction forwarding strategy is based on the transaction type currently entering the data center and whether the current data center is suitable to determine whether forwarding is required.

4. According to claim 2, a method for constructing a dual-active framework in the same city based on a bank distributed core is characterized in that: The routing platform transformation specifically includes: Before the active-active transformation, the transaction link of the distributed core system is initially matched and forwarded by the gateway. After the transaction enters the gateway, the routing information of the corresponding transaction is obtained. The routing information of the routing platform is configured on the routing platform before the transaction is initiated. The routing is modified, and a transaction type field is added to the routing table structure to distinguish transactions. Since the classification of different types of transactions is only for the distributed core, transactions sent to the AS400 core system are not distinguished.

5. According to claim 2, a method for constructing a dual-active framework in the same city based on a bank distributed core is characterized in that: The gateway transaction forwarding specifically includes: Transaction diversion and forwarding are performed in the gateway's processing filter chain; First, obtain the switch of the nacos configuration center, the logo of this center, and the F5 address of another data center in the custom filter, and obtain the transaction routing information corresponding to the corresponding transaction code and channel; After the forwarding conditions are ready, the forwarding judgment logic begins. First, the forwarding operation is required only when the active-active switch is on. If the switch is off, no forwarding is required and the transaction is handled by the center. Then, the specific content of the transaction type field in the transaction route is determined. If the transaction is sent to AS400, it is released without forwarding. If it is a distributed core transaction, the transaction is forwarded based on the current data center's processing capacity and the high and low performance of the transaction. If forwarding is required, asynchronous non-blocking forwarding is required. Due to the premise that the distributed core system connects to a large number of channels and guarantees high performance and high concurrency of transactions, asynchronous non-blocking forwarding is used. Since the center does not need to process the transaction after forwarding, the processing result of the other data center is promptly fed back to the caller, and the original gateway filter chain is interrupted. The webclient client is used to send asynchronous non-blocking http requests. Combined with the SpringWebFlux responsive programming framework, the response data stream of the other data center is processed and customized and packaged in time and returned to the caller. The asynchronous non-blocking forwarding method ensures that high performance and high concurrency processing can be maintained when large quantities of transactions enter, and responsive programming supports timely notification and feedback of the return results of each transaction information.

6. According to claim 1, a method for constructing a dual-active framework in the same city based on a bank distributed core is characterized in that: Based on the premise of the current single-center deployment of the bank's distributed core system, the dual-center data synchronization specifically includes: The underlying database of the active-active architecture adopts the OceanBase cluster deployment mode, and is dual-center dual deployment. When a transaction enters a certain center for processing, the data required for each transaction may be distributed in another central database, and data synchronization is required. The OBProxy proxy tool officially provided by OceanBase is used to implement request routing and load balancing. OBproxy receives client requests and routes them to the corresponding storage nodes. Responsible for achieving load balancing of requests and ensuring that the loads of each node in the cluster are relatively balanced; Through OBproxy, quickly request the target exchange's database and obtain the corresponding data; and OBproxy uses mechanisms such as automatic failover, load balancing adjustment, request retry and timeout processing; If a database in a data center goes down, OBproxy automatically adjusts the request routing strategy based on the cluster load.

7. According to claim 1, a method for constructing a dual-active framework in the same city based on a bank distributed core is characterized in that: In the active-active architecture, active-active high availability guarantees specifically include: The transformation of the active-active architecture includes the deployment of redis, kafka and nacos in a dual-center dual-cluster manner. When a major catastrophic accident occurs in a data center and it is unable to continue to provide services, each middleware is deployed in a dual-center dual-cluster manner. The failure of one data center does not affect the other data center's continued external services, and each middleware continues to output internally.

Images