Dynamic transaction routing establishment method based on bank multi-system environment

Abstract

The invention discloses a bank multi-system environment transaction dynamic route establishment method, which comprises the following steps that: after a front end initiates a call to a system A, the system A assembles and splices a call address of a system C; transaction calling of the system is packaged; the configuration takes effect in real time. And only one set of test environment needs to be deployed to correspond to multiple sets of environments of the transaction provider, so that the resource cost and the maintenance cost are saved, and the maintenance difficulty is reduced.

Description

Technical Field

[0001] The present invention relates to the field of bank transaction systems, and in particular to a method for establishing dynamic routing based on bank multi-system environment transactions. Background Art

[0002] In the distributed application scenario of banks, there may be more than one business system behind a terminal application. For example, the bank's own mobile banking system has core businesses such as balance inquiry and transfer, which call the bank's core system. The mobile banking system also has the business of collecting points, so there may be a corresponding points system. Moreover, the points system may be called in different business modules such as transfer and financial management.

[0003] Therefore, in the distributed application scenario of banks, there will be complex calling relationships between internal business systems to maintain the business relationships and data relationships between various business systems. The above is the system relationship in the formal production environment of the distributed application scenario of banks.

[0004] In the test environment, the core system of the transaction provider will have multiple test environments such as core-1 and core-2. For the caller's mobile banking system, it is necessary to call multiple environments of core-1 and core-2 of the core system at the same time. For this multiple environment problem, only one http request is issued to call the service provider interface to support all businesses. How to call different service provider system environments in the test environment and ensure that modules in different environments run in parallel to meet the cross-environment call requirements in the development and testing stages without affecting the single environment configuration of the production environment, which makes us need to deal with a series of problems.

[0005] By preparing multiple sets of caller system environments, we can adapt to the multiple environments of the transaction provider. This has the following disadvantages:

[0006] The problem is thrown to the front end, and the front end may be unable to solve it, or the solution requires additional costs. By deploying multiple sets of caller service system environments, it is adapted to the multiple environments of the transaction provider system. When the front end calls the back end service, it needs to connect to multiple sets of environment information at the same time. The back end throws the problem forward, and the front end system needs to solve the multi-environment adaptation problem. Generally, there is a set of gateway services or proxy services between the front end and the back end services to adapt the address, but the configuration is relatively troublesome, because the front end interface has more transactions than the back end, and more transactions need to be configured. Secondly, if there is no similar gateway service between the front end and the back end, the back end is not suitable for handing over the multi-environment problem to the front end to solve.

[0007] Deploying multiple environments will increase resource usage costs. If the calling system deploys multiple environments for adaptation, more deployment resources are required, which increases deployment costs. Deploying multiple test environments requires more maintenance costs. If the number of transaction provider system environments is large, and another transaction provider system also needs to be called by the same system, then the number of deployed environments may be greater, increasing the maintenance cost and difficulty of environment information.

[0008] SpringCloud Gateway is a professional routing gateway that can achieve flexible routing call relationships through appropriate configuration. However, compared with the present invention, SpringCloud Gateway has the following disadvantages:

[0009] Resource cost issue: Gateway needs to add a Gateway service between service calls as an intermediate routing system for service A to call service B, which increases the calling path. Originally, service A could call service B, but after adding Gateway routing, it becomes service A to routing, and routing to service B, wasting network resources. Since Gateway needs to be deployed on the server, server costs are increased. Summary of the invention

[0010] In view of the above problems, the present invention is proposed to provide a method for establishing dynamic routing of transactions based on a multi-system environment of a bank, which overcomes the above problems or at least partially solves the above problems.

[0011] According to one aspect of the present invention, a method for establishing a dynamic routing based on a multi-system environment transaction in a bank is provided, the routing establishment method comprising:

[0012] After the front-end initiates a call to system A, system A assembles and splices the call address to system C;

[0013] Encapsulate the transaction calls of the system;

[0014] The configuration takes effect immediately.

[0015] Optionally, after the front end initiates a call to system A, system A needs to assemble and splice the calling address of system C, specifically including:

[0016] The client initiates the call, and the interface caller system assembles the request address;

