New and old application cluster flow cutting method and device based on transaction return code distribution
By building a data set based on the return code frequency distribution and adjusting traffic distribution in real time, the problems of static weights and manual intervention in switching between old and new application clusters are solved, an automated and rapid cluster switching process is implemented, ensuring business stability.
Patent Information
- Application Number
- CN202510923228.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-07-04
- Publication Date
- 2025-09-09
AI Technical Summary
In the existing technology, during the switching process between old and new application clusters, the static weight ratio is fixed and cannot be dynamically adjusted. It relies on manual intervention, which is costly and has delayed abnormal response, which may lead to a wider range of business impact.
By receiving transaction requests, building a dimensional data set based on the return code frequency distribution, adjusting traffic distribution in real time, and using an automated flow switching method combined with similarity calculation and manual verification, a smooth transition between new and old application clusters can be achieved.
It achieves automated flow switching without human intervention, reduces delays and subjective biases, improves fault response speed, and avoids omissions of low-frequency transactions and business risks.
Smart Images

Figure CN120614294A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of data processing technology, and in particular to a method and device for switching between new and old application clusters based on transaction return code distribution. Background Art
[0002] System reconstruction becomes necessary for scenarios with high concurrency and high traffic volumes. While ensuring production business continuity, how to efficiently and quickly complete the smooth transition between the reconstructed new application cluster and the old one is a key issue that every system needs to consider.
[0003] During the switching process between old and new application clusters, existing technologies usually adopt a static weighted ratio traffic distribution mode, but this method has the following defects: static rules are highly dependent, the traffic switching ratio is fixed, and it cannot be dynamically adjusted according to the real-time business status; the cost of manual intervention is high, and operation and maintenance personnel are required to continuously monitor anomalies and manually switch back, which is inefficient and prone to operational risks; abnormal response is delayed, and reliance on manual judgment leads to delayed problem discovery and resolution, which may cause the scope of business impact to expand.
[0004] Therefore, an automatic flow switching method is needed to solve the defects in the existing technology. Summary of the Invention
[0005] The present invention provides a method and device for switching traffic between new and old application clusters based on transaction return code distribution, so as to solve the defects in the existing traffic switching technology.
[0006] According to one aspect of the present invention, a method for switching traffic between old and new application clusters based on transaction return code distribution is provided, comprising:
[0007] When the front-end gateway receives a transaction request for an external transaction, it determines whether the external transaction is accepted by the new application cluster or the old application cluster;
[0008] After routing the transaction request to the new application cluster or the old application cluster, receiving response data including a return code generated after business logic processing;
[0009] Collecting return codes of the new and old application clusters in a preset time window in real time, and constructing a dimensional data set including the frequency distribution of each return code;
[0010] The new and old application clusters are switched according to the dimensionalized data set.
[0011] Optionally, the return code includes an HTTP status code, a system custom code, and a business custom code; wherein, the HTTP status code is a digital status code in response to the transaction request status; the system custom status code is a digital status code defined by the application system, used to indicate system-level exceptions; the business custom status code is a digital status code defined based on business logic, used to identify the processing result of a specific business scenario.
[0012] Optionally, determining whether the external transaction is accepted by the new application cluster or the old application cluster includes:
[0013] Determine the transaction type of the external transaction, and determine the weight ratio of traffic distribution between the new and old application clusters of the transaction type;
[0014] According to the traffic distribution weight ratio of the new and old application clusters, it is determined whether the external transaction is accepted by the new application cluster or the old application cluster.
[0015] Optionally, the real-time collection of return codes of the new and old application clusters within a preset time window and the construction of a dimensionalized data set including the frequency distribution of each return code include:
[0016] Real-time collection of return codes of each of the new and old application clusters under different transaction types within a preset time window;
[0017] For each of the transaction types, the frequency distribution of the return codes of different types is determined to obtain the dimensionalized data set.
[0018] Optionally, switching the new and old application clusters according to the dimensionalized data set includes:
[0019] Optionally, determining, based on the dimensionalized data set, similarities in frequency distributions of different types of return codes in each transaction type between the new and old application clusters;
[0020] If the similarity is greater than a preset threshold, a traffic promotion operation is performed according to a preset gradient to adjust the traffic quota of the new application cluster in the transaction type;
[0021] If the similarity is not greater than a preset threshold, the traffic of the new application cluster is rolled back, and the traffic quota in the transaction type is reset to a preset safety baseline value.
[0022] Optionally, the preset gradient is dynamically adjusted according to the transaction importance level, the historical status of the new application cluster and the system resource utilization.
[0023] Optionally, before performing the flow promotion operation according to the preset gradient, the method further includes:
[0024] Determine whether the transaction type is an important transaction based on a preset key transaction identification rule library;
[0025] Perform secondary verification on the determined important transactions, and when receiving the traffic upgrade confirmation information from external input, execute the traffic upgrade operation according to the preset gradient.
[0026] According to another aspect of the present invention, a device for switching traffic between old and new application clusters based on transaction return code distribution is provided, comprising:
[0027] an acceptance determination unit, configured to determine whether the external transaction is accepted by the new application cluster or the old application cluster when the front-end gateway receives a transaction request for the external transaction;
[0028] a response data generating unit, configured to receive response data including a return code generated after business logic processing after routing the transaction request to the new application cluster or the old application cluster;
[0029] A return code collection unit is used to collect the return codes of the new and old application clusters in a preset time window in real time and construct a dimensional data set including the frequency distribution of each return code;
[0030] A flow switching execution unit is configured to switch the flow of the new and old application clusters according to the dimensionalized data set.
[0031] According to another aspect of the present invention, an electronic device is provided, comprising:
[0032] At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor to enable the at least one processor to execute the method for switching between old and new application clusters based on transaction return code distribution as described in any embodiment of the present invention.
[0033] According to another aspect of the present invention, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores computer instructions, and wherein the computer instructions are used to enable a processor to implement the method for switching traffic between old and new application clusters based on transaction return code distribution according to any embodiment of the present invention when executed.
[0034] The technical solution of the embodiment of the present invention determines whether the transaction is accepted by the new application cluster or the old application cluster, receives response data containing return codes generated by business logic processing, constructs a dimensional data set containing the frequency distribution of each return code according to the return code, and uses it as a basis for switching the new and old application clusters. This achieves fully automated switching and avoids problems such as high delays, large subjective deviations, and omissions of low-frequency transactions caused by manual intervention.
[0035] It should be understood that the content described in this section is not intended to identify the key or important features of the embodiments of the present invention, nor is it intended to limit the scope of the present invention. Other features of the present invention will become readily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS
[0036] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.
[0037] Figure 1 This is a flow chart of a method for switching traffic between old and new application clusters based on transaction return code distribution, provided in Example 1 of the present invention;
[0038] Figure 2 This is a flow chart of a method for determining an external transaction acceptance mode provided in the second embodiment of the present invention;
[0039] Figure 3 This is a flow chart of a method for switching traffic between old and new application clusters based on transaction return code distribution, provided in the second embodiment of the present invention;
[0040] Figure 4 A schematic diagram of the structure of a new and old application cluster flow switching device based on transaction return code distribution provided in the third embodiment of the present invention;
[0041] Figure 5 The present invention is a schematic structural diagram of an electronic device for implementing a method for switching between old and new application clusters based on transaction return code distribution according to an embodiment of the present invention. DETAILED DESCRIPTION
[0042] In order to enable those skilled in the art to better understand the solutions of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the embodiments described are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of the present invention.
[0043] It should be noted that the terms "first", "second", etc. in the description and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that the numbers used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.
[0044] Example 1
[0045] Figure 1 This is a flow chart of a method for switching between old and new application clusters based on transaction return code distribution, provided by the first embodiment of the present invention. This embodiment is applicable to the case where old and new application clusters are switched during the migration and reconstruction of large and complex systems. The method can be executed by a device for switching between old and new application clusters based on transaction return code distribution. The device for switching between old and new application clusters based on transaction return code distribution can be implemented in the form of hardware and / or software. The device for switching between old and new application clusters based on transaction return code distribution can be configured in an electronic device. Figure 1 As shown, the method includes:
[0046] S110 : When the front-end gateway receives a transaction request for an external transaction, it determines whether the external transaction is accepted by the new application cluster or the old application cluster.
[0047] Specifically, most legacy application clusters are existing system clusters using traditional technical architectures. They carry the core business traffic of the current production environment and offer high stability but limited scalability. During the initial phase of traffic switching, they serve as the primary traffic carrier and also as a benchmark for the functional behavior of the new cluster. New application clusters are newly reconstructed system clusters based on modern technical architectures, with the goal of improving performance, scalability, and fault tolerance. However, their stability must be verified through traffic flow initially, and they will gradually take over traffic during the traffic switching process, gradually achieving full replacement. Therefore, while the new application cluster has not completely replaced the old application cluster, both the old and new application clusters will be used to process transaction requests simultaneously, and it is necessary to determine which external transactions will be accepted.
[0048] S120 : After routing the transaction request to the new application cluster or the old application cluster, receiving response data including a return code generated through business logic processing.
[0049] Specifically, after receiving a transaction request, the old and new application clusters call corresponding business components, such as service interfaces, database operations, and third-party system interactions, to execute transaction logic. After processing is complete, they generate structured response data, which includes at least the following parts:
[0050] Transaction code: identifies the specific business type, such as TRADE_PAYMENT and USER_REGISTER;
[0051] Return code: a status identifier customized by the system or business;
[0052] Timestamp: the exact time the response was generated;
[0053] Extended fields: Contains metadata such as error details, processing time, and impact scope.
[0054] In an embodiment of the present invention, the return code includes an HTTP status code, a system custom code, and a business custom code; wherein the HTTP status code is a digital status code that responds to the transaction request status; the system custom status code is a digital status code defined by the application system, used to indicate system-level exceptions; and the business custom status code is a digital status code defined based on business logic, used to identify the processing results of a specific business scenario.
[0055] Specifically, the HTTP status code follows the RFC standard and is used to identify the processing status of the HTTP request. Exemplary HTTP status codes may include: 200 (Success), 400 (Bad Request), 401 (Unauthorized), 403 (Forbidden), 404 (Not Found), and 500 (Server Internal Error).
[0056] The system-level return code is a digital status code defined by the application system and is used to indicate system-level exceptions, such as 1001 (database connection failure) and 1002 (cache service unavailable).
[0057] A business-defined status code is a five-digit status code defined based on business logic and is used to identify the processing results of a specific business scenario, such as 20001 (order creation successful) and 30002 (insufficient inventory).
[0058] In addition, the return code can also contain additional metadata in the return code, including the timestamp of the error occurrence, the error stack summary, the impact scope identifier, and the recommended processing action code.
[0059] S130 : Collect return codes of new and old application clusters in a preset time window in real time, and construct a dimensional data set including the frequency distribution of each return code.
[0060] Specifically, the collection of return codes can be achieved by designing a data collection layer. The data collection layer includes non-intrusive collection and asynchronous transmission mechanisms. Non-intrusive collection uses API gateways, service grids, or AOP interceptors to capture response data from new and old application clusters in real time, avoiding modifications to business code. The asynchronous transmission mechanism uses message queues such as Kafka and RabbitMQ to buffer collected data, ensuring that business system performance is not affected in high-concurrency scenarios.
[0061] The preset time window uses a rolling update method, retaining historical data and adding new data each time the window slides, forming a time series dataset. Initially, the window duration is automatically extended, for example, from 10 minutes to 30 minutes, to increase the sample size. Once the traffic in the new application cluster stabilizes, the window duration is shortened to a standard window, such as 5 minutes.
[0062] This dimensionalized dataset contains the frequency distribution of each return code. This dataset aggregates the return code data generated by new and old application clusters within a preset time window, structured by multiple dimensions such as transaction type, cluster ID, and time window. This dataset is used to count the number of occurrences and proportions of each return code within each dimension. For example, based on the dimensions "transaction type = payment," "cluster = new application," and "time window = 2025-06-30T09:00:00-09:10:00," frequency information such as "success code 200 appears 1000 times, insufficient balance code 300 appears 50 times" within this interval is counted. This forms a structured data model that can be used to analyze distribution patterns, providing a quantitative basis for calculating the similarity of return code distributions between new and old clusters and evaluating business consistency.
[0063] S140: Switch traffic between the new and old application clusters based on the dimensionalized data set.
[0064] Specifically, by collecting and aggregating the return code frequency distribution of the new and old clusters within the preset time window in real time, after building a structured data set, it is de-weighted to eliminate traffic ratio interference, and then the similarity of the return code distribution of the two is calculated to determine whether the business logic of the new and old application clusters is consistent, and automatic flow switching is performed based on this.
[0065] The technical solution of the embodiment of the present invention determines whether the transaction is accepted by the new application cluster or the old application cluster, receives response data containing return codes generated by business logic processing, constructs a dimensional data set containing the frequency distribution of each return code according to the return code, and uses it as the basis for switching the new and old application clusters, thereby avoiding problems such as high delays, large subjective deviations, and omissions of low-frequency transactions caused by manual intervention through a fully automated method based on the return code distribution.
[0066] Example 2
[0067] Figure 2This is a flow chart of a method for determining an external transaction acceptance mode provided by the second embodiment of the present invention. This embodiment further explains the above embodiment. Figure 2 As shown, the method includes:
[0068] S210: Determine the transaction type of the external transaction, and determine the weight ratio of traffic distribution between the new and old application clusters for the transaction type.
[0069] Specifically, through preset transaction type classification rules, such as transaction amount, business impact scope, and risk level, external transaction types are identified and differentiated initial weight matrices are assigned to different types of transactions. For example, the initial weight of the new application cluster for core transactions is 1%-10%, and that for non-core transactions is 20%-30%. The weights are dynamically adjusted based on the cluster's real-time health status, resource utilization, and historical performance. High-risk transactions are forcibly routed to the old cluster, while grayscale test transactions are distributed to the new cluster. This ensures that traffic distribution is both consistent with business priorities and adapted to the system's real-time operating status.
[0070] S220: Determine whether the external transaction is accepted by the new application cluster or the old application cluster based on the traffic distribution weight ratio between the new and old application clusters.
[0071] When the front-end gateway determines the external transaction acceptance cluster based on the traffic distribution weight ratio of the new and old application clusters, the core principle is to distribute transaction requests to the corresponding cluster according to preset weights through a load balancing algorithm, such as 30% for the new cluster and 70% for the old cluster. At the same time, dynamic adjustment is achieved by combining real-time monitoring and business rules: first, traffic is distributed according to the initial weight matrix. When it is detected that the cluster resource utilization exceeds the threshold or the response time is abnormal, the weight is automatically adjusted to a safe range.
[0072] In an embodiment of the present invention, the return codes of the new and old application clusters within a preset time window are collected in real time, and a dimensionalized data set containing the frequency distribution of each return code is constructed, including:
[0073] Real-time collection of return codes for different transaction types in new and old application clusters within a preset time window;
[0074] For each transaction type, the frequency distribution of different types of return codes is determined to obtain a dimensionalized data set.
[0075] Real-time collection of return codes for different transaction types from both the new and old application clusters within a preset time window involves non-invasively capturing transaction response data through components such as the service grid and API gateway. The data collection cycle is divided according to the preset time window, and return code data is stored by transaction type. For each transaction type, the frequency of occurrence of each type of return code is automatically counted, and its distribution ratio within the window is calculated. For example, between 9:00 and 9:10 on a certain day, if the transaction type is a payment transaction and the return code type is 200 (success), the frequency of occurrence for the new application cluster is 3200, while the frequency of occurrence for the old application cluster is 800. If the transaction type is an account query and the return code type is 400 (failure), the frequency of occurrence for the new application cluster is 200, while the frequency of occurrence for the old application cluster is 50.
[0076] Figure 3 This is a flow chart of a method for switching between old and new application clusters based on transaction return code distribution, provided by the second embodiment of the present invention. Figure 3 As shown, the method includes:
[0077] S310: Determine, based on the dimensionalized data set, the similarity of the frequency distribution of different types of return codes in each transaction type between the new and old application clusters.
[0078] As mentioned above, the dimensionalized dataset collected based on the preset time window already contains the frequency distribution of various return codes for different transaction types in the new and old clusters, such as the success code 200, parameter error code 400, and system exception code 500 mentioned above. Before calculating the similarity, the data needs to be de-weighted. If the current traffic weight of the new application cluster is 20% and the old cluster is 80%, the return code frequency of the new cluster is proportionally increased accordingly, such as adjusting the original frequency of 100 to 500, to eliminate the impact of traffic differences on the distribution.
[0079] The similarity algorithm preferably uses the following method:
[0080] Cosine similarity: This method evaluates distribution similarity by calculating the cosine of the vector angle. Values closer to 1 indicate higher similarity. This method is useful for quickly determining overall distribution trends.
[0081] KL divergence (Kullback-Leibler divergence): Quantifies the degree of difference between two probability distributions. Smaller values indicate closer distributions of return codes between the old and new clusters. This is often used to accurately analyze subtle differences.
[0082] Jaccard similarity: Calculates the overlap ratio of the return code set, which is suitable for judging the consistency of abnormal return codes.
[0083] S320: If the similarity is greater than a preset threshold, perform a traffic promotion operation according to a preset gradient to adjust the traffic quota of the new application cluster in the transaction type.
[0084] S330: If the similarity is not greater than the preset threshold, the traffic of the new application cluster is rolled back, and the traffic quota in the transaction type is reset to the preset safety baseline value.
[0085] When the return code distribution similarity for a transaction type exceeds a preset threshold, such as 0.95, the new cluster's processing capabilities for that business scenario are essentially the same as the old cluster's, indicating increased traffic flow. Different promotion levels are set based on transaction risk level. For core transactions, such as large-value payments, the increase is only 1%-3%, while for non-core transactions, such as product browsing, the increase can be relaxed to 5%-10%. If the similarity remains high for three consecutive time windows, the promotion level is automatically increased by 50%, accelerating the traffic switching process.
[0086] If the similarity does not reach the threshold (≤0.95) or there is a surge in abnormal return codes (for example, the proportion of 500 error codes in the new cluster increases from 1% to 10%), the rollback mechanism is triggered; the traffic quota of the new cluster for this transaction type is instantly reduced to the preset safety baseline to prevent the potential fault from spreading.
[0087] If the same transaction type triggers rollback three times within 24 hours, traffic switching for that type will be automatically suspended and 100% of the traffic will be directed to the old cluster to avoid repeated trial and error affecting the business.
[0088] In an embodiment of the present invention, the preset gradient is dynamically adjusted according to the transaction importance level, the historical status of the new application cluster, and the utilization rate of system resources.
[0089] Specifically, the dynamic adjustment mechanism for the preset gradient is based on transaction importance, the historical status of the new application cluster, and system resource utilization, enabling intelligent regulation of traffic promotion strategies. For core transactions (such as financial payments and user fund operations) due to their high risk, the preset gradient is initially low and adjusted slightly to ensure a stable transition. Non-core transactions (such as information queries and advertising) use a higher gradient to accelerate traffic switching efficiency. Regarding the historical status of a new application cluster, if its success rate in previous traffic promotions consistently exceeds 95% and its error rate is below a threshold, the system automatically increases the gradient to accelerate deployment. Conversely, if frequent anomalies occur, the gradient is reduced or promotion is suspended. System resource utilization is monitored in real time. When CPU and / or memory utilization exceeds 70%, the gradient is automatically halved to avoid resource overload. If it reaches the 90% warning line, promotion is immediately suspended and resource expansion is triggered. Through multi-dimensional dynamic adjustment, this mechanism maximizes the efficiency of new cluster deployment while ensuring business stability.
[0090] In an embodiment of the present invention, the method may further include:
[0091] Determine whether the transaction type is an important transaction based on a preset key transaction identification rule library;
[0092] Perform secondary verification on the determined important transactions, and when receiving the traffic upgrade confirmation information from external input, execute the traffic upgrade operation according to the preset gradient.
[0093] Through the preset key transaction identification rule base, each transaction type is automatically screened. The rule base contains multi-dimensional judgment conditions, such as transaction amount thresholds, such as a single transaction exceeding 50,000 yuan; business sensitivity labels, involving core accounts, fund settlement; abnormal transaction frequency, high-frequency operations in a short period of time, etc. If any of the conditions are met, it will be determined as an important transaction. For such transactions, a secondary verification mechanism is activated, and the core data such as the return code distribution, response time comparison, and resource utilization of the new and old clusters are displayed to the operation and maintenance personnel through a visual interface. The operation and maintenance personnel will manually confirm it based on their business experience and system prompts. Only after the operation and maintenance personnel enter the traffic promotion confirmation information through two-factor authentication (such as fingerprint and dynamic token), the traffic share of the new application cluster will be gradually increased according to the preset gradient, so as to ensure the stability and reliability of high-risk transactions during the flow cutting process, and avoid business risks caused by automated misjudgment.
[0094] In summary, the solutions of the embodiments of the present invention have the following advantages and improvements:
[0095] 1. A dual decision-making mechanism of similarity index calculation and manual verification has been introduced. The fully automated return code distribution similarity index calculation avoids problems such as high latency, large subjective bias, and omission of low-frequency transactions caused by manual intervention. At the same time, the introduction of manual secondary verification for key transactions avoids the risk of flow switching caused by possible automated misjudgment.
[0096] 2. Determine in real time whether traffic rollback is necessary based on the similarity index calculation results. No manual intervention is required throughout the process, which improves fault response speed and shortens the production fault window.
[0097] Example 3
[0098] Figure 4 This is a schematic diagram of the structure of a new and old application cluster flow switching device based on transaction return code distribution provided by the third embodiment of the present invention. Figure 4 As shown, the device includes:
[0099] The acceptance determination unit 410 is configured to determine whether the external transaction is accepted by the new application cluster or the old application cluster when the front-end gateway receives a transaction request for the external transaction;
[0100] The response data generation unit 420 is used to receive response data including a return code generated after business logic processing after routing the transaction request to the new application cluster or the old application cluster;
[0101] The return code collection unit 430 is used to collect the return codes of the new and old application clusters in a preset time window in real time and construct a dimensional data set containing the frequency distribution of each return code;
[0102] The flow switching execution unit 440 is configured to switch the flow between the new and old application clusters according to the dimensionalized data set.
[0103] Optionally, the return code includes the HTTP status code, system-defined code, and business-defined code; the HTTP status code is a digital status code that responds to the transaction request status; the system-defined status code is a digital status code defined by the application system and is used to indicate system-level exceptions; the business-defined status code is a digital status code defined based on business logic and is used to identify the processing result of a specific business scenario.
[0104] Optionally, the acceptance determination unit 410 is specifically configured to execute:
[0105] Determine the transaction type of the external transaction and the weight ratio of traffic distribution between the new and old application clusters for the transaction type;
[0106] The external transactions are handled by the new application cluster or the old application cluster based on the traffic distribution weight ratio of the new and old application clusters.
[0107] Optionally, the return code collection unit 430 is specifically configured to execute:
[0108] Real-time collection of return codes for different transaction types in new and old application clusters within a preset time window;
[0109] For each transaction type, the frequency distribution of different types of return codes is determined to obtain a dimensionalized data set.
[0110] Optionally, the flow switching execution unit 440 is specifically configured to execute:
[0111] Based on the dimensionalized dataset, determine the similarity of the frequency distribution of different types of return codes in each transaction type between the old and new application clusters;
[0112] If the similarity is greater than the preset threshold, the traffic promotion operation is performed according to the preset gradient, and the traffic quota of the new application cluster in this transaction type is adjusted;
[0113] If the similarity is not greater than the preset threshold, the traffic of the new application cluster will be rolled back, and the traffic quota in this transaction type will be reset to the preset safety baseline value.
[0114] Optionally, the preset gradient is dynamically adjusted based on the transaction importance level, the historical status of the new application cluster, and the system resource utilization.
[0115] Optionally, before performing the flow promotion operation according to the preset gradient, the flow cutting execution unit 440 is further configured to execute:
[0116] Determine whether the transaction type is an important transaction based on a preset key transaction identification rule library;
[0117] Perform secondary verification on the determined important transactions, and when receiving the traffic upgrade confirmation information from external input, execute the traffic upgrade operation according to the preset gradient.
[0118] The device for switching traffic between old and new application clusters based on transaction return code distribution provided by an embodiment of the present invention can execute the method for switching traffic between old and new application clusters based on transaction return code distribution provided by any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.
[0119] Example 4
[0120] Figure 5 A schematic diagram of the structure of an electronic device 10 that can be used to implement an embodiment of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices (such as helmets, glasses, watches, etc.) and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present invention described and / or claimed herein.
[0121] like Figure 5 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12, a random access memory (RAM) 13, etc., which is communicatively connected to the at least one processor 11. The memory stores a computer program that can be executed by the at least one processor. The processor 11 can perform various appropriate actions and processes according to the computer program stored in the read-only memory (ROM) 12 or the computer program loaded from the storage unit 18 into the random access memory (RAM) 13. Various programs and data required for the operation of the electronic device 10 can also be stored in the RAM 13. The processor 11, ROM 12, and RAM 13 are connected to each other via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.
[0122] Multiple components in the electronic device 10 are connected to the I / O interface 15, including an input unit 16, such as a keyboard, a mouse, etc.; an output unit 17, such as various types of displays, speakers, etc.; a storage unit 18, such as a magnetic disk, an optical disk, etc.; and a communication unit 19, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 19 allows the electronic device 10 to exchange information / data with other devices via a computer network such as the Internet and / or various telecommunication networks.
[0123] Processor 11 can be any general-purpose and / or specialized processing component with processing and computing capabilities. Examples of processor 11 include, but are not limited to, central processing units (CPUs), graphics processing units (GPUs), various specialized artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, digital signal processors (DSPs), and any other suitable processors, controllers, microcontrollers, and the like. Processor 11 executes the various methods and processes described above, such as the method for switching between old and new application clusters based on transaction return code distribution.
[0124] In some embodiments, the method for switching between clusters of new and old applications based on the distribution of transaction return codes can be implemented as a computer program, which is tangibly contained in a computer-readable storage medium, such as a storage unit 18. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 10 via the ROM 12 and / or the communication unit 19. When the computer program is loaded into the RAM 13 and executed by the processor 11, one or more steps of the method for switching between clusters of new and old applications based on the distribution of transaction return codes described above can be performed. Alternatively, in other embodiments, the processor 11 can be configured to execute the method for switching between clusters of new and old applications based on the distribution of transaction return codes by any other appropriate means (for example, by means of firmware).
[0125] Various embodiments of the systems and techniques described herein can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), system-on-chip systems (SOCs), programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments can include being implemented in one or more computer programs that are executable and / or interpreted on a programmable system that includes at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.
[0126] Computer programs for implementing the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when the computer program is executed by the processor, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The computer program may be executed entirely on the machine, partially on the machine, as a stand-alone software package, partially on the machine and partially on a remote machine, or entirely on a remote machine or server.
[0127] In the context of the present invention, computer-readable storage media can be tangible media that can contain or store a computer program for use with an instruction execution system, device or equipment or used in combination with an instruction execution system, device or equipment. Computer-readable storage media can include but are not limited to electronic, magnetic, optical, electromagnetic, infrared or semiconductor systems, devices or equipment, or any suitable combination of the foregoing. Alternatively, computer-readable storage media can be machine-readable signal media. More specific examples of machine-readable storage media can include electrical connections based on one or more lines, portable computer disks, hard disks, random access memories (RAM), read-only memories (ROM), erasable programmable read-only memories (EPROM or flash memory), optical fibers, portable compact disk read-only memories (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.
[0128] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, the feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including acoustic input, voice input, or tactile input).
[0129] The systems and techniques described herein can be implemented in a computing system that includes back-end components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes front-end components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such back-end components, middleware components, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: a local area network (LAN), a wide area network (WAN), a blockchain network, and the Internet.
[0130] A computing system may include clients and servers. The clients and servers are typically remote from each other and typically interact via a communication network. This client-server relationship arises through computer programs running on the respective computers, creating a client-server relationship. The server may be a cloud server, also known as a cloud computing server or cloud host. This server is a hosting product within the cloud computing service ecosystem that addresses the management difficulties and limited scalability of traditional physical hosting and VPS services.
[0131] It should be understood that the various forms of the processes shown above can be used to reorder, add, or delete steps. For example, the steps described in the present invention can be performed in parallel, sequentially, or in a different order, as long as the desired results of the technical solution of the present invention can be achieved. This is not limited herein.
[0132] The above specific embodiments do not limit the scope of protection of the present invention. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions may be made based on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention are intended to be included within the scope of protection of the present invention.
Claims
1. A method for switching traffic between old and new application clusters based on transaction return code distribution, characterized in that: include: When the front-end gateway receives a transaction request for an external transaction, it determines whether the external transaction is accepted by the new application cluster or the old application cluster; After routing the transaction request to the new application cluster or the old application cluster, receiving response data including a return code generated after business logic processing; Collecting return codes of the new and old application clusters in a preset time window in real time, and constructing a dimensional data set including the frequency distribution of each return code; The new and old application clusters are switched according to the dimensionalized data set.
2. The method according to claim 1, characterized in that The return code includes an HTTP status code, a system-defined code, and a business-defined code; wherein the HTTP status code is a digital status code in response to the transaction request status; the system-defined status code is a digital status code defined by the application system, used to indicate system-level exceptions; the business-defined status code is a digital status code defined based on business logic, used to identify the processing result of a specific business scenario.
3. The method according to claim 1, characterized in that The determining whether the external transaction is accepted by the new application cluster or the old application cluster includes: Determine the transaction type of the external transaction, and determine the weight ratio of traffic distribution between the new and old application clusters of the transaction type; According to the traffic distribution weight ratio of the new and old application clusters, it is determined whether the external transaction is accepted by the new application cluster or the old application cluster.
4. The method according to claim 3, characterized in that The real-time collection of return codes of the new and old application clusters within a preset time window and the construction of a dimensional data set including the frequency distribution of each return code include: Real-time collection of return codes of each of the new and old application clusters under different transaction types within a preset time window; For each of the transaction types, the frequency distribution of the return codes of different types is determined to obtain the dimensionalized data set.
5. The method according to claim 4, characterized in that The switching of the new and old application clusters according to the dimensionalized data set includes: Determining, based on the dimensionalized data set, similarities in frequency distributions of different types of return codes in each transaction type between the new and old application clusters; If the similarity is greater than a preset threshold, a traffic promotion operation is performed according to a preset gradient to adjust the traffic quota of the new application cluster in the transaction type; If the similarity is not greater than a preset threshold, the traffic of the new application cluster is rolled back, and the traffic quota in the transaction type is reset to a preset safety baseline value.
6. The method according to claim 5, characterized in that The preset gradient is dynamically adjusted according to the transaction importance level, the historical status of the new application cluster and the system resource utilization.
7. The method according to claim 5, characterized in that Before performing the flow promotion operation according to the preset gradient, the method further includes: Determine whether the transaction type is an important transaction based on a preset key transaction identification rule library; Perform secondary verification on the determined important transactions, and when receiving the traffic upgrade confirmation information from external input, execute the traffic upgrade operation according to the preset gradient.
8. A device for switching between old and new application clusters based on transaction return code distribution, characterized in that: include: an acceptance determination unit, configured to determine whether the external transaction is accepted by the new application cluster or the old application cluster when the front-end gateway receives a transaction request for the external transaction; a response data generating unit, configured to receive response data including a return code generated after business logic processing after routing the transaction request to the new application cluster or the old application cluster; A return code collection unit is used to collect the return codes of the new and old application clusters in a preset time window in real time and construct a dimensional data set including the frequency distribution of each return code; A flow switching execution unit is configured to switch the flow of the new and old application clusters according to the dimensionalized data set.
9. An electronic device, characterized in that: The electronic device comprises: At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor so as to enable the at least one processor to execute the new and old application cluster flow switching method based on transaction return code distribution according to any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to implement the new and old application cluster flow switching method based on transaction return code distribution according to any one of claims 1 to 7 when executed.