Transaction channel system transformation method and device, electronic equipment and storage medium
By reconstructing the microservice architecture, transforming the data storage layer, and implementing automated operation and maintenance mechanisms, the problems of outdated technology and high coupling in traditional transaction channel systems have been solved. This has enabled the system to adapt to domestic IT innovation and achieve efficient operation and maintenance, improving performance and scalability while reducing maintenance costs.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-31
- Publication Date
- 2026-04-14
AI Technical Summary
Traditional transaction channel systems are technologically outdated, highly coupled, poorly scalable, and complex to operate and maintain. They cannot adapt to the information technology innovation environment, resulting in insufficient response speed and throughput, high maintenance costs, and difficulty in quickly connecting with new businesses and new partners.
The system was restructured using a microservice architecture, the data storage layer was modified to be deployed collaboratively with the main database and cache database, a unified interface specification and independent business modules were established, and an automated operation and maintenance mechanism was built to achieve system adaptation and efficient operation and maintenance in the domestic IT innovation environment.
It improves the system's data read/write performance and security, reduces maintenance costs, supports rapid business expansion and product launch, meets the requirements for domestic IT innovation compatibility, and improves system stability and operational efficiency.
Smart Images

Figure CN121858080A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer software technology, and in particular to a method, apparatus, electronic device and storage medium for modifying a transaction channel system. Background Technology
[0002] In modern business operations, transaction systems serve as core infrastructure supporting enterprise business processes. Their performance, architectural rationality, and business adaptability directly impact operational efficiency, cost control, and market competitiveness. With the rapid development of information technology, various industries have placed higher demands on the technological advancement, business flexibility, and security controllability of transaction systems. Especially under the policy background of the comprehensive promotion of the information technology innovation industry, achieving the replacement of IT infrastructure, basic software, and application software, and ensuring the independent controllability of information systems have become core demands for enterprise technology upgrades. Currently, the traditional transaction channel systems commonly used in the industry are mostly built on previously deployed technical frameworks, with Java + Servlet + Nginx + Drools as the core technology stack. They share the same Oracle / WebLogic cluster with the order processing system, share the same database instance, and achieve load balancing through Nginx reverse proxy at the front end. This architecture met basic transaction needs during a specific historical period.
[0003] However, with the continuous expansion of business scale and the constant evolution of the technological environment, traditional transaction channel systems have gradually exposed many unavoidable problems. On the one hand, the underlying technical framework is outdated and cannot adapt to new domestically developed terminals and servers, making it difficult to fully leverage the performance advantages of new hardware. This results in insufficient response speed and throughput in high-concurrency transaction scenarios, failing to meet the needs of business growth. On the other hand, the system's business rules and process logic are highly coupled within the WebLogic container, with excessively strong interrelationships between functional modules, making maintenance and upgrades extremely difficult. Modifications to a single module can easily trigger a chain reaction, significantly increasing maintenance costs and risks. At the same time, redundant functions accumulated over long-term iterations consume a large amount of system resources, further reducing operational efficiency. The rigid architectural design also makes it difficult for the system to quickly connect with new businesses and new partners, requiring extensive customization development. This results in long development cycles and high costs, severely restricting the company's ability to respond to rapid market changes. Summary of the Invention
[0004] In view of this, the embodiments of this application provide a method, apparatus, electronic device and storage medium for transforming a transaction channel system, which can effectively solve the pain points of traditional systems such as outdated technology, high coupling, poor scalability and complex operation and maintenance, and realize system compatibility with information technology innovation, performance upgrade, flexible expansion and efficient operation and maintenance, providing solid technical support for the continuous development of business.
[0005] The technical solution of this application embodiment is implemented as follows: In a first aspect, embodiments of this application provide a method for modifying a transaction channel system, comprising the following steps: The traditional transaction channel system is restructured using a microservice architecture to adapt to the information technology innovation environment; Transform the system's data storage layer by adopting a collaborative deployment approach between the main database and the cache database to improve data read / write performance and data security. Standardize and decouple system business processes, establish unified interface specifications and independent business modules, and realize business configuration-based expansion; Build an automated operation and maintenance mechanism to automate task scheduling, system deployment, and operational status monitoring.
[0006] Secondly, embodiments of this application also provide a transaction channel system transformation device, the device comprising: The architecture refactoring module is used to refactor the traditional transaction channel system using a microservice architecture to achieve compatibility with the information technology innovation environment. The database transformation module is used to transform the system's data storage layer, adopting a collaborative deployment approach between the main database and the cache database to improve data read and write performance and data security. The business decoupling module is used to standardize and decouple system business processes, establish unified interface specifications and independent business modules, and realize business configuration-based expansion. The operations and maintenance module is used to build an automated operations and maintenance mechanism to automate task scheduling, system deployment, and operational status monitoring.
[0007] Thirdly, embodiments of this application also provide an electronic device, including: a processor, a storage medium, and a bus, wherein the storage medium stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the transaction channel system modification method described in any of the first aspects.
[0008] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the transaction channel system modification method described in any one of the first aspects.
[0009] The embodiments of this application have the following beneficial effects: By reconstructing the system using a microservice architecture, we achieve full compatibility with the domestic IT innovation environment, meeting the requirements of independent control and security compliance in information technology. Adopting a collaborative deployment model of main database and cache database significantly improves data read / write efficiency, ensures data security and consistency, and effectively supports high-concurrency transaction scenarios. Through business process standardization, module decoupling, and configurable design, we achieve complete separation between transaction channels and order generation systems, reducing system complexity and maintenance costs, and supporting rapid product launches and flexible expansion of transaction channels. Utilizing automated operation and maintenance mechanisms, we automate task scheduling, system release, and operational status monitoring, reducing human error, improving operational efficiency and system stability. This comprehensively addresses the pain points of traditional transaction channel systems, such as outdated technology, high coupling, poor scalability, and complex operation and maintenance, providing solid technical support for the continuous growth of enterprise business. Attached Figure Description
[0010] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.
[0011] Figure 1 This is a flowchart illustrating steps S101-S104 provided in the embodiments of this application; Figure 2 This is a flowchart illustrating steps S201-S204 provided in the embodiments of this application; Figure 3 This is a flowchart illustrating steps S301-S303 provided in the embodiments of this application; Figure 4 This is a flowchart illustrating steps S401-S403 provided in the embodiments of this application; Figure 5 This is a flowchart illustrating steps S501-S503 provided in the embodiments of this application; Figure 6 This is a flowchart illustrating steps S601-S603 provided in the embodiments of this application; Figure 7 This is a flowchart illustrating steps S701-S703 provided in the embodiments of this application; Figure 8 This is a schematic diagram of the structure of the transaction channel system transformation device provided in the embodiments of this application; Figure 9 This is a schematic diagram of the composition structure of the electronic device provided in the embodiments of this application. Detailed Implementation
[0012] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the accompanying drawings in this application are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of this application. Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or implemented simultaneously. In addition, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.
[0013] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.
[0014] Furthermore, the described embodiments are merely some, not all, of the embodiments of this application. The components of the embodiments of this application described and illustrated herein can typically be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.
[0015] In the following description, the terms "first, second, third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first, second, third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.
[0016] It should be noted that the term "comprising" will be used in the embodiments of this application to indicate the presence of the features declared thereafter, but does not exclude the addition of other features.
[0017] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application and is not intended to limit this application.
[0018] See Figure 1 , Figure 1This is a flowchart illustrating steps S101-S104 of the transaction channel system modification method provided in this application embodiment, which will be combined with... Figure 1 Steps S101-S104 are explained below.
[0019] In step S101, a microservice architecture is used to reconstruct the traditional transaction channel system to adapt it to the information technology innovation environment; Traditional transaction channel systems employ a monolithic architecture, sharing a cluster with the order processing system, making it difficult for their technology stack to adapt to the requirements of domestic IT innovation. This application's embodiment introduces a microservice architecture, breaking down the monolithic system into independent microservice units. Each service focuses on a single business function and can be independently developed, deployed, and scaled. Adaptation to the domestic IT innovation environment is one of the core objectives. By replacing non-domestic IT innovation technology components (such as servers, operating systems, and middleware), the system meets the requirements of independent controllability of information technology, while ensuring stable operation in domestic IT innovation hardware and software environments, fully leveraging the performance advantages of new hardware.
[0020] In step S102, the system data storage layer is modified by adopting a collaborative deployment of the main database and the cache database to improve data read and write performance and data security. Traditional systems share a single database, resulting in high data read / write pressure and insufficient security. This approach adopts a collaborative deployment model of "master database + cache database": the master database stores core transaction data, ensuring data persistence and security; the cache database stores frequently accessed data (such as popular product information and basic user information), reducing the access pressure on the master database and improving data retrieval efficiency. Working together, they not only solve the performance bottlenecks of traditional databases but also ensure data consistency through master-slave data synchronization, while the master database's security mechanisms (such as authentication, access control, and encryption) enhance data storage security.
[0021] In step S103, the system business processes are standardized and decoupled to establish unified interface specifications and independent business modules, thereby enabling business configuration-based expansion. Traditional systems suffer from highly coupled business rules and process logic, with no unified interface standard, leading to difficulties in business expansion. This step optimizes this through two core operations: first, establishing a unified interface specification, clarifying data transmission formats, interface protocols, and interaction processes to standardize internal and external system interactions; second, decomposing coupled business logic according to business functions, forming independent business modules, with each module communicating through standardized interfaces to eliminate strong dependencies between modules. Simultaneously, through configuration-based design, product information, transaction channel connection parameters, and other data are incorporated into a configuration center, enabling rapid deployment with only configuration adjustments required for business expansion, without extensive code modifications.
[0022] In step S104, an automated operation and maintenance mechanism is built to automate task scheduling, system deployment, and operational status monitoring.
[0023] Traditional system operation and maintenance relies on manual operation, resulting in low deployment efficiency and untimely fault detection. This step builds an operation and maintenance system through three major automation capabilities: automated task scheduling (such as scheduled data backup and log cleanup), automated system deployment (achieving rapid deployment and version updates through containerization technology), and automated operational status monitoring (real-time collection of system resources, interface performance, and other indicators). Automated operation and maintenance not only reduces human error but also detects system anomalies in real time and triggers alerts, alleviating operational pressure and improving system reliability and business continuity.
[0024] The above approach achieves system adaptation to domestic IT innovation, high performance, high flexibility, and low operation and maintenance costs, solving multiple technical pain points of traditional systems.
[0025] In some embodiments, see Figure 2 , Figure 2 This is a flowchart illustrating steps S201-S204 provided in the embodiments of this application. Microservice architecture refactoring can be achieved through steps S201-S204, and will be explained in conjunction with each step.
[0026] In step S201, independent microservice units are built based on a microservice development framework, and distributed governance of the microservice cluster is achieved through a distributed governance component. The microservice development framework is the Spring Boot framework, and the distributed governance component is Spring Cloud. In step S202, a centralized configuration center is deployed, which is used to support the dynamic refreshing and unified management of microservice configuration information; In step S203, the service registration and discovery component is configured to enable automatic registration, address resolution, and service invocation of microservice instances; In step S204, load balancing and fault tolerance components are integrated to distribute external requests evenly and to perform circuit breaking and degradation processing on faulty services.
[0027] Here, Spring Boot is chosen as the microservice development framework. Based on the principle of convention over configuration, it simplifies the initial setup and development process of microservices. By embedding a server, such as Tomcat, it enables rapid application startup without additional deployment steps and supports automatic dependency configuration, reducing redundant XML configuration. Spring Cloud, as a distributed governance component, is built on top of Spring Boot and provides core distributed system capabilities such as service registration and discovery, load balancing, and fault tolerance. Together, they form the foundation of the microservice architecture, ensuring that each microservice unit can work efficiently together.
[0028] Apollo is used as the centralized configuration center to manage the configuration information of all microservices, such as database connection parameters and business rule thresholds. The configuration center supports dynamic updates of configuration information. When business requirements change or the system is upgraded, configurations can be modified directly in the configuration center without restarting microservices or the entire system, greatly improving system flexibility and maintainability. For example, when adding a new transaction channel, only the channel configuration parameters need to be updated in Apollo, and all relevant microservices can obtain the latest configuration and apply it in real time.
[0029] Consul is chosen as the service registration and discovery component. When a microservice starts, it automatically registers its information with Consul, including service name, address, and port, forming a list of service instances. When other microservices need to call a target service, they can query the available instance address of the target service through Consul, eliminating the need for hardcoding service addresses and enabling dynamic adaptation for service calls. For example, when a transaction microservice needs to call an order processing microservice, it obtains the currently available instance list of the order processing microservice through Consul, ensuring the accuracy and high availability of the call.
[0030] Ribbon was chosen as the client-side load balancer, used in conjunction with Consul. After obtaining the list of target service instances from Consul, Ribbon distributes requests evenly across the instances using preset strategies such as round-robin, random, and weighted allocation. This prevents individual instances from becoming overloaded and improves the overall system processing capacity. For example, in high-concurrency scenarios, requests from multiple transaction channels are evenly distributed across multiple order processing microservice instances via Ribbon, ensuring fast interface response times.
[0031] Hystrix is chosen as the fault tolerance library, providing mechanisms such as circuit breakers and degradation handling. When a microservice fails or times out, Hystrix automatically shuts down the service to prevent the failure from spreading to the entire system and avoid a cascading failure effect; at the same time, it triggers degradation handling, returning a preset default response, such as "Service is temporarily unavailable, please try again later", to ensure basic system availability and user experience.
[0032] The above approach ensures the stability, scalability, and fault tolerance of the microservice architecture, providing solid architectural support for overall system upgrades.
[0033] In some embodiments, see Figure 3 , Figure 3 This is a flowchart illustrating steps S301-S303 provided in the embodiments of this application. Adaptation to the information technology innovation environment can be achieved through steps S301-S303, which will be explained in conjunction with each step.
[0034] In step S301, a technology stack is used to replace traditional non-IT innovation components. The technology stack includes an IT innovation server, an operating system, and middleware. In step S302, the microservice interface is adapted for compatibility to ensure consistency with the data interaction format of the domestic IT terminal. In step S303, the concurrent processing capability and stable operation performance of the system under the information technology innovation environment are verified through concurrent stress test and compatibility test.
[0035] Traditional transaction channel systems use non-domestic-innovation components such as Oracle / WebLogic, which cannot meet the requirements of independent controllability. This application's embodiment replaces core components such as servers, operating systems, and middleware with domestically-compatible products, such as domestically-compatible servers, operating systems, and middleware, through technology stack replacement, thus constructing a fully independent and controllable technology system. During the replacement process, it is necessary to ensure the compatibility between various domestically-compatible components and their adaptability to microservice architecture, laying the foundation for stable system operation.
[0036] Data interaction formats may differ between domestically developed (IT) terminals and traditional terminals. To ensure smooth communication between the system and IT-enabled terminals, microservice interfaces need to be adapted for compatibility. This includes standardizing data interaction formats (e.g., JSON), standardizing interface protocols (e.g., HTTP / HTTPS), and adapting to the specific data parsing requirements of IT-enabled terminals. Through interface compatibility adaptation, it is ensured that requests sent by IT-enabled terminals can be correctly parsed by the system, and that responses returned by the system can be properly processed by the IT-enabled terminals, thus achieving consistency in data interaction.
[0037] To verify the system's performance and stability in a domestic IT innovation environment, two core tests need to be conducted: Concurrency stress testing: Simulate high-concurrency transaction scenarios, such as e-commerce promotions and peak business periods. Using testing tools such as JMeter, send a large number of concurrent requests to the system to verify whether the system's throughput, response time and other indicators meet business requirements, and ensure that the system can cope with the concurrency pressure brought by business growth in the domestic IT innovation environment.
[0038] Compatibility testing: Comprehensively verify the compatibility of the system with domestically developed hardware, servers, terminals, domestically developed software, operating systems, databases, and middleware; troubleshoot compatibility issues during the adaptation process, such as interface call failures and data storage anomalies, to ensure the system runs stably in all scenarios under the domestically developed environment.
[0039] The above methods ensure that the system fully complies with the requirements of the information technology innovation initiative, while guaranteeing the system's performance and stability in the information technology innovation environment, and eliminating compliance and operational risks brought about by technology selection.
[0040] In some embodiments, see Figure 4 , Figure 4This is a flowchart illustrating steps S401-S403 provided in the embodiments of this application. The data storage layer modification can be achieved through steps S401-S403, which will be explained in conjunction with each step.
[0041] In step S401, the traditional shared database is replaced with a high-reliability master database, which is used to store core transaction data and provides user authentication, permission management and data encryption functions. In step S402, a cache database is deployed to store frequently accessed data, wherein the cache database is a Redis database; In step S403, a cache synchronization update strategy is established. When the data in the main database changes, the corresponding data in the cache database is updated synchronously to ensure data consistency between the main database and the cache database.
[0042] Here, the traditional shared Oracle database is replaced with Gauss database as the primary database. Gauss database features high performance, high reliability, and high security, making it suitable for storing core transaction data, such as order information and user transaction records.
[0043] Redis was chosen as the caching database due to its in-memory storage characteristics, which offer extremely high read and write speeds. The core application scenario for caching databases is storing frequently accessed data, such as popular product information, basic user information, and business rule configurations. When the system needs to retrieve this data, it prioritizes reading from the Redis cache, avoiding frequent access to the main database, significantly reducing the pressure on the main database, and improving data read response speed, typically down to milliseconds.
[0044] To ensure data consistency between the primary database Gauss and the cache database Redis, a synchronization update strategy is also included: when data in the primary database changes, such as product price modifications or user information updates, an update mechanism, such as a database trigger or application callback, is used to synchronously update the corresponding data in the Redis cache. The specific process is as follows: The application modifies the target data in the main database; Synchronously trigger a cache update operation to delete the old cache of the data in Redis or directly write the new data; Subsequent data query requests will prioritize reading the latest cached data in Redis.
[0045] This strategy ensures real-time consistency between cached data and the main database, avoiding business anomalies such as incorrect transaction prices caused by expired cached data.
[0046] The above approach, through the collaborative design of master-slave databases, not only improves data read and write performance but also ensures data security and consistency, providing data layer support for the high-performance operation of the system.
[0047] In some embodiments, see Figure 5 , Figure 5 This is a flowchart illustrating steps S501-S503 provided in the embodiments of this application. The standardization and decoupling of business processes can be achieved through steps S501-S503, which will be explained in conjunction with each step.
[0048] In step S501, a unified external service interface standard is established, and the data transmission format, interface protocol and interaction process are defined. In step S502, the original coupled business logic is split according to business functions to form independently operating business modules, and each business module realizes data communication through the unified external service interface; In step S503, a business configuration center is built to store configuration data such as product information and transaction channel connection parameters. When adding new businesses or expanding transaction channels, the expansion can be completed simply by modifying the configuration data in the business configuration center. Here, the standards for external service interfaces are defined, and the core content includes: Data transmission format: JSON is used as the data exchange format. Field naming rules, data types (such as strings, numbers, booleans), and length constraints are clearly defined. Interface protocol: Uses HTTP / HTTPS protocol, explicitly defines request methods (GET / POST / PUT / DELETE) and their use cases; Interaction process: Define the steps of the interface call, such as request verification, business processing, response return, timeout handling mechanism and error feedback format, and standardize error codes and error descriptions.
[0049] Next, adhering to the single responsibility principle, the previously coupled business logic was broken down into independent business modules, such as the transaction, order processing, and data statistics functions integrated in the traditional system. These modules include transaction channel modules, order processing modules, and reporting modules. Each module has its own independent database or data partition and business logic. Modules communicate only through a unified external service interface, with no direct code dependencies. For example, the transaction channel module receives transaction requests, transmits order data to the order processing module via a standardized interface, and the order processing module returns the result through the interface after processing the order; the two modules operate independently.
[0050] Then, a centralized business configuration center is built, based on Apollo or a database, to store two types of core configuration data: Product configuration information: such as product name, return rules, risk level, transaction limit, etc.; Transaction channel integration parameters: such as channel identifier, interface address, signature key, etc.
[0051] When adding new services, such as launching new products or expanding transaction channels, there is no need to modify the business module code. Simply add or update the corresponding configuration data in the configuration center, and the system will automatically recognize and load the configuration, enabling rapid business expansion. For example, when adding a new wealth management product, you only need to enter the product parameters in the configuration center, and the transaction channel module can obtain the parameters through the configuration center and support the trading of that product, significantly shortening the business launch cycle.
[0052] The above approach enhances the flexibility and scalability of business processes, reduces system maintenance costs, and meets the rapidly changing business needs of the market.
[0053] In some embodiments, see Figure 6 , Figure 6 This is a flowchart illustrating steps S601-S603 provided in the embodiments of this application. The construction of an automated operation and maintenance mechanism can be achieved through steps S601-S603, which will be explained in conjunction with each step.
[0054] In step S601, a distributed task scheduling platform is introduced to automate the scheduling of periodic tasks such as data backup, log cleanup, and report generation, and supports dynamic adjustment of task execution time and frequency. In step S602, containerization technology is used to package the microservices into image files, and container orchestration tools are used to achieve automatic deployment and version updates of the system. In step S603, a monitoring tool is deployed to collect system operation indicators, including CPU utilization, memory usage, interface response time, and data throughput. When the system operation indicators exceed a preset threshold, an alarm is automatically triggered. Here, xxl-job is chosen as the distributed task scheduling platform to automate the scheduling of periodic tasks. Core application scenarios include: Data backup: Core transaction data is backed up daily at midnight to ensure data recovery. Log cleanup: Regularly clean up expired system logs and business logs to free up storage resources; Report generation: Generate business statistical reports on a regular basis, such as daily transaction volume and channel transaction ratio.
[0055] The platform supports creating, modifying, and deleting tasks through a web interface. Task execution time can be dynamically adjusted, such as from 2 AM to 3 AM daily, and execution frequency can be adjusted, such as from once a day to once a week. Task scheduling configuration can be completed without modifying the code.
[0056] By employing Docker containerization technology, each microservice is packaged into a standardized image file and stored in an image repository. When the system is deployed, container orchestration tools, such as Kubernetes, pull the latest image from the image repository, automatically create or update container instances, and complete the deployment and version updates of the microservices.
[0057] Deploy the Prometheus + Grafana monitoring combination to build a comprehensive monitoring system: Monitoring metrics collection: Prometheus collects system operation metrics in real time, including server resource metrics, CPU utilization, memory usage, disk space, application performance metrics, interface response time, request success rate, throughput, database metrics, connection count, query time; Data visualization: Grafana displays the collected metric data in the form of charts, such as line charts and bar charts, so that operation and maintenance personnel can intuitively grasp the system's operating status. Anomaly Alarm Trigger: Preset indicator thresholds, such as CPU utilization ≥80% and interface response time ≥500ms. When the indicator exceeds the threshold, the monitoring tool will automatically send an alarm via SMS, email, etc., to notify the operation and maintenance personnel to handle it in a timely manner.
[0058] The above approach, through the full automation of task scheduling, deployment, and monitoring, significantly improves operational efficiency, reduces system downtime, and ensures stable business operation.
[0059] In some embodiments, see Figure 7 , Figure 7 This is a flowchart illustrating steps S701-S703 provided in the embodiments of this application. The establishment of a unified interface specification can be achieved through steps S701-S703, which will be explained in conjunction with each step.
[0060] In step S701, a declarative web service client component is used to encapsulate HTTP requests into programming language interface calls, simplifying the communication process between microservices; In step S702, the unified interface specification clearly defines the name, data type, length constraint of the request parameters, and the format and error code definition of the response data; In step S703, for external system integration scenarios, data interaction with third-party platforms is implemented based on the unified interface specification.
[0061] Here, OpenFeign is chosen as the declarative web service client component, encapsulating HTTP requests as Java interface calls. Developers only need to define the interface using annotations, such as `@FeignClient` specifying the target service and `@GetMapping` specifying the request path, without needing to manually write HTTP request code, such as using `HttpClient`. For example, when the transaction channel module calls the order module interface, it only needs to call the encapsulated Java interface method. OpenFeign automatically handles request sending, data serialization, and response parsing, simplifying the communication process between microservices and improving code readability and development efficiency.
[0062] A unified interface specification ensures the consistency and availability of interfaces: Request parameter constraints: Clearly define the name and data type of each parameter, such as String or Integer, and the length limit, such as 10-20 characters for user ID. Specify required / optional attributes to avoid business processing exceptions caused by non-standard parameters. Response data format: A unified response structure, including status codes (e.g., 200 for success, 500 for server error), response information (e.g., operation successful), and business data (e.g., order details); Error code definition: Establish a unified error code system, such as 10001 indicating parameter error and 10002 indicating insufficient permissions, to ensure the consistency and understandability of error messages.
[0063] For scenarios involving integration with third-party platforms, such as payment institutions and channel partners, data interaction is achieved based on a unified interface specification. Third-party platforms only need to encapsulate request data and parse response data according to this specification to integrate with the transaction channel system, eliminating the need for customized interface development. For example, when adding a third-party payment channel, the channel provides a payment result callback interface according to the unified interface specification, and the transaction channel system sends payment requests and receives callback notifications according to the specification, significantly reducing integration costs and improving integration efficiency.
[0064] The above approach ensures the feasibility of a unified interface specification, simplifies internal microservice communication, improves compatibility with external systems, and provides interface-level support for business expansion.
[0065] In summary, the embodiments of this application have the following beneficial effects: By adopting technologies such as Spring Cloud and Spring Boot to build a brand-new microservice architecture, coupled with a collaborative storage solution of Gauss database and Redis caching, and combining business process standardization, module decoupling, and configuration optimization, further supplemented by automated operation and maintenance mechanisms implemented with xxl-job, containerization technology, and Prometheus + Grafana, this system comprehensively solves the pain points of traditional transaction channel systems, such as outdated technical frameworks, high code coupling, functional redundancy, limited business expansion, and complex operation and maintenance. It not only successfully adapts the system to domestically developed terminals and servers, meeting the requirements of independent control and security compliance in information technology, but also significantly improves the system's carrying capacity, stability, and data processing efficiency. It achieves complete decoupling between the transaction channel and the order issuance system, reduces system maintenance costs and development difficulty, supports rapid product launch and flexible expansion of transaction channels, while significantly reducing operation and maintenance pressure and improving the timeliness of operation and maintenance response. Ultimately, it helps enterprises improve operational efficiency, enhance market responsiveness and core competitiveness, and provide solid technical support for continuous business growth.
[0066] Based on the same inventive concept, this application also provides a transaction channel system transformation device corresponding to the transaction channel system transformation method in the first embodiment. Since the principle of the device in this application is similar to the above-mentioned transaction channel system transformation method, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.
[0067] like Figure 8 As shown, Figure 8 This is a schematic diagram of the structure of the transaction channel system transformation device 800 provided in this application embodiment. The transaction channel system transformation device 800 includes: The architecture refactoring module 801 is used to refactor the traditional transaction channel system using a microservice architecture to achieve adaptation to the information technology innovation environment. The database transformation module 802 is used to transform the system's data storage layer by adopting a collaborative deployment approach between the main database and the cache database to improve data read and write performance and data security. The business decoupling module 803 is used to standardize and decouple system business processes, establish unified interface specifications and independent business modules, and realize business configuration-based expansion. Operations and maintenance module 804 is used to build an automated operations and maintenance mechanism to automate task scheduling, system deployment, and operational status monitoring.
[0068] Those skilled in the art should understand that Figure 8 The functions of each unit in the transaction channel system transformation device 800 shown can be understood by referring to the relevant description of the aforementioned transaction channel system transformation method. Figure 8The functions of each unit in the transaction channel system modification device 800 shown can be realized by a program running on a processor or by specific logic circuits.
[0069] In one possible implementation, microservice architecture refactoring includes: Independent microservice units are built based on a microservice development framework, and distributed governance of the microservice cluster is achieved through a distributed governance component. The microservice development framework is the Spring Boot framework, and the distributed governance component is Spring Cloud. Deploy a centralized configuration center, which is used to support the dynamic refreshing and unified management of microservice configuration information; Configure the service registration and discovery component to enable automatic registration, address resolution, and service invocation of microservice instances; It integrates load balancing and fault tolerance components to distribute external requests evenly and perform circuit breaking and degradation processing on faulty services. In one possible implementation, adaptation to the domestic IT innovation environment includes: The traditional non-IT innovation components are replaced with a technology stack, which includes IT innovation servers, operating systems and middleware; Perform compatibility adaptation on microservice interfaces to ensure consistency of data interaction formats with domestically developed terminals; The concurrent stress test and compatibility test were conducted to verify the system's concurrent processing capability and stable operation performance in the domestic IT innovation environment. In one possible implementation, the data storage layer modification includes: The traditional shared database is replaced with a highly reliable master database, which is used to store core transaction data and provides user authentication, access management and data encryption functions. Deploy a cache database to store frequently accessed data in the cache database, which is a Redis database; Establish a cache synchronization update strategy. When data changes in the main database, the corresponding data in the cache database is updated synchronously to ensure data consistency between the main database and the cache database. In one possible implementation, the standardization and decoupling of business processes includes: Establish unified external service interface standards to clarify data transmission formats, interface protocols, and interaction processes; The original coupled business logic is split according to business functions to form independently operating business modules. Each business module communicates with data through the unified external service interface. A business configuration center is built to store configuration data such as product information and transaction channel connection parameters. When adding new businesses or expanding transaction channels, the expansion can be completed simply by modifying the configuration data in the business configuration center. In one possible implementation, the construction of an automated operation and maintenance mechanism includes: A distributed task scheduling platform is introduced to automate the scheduling of periodic tasks such as data backup, log cleanup, and report generation, and supports dynamic adjustment of task execution time and frequency; Containerization technology is used to package microservices into image files, and container orchestration tools are used to achieve automatic system deployment and version updates. The system uses monitoring tools to collect system performance metrics, including CPU utilization, memory usage, interface response time, and data throughput. When these metrics exceed preset thresholds, an alarm is automatically triggered. In one possible implementation, the establishment of a unified interface specification includes: By using a declarative web service client component, HTTP requests are encapsulated into programming language interface calls, simplifying the communication process between microservices; The unified interface specification clearly defines the name, data type, length constraints of request parameters, and the format and error code definitions of response data. For scenarios involving external system integration, data interaction with third-party platforms is achieved based on the aforementioned unified interface specification.
[0070] The aforementioned transaction channel system transformation device utilizes technologies such as Spring Cloud and Spring Boot to build a brand-new microservice architecture, coupled with a collaborative storage solution of Gauss database and Redis caching. It combines business process standardization, module decoupling, and configuration optimization, further supplemented by automated operation and maintenance mechanisms implemented using xxl-job, containerization technology, and Prometheus+Grafana. This comprehensively addresses the pain points of traditional transaction channel systems, such as outdated technical frameworks, high code coupling, functional redundancy, limited business expansion, and complex operation and maintenance. It not only successfully adapts the system to domestically developed terminals and servers, meeting the requirements of independent control and security compliance in information technology, but also significantly improves the system's carrying capacity, stability, and data processing efficiency. It achieves complete decoupling between the transaction channel and the order issuance system, reducing system maintenance costs and development difficulty, supporting rapid product launches and flexible expansion of transaction channels, while significantly reducing operational pressure and improving the timeliness of operational response. Ultimately, it helps enterprises improve operational efficiency, enhance market responsiveness and core competitiveness, and provide solid technical support for continuous business growth.
[0071] like Figure 9 As shown, Figure 9This is a schematic diagram of the composition structure of the electronic device 900 provided in the embodiments of this application. The electronic device 900 includes: The device 900 includes a processor 901, a storage medium 902, and a bus 903. The storage medium 902 stores machine-readable instructions that can be executed by the processor 901. When the electronic device 900 is running, the processor 901 communicates with the storage medium 902 via the bus 903. The processor 901 executes the machine-readable instructions to perform the steps of the transaction channel system modification method described in the embodiments of this application.
[0072] In practical applications, the various components in the electronic device 900 are coupled together via a bus 903. It is understood that the bus 903 is used to achieve communication between these components. In addition to a data bus, the bus 903 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 9 The general designated all buses as Bus 903.
[0073] The aforementioned electronic devices utilize a novel microservice architecture built with technologies such as Spring Cloud and Spring Boot, coupled with a collaborative storage solution combining Gauss database and Redis caching. This is further enhanced by standardized business processes, module decoupling, and configuration optimization, supplemented by automated operation and maintenance mechanisms implemented using xxl-job, containerization technology, and Prometheus+Grafana. This comprehensively addresses the pain points of traditional transaction channel systems, such as outdated technical frameworks, high code coupling, functional redundancy, limited business expansion, and complex operation and maintenance. The system not only successfully adapts to domestically developed terminals and servers, meeting the requirements of independent control and security compliance in information technology, but also significantly improves the system's carrying capacity, stability, and data processing efficiency. It achieves complete decoupling between the transaction channel and the order processing system, reducing system maintenance costs and development difficulty, supporting rapid product launches and flexible expansion of transaction channels, while greatly alleviating operational pressure and improving the timeliness of operational response. Ultimately, this helps enterprises improve operational efficiency, enhance market responsiveness and core competitiveness, and provide solid technical support for continuous business growth.
[0074] This application also provides a computer-readable storage medium storing executable instructions. When the executable instructions are executed by at least one processor 901, the transaction channel system modification method described in this application is implemented.
[0075] In some embodiments, the storage medium may be a magnetic random access memory (FRAM), a read-only memory (ROM), or a programmable read-only memory (PROM). Erasable Programmable Read-Only Memory (EPROM) Electrically Erasable Programmable Read-Only Memory (EEPROM) Read-only memory, flash memory, magnetic surface storage, optical disc, or CD-ROM ROM, Compact Disc Read It can be a memory such as a memory only; or it can be a device that includes one or any combination of the above-mentioned memories.
[0076] In some embodiments, executable instructions may take the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.
[0077] As an example, executable instructions may, but do not necessarily, correspond to files in the file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a HyperText Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple collaborating files (e.g., a file that stores one or more modules, subroutines, or code sections).
[0078] As an example, executable instructions can be deployed to execute on a single computing device, or on multiple computing devices located in one location, or on multiple computing devices distributed across multiple locations and interconnected via a communication network.
[0079] The aforementioned computer-readable storage media utilizes a novel microservice architecture built with technologies such as Spring Cloud and Spring Boot, coupled with a collaborative storage solution combining Gauss database and Redis caching. This is further enhanced by standardized business processes, module decoupling, and configurable optimization, supplemented by automated operation and maintenance mechanisms implemented using xxl-job, containerization technology, and Prometheus+Grafana. This comprehensively addresses the pain points of traditional transaction channel systems, such as outdated technical frameworks, high code coupling, functional redundancy, limited business expansion, and complex operation and maintenance. It not only successfully adapts the system to domestically developed terminals and servers, meeting the requirements of independent control and security compliance in information technology, but also significantly improves the system's carrying capacity, stability, and data processing efficiency. It achieves complete decoupling between the transaction channel and the order processing system, reducing system maintenance costs and development difficulty, supporting rapid product launches and flexible expansion of transaction channels, while significantly alleviating operational pressure and improving the timeliness of operational response. Ultimately, it helps enterprises improve operational efficiency, enhance market responsiveness and core competitiveness, and provide solid technical support for continuous business growth.
[0080] In the several embodiments provided in this application, it should be understood that the disclosed methods and electronic devices can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components may be combined, or integrated into another system, or some features may be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed may be through some interfaces, and the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.
[0081] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0082] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.
[0083] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a platform server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.
[0084] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
Claims
1. A method for transforming a transaction channel system, characterized in that, Includes the following steps: The traditional transaction channel system is restructured using a microservice architecture to adapt to the information technology innovation environment; Transform the system's data storage layer by adopting a collaborative deployment approach between the main database and the cache database to improve data read / write performance and data security. Standardize and decouple system business processes, establish unified interface specifications and independent business modules, and realize business configuration-based expansion; Build an automated operation and maintenance mechanism to automate task scheduling, system deployment, and operational status monitoring.
2. The method for transforming a transaction channel system according to claim 1, characterized in that, Microservice architecture refactoring includes: Independent microservice units are built based on a microservice development framework, and distributed governance of the microservice cluster is achieved through a distributed governance component. The microservice development framework is the Spring Boot framework, and the distributed governance component is Spring Cloud. Deploy a centralized configuration center, which is used to support the dynamic refreshing and unified management of microservice configuration information; Configure the service registration and discovery component to enable automatic registration, address resolution, and service invocation of microservice instances; It integrates load balancing and fault tolerance components to distribute external requests evenly and perform circuit breaking and degradation processing on faulty services.
3. The method for transforming a transaction channel system according to claim 1, characterized in that, The adaptation to the domestic IT innovation environment includes: The traditional non-IT innovation components are replaced with a technology stack, which includes IT innovation servers, operating systems and middleware; Perform compatibility adaptation on microservice interfaces to ensure consistency of data interaction formats with domestically developed terminals; The concurrent stress test and compatibility test were conducted to verify the system's concurrent processing capability and stable operation performance in the domestic IT innovation environment.
4. The method for transforming a transaction channel system according to claim 1, characterized in that, The data storage layer transformation includes: The traditional shared database is replaced with a highly reliable master database, which is used to store core transaction data and provides user authentication, access management and data encryption functions. Deploy a cache database to store frequently accessed data in the cache database, which is a Redis database; Establish a cache synchronization update strategy. When data changes in the main database, the corresponding data in the cache database is updated synchronously to ensure data consistency between the main database and the cache database.
5. The method for transforming a transaction channel system according to claim 1, characterized in that, The standardization and decoupling of business processes includes: Establish unified external service interface standards to clarify data transmission formats, interface protocols, and interaction processes; The original coupled business logic is split according to business functions to form independently operating business modules. Each business module communicates with data through the unified external service interface. A business configuration center is built to store configuration data such as product information and transaction channel connection parameters. When adding new businesses or expanding transaction channels, the expansion can be completed simply by modifying the configuration data in the business configuration center.
6. The method for transforming a transaction channel system according to claim 1, characterized in that, The construction of an automated operation and maintenance mechanism includes: A distributed task scheduling platform is introduced to automate the scheduling of periodic tasks such as data backup, log cleanup, and report generation, and supports dynamic adjustment of task execution time and frequency; Containerization technology is used to package microservices into image files, and container orchestration tools are used to achieve automatic system deployment and version updates. The system uses monitoring tools to collect system performance metrics, including CPU utilization, memory usage, interface response time, and data throughput. When these metrics exceed preset thresholds, an alarm is automatically triggered.
7. The method for transforming a transaction channel system according to claim 1, characterized in that, The establishment of a unified interface specification includes: By using a declarative web service client component, HTTP requests are encapsulated into programming language interface calls, simplifying the communication process between microservices; The unified interface specification clearly defines the name, data type, length constraints of request parameters, and the format and error code definitions of response data. For scenarios involving external system integration, data interaction with third-party platforms is achieved based on the aforementioned unified interface specification.
8. A device for upgrading a transaction channel system, characterized in that, The device includes: The architecture refactoring module is used to refactor the traditional transaction channel system using a microservice architecture to achieve compatibility with the information technology innovation environment. The database transformation module is used to transform the system's data storage layer, adopting a collaborative deployment approach between the main database and the cache database to improve data read and write performance and data security. The business decoupling module is used to standardize and decouple system business processes, establish unified interface specifications and independent business modules, and realize business configuration-based expansion. The operations and maintenance module is used to build an automated operations and maintenance mechanism to automate task scheduling, system deployment, and operational status monitoring.
9. An electronic device, characterized in that, include: The device includes a processor, a storage medium, and a bus, wherein the storage medium stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the transaction channel system modification method as described in any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which, when executed by a processor, performs the transaction channel system modification method as described in any one of claims 1 to 7.