Aggregated payment multi-channel isolation framework

Abstract

An aggregation payment multi-channel isolation framework comprises a payment service layer, a guide class loader, an extension class loader, a system class loader, a payment channel, a custom class loader, an agent class loader and a multi-version management module. Each payment channel is correspondingly associated with a custom class loader, and the custom class loaders do not support mutual calling. And the proxy class loader is used for instantiating the custom class loader associated with each payment channel in an initialization process and is responsible for coordinating the custom class loader and the system class loader. And the multi-version management module is used for controlling switching between different versions of the payment channel and gray release. Compared with the prior art, the method has the capability of supporting multi-payment channel isolation, multi-version gray scale and infinitely extending payment channels.

Description

Technical Field

[0001] The present invention belongs to the technical field of aggregate payment channel isolation, and in particular relates to an aggregate payment multi-channel isolation framework. Background Art

[0002] With the rapid development of the electronic payment industry, aggregate payment, as a technical solution integrating multiple payment channels, plays a bridging role between merchants and payment institutions. Although the existing aggregate payment technology has achieved multi-channel integration, it often has the following problems:

[0003] 1. Insufficient isolation of multiple payment channels: In the existing aggregated payment system, different payment channels often adopt a parent delegation mechanism. This mechanism may lead to dependency conflicts between different channels, such as different channels relying on different versions of the same library, or conflicts between classes with the same name. These conflicts may cause system crashes or unexpected behaviors, seriously affecting the stability and security of the system.

[0004] 2. Lack of support for multiple versions of grayscale: With the update and iteration of payment channels, existing systems often cannot support the grayscale release of multiple versions. This means that system upgrades must be stopped and cannot be smoothly transitioned to the new version, affecting the continuity and stability of payment services.

[0005] 3. Limited scalability of payment channels: As the payment market changes, new payment channels continue to emerge, and existing aggregate payment systems often find it difficult to support unlimited scalability of payment channels. This limits the flexibility of the system and cannot meet the diverse payment needs of merchants. Summary of the invention

[0006] In view of the above deficiencies in the prior art, the present invention provides an aggregated payment multi-channel isolation framework, which has the ability to support multi-payment channel isolation, multi-version grayscale and unlimited expansion of payment channels in the same JVM (Java virtual machine).

[0007] In order to solve the above technical problems, the present invention is solved by the following technical solutions.

[0008] An aggregated payment multi-channel isolation framework includes a payment service layer, a boot class loader, an extension class loader, a system class loader, a payment channel, a custom class loader, a proxy class loader and a multi-version management module.

[0009] Each payment channel is associated with a custom class loader, and custom class loaders do not support mutual calls. This ensures complete isolation between different payment channels, and the upper-level proxy container uniformly routes the calls, avoiding channel conflicts and resource competition, and improving system stability. In addition, the design of the custom class loader cooperates with the existing containerized deployment strategy to support unlimited expansion of payment channels, making the system more flexible and adaptable. The proxy class loader is used to instantiate the custom class loader associated with each payment channel during the initialization process, and is responsible for coordinating the custom class loader and the system class loader. The multi-version management module is used to control the switching and grayscale release between different versions of the payment channel. The design of the multi-version management module can achieve smooth upgrades and fault rollbacks to ensure the continuity and stability of payment services.

[0010] Preferably, the multi-version management module is configured with version information of each payment channel, and the version information includes the channel name, version number and the path of the corresponding channel package. The version information can distinguish different channels and different versions of the same channel, and facilitate the introduction of channel packages by custom class loaders, facilitate version management of payment channels, and perform version switching and grayscale release.

[0011] Preferably, the multi-version management module is also configured with flow permission control rules, which include flow limiting rules and fuse rules. Through flow permission control, faulty channels can be isolated and flow limited to the faulty channels to avoid affecting the throughput of the payment system, increase system stability, and provide merchants and customers with a better payment experience.

[0012] Preferably, a packaging plug-in is also included, and the packaging plug-in is implemented by a Maven plug-in, which is used to package the channel dependency configuration information that needs to be isolated, so that the corresponding custom class loader can import and load it. This design can avoid problems such as channel package conflicts, and the packaging process can be customized, which simplifies the packaging process, improves development efficiency, and ensures the effectiveness of dependency isolation.

[0013] Compared with the prior art, this application has the following beneficial effects: it breaks the traditional parent delegation mechanism, binds an independent custom class loader to each payment channel and its dependencies, implements the isolation of different payment channels, ensures that each payment channel will be loaded with an independent custom class loader, and does not have any risk of channel conflict. At the same time, it provides support for multi-version grayscale release of different versions of the same payment channel. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Figure 1 This is a diagram illustrating the mechanism of a class loader in the prior art.

[0015] Figure 2 This is a diagram illustrating the mechanism of the class loader in this application.

[0016] Figure 3 This is a workflow diagram of the class loader in this application.

[0017] Figure 4 The following is an example diagram of a channel package dependency conflict. DETAILED DESCRIPTION

[0018] The present invention is further described in detail below in conjunction with the accompanying drawings and specific embodiments.

[0019] In the following embodiments, the same or similar reference numerals throughout represent the same or similar components or components with the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0020] In the description of the present invention, it should be understood that the terms: center, longitudinal, transverse, length, width, thickness, up, down, front, back, left, right, vertical, horizontal, top, bottom, inside, outside, clockwise, counterclockwise, etc. indicating the orientation or position relationship are based on the orientation or position relationship shown in the accompanying drawings, which is only for the convenience of describing the present invention and simplifying the description, and therefore cannot be understood as limiting the present invention. In addition, the terms: first, second, etc. are only used for descriptive purposes and cannot be understood as indicating or implying relative importance or implicitly indicating the number of technical features shown. In the description of the present invention, unless otherwise clearly specified and limited, the terms: install, connect, connect, etc. should be understood in a broad sense, and ordinary technicians in this field can understand the specific meaning of the above terms in this practicality according to the specific circumstances.

