An architectural design method for full-stack localization scenarios in the financial industry

Abstract

The present invention discloses an architecture design method for full-stack localization of the financial industry. The present invention splits the system into a presentation layer, a service layer, a persistence layer, and a message middleware layer. Each layer is decoupled from each other and migrated separately, realizing a progressive alternative. The present invention adopts a distributed service architecture, allowing its independent business services to use different databases and other products; at the same time, when facing peaks, users are diverted to various business service modules, reducing the concurrency pressure of a single service and improving system stability.

Description

Technical Field

[0001] The present invention relates to the field of financial information technology, and in particular to an architecture design method for a full-stack localization scenario in the financial industry. Background Art

[0002] In the current promotion of ICT, financial institutions often adopt a mixed use and gradual replacement approach to complete the full-stack domestic replacement in order to achieve a smooth transition. However, in the existing system architecture design, it is often difficult to take into account the compatibility and adaptability between domestic ICT products and non-ICT products and between ICT products. Therefore, the system stability and security of the phased full-stack domestic replacement are difficult to be effectively guaranteed. Summary of the invention

[0003] The purpose of the present invention is to solve the compatibility and adaptation problems between domestic products and non-domestic products when the financial industry is carrying out full-stack localization substitution, to ensure the stability and security of the financial industry in the process of phased implementation of full-stack localization substitution, and to this end proposes an architecture design method for the full-stack localization scenario of the financial industry.

[0004] In order to achieve the above objectives, the present invention proposes an architecture design method for the full-stack localization scenario of the financial industry, comprising the following steps:

[0005] (1) Build the presentation layer application, including the following sub-steps:

[0006] (1.1) Use the Vue front-end framework to encapsulate the business-related interfaces into components; use front-end routing technology to encapsulate the application into a single-page application;

[0007] (1.2) Use the resource packaging tool Webpack to package all source codes for obfuscation and encryption, and generate target files, including: entry page HTML, JS scripts, cascading style sheet files, multimedia static resources, etc.; upload all the above files to CDN for backup, to provide access acceleration for subsequent users;

[0008] (1.3) Install the Tengine server on multiple hosts with public IP addresses and expose port 80; configure the virtual host and add the entry page HTML of step (1.2) to the root directory of the Tengine server;

[0009] (1.4) Use Web server virtual host technology to return static resources or forward business requests to the service layer according to different paths of user requests;

[0010] (1.5) Perform DNS resolution through the domain name provider, and resolve users in different regions to different IP addresses in step (1.3), so as to distribute users to different servers and achieve DNS-based load balancing; for users in different regions, adopt the strategy of preferentially requesting the closest resources to optimize access and response efficiency;

[0011] (2) Building a service layer business cluster includes the following sub-steps:

[0012] (2.1) Install the Zookeeper service on the intranet host as the registration center for other services;

[0013] (2.2) Add Dubbo settings to the project configuration file, including the registration center in step (2.1); at the same time, add the Dubbo protocol to the business interface of the current sub-service; start the sub-service on multiple server nodes in the intranet, so that this interface is successfully registered in the registration center and becomes multiple providers of the service;

[0014] (2.3) According to the actual needs of the business, the business is divided into multiple sub-services, and they are deployed and maintained independently; the same Dubbo configuration as step (2.2) is added, and the corresponding service call interface is introduced; the sub-services will call each other's interfaces through Dubbo; all sub-services are registered with the gateway and provide services to the outside world;

[0015] (3) Building a message center platform, including the following sub-steps:

[0016] (3.1) Build RocketMQ service on the intranet host; add LogAppender to the subservices that need to analyze logs, and transfer the generated logs to the message middleware; identify and distinguish the services that use different MessageQueues or Topics;

[0017] (3.2) According to the needs, real-time analysis of business data in different scenarios is performed through offline tasks, or offline data is analyzed through SQL queries to provide data analysis functions for business decision-making;

[0018] (4) Build the data persistence layer, including the following sub-steps:

[0019] (4.1) Build Tair and TiDB services for the intranet host to store business-related data; install multiple sub-modules such as idb-server, tikv-server, and pd-server for the TiDB service to meet the needs of various scenarios;