[0017] Determine whether there is a dynamic routing configuration on the current interface. If so, assemble the dynamic routing configuration into the current interface request address; if not, directly use the default request address to assemble;

[0018] Call the assembled address;

[0019] The interface provider returns data to the caller;

[0020] The interface caller returns data to the client.

[0021] Optionally, encapsulating the transaction call of the system specifically includes:

[0022] For the transaction call from system A to system C, there must be a certain calling function named coreInvoke;

[0023] To read dynamic configuration, in coreInvoke, make sure that the configuration prefix is ​​dynamic.url-map.core when reading dynamic configuration.

[0024] When calling coreInvoke, pass in the transaction address suffix, which is A001;

[0025] In the internal logic of coreInvoke, based on the incoming A001, determine whether there is a dynamic.url-map.core.A001 configuration. If there is, directly call the address corresponding to the dynamic.url-map.core.A001 configuration. If not, check the configuration of core-url to obtain the default system C call address.

[0026] Optionally, the process of calling the function specifically includes: when calling the coreInvoke function, the path for reading the configuration file must first be determined internally.

[0027] Optionally, the configuration taking effect in real time specifically includes:

[0028] Configuration of the test environment;

[0029] In the configuration file in the code, select the configuration item and fill it in;

[0030] Choose to put the configuration of dynamic.url-map.core into the configuration center;

[0031] When the configurator of the test environment adds or modifies the dynamic routing configuration for a transaction, he / she enters the configuration center to make adjustments and modifications. After the changes are saved, the configuration center will notify the local service changes of the system in real time.

[0032] Optionally, the configuration of the test environment specifically includes: placing it directly in the code of the caller service, or placing it in the server of the caller service, or selecting a configuration center service for configuration.

[0033] The present invention provides a method for establishing dynamic routing based on multi-system environment transactions of a bank, and the routing establishment method comprises: after the front end initiates a call to system A, system A assembles and splices the call address to system C; encapsulates the transaction call of the system; and the configuration takes effect in real time. Only one set of test environment needs to be deployed to correspond to multiple sets of environments of the transaction provider, which saves resource costs and maintenance costs and reduces the difficulty of maintenance.

[0034] 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

[0035] 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.

[0036] Figure 1 A schematic diagram of requests before and after dynamic routing configuration for transactions provided by an embodiment of the present invention;

[0037] Figure 2 A logic diagram of a dynamic routing transaction call process provided by an embodiment of the present invention;

[0038] Figure 3 The nacos configuration center configuration modification real-time effectiveness logic provided by the embodiment of the present invention;

[0039] Figure 4 The embodiment of the present invention provides the relationship between the nacos configuration center and the caller system A and system C, as well as the call flow chart. 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] The present invention is a method for adapting the calling configuration and calling logic of multiple environments of the caller and service side of the test environment backend service. It is necessary to let a caller system A call another transaction service side system C, and the caller system A configures a separate request address for any transaction of the transaction service side system C.

[0044] Assume that there are two backend service systems, a caller system A and a transaction service system C. Assume that the caller system A provides data query transactions to the front end. The transaction service system C stores the data needed by the front end. The front end calls the backend system A, and the backend system A then queries the data from the transaction service system C through certain logic and conversion. Assume that the transaction service system C has three transactions called by the caller system A, namely transaction A001 for core balance query, transaction B001 for core transfer record query, and transaction C001 for core card information query.

[0045] If there is only one set of caller system A and transaction service system C in the formal production environment, encapsulate a fegin client or http request client as the transaction exit, and specify the service address to be requested in the client, such as configuring core-url = http: / / core in the configuration file of system A, core-url is the request entry address configuration variable of service system C (the request entry address is referred to as baseURL below). Then the addresses of calling A001, B001, and C001 in the production environment are http: / / core / A001, http: / / core / B001, and http: / / core / C001 respectively, that is, the http: / / core part can be encapsulated as the baseURL in the request client, and the developer only needs to pay attention to the transaction path, and does not need to care about the baseURL of the service.

