Gray switching method and device for transaction upgrade

Abstract

The application discloses a transaction upgrade gray switching method and device, and relates to the technical field of big data resource scheduling. The method comprises the following steps: identifying transactions, and screening out transactions that need to be subjected to gray switching; matching the transactions that need to be subjected to gray switching according to a gray algorithm rule to obtain a matching result, wherein the gray algorithm rule comprises multi-dimensional switching parameters; and based on the matching result, distributing and routing the transactions that need to be subjected to gray switching to a changed new transaction service according to the corresponding relationship between the gray algorithm expected processing result and the transaction routing, and performing transaction processing. The application does not need to stop business switching; the switching is based on the gray algorithm rule, and therefore the availability is stronger; a gateway does not need to be additionally deployed, the cost is reduced, and the response time of the transaction is not increased.

Description

Technical Field

[0001] This invention can be applied to the field of big data resource scheduling technology, and in particular relates to a method and apparatus for gray-scale switching of transaction upgrades. Background Technology

[0002] This section is intended to provide background or context for the embodiments of the invention set forth in the claims. The description herein is not an admission that it is prior art simply because it is included in this section.

[0003] With the development of social informatization and banking technology, especially the rapid growth of mobile internet in recent years, mobile payment transaction volume has increased rapidly. Bank systems are handling increasingly larger volumes of business, placing higher demands on their security and stability. Simultaneously, technological advancements necessitate upgrades and modifications to existing transactions. Transaction upgrades refer to the upgrading and migration of existing transactions based on business and technical requirements, such as replacing or upgrading security certificates between transactions, migrating transactions, and upgrading transaction security modes. Therefore, ensuring a smooth transition after transaction upgrades and modifications becomes crucial.

[0004] Gray-scale release refers to a release method that allows for a smooth transition between black and white versions. Versions A and B are released simultaneously, allowing some users to continue using version A while others start using version B. If users have no feedback on version B, the scope is expanded, and all users are migrated to version B. Gray-scale release can ensure the overall stability of the system and minimize the impact.

[0005] Existing methods for achieving a smooth transition during transaction upgrades through canary releases include: 1. Business shutdown switchover: During off-peak trading periods, the transaction is paused for switching and verification. Service resumes after successful verification. This method requires suspending transactions, resulting in a poor customer experience and significant business impact, and is only suitable for businesses with extremely low transaction volumes. 2. Whitelist-based canary release: This technology configures a whitelist and performs canary switching on users within the whitelist. If no feedback is received from whitelist users, the whitelist is expanded until a full switch is implemented. This method requires multiple switches to verify the reliability of the upgraded transaction, increasing system complexity and maintenance costs. It also impacts whitelist users, requiring precise determination of the whitelist scope. 3. Simultaneous deployment of new and old transactions on different servers, providing services concurrently, using a gateway to distribute traffic and distribute transactions to different servers. This method, based on API gateway canary releases, can achieve canary access to transactions, but requires simultaneous deployment of both old and new systems, increasing server costs. Furthermore, for outbound calls within the same access transaction, gray-scale switching cannot be implemented. For example, if the transaction path is A -> Gateway -> B -> C, outbound call transactions from system B to system C cannot be gray-scale switched. Summary of the Invention

[0006] This invention provides a method for gray-scale switching of transaction upgrades, the method comprising:

[0007] Identify and filter out transactions that require grayscale switching;

[0008] Transactions that require grayscale switching are matched according to grayscale algorithm rules to obtain matching results. The grayscale algorithm rules include multi-dimensional switching parameters.

[0009] Based on the matching results, and according to the correspondence between the expected processing results of the grayscale algorithm and the transaction routing, the transactions that need to be switched to grayscale are routed to the new transaction service for processing.

[0010] In one embodiment, the transaction is an access transaction or an outbound call transaction.

[0011] In one embodiment, identifying transactions and filtering out those requiring grayscale switching includes:

