Gray scale switching method and apparatus

Abstract

This application provides a grayscale switching method and apparatus, relating to the field of artificial intelligence technology. The method includes: receiving a transaction request sent by a transaction channel, wherein the transaction is a non-first transaction within a related transaction; determining a target route based on a coloring strategy and a routing strategy corresponding to the transaction request, wherein the coloring strategy includes a feature coloring strategy for related transactions, and the target route includes an alternative route and a default route; when the target route is an alternative route, sending the transaction request to a first subsystem, and returning the response result of the first subsystem to the transaction channel. This method improves the consistency of grayscale switching methods for related transactions.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to a grayscale switching method and device. Background Technology

[0002] With the rapid development of information technology, system upgrades have become a necessary means to ensure business continuity and improve service quality. Ensuring a smooth transition of new functions or changes during system upgrades, without affecting the normal operation of existing businesses, is a common challenge faced by the industry.

[0003] In existing technologies, the canary rollout method is widely used in system upgrade processes. Canary rollout configuration rules, as an effective system upgrade strategy, aim to reduce upgrade risks by gradually introducing changes. Existing canary rollout methods primarily involve setting different traffic distribution rules to guide user traffic to different versions of the system, thereby achieving a gradual upgrade. This method can, to some extent, reduce the impact of upgrades on business operations and improve system stability and reliability.

[0004] However, applying the above grayscale switching method to related businesses may result in serious consequences such as transaction failures and data errors. Summary of the Invention

[0005] This application provides a grayscale switching method and device to solve the problems of transaction failure and data errors that may occur when applying grayscale switching methods in related transactions.

[0006] Firstly, this application provides a gray-scale switching method. The gray-scale switching system includes a transaction channel, a first subsystem, and a second subsystem. The second subsystem is an upgraded version of the first subsystem, and the method is applied to the second subsystem, including:

[0007] Receive transaction requests sent from the transaction channel, where the transaction is a related transaction that is not the first one;

[0008] The target route is determined based on the coloring strategy and routing strategy corresponding to the transaction request. The coloring strategy includes the feature coloring strategy for associated transactions, and the target route includes alternative routes and default routes.

[0009] When the target route is an alternative route, the transaction request is sent to the first subsystem, and the response result of the first subsystem is returned to the transaction channel.

[0010] In one possible design, the target route is determined based on the coloring strategy and routing strategy corresponding to the transaction request, including:

[0011] Obtain the coloring and routing strategies corresponding to the transaction request;

[0012] Determine whether the transaction request matches the coloring strategy;

[0013] When a transaction request matches a coloring strategy, the target coloring for the transaction request is determined according to the coloring strategy.

[0014] The target route is determined based on the routing strategy and the target coloring of the transaction request.

[0015] In one possible design, when a transaction request matches a coloring strategy, the target coloring for the transaction request is determined according to the coloring strategy, specifically including:

[0016] When a transaction request hits the feature coloring strategy, the inherited coloring of the feature is determined as the target coloring of the transaction request. Here, the inherited coloring of the feature represents the coloring inherited from the first transaction of the related transaction.

[0017] When a transaction request hits a coloring strategy other than the feature coloring strategy, the configuration coloring of the coloring strategy is determined as the target coloring of the transaction request.

[0018] In one possible design, determining the target route based on the coloring strategy and routing strategy corresponding to the transaction request also includes:

[0019] When a transaction request does not match the coloring strategy, the initial coloring of the transaction is determined to be the target coloring of the transaction request.

[0020] In one possible design, the coloring strategy includes multiple coloring strategies with different priorities, and the priority of the coloring strategy is negatively correlated with the hit range of the coloring strategy.

[0021] Determining whether a transaction request matches the coloring strategy includes:

[0022] The process iterates through multiple coloring strategies from highest to lowest priority until a transaction request matches a coloring strategy or the iteration ends and it is determined that the transaction request did not match a coloring strategy.

[0023] In one possible design, the method also includes:

[0024] When the target route is the default route, the transaction request is responded to and returned to the transaction channel.

[0025] Secondly, this application provides a grayscale switching device, comprising:

[0026] The receiving module is used to receive transaction requests sent by the transaction channel, wherein the transaction is a non-first transaction in a related transaction.

[0027] The determination module is used to determine the target route based on the coloring strategy and routing strategy corresponding to the transaction request. The coloring strategy includes the feature coloring strategy for associated transactions, and the target route includes alternative routes and default routes.

[0028] The response module is used to send the transaction request to the first subsystem when the target route is an alternative route, and return the response result of the first subsystem to the transaction channel end.

[0029] Thirdly, embodiments of this application provide an electronic device, including: at least one processor and a memory; the memory stores a computer program; the at least one processor executes the computer program stored in the memory, such that the at least one processor performs the grayscale switching method as described in the first aspect above and any possible design of the first aspect.