[0046] In the test environment, core-url will be configured as the test environment service address. However, in the test environment, the transaction service system C will have three different environments, namely core1 (sit1 environment), core2 (sit2 environment), and core3 (sit3 environment), which provide core card information check transaction C001, core balance check transaction A001, and core transfer record check transaction B001. If you need to make the caller system A call A001, B001, and C001 transactions in the test environment, you need to configure different request addresses for the transactions http: / / core-2 / A001, http: / / core-3 / B001, and http: / / core-1 / C001, respectively. However, the baseURL of the fegin client or http request client can only be configured once, which cannot solve the problem of calling multiple service systems in one environment. In order to solve this problem, a dynamic routing configuration mechanism is added to the fegin client or http request client to configure a request address for each transaction of the client.

[0047] For example, in the above system call relationship, a different address is configured for each transaction of the service system C. The configuration method is: dynamic.url-map.service system abbreviation.transaction name = service system new address (newServiceURL), such as:

[0048] dynamic.url-map.core.A001=http: / / core-2

[0049] dynamic.url-map.core.B001=http: / / core-3

[0050] dynamic.url-map.core.C001=http: / / core-1

[0051] In this configuration, dynamic.url-map is the prefix of dynamic configuration. When dynamic.url-map is not configured, the baseURL of the fegin client or http request client is read as the service request address, which is the default service address. When dynamic.url-map is configured, we can use the configured new service address (newServiceURL) as the request address of the transaction, as mentioned above: the request address of A001 transaction will be dynamically replaced with http: / / core-2 / A001, the request address of B001 transaction will be dynamically replaced with http: / / core-3 / B001, and the request address of C001 transaction will be dynamically replaced with http: / / core-1 / C001. The request before and after the dynamic routing configuration of the transaction is as follows: Figure 1 As shown in the figure, the client transaction request address is dynamically replaced without modifying the client code.

[0052] Call flow and logic

[0053] After the front-end initiates a call to system A, system A needs to assemble and splice the call address to system C. As mentioned in the basic idea, the configuration may include the following:

[0054] core-url=http: / / core

[0055] #Dynamic Configuration

[0056] dynamic.url-map.core.A001=http: / / core-1

[0057] dynamic.url-map.core.B001=http: / / core-2

[0058] dynamic.url-map.core.C001=http: / / core-3

[0059] When the dynamic.url-map dynamic routing address is not configured, such as when the currently called system C transaction is not configured in the dynamic configuration, the default address is read in the process. When the current transaction is configured in the dynamic configuration, the request uses the dynamic routing configuration address.

[0060] Example 1 is configured as follows:

[0061] core-url=http: / / core

[0062] The current configuration does not have dynamic.url-map related configuration. When system A calls the A001 transaction of system C, the request address is http: / / core

[0063] Example 2 is configured as follows:

[0064] core-url=http: / / core

[0065] #Dynamic Configuration

[0066] dynamic.url-map.core.A001=http: / / core-1

[0067] The dynamic.url-map configuration is currently configured, and the A001 transaction of the core system is configured. When system A calls the A001 transaction of system C, the request address is http: / / core-1 / A001.

[0068] Still in the current configuration of Example 2, when system A calls the B001 transaction of system C, since there is no transaction B001 of the core system configured in the dynamic configuration, the request address uses core-url=http: / / core, and the transaction address suffix is ​​http: / / core / B001. The logic of the dynamic routing transaction call process is as follows Figure 2 shown.

[0069] Need to encapsulate the transaction call of a certain system

[0070] In order to achieve the above effect, the call of system A to system C transaction needs to be encapsulated.

[0071] First, for the transaction call of system A calling system C, there must be a certain calling function named coreInvoke. When calling the coreInvoke function, the path to read the configuration file must be determined internally. For example, in the configuration file, there are core-url = http: / / core, jifen-url = http: / / jifen and other system addresses of various transaction providers. In coreInvoke, it is necessary to specify that the configuration to be read is the address corresponding to core-url.

[0072] Then, in order to read the dynamic configuration, you need to make sure that the configuration prefix is ​​dynamic.url-map.core in coreInvoke. Because other transaction provider systems, such as jifen, may have a dynamic configuration prefix of dynamic.url-map.jifen, which cannot be confused.

[0073] Finally, when calling coreInvoke, you need to pass in the transaction address suffix, which is A001, etc.

[0074] In the coreInvoke internal logic, according to the incoming A001, determine whether there is