[0012] Transactions are identified based on their transaction messages and HTTP request headers, and those requiring canary rollout are selected.

[0013] In one embodiment, it also includes:

[0014] The identified transactions are stored in thread variables for use in transaction routing.

[0015] In one embodiment, the multi-dimensional switching parameters include application cluster dimension, server dimension, transaction dimension, transaction field dimension, transaction stage dimension, and / or transaction ratio dimension.

[0016] In one embodiment, it also includes:

[0017] Use a cache database to store multi-dimensional switching parameters.

[0018] This invention also provides a grayscale switching device for transaction upgrades, the grayscale switching device for transaction upgrades comprising:

[0019] The transaction identification module is used to identify transactions and filter out those that need to be switched to grayscale.

[0020] The grayscale algorithm module is used to match transactions that need to be switched to grayscale according to grayscale algorithm rules and obtain matching results. The grayscale algorithm rules include multi-dimensional switching parameters.

[0021] The transaction routing module is used to route transactions that need to be switched to the new transaction service for processing based on the matching results and the correspondence between the expected processing results of the grayscale algorithm and the transaction routing.

[0022] In one embodiment, the transaction is an access transaction or an outbound call transaction.

[0023] In one embodiment, the transaction identification module is specifically used for:

[0024] Transactions are identified based on their transaction messages and HTTP request headers, and those requiring canary rollout are selected.

[0025] In one embodiment, the transaction identification module is also used for:

[0026] The identified transactions are stored in thread variables for use in transaction routing.

[0027] In one embodiment, the multi-dimensional switching parameters include application cluster dimension, server dimension, transaction dimension, transaction field dimension, transaction stage dimension, and / or transaction ratio dimension.

[0028] In one embodiment, it also includes:

[0029] A caching server is used to store multi-dimensional switching parameters.

[0030] This invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the above-mentioned grayscale switching method for transaction upgrade.

[0031] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described grayscale switching method for transaction upgrades.

[0032] This invention also provides a computer program product, which includes a computer program that, when executed by a processor, implements the above-mentioned grayscale switching method for transaction upgrade.

[0033] In this embodiment of the invention, the proposed method for gray-scale switching of transaction upgrades includes: identifying transactions and filtering out those requiring gray-scale switching; matching the transactions requiring gray-scale switching according to gray-scale algorithm rules to obtain matching results, wherein the gray-scale algorithm rules include multi-dimensional switching parameters; and, based on the matching results and the correspondence between the expected processing results of the gray-scale algorithm and the transaction routing, distributing and routing the transactions requiring gray-scale switching to the new transaction service for transaction processing. Compared with existing technologies such as business shutdown switching, whitelist-based gray-scale release, and API gateway-based gray-scale release, this invention has the following advantages:

[0034] No business shutdown is required for the switchover; the switchover is based on gray-scale algorithm rules, resulting in stronger availability; no additional gateway deployment is required, reducing costs and not increasing transaction response time. Attached Figure Description

[0035] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings:

[0036] Figure 1 The following is a flowchart of the gray-scale switching method for transaction upgrades in this embodiment of the invention. Figure 1 ;

[0037] Figure 2 This is an example of an applicable scenario for grayscale transaction switching in this invention.

[0038] Figure 3 The following is a flowchart of the gray-scale switching method for transaction upgrades in this embodiment of the invention. Figure 2 ;

[0039] Figure 4 The following is a flowchart of the gray-scale switching method for transaction upgrades in this embodiment of the invention. Figure 3 ;

[0040] Figure 5 The structural frame of the grayscale switching device for transaction upgrade in this embodiment of the invention. Figure 1 ;

[0041] Figure 6 The structural frame of the grayscale switching device for transaction upgrade in this embodiment of the invention. Figure 2 . Detailed Implementation