[0030] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the grayscale switching method described in the first aspect above and any possible design of the first aspect.

[0031] Fifthly, embodiments of this application provide a computer program product, including a computer program, which, when executed by a processor, implements the grayscale switching method described in the first aspect above and any possible design of the first aspect.

[0032] The gray-scale switching method and device provided in this application, in the upgraded system, determine the target route based on the coloring and routing strategies corresponding to the transaction request. When the target route is an alternative route, the transaction request is sent to the system before the upgrade, and the response result of the system before the upgrade to the transaction request is returned to the transaction channel. Specifically, the upgraded system accurately determines the target route by coloring the features of related transactions and continuing this coloring in related transactions. This allows multiple transactions in a related transaction to synchronously undergo gray-scale switching in the same manner, improving data consistency during gray-scale switching and reducing the risk of transaction failure. Attached Figure Description

[0033] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0034] Figure 1 This is a schematic diagram of a transaction processing procedure before a system upgrade;

[0035] Figure 2 A schematic diagram of a transaction processing procedure after system upgrade provided in this application embodiment;

[0036] Figure 3 This is a schematic diagram of the structure of a grayscale component provided in an embodiment of this application;

[0037] Figure 4A flowchart illustrating a grayscale switching method provided in an embodiment of this application;

[0038] Figure 5 This is a partial flowchart of a grayscale switching method provided in an embodiment of this application;

[0039] Figure 6 A flowchart illustrating another grayscale switching method provided in this application embodiment;

[0040] Figure 7 This is a schematic diagram of the structure of a grayscale switching device provided in an embodiment of this application;

[0041] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0042] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0043] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0044] It should be noted that the collection, storage, use, processing, transmission, provision, and disclosure of financial data or user data involved in the technical solution of this application all comply with the provisions of relevant laws and regulations and do not violate public order and good morals. The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with relevant laws, regulations, and standards, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0045] Canary rollout is a solution for mitigating the risks of software upgrades by gradually introducing changed software into the production environment when changes occur in the system's architecture, data model, or added / modified features. It involves controlling the scope of impact. After thorough canary rollout verification, summarizing the verification results, rolling back or increasing the rollout, and finally transitioning to a full rollout of the upgraded version. Canary rollout is a crucial method for achieving a smooth system transition and minimizing the impact of upgrades.

[0046] For some highly complex system changes, it's difficult to guarantee the completeness of pre-release environment verification when there are differences between the pre-release and production environments. Software upgrades still carry the risk of production environment failures. If all changes are directly introduced into the production environment, any problems with those changes will render that part of the functionality unusable. Canary rollouts allow for a controlled, gradual introduction of system changes into the production system, thus controlling the impact of system changes on users.

[0047] Currently, common canary rollout methods include grouped rollout and random rollout. Grouped rollout groups users based on predetermined behavioral characteristics, gradually introducing changes to eligible users. For example, pre-defined rule-based canary rollout differentiates traffic by matching user request header parameters; or by matching user request host characteristics; or by adding version numbers to requests at the channel end, with the gateway using these version numbers to distribute traffic to the specified version of the service throughout the transaction chain. Random rollout gradually distributes user traffic randomly to the new and old services in a certain proportion. For example, percentage-based canary rollout deploys new and old versions on different machines, using various load balancing strategies such as weighted round-robin or IP hashing to distribute traffic evenly to the new and old services according to a set ratio.

[0048] However, upgrading the system may also present challenges such as significant system heterogeneity and high complexity of individual transactions. For example, the database selection may differ before and after the upgrade, or a monolithic architecture may be upgraded to a microservices architecture. Simultaneously, the externally provided transaction logic may remain unchanged during the upgrade process, meaning the switching cost is extremely high. If the system's business is directly related to the financial sector, the transformation becomes sensitive, and the scope of the switch's impact needs to be strictly controlled. Especially before a gradual rollout, a random switching strategy cannot be directly adopted for fund-related transactions.

[0049] In random switching, the percentage-based gray-scale approach has the least invasiveness to applications, but it is completely unfeasible for system changes that are incompatible before and after the upgrade. This incompatibility includes differences in the internal calculation logic of the interfaces before and after the upgrade, making mixed processing impossible; and for processing related transactions, where heterogeneous systems have different databases, data synchronization has time differences, and data is synchronized in a one-way manner, making mixed traffic processing even more inappropriate.

[0050] If both the external calls to a transaction and its internal business logic are complex—meaning the transaction may be called by different channels simultaneously, with different channels having different call processing methods, and the transaction has many branches of business logic—it is difficult to fully analyze all the boundary situations of a transaction due to the long transaction maintenance time and the lack of a complete business case library. Even if customer characteristics are controlled, it is impossible to control all the variables faced when the transaction changes. The group switching strategy is difficult to meet the needs of complex transactions.