[0020] (4.2) Read and write Tair using redis-compatible methods and formats such as GET, SET, HGET, and HSET;

[0021] (4.3) Pre-service is provided for data query requests through multi-level caching technology; when the system receives a request for data query, the sub-service in step (2) will give priority to accessing the data in Tendis; if the data is not hit, the data in TiDB is accessed again, and the access result is rewritten into Tendis to provide subsequent access.

[0022] The beneficial effect of the present invention is that the present invention adopts a distributed service architecture, allowing its independent business services to use different databases and other products; at the same time, when facing peak times, users are diverted to various business service modules, reducing the concurrency pressure of a single service and improving system stability. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 It is a schematic diagram of the system architecture of the present invention;

[0024] Figure 2 A flowchart for implementing the system architecture of the present invention;

[0025] Figure 3 A flow chart is used for users of the present invention. DETAILED DESCRIPTION

[0026] The present invention will be described in detail below with reference to the accompanying drawings.

[0027] The architecture designed by the present invention for the full-stack localization scenario in the financial industry includes four parts: the presentation side, the service layer, the message middleware, and the persistence layer:

[0028] Presentation layer: Adopting the model of independent engineering deployment, each business line is independently deployed and maintained according to its actual needs. Using convenient and intuitive human-computer interaction methods, users can communicate with the system, greatly improving the system's availability or user-friendliness.

[0029] Service layer: Adopting a distributed service framework and using protocols such as HTTP / RPC, repetitive business functions are encapsulated into independent business services, which are then used to provide services to the presentation layer. These services can be reused to handle actual business needs. The service layer splits a single user operation into multiple specific logical processes to achieve the corresponding complete functions.

[0030] Message middleware: Based on queue and message transmission technology, it provides synchronous or asynchronous, reliable message transmission support capabilities for the service layer in the network environment. Message middleware activates each other's events by transmitting messages between different services, and integrates the remaining sub-services in the system using an efficient and reliable asynchronous message transmission mechanism, thereby providing the application system with an asynchronous message transmission mechanism, as well as asynchronous decoupling and peak-shaving capabilities.

[0031] Persistence layer: saves data to a storage system that can be permanently saved, establishes a unified, secure and concurrent data persistence mechanism, and provides data services for system business through persistence programming of the database. Database cache, database middleware, etc. are transparent and invisible to the upper layer in this architecture system.

[0032] The present invention provides a method for designing a full-stack localized architecture for the financial industry, comprising the following steps:

[0033] (1) Build presentation layer applications

[0034] (1.1) Use the Vue front-end framework to encapsulate the business-related interfaces into components; use front-end routing technology to encapsulate the application into a single-page application.

[0035] (1.2) Use the resource packaging tool Webpack to package all source codes, perform obfuscation encryption and other pre-processing, and generate target files, including: entry page HTML, JS scripts, cascading style sheet files, multimedia static resources, etc.; upload all the above files to CDN for backup, to provide access acceleration for subsequent users.

[0036] (1.3) Install the Tengine server on multiple hosts with public IP addresses and expose port 80; configure the virtual host and add the entry page HTML of step (1.2) to the root directory of the Tengine server.

[0037] (1.4) Use Web server virtual host technology to return static resources or forward business requests to the service layer according to different paths of user requests.

[0038] (1.5) Perform DNS resolution through the domain name provider and resolve users in different regions to different IP addresses in step (1.3), so as to distribute users to different servers and achieve DNS-based load balancing; for users in different regions, adopt the strategy of prioritizing requests for the closest resources to optimize access and response efficiency.

[0039] (2) Building a service layer business cluster

[0040] (2.1) Install the Zookeeper service on the intranet host as the registration center for other services.

[0041] (2.2) Add Dubbo settings to the project configuration file, including the registration center in step (2.1); at the same time, add the Dubbo protocol to the business interface of the current sub-service; start the sub-service on multiple server nodes in the intranet, so that this interface is successfully registered in the registration center and becomes one of the multiple providers of the service.

[0042] (2.3) According to the actual needs of the business, split the business into multiple sub-services and deploy and maintain them independently; add the same Dubbo configuration as step (2.2) and introduce the corresponding service call interface; the sub-services will call each other's interfaces through Dubbo; register all sub-services with the gateway and provide services to the outside world.