[0042] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the embodiments of the present invention will be further described in detail below with reference to the accompanying drawings. Here, the illustrative embodiments of the present invention and their descriptions are used to explain the present invention, but are not intended to limit the present invention.

[0043] Terminology Explanation:

[0044] Canary release: The principle behind canary release is request routing, allowing specific users to access a service with new features, while other users continue using the old service. Since it involves request routing, this can be handled centrally within the API gateway. The gateway is the external entry point; when a user request arrives, it can forward the specific user's request to the newly released service with the new features. Canary release is only used when the system needs to release new features, and it requires a rotational switch. First, the service on machine A is put into a canary release state to isolate all requests, then it is re-released. After successful verification, the service on another machine is re-released. The Apollo configuration center is needed to manage the service and user information for canary releases, enabling this rotational switching.

[0045] The acquisition, storage, use, and processing of data in this application all comply with the relevant provisions of national laws and regulations.

[0046] Figure 1 The following is a flowchart of the gray-scale switching method for transaction upgrades in this embodiment of the invention. Figure 1 ,like Figure 1 As shown, the method includes:

[0047] Step 101: Identify the transactions and filter out those that need to be switched to grayscale.

[0048] Step 102: Match the transactions that need to be switched to grayscale according to the grayscale algorithm rules to obtain the matching results. The grayscale algorithm rules include multi-dimensional switching parameters.

[0049] Step 103: Based on the matching results, and according to the correspondence between the expected processing results of the grayscale algorithm and the transaction routing, the transactions that need to be switched to grayscale are routed to the new transaction service after the change for transaction processing.

[0050] Specifically, the grayscale algorithm is located at the core of the transaction process and is used to determine whether a transaction needs to be switched. Transactions requiring switching are matched according to the algorithm rules to calculate the scope of the switch. The algorithm rules support both hardware and software matching; hardware matching refers to matching based on physical machines or data centers, while software matching refers to matching based on transaction messages.

[0051] The grayscale algorithm rules include multi-dimensional switching parameters, which can include application cluster dimension, server dimension, transaction dimension, transaction field dimension, transaction stage dimension, and / or transaction ratio dimension. The transaction being switched can be a single transaction or multiple transactions.

[0052] Application cluster dimension: The application will be deployed in multiple clusters and will switch between them according to the cluster identifier.

[0053] Server dimension: Switch based on the name of the physical machine.

[0054] Transaction dimension: Switches based on transaction information, usually the transaction code.

[0055] Transaction field dimension: Based on the fields in the transaction message.

[0056] Transaction ratio dimension: This refers to the proportion of the transaction. The switching ratio can be freely defined according to needs, such as 0.01% or 0.1%.

[0057] Transaction phase dimension (a transaction involves encryption and signing, and only one phase is switched).

[0058] Matching depends on whether a transaction code is used when switching dimensions. If a transaction code is used, the matching rules need to be defined according to the actual situation and are not fixed rules.

[0059] The grayscale algorithm can be flexibly switched between server, transaction, and scale dimensions, and can be rolled back with one click to cancel the switch of changed transactions and use the old transactions for all transactions.

[0060] Specifically, the correspondence between the expected processing results of the canary deployment algorithm and the transaction routes is as follows: If the canary deployment algorithm expects a transaction switch to occur on a certain machine, there will be a correspondence between the machine name and the route ID. When the canary deployment algorithm hits the target, it will use that route ID. One route ID will correspond to a set of backend services. This correspondence is stored in the Redis cache as key-value pairs.

[0061] Specifically, the transaction route is located at the end of the transaction chain. All transactions that the transaction route faces are distributed to the switching processing logic and the non-switching processing logic (i.e., the new transaction after the change and the original transaction) based on the transaction identification and the processing results of the gray scale algorithm.