[0051] In group switching, the preset rule grayscale is suitable for the situation where the front-end and back-end cooperate to upgrade the function from the channel. However, for the upgrade of large back-end business components, and the situation where a business component is adapted to multiple channels, this transformation method will affect the channels and requires grayscale marking by the channel or the direct upstream system of the back-end system.

[0052] In addition, due to the enormous workload and high risk of system upgrades, the production environment has a relatively long parallel switching window, during which services can be provided simultaneously to the outside world. For highly interconnected transactions, there is a coupling between the preceding and following logic in the system's computational processing. Subsequent transactions depend on the structure or triggering conditions of a previous transaction, requiring the calculation of subsequent transactions based on the data generated by the previous transaction. For example, in a loan process with strong correlation at the contract level, among the related transactions of credit limit assessment, approval, signing, and disbursement, the processing of signing and disbursement transactions requires approval data. However, synchronizing data from the upgraded system to the pre-upgrade system can lead to issues such as data synchronization delays and inconsistencies in business logic. For interconnected transactions, it is necessary to calculate the correct service route for each transaction, i.e., whether traffic should go to the new system or the old system; otherwise, serious consequences such as transaction failures and data errors may occur.

[0053] For highly complex transactions, simply using different gray-scale traffic splitting configuration rules is not ideal. For example, a loan assessment transaction used in multiple scenarios could have gray-scale rules configured for a customer-level whitelist, a branch-level whitelist, a product-level whitelist, or even a channel-level whitelist. When the gray-scale rules are adjusted, only one gray-scale rule takes effect. For instance, switching from the customer whitelist to the branch-level whitelist invalidates the original customer whitelist. However, in reality, it might be desirable for the customer whitelist to become invalid, or it might be desirable for it to remain valid. Furthermore, currently, achieving a rollback effect by removing the original gray-scale traffic splitting rules can lead to situations where related transactions cannot proceed.

[0054] To address the aforementioned issues, this application proposes a canary scale switching method and device. When external calling conditions remain unchanged and only the system itself is upgraded (i.e., without relying on upstream component modifications), it deeply analyzes the system's business characteristics and sets multi-dimensional canary scale switching strategies for the same transaction or group of transactions. By designing feature coloring, related transactions are synchronously switched and rolled back in the same canary scale manner. By integrating a canary scale component into the upgraded system, it flexibly supports multiple custom canary scale strategies without affecting upstream and downstream processes. Canary scale switching is performed in conjunction with the business strategies of system component upgrades and modifications, without intruding on the component's own business logic code, thus adapting to system upgrades and switching with low compatibility, and is suitable for related transactions. Simultaneously, the routing strategy is configured according to the transaction dimension, achieving business logic that does not intrude on any system, and the system does not require any adaptation modifications before the upgrade.

[0055] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0056] Figure 1 A schematic diagram of a transaction processing procedure before a system upgrade is shown. Figure 1 As shown, before the system upgrade, the service address registered in the addressing component was the first subsystem, which was the system before the upgrade. The transaction processing includes the following steps:

[0057] S101. After receiving a transaction request, the transaction channel addresses the first subsystem in the addressing component according to the transaction code.

[0058] S102, The transaction channel sends the transaction request to the first subsystem.

[0059] S103. The first subsystem responds to the transaction request and returns the response message to the transaction channel as the final output of the transaction request.

[0060] Figure 2 This illustration shows a schematic diagram of a transaction processing procedure after system upgrade according to an embodiment of this application. Figure 2 As shown, during system upgrades, the service address registered in the addressing component is the second subsystem, which is the upgraded system. The second subsystem integrates a grayscale component, and the transaction processing includes the following steps:

[0061] S201. After receiving a transaction request, the transaction channel addresses the second subsystem in the addressing component according to the transaction code.

[0062] S202, The transaction channel sends the transaction request to the second subsystem.

[0063] S203. The grayscale component integrated in the second subsystem determines the target route for the transaction request.

[0064] S204. If the target route is an alternative route, i.e., the first subsystem, the grayscale component determines the service address of the alternative route through the addressing component.

[0065] S205. The second subsystem will send the transaction request to the first subsystem and send the response message returned by the first subsystem to the transaction channel as the final output of the transaction request.

[0066] S206. If the target route is the default route, i.e. the second subsystem, the second subsystem will respond to the transaction request and return the response message to the transaction channel as the final output of the transaction request.

[0067] Figure 3 A schematic diagram of a grayscale component provided in an embodiment of this application is shown. Figure 3 As shown, the grayscale component includes an interception module, a coloring strategy module, a routing strategy module, a feature marking module, and a data storage module.

[0068] Assuming that grayscale transitions are performed on a transaction-by-transaction basis, the interception module is configured with a mapping relationship between transaction types and grayscale transitions, as well as a parsing method for transaction requests. Upon receiving a transaction request, the second subsystem uses the interception module's transaction request parsing method to analyze request keywords, determine the transaction type, and then determine whether the transaction requires a grayscale transition.