[0043] (3) Build a message center platform

[0044] (3.1) Build RocketMQ service on the intranet host; add LogAppender to the subservices that need to analyze logs, and transfer the generated logs to the message middleware; identify and distinguish the services that use different MessageQueues or Topics.

[0045] (3.2) Based on demand, real-time analysis of business data in different scenarios is performed through offline tasks, or offline data is analyzed through SQL queries to provide data analysis functions for business decision-making.

[0046] (4) Building a data persistence layer

[0047] (4.1) Set up Tair and TiDB services for the intranet host to store business-related data; install multiple sub-modules such as idb-server, tikv-server, and pd-server for the TiDB service to meet the needs of diverse scenarios.

[0048] (4.2) Read and write Tair using redis-compatible methods and formats such as GET, SET, HGET, and HSET.

[0049] (4.3) Provide pre-service for data query requests through multi-level caching technology. When the system receives a request for data query, the sub-service in step (2) will give priority to accessing the data in Tendis; if the data is not hit, it will access the data in TiDB again and rewrite the access results to Tendis to provide subsequent access.

Claims

1. An architecture design method for full-stack localization of the financial industry, characterized in that: The following steps are involved: (1) Build the presentation layer application, including the following sub-steps: (1.1) Use the Vue front-end framework to encapsulate the business-related interfaces into components; use front-end routing technology to encapsulate the application into a single-page application; (1.2) Use the resource packaging tool Webpack to package all source codes for obfuscation and encryption preprocessing, and generate target files, including: entry page HTML, JS scripts, cascading style sheet files, multimedia static resources; upload all the above files to CDN for backup, to provide access acceleration for subsequent users; (1.3) Install the Tengine server on multiple hosts with public IP addresses and expose port 80; configure the virtual host and add the entry page HTML of step (1.2) to the root directory of the Tengine server; (1.4) Use Web server virtual host technology to return static resources or forward business requests to the service layer according to different paths of user requests; (1.5) Perform DNS resolution through the domain name provider, and resolve users in different regions to different IP addresses in step (1.3), so as to distribute users to different servers and achieve DNS-based load balancing; for users in different regions, adopt the strategy of preferentially requesting the closest resources to optimize access and response efficiency; (2) Building a service layer business cluster includes the following sub-steps: (2.1) Install the Zookeeper service on the intranet host as the registration center for other services; (2.2) Add Dubbo settings to the project configuration file, including the registration center in step (2.1); at the same time, add the Dubbo protocol to the business interface of the current sub-service; start the sub-service on multiple server nodes in the intranet, so that this interface is successfully registered in the registration center and becomes multiple providers of the service; (2.3) According to the actual needs of the business, the business is divided into multiple sub-services, and they are deployed and maintained independently; the same Dubbo configuration as step (2.2) is added, and the corresponding service call interface is introduced; the sub-services will call each other's interfaces through Dubbo; all sub-services are registered with the gateway and provide services to the outside world; (3) Building a message center platform, including the following sub-steps: (3.1) Build RocketMQ service on the intranet host; add LogAppender to the subservices that need to analyze logs, and transfer the generated logs to the message middleware; identify and distinguish the services that use different MessageQueues or Topics; (3.2) According to the needs, real-time analysis of business data in different scenarios is performed through offline tasks, or offline data is analyzed through SQL queries to provide data analysis functions for business decision-making; (4) Build the data persistence layer, including the following sub-steps: (4.1) Build Tair and TiDB services for the intranet host to store business-related data; install idb-server, tikv-server, and pd-server submodules for the TiDB service to meet the needs of diverse scenarios; (4.2) Read and write Tair using redis-compatible methods and formats; the redis-compatible methods and formats include GET, SET, HGET, and HSET; (4.3) Pre-service is provided for data query requests through multi-level caching technology; when the system receives a request for data query, the sub-service in step (2) will give priority to accessing the data in Tendis; if the data is not hit, the data in TiDB is accessed again, and the access result is rewritten into Tendis to provide subsequent access.

Images