[0062] The system matches the required routes for a transaction based on the identified transaction content. Routing rules can be customized based on HTTP headers and message bodies (generally using a grayscale algorithm for identification, but also supporting URL paths, transaction codes, etc.). The grayscale algorithm determines whether a transaction has switched, and routing is used to determine where the transaction should be sent. Employing chained calls and reactive programming, multi-level route matching is easily achieved, significantly reducing development difficulty and complexity, and lowering system response time.

[0063] Chaining is a design pattern that simplifies code and greatly reduces repetitive code when there are many routing rules by using multi-level callbacks.

[0064] In this embodiment of the invention, the transaction is an access transaction or an active outbound call transaction.

[0065] Specifically, such as Figure 2 These are two scenarios in which the invention is applicable.

[0066] Access to transaction scenarios:

[0067] This scenario mainly targets the gray-scale switching of this system. After a transaction is accessed, it undergoes transaction identification processing and gray-scale calculation to route the transaction to different application logics, thereby realizing dynamic transaction access.

[0068] Outgoing transaction scenario:

[0069] This scenario mainly targets the gray-scale switching of outbound calls to third-party systems. The system's proactive outbound call transactions are processed by the gray-scale algorithm and routed to different third-party systems to achieve dynamic transaction switching between third-party systems.

[0070] In embodiments of the present invention, such as Figure 3 As shown, step 101 identifies transactions and filters out those that need to undergo grayscale switching, including:

[0071] Step 301: Identify transactions based on transaction messages and HTTP request headers, and filter out transactions that need to be phased out.

[0072] Specifically, transaction identification is located at the very beginning of the entire transaction processing chain. Each access is initially predicted at the application layer. Based on the transaction message and HTTP request header, all incoming transactions are identified, and transactions that need to be gray-scale switched are selected. The specific content to be identified can be customized according to different transactions.

[0073] For example, the transaction code can be identified from the message. The transaction code corresponds to a specific field in the message, and can be identified by regular expression matching. The request URI information can be identified from the HTTP message header, which can be directly obtained from the HttpServletRequest object.

[0074] In embodiments of the present invention, such as Figure 4 As shown, it also includes:

[0075] Step 401: Store the transactions that need to be grayscale switched into a thread variable for use in transaction routing.

[0076] In this embodiment of the invention, it further includes:

[0077] Use a cache database to store multi-dimensional switching parameters.

[0078] Specifically, data caching is a technique that temporarily stores data in a memory cache. It refers to a high-speed storage device inside the hard drive, which acts like a buffer in a computer, temporarily storing data for later retrieval.

[0079] Typically, large amounts of data are stored in databases, and accessing the database by an application is a time-consuming operation. If data from the database is cached in a cache beforehand, and the application retrieves this data directly from the cache when needed, system overhead can be reduced.

[0080] This invention utilizes a Redis cache database to update the switching range (the old and new transactions will run in parallel after a gray-scale switch, and this switching range refers to the range of the new transaction) and switching ratio in real time. The Redis cache allows for flexible control of the switching range, enabling arbitrary switching of transactions without restarting the service.

[0081] This invention is a canary phase switching mechanism that can identify different transaction messages based on their content and request headers. Different matching rules can be configured in the cache database for different transaction messages. The scope of the canary phase switching is determined by configuration, not by a probing mechanism. This canary phase switching guarantees a 100% success rate before and after the switch. If transaction failures occur after the switch, the switch must be terminated.

[0082] For example.

[0083] First, add a set of transaction switching configurations, which includes transaction recognition and processing strategies, grayscale algorithm strategies, and transaction routing location switching.

[0084] Example 1 (for proportional dimension switching): After a transaction enters, it is matched using the transaction code. If the match is successful, the transaction chain continues; otherwise, the old transaction is executed. When a transaction match and switch is successful, the transaction does not need to be fully switched at that time. For example, if the transaction only switches 10% (or 30%, or other values), the grayscale calculation will randomly select a value between 0 and 100. If it matches 0-10 (or 0-30), it continues to be executed in the transaction chain (i.e., the grayscale switch continues); otherwise, it exits the execution chain and executes the old transaction. If both transaction identification and grayscale calculation are successful, the route in the transaction configuration is used for outbound calls.