[0069] The interception module is also used to intercept transactions at the response point and save the data to the data storage module of the canary component by marking the characteristics. Here, the aspect-oriented programming (AOP) approach of the Spring framework can be used to define aspects in the interception module and decouple the canary switching logic from the business module through interception pointcuts.

[0070] The data storage module is configured with multiple coloring strategies, including the initial coloring value for each transaction, the coloring strategy code value, the color applied by the coloring strategy, supplementary coloring strategy values, and the coloring strategy priority. The supplementary coloring strategy values ​​are used in conjunction with the coloring strategy, such as regular expressions and the type of feature.

[0071] For example, the coloring strategy code value W001 indicates that the request client is matching the list of new features in the data access module. C001 indicates that the serialized value after parsing the request message matches the regular expression of the supplementary coloring strategy value, which can be configured with multiple dimensions such as organization and branch. R001 indicates that the feature index of the request message matches the feature and must inherit the coloring of the feature. WC001 indicates that the request client is matching the list of new features in the data access module, and the serialized value of the request keyword matches the regular expression of the supplementary coloring strategy value. H001 indicates that the header field of the request message meets the preset conditions.

[0072] Coloring strategy priority is configured based on the hit range of the coloring strategy. A smaller hit range means a smaller impact, and its priority needs to be configured higher to ensure that these smaller lists are colored first. For example, suppose coloring strategy A requires that the credit rating of the customer corresponding to the transaction request matches the customer credit rating in the coloring strategy, while coloring strategy B requires that the coloring value of the transaction request is the feature coloring value. In other words, coloring strategy B is more difficult to hit, meaning its hit range is smaller. In this case, the priority of coloring strategy B should be configured higher than that of coloring strategy A.

[0073] Configuring different colorings for the same transaction implies different impact ranges. These colorings can aid in analyzing the scope of transaction impact within the business system, and routing strategies allow for timely switching and reversal. Related transactions, due to their continuous coloring configurations, inherit the same coloring, thus enabling unified processing of data within the same impact range even if the transactions are different.

[0074] The coloring strategy module can retrieve the coloring strategy from the data storage module and compare it with the information in the transaction request to determine whether the transaction request matches the coloring strategy. For example, if the transaction request includes information about a certain feature, it can be compared with the feature coloring strategy. If the feature information in the transaction request matches the feature information in the feature coloring strategy, then the transaction request is determined to match this feature coloring strategy.

[0075] If a transaction request matches a coloring strategy, the coloring value corresponding to that strategy becomes the coloring value for that transaction request; if it does not match, the transaction request retains its initial coloring value. The final coloring value can be passed as an HTTP header to downstream transaction requests to facilitate collaborative processing.

[0076] The routing policy module is configured to determine whether the service address for a transaction is the default route or an alternative route when the coloring value is different.

[0077] The feature marking module typically configures feature interception rules for the first transaction in a related transaction. If a feature of a related transaction is generated during or after the first transaction, it is marked after its generation. It should be understood that feature interception rules and marking results can also be stored in the data storage module.

[0078] Figure 4 A flowchart illustrating a grayscale switching method according to an embodiment of this application is shown. Figure 2 , Figure 3 On the basis of, such as Figure 4 As shown, with the second subsystem as the execution entity, the method in this embodiment may include the following steps:

[0079] S301, Receive transaction requests sent by the transaction channel.

[0080] In this context, the transaction refers to a non-first transaction within a related transaction. For example, a related transaction might include four transactions: A, B, C, and D, linked together by contract number Z1. Transaction A generates characteristic Z1; the transaction requests of transactions B and C contain characteristic Z1; and although the transaction request of transaction D does not directly contain characteristic Z1, it includes data Z2 related to characteristic Z1, and data Z2 was generated by transaction C. Thus, a related transaction can be identified as multiple transactions that directly or indirectly contain the same characteristic. This embodiment describes a grayscale switching process for non-first transactions B, C, or D within a related transaction.

[0081] S302. Determine the target route based on the coloring strategy and routing strategy corresponding to the transaction request.

[0082] The coloring strategy includes feature coloring strategies for related transactions, and the target route includes alternative routes and default routes. A default route indicates that the transaction does not require re-addressing and can be served directly by the default service address of the transaction on the addressing component, meaning it can be served by the second subsystem. An alternative route indicates that the default service address of the transaction on the addressing component cannot be used directly, meaning it needs to be served by the first subsystem.

[0083] The second subsystem can integrate a grayscale component, which is configured with various coloring and routing strategies. The grayscale component can determine the target route for transaction requests based on the coloring and routing strategies.

[0084] S303. When the target route is an alternative route, the transaction request is sent to the first subsystem, and the response result of the first subsystem is returned to the transaction channel.