[0021] The existing aggregate payment system includes a payment service layer, a boot class loader, an extension class loader, a system class loader, and several payment channels. The payment service layer is used to receive payment requests, identify and call payment channels to complete payment services. Different payment channels often use a parent delegation mechanism. Under the parent delegation mechanism, reference Figure 1 After receiving the loading request, the system class loader will first delegate to the extension class loader, and the extension class loader will delegate to the boot class loader. When the boot class loader cannot load, the extension class loader will load it. When the extension class loader cannot load, the system class loader will load it. This mechanism may cause dependency conflicts between different payment channels, such as different payment channels relying on different versions of the same library, or conflicts between classes with the same name. These conflicts may cause system crashes or unexpected behaviors, seriously affecting the stability and security of the system.

[0022] To solve the above problems, the present application proposes a multi-channel isolation framework for aggregated payment, including a payment service layer, a boot class loader, an extension class loader, a system class loader, a payment channel, a custom class loader, a proxy class loader and a multi-version management module. Each payment channel is associated with a custom class loader, and custom class loaders do not support mutual calls. This ensures that different payment channels are completely isolated, and the upper-level proxy container uniformly routes the calls, avoiding channel conflicts and resource competition, and improving system stability. In addition, the design of the custom class loader cooperates with the existing containerized deployment strategy to support unlimited expansion of payment channels, making the system more flexible and adaptable. The proxy class loader is used to instantiate the custom class loader associated with each payment channel during the initialization process, and is responsible for coordinating the custom class loader and the system class loader. The multi-version management module is used to control the switching and grayscale release between different versions of the payment channel. The design of the multi-version management module can achieve smooth upgrades and fault rollbacks, ensuring the continuity and stability of payment services.

[0023] The deployment and workflow of the multi-channel isolation framework for aggregated payment described in this application are as follows: When building and deploying, each channel and its dependencies that need to be isolated are built into independent channel packages and stored in the same directory. At the same time, the corresponding version information for each channel is built and stored in the multi-version management module. When the project starts, during the initialization process, the proxy class loader instantiates independent custom class loaders when parsing the channel package. These custom class loaders do not support mutual calls to ensure that channels are isolated from each other. When a payment request occurs, the payment service layer calls the corresponding code logic according to the identified channel to complete the payment business. When performing version management, the multi-version management module is used to cooperate with various loaders to perform operations such as online and offline payment channels, version switching, and grayscale release.

[0024] Among them, reference Figure 2 and Figure 3 When a class needs to be loaded (including channel package jar package, software development kit SDK, and non-channel class file), the proxy class loader determines whether the class to be loaded needs to be isolated. If isolation is required, it is routed to the custom class loader for loading; if isolation is not required, it is routed to the system class loader for loading. The system class loader complies with the parent delegation mechanism.

[0025] In the present application, the multi-version management module is configured with version information of each payment channel, and the version information includes the channel name, version number and the path of the corresponding channel package. The version information can distinguish different channels and different versions of the same channel, and facilitate the introduction of channel packages by custom class loaders, facilitate version management of payment channels, and perform version switching and grayscale release.

[0026] In order to further improve the payment experience of merchants and customers, the multi-version management module is also configured with flow permission control rules, which include flow limiting rules and fuse rules. Through flow permission control, faulty channels can be isolated and flow limited to the faulty channels to avoid affecting the throughput of the payment system and increase system stability.

[0027] The present application also includes a packaging plug-in, which is implemented using a Maven plug-in and is used to package the channel dependency configuration information that needs to be isolated for introduction and loading by the corresponding custom class loader. This design can avoid problems such as channel package conflicts, and the packaging process can be customized, which simplifies the packaging process, improves development efficiency, and ensures the effectiveness of dependency isolation.

[0028] For example, refer to Figure 4 , the framework needs to introduce two payment channels: A and B, but A needs to rely on package C with version number 1, and B happens to rely on package C with version number 2. The two versions of package C are incompatible, which will cause a channel package dependency conflict. At this time, you only need to use the packaging plug-in to package A and package C with version 1 into a jar package, and then let the application project introduce the jar package through a custom class loader to solve the dependency conflict.

[0029] The protection scope of the present invention includes but is not limited to the above embodiments. The protection scope of the present invention shall be based on the claims. Any replacement, deformation, and improvement of the technology that can be easily thought of by technicians in this field shall fall within the protection scope of the present invention.

Claims

1. An aggregate payment multi-channel isolation framework, including a payment service layer, a boot class loader, an extension class loader, a system class loader and several payment channels, characterized in that: It also includes custom class loaders, proxy class loaders, and multi-version management modules; Each payment channel is associated with a custom class loader, and custom class loaders do not support mutual calls; The proxy class loader is used to instantiate the custom class loader associated with each payment channel during the initialization process, and is responsible for coordinating the custom class loader and the system class loader; The multi-version management module is used to control the switching and grayscale release between different versions of the payment channel.

2. According to claim 1, a multi-channel isolation framework for aggregated payment is characterized in that: The multi-version management module is configured with version information of each payment channel, and the version information includes the channel name, version number and path of the corresponding channel package.

3. According to claim 2, a multi-channel isolation framework for aggregated payment is characterized in that: The multi-version management module is also configured with flow permission control rules, and the flow permission control rules include flow limiting rules and fuse rules.

4. According to claim 1, a multi-channel isolation framework for aggregated payment is characterized in that: It also includes a packaging plug-in, which is implemented using a Maven plug-in and is used to package channel dependency configuration information that needs to be isolated so that the corresponding custom class loader can import and load it.

Images