[0085] Example 2 (for server-level switching): After a transaction enters, it is matched using the `mesgType` field. If a match is found, the transaction chain continues; otherwise, the old transaction is executed. When switching transactions based on server name (hostname), the server name is obtained through canary computation and matched against the hostname configured in the database. If a match is found, the transaction chain continues (i.e., the canary switch continues); otherwise, the execution chain is terminated and the old transaction is executed. If both transaction identification and canary computation are successful, the route configured in the transaction group is used for outbound calls.

[0086] This invention also provides a grayscale switching device for transaction upgrades, as described in the following embodiments. Since the principle behind this grayscale switching device for transaction upgrades is similar to that of the grayscale switching method for transaction upgrades, the implementation of this grayscale switching device can refer to the implementation of the grayscale switching method for transaction upgrades; repeated details will not be elaborated further.

[0087] Figure 5 The structural frame of the grayscale switching device for transaction upgrade in this embodiment of the invention. Figure 1 ,like Figure 5 As shown, the device includes:

[0088] The transaction identification module 02 is used to identify transactions and filter out those that need to be switched to grayscale.

[0089] The grayscale algorithm module 04 is used to match transactions that need to be switched in grayscale according to the grayscale algorithm rules and obtain matching results. The grayscale algorithm rules include multi-dimensional switching parameters.

[0090] The transaction routing module 06 is used to route transactions that need to be switched to the new transaction service for transaction processing based on the matching results and the correspondence between the expected processing results of the grayscale algorithm and the transaction routing.

[0091] In this embodiment of the invention, the transaction is an access transaction or an active outbound call transaction.

[0092] In this embodiment of the invention, the transaction identification module is specifically used for:

[0093] Transactions are identified based on their transaction messages and HTTP request headers, and those requiring canary rollout are selected.

[0094] In this embodiment of the invention, the transaction identification module is further used for:

[0095] The identified transactions are stored in thread variables for use in transaction routing.

[0096] In this embodiment of the invention, the multi-dimensional switching parameters include application cluster dimension, server dimension, transaction dimension, transaction field dimension, transaction stage dimension, and / or transaction ratio dimension.

[0097] In embodiments of the present invention, such as Figure 6 As shown, the device also includes:

[0098] Cache server 08 is used to store multi-dimensional switching parameters and / or switching ratios.

[0099] This invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the above-mentioned grayscale switching method for transaction upgrade.

[0100] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described grayscale switching method for transaction upgrades.

[0101] This invention also provides a computer program product, which includes a computer program that, when executed by a processor, implements the above-mentioned grayscale switching method for transaction upgrade.

[0102] In this embodiment of the invention, compared with existing technologies such as business shutdown switching, whitelist-based canary release, and API gateway-based canary release, the method of the present invention identifies transactions and filters out those requiring canary release switching. The canary release algorithm rules include multi-dimensional switching parameters. Transactions requiring canary release switching are matched according to the canary release algorithm rules to obtain matching results. Based on the matching results, the transactions requiring canary release switching are distributed and routed to the new transaction service for processing. By identifying, calculating, and distributing at the application layer, multi-version deployment and business shutdowns are avoided, reducing business impact and server resource usage, and ensuring a smooth transaction switchover.

[0103] Furthermore, this invention eliminates the need for business shutdowns during transaction switching, resolving the significant business disruption issues associated with existing technologies. Regarding existing whitelist-based solutions, this invention supports switching schemes across multiple dimensions, including the whitelist, and allows for dynamic adjustments within the cache database. It also supports the proportion of transactions that have been successfully matched to the whitelist, resulting in finer-grained switching and enhanced system availability. Compared to existing three-gateway solutions, this invention eliminates the need for additional gateway deployment, reducing costs and maintaining transaction response time. Moreover, it supports not only canary switching of access systems but also canary switching initiated by the system itself (outbound calls).