[0085] The addressing component stores the service identifier corresponding to the transaction code and the service addresses of the first and second subsystems corresponding to the service identifier.

[0086] When the target route is an alternative route, the grayscale component in the second subsystem can obtain the address of the first subsystem from the addressing component based on the transaction code corresponding to the transaction request. Thus, the second subsystem can send the transaction request to the first subsystem, which is the system before the upgrade.

[0087] The grayscale switching method provided in this embodiment designs a feature coloring system for related transactions. During grayscale switching, for transactions other than the first one in the related transaction, the feature coloring is reused, and the target route for grayscale switching is determined based on the coloring results. This allows multiple transactions in a related transaction to synchronously perform grayscale switching and rollback in the same grayscale manner, improving the consistency of data processing in related transactions and reducing the risk of transaction failure. Furthermore, by integrating a grayscale component into the upgraded system, it can flexibly support various custom grayscale strategies, including coloring and routing strategies, without affecting upstream and downstream processes. Grayscale switching can be combined with the business strategies of system component upgrades and modifications without intruding on the business logic code of the components themselves. This allows for adaptation to system upgrades and switching with low compatibility, and it can be applied to related transactions without any adaptation modifications to the system before the upgrade.

[0088] In some embodiments, when the target route is the default route, the second subsystem responds to the transaction request and returns to the transaction channel.

[0089] Figure 5 This is a partial flowchart of a grayscale switching method provided in an embodiment of this application. Figure 4 Based on the embodiments, such as Figure 5 As shown, the specific implementation of step S302 includes:

[0090] S401. Obtain the coloring strategy and routing strategy corresponding to the transaction request.

[0091] Among them, the coloring strategy and the routing strategy are both pre-configured and stored strategies. The second subsystem can obtain multiple coloring strategies and routing strategies related to the transaction request from the data storage module of the grayscale component.

[0092] S402. Determine whether the transaction request matches the coloring strategy.

[0093] Specifically, the second subsystem compares the information contained in the transaction request with the information in the coloring strategy. If the information matches, the transaction request is considered to have matched the coloring strategy.

[0094] It should be understood that the coloring strategy is obtained through custom configuration. Hitting a coloring strategy means hitting at least one piece of information within it, such as a customer's credit rating. If the credit rating of the customer making the transaction request matches the coloring strategy, then the transaction request is considered to have hit the coloring strategy.

[0095] In some embodiments, the coloring strategy includes multiple coloring strategies with different priorities, and the priority of a coloring strategy is negatively correlated with its hit range. That is, if there are significantly more transactions that hit coloring strategy A than those that hit coloring strategy B, then coloring strategy A is considered to have a larger hit range, and in this case, coloring strategy B should be configured with a higher priority, prioritizing the determination of whether a transaction request hits coloring strategy B. Here, the significantly higher number of transactions hitting coloring strategy A compared to coloring strategy B might be due to, for example, coloring strategy A requiring the customer credit rating of the transaction request to meet certain requirements, while coloring strategy B requires the transaction request to contain a specific feature.

[0096] Based on this embodiment, the specific implementation of step S402 includes: traversing multiple coloring strategies from high to low priority until the transaction request hits a coloring strategy or the traversal ends and it is determined that the transaction request did not hit a coloring strategy.

[0097] Specifically, according to the priority of the coloring strategy from high to low, the transaction request is checked in turn to see if it matches the coloring strategy, until a coloring strategy is matched or all coloring strategies have been traversed.

[0098] By configuring coloring strategies with different priorities, the accuracy of identifying related transactions is improved by prioritizing whether transaction requests match the feature coloring strategy. By continuing to use feature coloring and determining the target route for grayscale switching based on the coloring results, multiple related transactions can synchronously perform grayscale switching and rollback in the same grayscale manner, improving data processing consistency for related transactions and reducing the risk of transaction failure.

[0099] S403. When a transaction request matches a coloring strategy, the target coloring for the transaction request is determined according to the coloring strategy.

[0100] Continue to refer to Figure 5 In some embodiments, step S403 is specifically implemented as follows:

[0101] S4031. When a transaction request hits a feature coloring strategy, the inherited coloring of the feature is determined as the target coloring of the transaction request.

[0102] Among them, the inherited coloring of the feature is the coloring inherited from the first transaction of the related transaction.

[0103] In light of the aforementioned role of the feature marking module in the grayscale component, it can be understood that for the first transaction of a related transaction, when determining the feature generated by the transaction, the feature can be marked, colored, and stored, which facilitates the judgment of feature coloring strategies for non-first transactions of related transactions.

[0104] S4032. When a transaction request hits a coloring strategy other than the feature coloring strategy, the configuration coloring of the coloring strategy is determined as the target coloring of the transaction request.

[0105] In some embodiments, when a transaction request does not hit the coloring strategy, the initial coloring of the transaction is determined to be the target coloring of the transaction request.