[0075] If dynamic.url-map.core.A001 is configured, directly call the address corresponding to dynamic.url-map.core.A001 configuration. If not, check the configuration of core-url to obtain the default system C call address.

[0076] The configuration takes effect immediately, including:

[0077] The configuration of the test environment is placed directly in the code of the caller service, or in the server of the caller service, or a configuration center service is selected for configuration.

[0078] For the configuration files in the code, select some configuration items that will not be modified and fill them in. After the configuration in the server is modified, you need to restart the caller service to take effect. The configuration files placed in the configuration center will automatically take effect in real time after modification.

[0079] In order to have a better experience of dynamic routing configuration, the configuration of the dynamic.url-map.core part is selected to be placed in the configuration center. There are many common configuration centers available on the market, all of which are used in the invention.

[0080] When the configuration person of the test environment needs to add or modify the dynamic routing configuration of a transaction, he / she will enter the configuration center to make adjustments. After the changes are saved, the configuration center will notify the local service changes of the system in real time. Figure 3 When the user initiates a call again, the service address will change accordingly according to the calling process (as shown in Figure 4 shown).

[0081] Beneficial effects: The present invention can dynamically configure the routing of backend service call transactions. For example, for a system with a default request address, a transaction can be dynamically configured, and the request address can be switched for the transaction alone without modifying the fegin client or http request client code.

[0082] The present invention uniformly encapsulates the calls at the backend service system level, and calls the encapsulated functions of the system for the requests of a single system, thereby enhancing the uniformity of the system level calls and facilitating the specific configuration or specific processing of a certain system call.

[0083] The present invention uses a configuration center to dynamically configure routing, meeting the unique dynamic real-time configuration capability of the test environment, facilitating the rapid effectiveness and rapid restoration of routing configuration, saving deployment resources, and reducing maintenance costs.

[0084] 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 establishing dynamic routing based on multi-system environment transactions in a bank, characterized in that: The routing establishment method comprises: After the front-end initiates a call to system A, system A assembles and splices the call address to system C; Encapsulate the transaction calls of the system; The configuration takes effect immediately.

2. A method for establishing dynamic routing based on bank multi-system environment transactions according to claim 1, characterized in that: After the front end initiates a call to system A, system A needs to assemble and splice the call address to system C, specifically including: The client initiates the call, and the interface caller system assembles the request address; Determine whether there is a dynamic routing configuration on the current interface. If so, assemble the dynamic routing configuration into the current interface request address; if not, directly use the default request address to assemble; Call the assembled address; The interface provider returns data to the caller; The interface caller returns data to the client.

3. A method for establishing dynamic routing based on bank multi-system environment transactions according to claim 1, characterized in that: The encapsulation of the transaction call of the system specifically includes: For the transaction call from system A to system C, there must be a certain calling function named coreInvoke; To read dynamic configuration, in coreInvoke, make sure that the configuration prefix is ​​dynamic.url-map.core when reading dynamic configuration. When calling coreInvoke, pass in the transaction address suffix, which is A001; In the internal logic of coreInvoke, based on the incoming A001, determine whether there is a dynamic.url-map.core.A001 configuration. If there is, directly call the address corresponding to the dynamic.url-map.core.A001 configuration. If not, check the configuration of core-url to obtain the default system C call address.

4. A method for establishing dynamic routing based on bank multi-system environment transactions according to claim 3, characterized in that: The process of calling the function specifically includes: when calling the coreInvoke function, the path for reading the configuration file must first be determined internally.

5. A method for establishing dynamic routing based on bank multi-system environment transactions according to claim 1, characterized in that: The real-time effectiveness of the configuration specifically includes: Configuration of the test environment; In the configuration file in the code, select the configuration item and fill it in; Choose to put the configuration of dynamic.url-map.core into the configuration center; When the configurator of the test environment adds or modifies the dynamic routing configuration for a transaction, he / she enters the configuration center to make adjustments and modifications. After the changes are saved, the configuration center will notify the local service changes of the system in real time.

6. A method for establishing dynamic routing based on bank multi-system environment transactions according to claim 5, characterized in that: The configuration of the test environment specifically includes: placing it directly in the code of the caller service, or placing it in the server of the caller service, or selecting a configuration center service for configuration.

Images