[0104] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0105] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0106] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0107] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0108] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for gray-scale switching of transaction upgrades, characterized in that, include: Identify and filter out transactions that require grayscale switching; Transactions requiring grayscale switching are matched according to grayscale algorithm rules to obtain matching results. These grayscale algorithm rules include multi-dimensional switching parameters. The grayscale algorithm rules include hardware and software matching; hardware matching refers to matching based on physical machines or data centers, while software matching refers to matching based on transaction messages. The multi-dimensional switching parameters include application cluster dimension, server dimension, transaction dimension, transaction field dimension, transaction stage dimension, and / or transaction ratio dimension. Application cluster dimension: Multiple clusters are deployed in the application, and switching is performed based on the cluster identifier. Server dimension: Switching is performed based on the name of the physical machine. Transaction dimension: Switching is performed based on transaction information. Transaction field dimension: Switching is performed based on fields in the transaction message. Based on the matching results, and according to the correspondence between the expected processing results of the grayscale algorithm and the transaction routing, the transactions that need to be switched to grayscale are routed to the new transaction service for processing. The corresponding relationships are stored in the Redis cache as key-value pairs; The transactions are identified and filtered to determine which transactions require grayscale switching, including: Transactions are identified based on their transaction messages and HTTP request headers, and those requiring canary rollout are selected.

2. The gray-scale switching method for transaction upgrades as described in claim 1, characterized in that, The transaction is either an access transaction or an outbound call transaction.

3. The gray-scale switching method for transaction upgrades as described in claim 1, characterized in that, Also includes: The identified transactions are stored in thread variables for use in transaction routing.

4. The gray-scale switching method for transaction upgrades as described in claim 1, characterized in that, Also includes: Use a cache database to store multi-dimensional switching parameters.

5. A grayscale switching device for transaction upgrades, characterized in that, include: The transaction identification module is used to identify transactions and filter out those that need to be switched to grayscale. The grayscale algorithm module is used to match transactions requiring grayscale switching according to grayscale algorithm rules to obtain matching results. These grayscale algorithm rules include multi-dimensional switching parameters. The grayscale algorithm rules include hardware and software matching; hardware matching refers to matching based on physical machines or data centers, while software matching refers to matching based on transaction messages. The multi-dimensional switching parameters include application cluster dimension, server dimension, transaction dimension, transaction field dimension, transaction stage dimension, and / or transaction ratio dimension. Application cluster dimension: Multiple clusters are deployed in the application, and switching is performed based on the cluster identifier. Server dimension: Switching is performed based on the name of the physical machine. Transaction dimension: Switching is performed based on transaction information. Transaction field dimension: Switching is performed based on fields in the transaction message. The transaction routing module is used to route transactions that need to be switched to the new transaction service for processing based on the matching results and the correspondence between the expected processing results of the gray-scale algorithm and the transaction routing. The correspondence is stored in the Redis cache as key-value pairs. The transaction identification module is specifically used for: Transactions are identified based on their transaction messages and HTTP request headers, and those requiring canary rollout are selected.

6. The grayscale switching device for transaction upgrades as described in claim 5, characterized in that, The transaction is either an access transaction or an outbound call transaction.

7. The grayscale switching device for transaction upgrades as described in claim 5, characterized in that, The transaction recognition module is also used for: The identified transactions are stored in thread variables for use in transaction routing.

8. The grayscale switching device for transaction upgrade as described in claim 5, characterized in that, Also includes: A caching server is used to store multi-dimensional switching parameters.

9. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the grayscale switching method for transaction upgrade as described in any one of claims 1 to 4.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the grayscale switching method for transaction upgrades according to any one of claims 1 to 4.

11. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the grayscale switching method for transaction upgrades as described in any one of claims 1 to 4.

Images