[0106] S404. Determine the target route based on the routing policy and the target coloring of the transaction request.

[0107] Specifically, in the second subsystem, the routing strategy module can determine the target route based on the mapping relationship between the target route and the coloring value in the routing strategy, as well as the target coloring of the transaction request.

[0108] The canary-scale switching method provided in this embodiment is suitable for upgrading and switching business components with related transactions and highly complex individual transactions. It can flexibly adjust the switching dimensions according to its own business characteristics without requiring external callers to modify system configurations. This facilitates flexible service dispatching for highly complex business components during the transition period of system upgrades, without requiring upstream component modifications. Simultaneously, the canary device, with the help of an interception module, does not intrude into business logic code; the canary strategy is handled by the canary component. Even when system data is not shared before and after the upgrade and related transactions exist, consistency in the processing of related transactions is achieved through the cooperation of the canary component's feature marking module, data storage module, and coloring strategy module. The canary component can flexibly configure coloring and routing strategies, enabling switching and reverting of related transactions under the same business characteristics. By controlling business variables, it facilitates the analysis and handling of similar problems that may arise during system upgrades.

[0109] Figure 6 A flowchart illustrating another grayscale switching method provided in an embodiment of this application. For example... Figure 6 As shown, with the second subsystem as the execution entity, the method in this embodiment may include the following steps:

[0110] S501, Receive transaction requests sent by the transaction channel.

[0111] In this embodiment, the transaction is the first transaction in a series of related transactions. For example, the related transactions include four transactions: A, B, C, and D, linked together by contract number Z1. Transaction A generates the characteristic Z1. The transaction requests of transactions B and C contain this characteristic Z1. Although the transaction request of transaction D does not directly contain the characteristic Z1, it contains data Z2 related to the characteristic Z1, and data Z2 is generated by transaction C. Thus, it can be determined that a series of related transactions are multiple transactions that directly or indirectly contain the same characteristic. This embodiment involves performing a grayscale switch on the first transaction A in the series of related transactions.

[0112] S502. Determine the characteristics of the related transaction based on the transaction request and configure the transaction marking strategy.

[0113] The transaction marking strategy includes a feature coloring strategy and a transaction routing strategy. Based on the transaction marking strategy, the second subsystem can color the features, determine the transaction route, and store the coloring and routing information so that when a non-first transaction of an associated transaction is received, the coloring and routing information of the first transaction can be used to determine the coloring strategy and routing strategy of the non-first transaction.

[0114] In S503, the transaction marking strategy is as follows: when the target route is the alternative route, the transaction request is sent to the first subsystem, and the response result of the first subsystem is returned to the transaction channel end; when the target route is the default route, the second subsystem responds to the transaction request and returns it to the transaction channel end.

[0115] Step S503 can be referred to Figure 4 Step S303 in the embodiment is understood and will not be repeated here.

[0116] S504. Color the features according to the transaction marking strategy.

[0117] In this embodiment, the response of the first subsystem or the second subsystem to the transaction request indicates that the first transaction of the related transaction has been completed, which means that a feature has been generated. At this time, the second subsystem can color the feature according to the feature coloring strategy and store the coloring information so that the second subsystem can call the feature coloring information when it receives a non-first transaction of the related transaction.

[0118] In the grayscale switching method of this embodiment, when the second subsystem receives the transaction request of the first transaction of the related transaction, it first determines the feature of the related transaction and configures the feature coloring strategy and the routing strategy for the related transaction. When the first transaction is completed and the feature is generated, the feature is colored according to the feature coloring strategy so that the feature coloring and routing can be used in subsequent transactions of the related transaction, thereby improving the data processing consistency of the related transaction and reducing the risk of transaction failure.

[0119] The following describes, with a more specific example, how to determine the target coloring of the first transaction and non-first transactions in a related transaction.

[0120] First, it's necessary to determine the key characteristics that link multiple related transactions, based on the specific circumstances of the system. Typically, these related transactions can be linked by contracts. After determining the key characteristics, it's necessary to identify the starting point of the key characteristic's lifecycle and how that key characteristic is retrieved in subsequent transaction requests.

[0121] The related transactions include four transactions: A, B, C, and D, which are linked together by contract number Z1. Transaction A generates the characteristic Z1. The transaction requests of transactions B and C contain the characteristic Z1. Although the transaction request of transaction D does not directly contain the characteristic Z1, it contains data Z2 related to the characteristic Z1, and data Z2 was generated by transaction C.

[0122] One approach is to view the aforementioned related-party transactions as including a characteristic.

[0123] For transaction A, since feature Z1 is generated, the marking strategy for feature Z1 in the output message of transaction A needs to be configured in the feature marking module of the grayscale component. When the grayscale component executes the marking strategy, it intercepts the output of A and caches feature Z1 and its coloring in the data storage module.

[0124] For transactions B and C, since the transaction request message contains feature Z1, it is only necessary to configure the coloring strategy that inherits feature Z1.

[0125] For transaction D, since the transaction request message does not directly contain feature Z1, it is necessary to configure a coloring strategy that obtains feature Z1 from a specified method and inherits its coloring.

[0126] Another approach is to view the aforementioned related-party transactions as encompassing two types of characteristics.

[0127] For transaction A, since feature Z1 is generated, the marking strategy for feature Z1 in the output message of transaction A needs to be configured in the feature marking module of the grayscale component. When the grayscale component executes the marking strategy, it intercepts the output of A and caches feature Z1 and its coloring in the data storage module.

[0128] For transaction B, since the transaction request message contains feature Z1, it is only necessary to configure the coloring strategy that inherits feature Z1.

[0129] For transaction C, since the request message contains feature Z1, a coloring strategy that inherits feature Z1 needs to be configured. Since data Z2, which is related to feature Z1, is generated, a marking strategy for feature Z2 in the output message of transaction C needs to be configured. This marking strategy will cause Z2 to inherit the coloring of Z1.

[0130] For transaction D, although its request message does not directly contain feature Z1, it does directly contain feature Z2. Therefore, the coloring strategy that inherits feature Z2 can be configured.

[0131] Figure 7 This is a schematic diagram of a grayscale switching device provided in an embodiment of this application. Figure 7 As shown, the grayscale switching device 10 in this embodiment is used to implement the operation corresponding to the second subsystem in any of the above method embodiments. The grayscale switching device 10 in this embodiment includes:

[0132] The receiving module 11 is used to receive transaction requests sent by the transaction channel, wherein the transaction is a non-first transaction in a related transaction.

[0133] The determination module 12 is used to determine the target route based on the coloring strategy and routing strategy corresponding to the transaction request. The coloring strategy includes a feature coloring strategy for associated transactions, and the target route includes an alternative route and a default route.

[0134] The response module 13 is used to send the transaction request to the first subsystem when the target route is an alternative route, and return the response result of the first subsystem to the transaction channel end.

[0135] In some embodiments, the receiving module 11 is further configured to obtain the coloring strategy and routing strategy corresponding to the transaction request;

[0136] The determination module 12 is also used to determine whether a transaction request hits the coloring strategy;

[0137] When a transaction request matches a coloring strategy, the target coloring for the transaction request is determined according to the coloring strategy.

[0138] The target route is determined based on the routing strategy and the target coloring of the transaction request.

[0139] In some embodiments, the determining module 12 is further configured to determine the inherited coloring of a feature as the target coloring of the transaction request when the transaction request hits the feature coloring strategy, wherein the inherited coloring of a feature represents the coloring inherited from the first transaction of the associated transaction;

[0140] When a transaction request hits a coloring strategy other than the feature coloring strategy, the configuration coloring of the coloring strategy is determined as the target coloring of the transaction request.

[0141] In some embodiments, the determining module 12 is further configured to determine the initial coloring of the transaction as the target coloring of the transaction request when the transaction request does not match the coloring strategy.

[0142] In some embodiments, the staining strategy includes multiple staining strategies with different priorities, and the priority of the staining strategy is negatively correlated with the hit range of the staining strategy.

[0143] The determination module 12 is also used to traverse multiple coloring strategies from high to low priority until the transaction request hits a coloring strategy or the traversal ends and it is determined that the transaction request did not hit a coloring strategy.

[0144] In some embodiments, the response module 13 is further configured to respond to the transaction request and return to the transaction channel when the target route is the default route.

[0145] The grayscale switching device 10 provided in this application embodiment can be used to execute the technical solution of the grayscale switching method in the above embodiment. Its implementation principle and technical effect are similar, and will not be described again here.

[0146] Figure 8 A schematic diagram of the hardware structure of an electronic device according to an embodiment of this application is shown. Figure 8 As shown, the electronic device 20 is used to implement the operation corresponding to the second subsystem in any of the above method embodiments. The electronic device 20 in this embodiment may include: a memory 21, a processor 22, and a communication interface 24.

[0147] The memory 21 is used to store computer programs. The memory 21 may include high-speed random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device, and may also be a USB flash drive, external hard drive, read-only memory, disk or optical disc, etc.

[0148] Processor 22 is used to execute computer programs stored in memory to implement the methods in the above embodiments. For details, please refer to the relevant descriptions in the foregoing method embodiments. The processor 22 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0149] Alternatively, the memory 21 can be either standalone or integrated with the processor 22.

[0150] When the memory 21 is a device independent of the processor 22, the electronic device 20 may also include a bus 23. This bus 23 is used to connect the memory 21 and the processor 22. The bus 23 may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0151] The communication interface 24 can be connected to the processor 22 via the bus 23. The processor 22 can control the communication interface 24 to realize the functions of receiving and sending signals.

[0152] The electronic device 20 provided in this embodiment can be used to execute the grayscale switching method described above. Its implementation method and technical effect are similar, and will not be described again in this embodiment.

[0153] This application also provides a computer-readable storage medium storing a computer program / instructions, which, when executed by a processor, are used to implement the methods provided in the various embodiments described above.

[0154] The computer-readable storage medium can be a computer storage medium or a communication medium. A communication medium includes any medium that facilitates the transfer of a computer program from one location to another. A computer storage medium can be any available medium accessible to a general-purpose or special-purpose computer. For example, a computer-readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the computer-readable storage medium. Of course, the computer-readable storage medium can also be a component of the processor. The processor and the computer-readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the ASIC can reside in a user equipment. Of course, the processor and the computer-readable storage medium can also exist as discrete components in a communication device.

[0155] Specifically, the computer-readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The storage medium can be any available medium accessible to general-purpose or special-purpose computers.

[0156] This application also provides a computer program product comprising a computer program / instructions stored in a computer-readable storage medium. At least one processor of the device can read the computer program / instructions from the computer-readable storage medium, and the at least one processor executes the computer program / instructions to cause the device to perform the methods provided in the various embodiments described above.

[0157] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0158] The modules can be physically separate, for example, installed in different locations within a single device, installed on different devices, distributed across multiple network units, or distributed across multiple processors. Alternatively, the modules can be integrated, for example, installed in the same device, or integrated into a single codebase. The modules can exist in hardware form, software form, or a combination of both. This application can select some or all of the modules to achieve the objectives of this embodiment based on actual needs.

[0159] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some of the steps in the figures may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0160] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A gray scale switching method, characterized by, The gray-scale transition system includes a transaction channel, a first subsystem, and a second subsystem; the second subsystem is an upgraded version of the first subsystem, and the method is applied to the second subsystem, the method including: Receive a transaction request sent by the transaction channel, wherein the transaction request includes feature information, the transaction is not the first transaction in a related transaction, and the related transaction is multiple transactions that directly or indirectly contain the same feature; Obtain the coloring strategy and routing strategy corresponding to the transaction request; wherein, the coloring strategy includes a feature coloring strategy for the associated transaction, and the feature coloring strategy is determined by comparing the feature information in the transaction request with the feature information pre-configured in the feature coloring strategy in the data storage module. If they match, it is determined that the transaction request hits the feature coloring strategy. Determine whether the transaction request matches the coloring strategy; When the transaction request matches the feature coloring strategy, the inherited coloring of the feature is determined as the target coloring of the transaction request; the inherited coloring of the feature represents the coloring inherited from the first transaction of the related transaction; When a transaction request matches a coloring strategy other than the feature coloring strategy, the configured coloring of the coloring strategy is determined as the target coloring of the transaction request; the transaction request contains data related to the pre-configured feature information, and the configured coloring inherits the coloring of the first transaction; when a transaction request does not match the coloring strategy, the initial coloring of the transaction is determined as the target coloring of the transaction request. Based on the routing strategy and the target coloring of the transaction request, a target route is determined; the target route includes an alternative route and a default route; the routing strategy is used to indicate whether the service address of the transaction is the default route or an alternative route when the coloring value is different. When the target route is the alternative route, the transaction request is sent to the first subsystem, and the response result of the first subsystem is returned to the transaction channel.

2. The gray scale switching method according to claim 1, wherein The staining strategy includes multiple staining strategies with different priorities, and the priority of the staining strategy is negatively correlated with the hit range of the staining strategy; Determining whether the transaction request matches the coloring strategy specifically includes: The multiple coloring strategies are traversed from high to low priority until the transaction request hits a coloring strategy or the traversal ends and it is determined that the transaction request did not hit a coloring strategy.

3. The gray scale switching method of claim 1, wherein The method further includes: When the target route is the default route, the transaction request is responded to and returned to the transaction channel.

4. A gray scale switching device, characterized by, The apparatus for implementing the method as described in any one of claims 1-3, the apparatus comprising: The receiving module is used to receive transaction requests sent by the transaction channel, wherein the transaction is not the first transaction in a related transaction. The determination module is used to determine the target route based on the coloring strategy and routing strategy corresponding to the transaction request, wherein the coloring strategy includes a feature coloring strategy for the associated transaction, and the target route includes an alternative route and a default route; The response module is configured to send the transaction request to the first subsystem when the target route is the alternative route, and return the response result of the first subsystem to the transaction channel.

5. An electronic device, comprising: include: A processor, and a memory communicatively connected to the processor; The memory stores computer programs; The processor executes the computer program stored in the memory to implement the grayscale switching method as described in any one of claims 1-3.

6. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which, when executed by a processor, is used to implement the grayscale switching method as described in any one of claims 1-3.

7. A computer program product, characterised in that, Includes a computer program that, when executed by a processor, implements the grayscale switching method according to any one of claims 1-3.

Images