Business processing method, device and equipment under parallel architecture of new and old systems
By combining white-box and black-box models for identification, the problem of burden and ineffective overhead when the new system fails under the parallel architecture of the old and new systems is solved. This achieves interpretability and traceability of failure categories and reduces the processing pressure on the old system.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- AGRICULTURAL DEVELOPMENT BANK OF CHINA
- Filing Date
- 2025-11-21
- Publication Date
- 2026-06-23
AI Technical Summary
In a parallel architecture of old and new systems, when the new system fails to process a request, directly switching back to the old system will increase the burden on the old system and inefficient processing overhead. Furthermore, some failure categories, such as information input errors, are difficult to handle successfully and will increase additional overhead.
A combined white-box and black-box modeling identification strategy is adopted. First, the white-box model is used to identify the failure category of the processing failure. If the white-box model fails to identify it, the black-box model is used to identify the failure category. Based on the identified failure category, a decision is made on whether to redistribute the request.
It reduces or avoids the increased pressure on the old system when the new system fails to process the data, thus reducing the overhead of ineffective processing and improving the interpretability and traceability of failure categories.
Smart Images
Figure CN121658034B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of data processing technology, and in particular to a business processing method, apparatus and equipment under a parallel architecture of old and new systems. Background Technology
[0002] When updating (upgrading) business systems, the current common approach is to deploy the new system in parallel with the old system (such as blue-green deployment, canary release, etc.) to reduce the potential risks associated with system updates (upgrades) and ensure the smooth operation of the business system. In this parallel architecture, processing requests can be routed to the target system based on routing conditions. In this scenario, if a processing request fails to be processed in the new system, it will be directly switched back to the old system for processing. However, this failure handling method not only increases the processing burden on the old system but may also increase unnecessary processing overhead. Summary of the Invention
[0003] The purpose of this application is to provide a business processing method, apparatus, and device under a parallel architecture of old and new systems, so as to reduce the processing burden and ineffective processing overhead of the old system under the parallel architecture of old and new systems.
[0004] To achieve the above objectives, in one aspect, embodiments of this application provide a business processing method under a parallel architecture of old and new systems, including:
[0005] Receive and process requests;
[0006] The processing request is routed to the target system for processing according to the routing configuration; the target system includes at least one of a new system and an old system.
[0007] When the new system fails to process the processing request, the failure category is identified based on the white-box model;
[0008] When the white-box model fails to identify the failure category, the failure category of the processing failure is identified according to the black-box model;
[0009] The processing request is rerouted based on the identified failure category.
[0010] In the business processing method of this application embodiment, the step of diverting the processing request to the target system for processing according to the diversion configuration includes:
[0011] Identify the request type corresponding to the processing request;
[0012] When the processing request is a parameter-based request, the processing request will be routed to the new system and the old system for processing;
[0013] When the processing request is a business request, the traffic distribution configuration is queried according to the business element corresponding to the processing request, and the processing request is distributed to the new system or the old system for processing according to the query result.
[0014] In the business processing method of this application embodiment, the business elements include at least one of the following:
[0015] Organizational logo;
[0016] User ID;
[0017] Channel identification;
[0018] Transaction code.
[0019] In the business processing method of this application embodiment, the step of identifying the failure category of processing failure based on the white-box model includes:
[0020] The log text corresponding to the processing failure is converted into feature encoding based on the sparse vectorization model;
[0021] The feature encoding is input into the decision tree model to obtain the first-level failure category; the first-level failure category includes one of the following: program defect, infrastructure failure, information input error, and unknown error.
[0022] In the business processing method of this application embodiment, the step of identifying the failure category of the processing failure based on the black-box model includes:
[0023] The log text corresponding to the failed processing request is converted into a semantic vector based on the dense vectorization model.
[0024] The semantic vector is input into the KNN model to obtain the second-level processing failure categories; the second-level processing failure categories include one of the following: program defects, infrastructure failures, and information input errors.
[0025] In the business processing method of this application embodiment, the step of deciding on the rerouting of the processing request based on the identified failure category includes:
[0026] When the failure category is a program defect or infrastructure failure, the processing request will be diverted to the legacy system for processing;
[0027] When the failure category is "incorrect information input", an error reason message will be returned.
[0028] In the business processing method of this application embodiment, after receiving the processing request, it further includes:
[0029] Assign a globally unique tracking identifier to the processing request;
[0030] During the processing of the processing request by the new system, key information of the span of each span traversed by the processing request is recorded, and the key information of the span is associated with the tracking identifier;
[0031] A tree-like call chain is constructed based on the span key information associated with the tracking identifier;
[0032] When the new system fails to process the processing request, it performs root cause analysis by traversing the tree-like call chain based on the tracing identifier.
[0033] In the business processing method of this application embodiment, the step of traversing the tree-like call chain based on the tracking identifier to perform root cause analysis includes:
[0034] When a processing failure is a single processing failure, the service node corresponding to the end of the tree-like call chain is determined as the root cause of the processing failure;
[0035] When a processing failure is a multiple processing failure, aggregate all processing requests identified as belonging to the same failure category within a specified time window;
[0036] Determine the root cause corresponding to each of the plurality of processing requests to form a root cause sequence;
[0037] When the proportion of the root cause sequence pointing to the same service node reaches a threshold, that service node is identified as the root cause of the multiple processing requests.
[0038] On the other hand, embodiments of this application also provide a business processing apparatus under a parallel architecture of old and new systems, including:
[0039] The request receiving module is used to receive and process requests;
[0040] A request routing module is used to route the processing request to a target system for processing according to the routing configuration; the target system includes at least one of a new system and an old system.
[0041] The first identification module is used to identify the failure category of the processing failure based on a white-box model when the new system fails to process the processing request.
[0042] The second identification module is used to identify the failure category of the processing failure based on the black box model when the white box model fails to identify the failure category.
[0043] The rerouting decision module is used to decide on the rerouting of the processing request based on the identified failure category.
[0044] On the other hand, embodiments of this application also provide a computer device, including a memory, a processor, and a computer program stored in the memory, wherein the computer program, when run by the processor, executes instructions of the above-described method.
[0045] As can be seen from the technical solutions provided in the embodiments of this application above, in the parallel architecture of the new and old systems, when the new system fails to process a request, it first identifies the failure category based on the white-box model; if the white-box model cannot identify the failure category, it then identifies the failure category based on the black-box model; based on this, it decides whether to re-distribute the request according to the identified failure category; thus, it reduces or avoids the increase in processing pressure on the old system by directly switching back to the old system when the new system fails to process the request; and it also reduces or avoids the problem that when certain failure categories (such as information input errors) are switched back to the old system, they are not only difficult to process successfully, but also add additional invalid processing overhead. Moreover, in the embodiments of this application, by adopting the identification strategy of using the white-box model as the main method (i.e., white-box model priority) and the black-box model as a supplement (i.e., black-box model as a fallback), it is possible not only to identify the failure category, but also to make the identified failure category more interpretable and traceable. Attached Figure Description
[0046] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings:
[0047] Figure 1 This application illustrates a schematic diagram of the application environment for business processing under the parallel architecture of the old and new systems in some embodiments of this application;
[0048] Figure 2 Flowcharts of business processing methods under the parallel architecture of new and old systems in some embodiments of this application are shown;
[0049] Figure 3 It shows Figure 2 The flowchart shown illustrates how the processing request is routed to the target system for processing based on the routing configuration.
[0050] Figure 4 It shows Figure 2 The flowchart shown illustrates the method for identifying failure categories based on a white-box model.
[0051] Figure 5 A schematic diagram of the structure of a decision tree model in an exemplary embodiment of this application is shown;
[0052] Figure 6 It shows Figure 2 The flowchart shown illustrates the method for identifying failure categories based on a black-box model.
[0053] Figure 7 Flowcharts of service processing methods under parallel architecture of new and old systems in other embodiments of this application are shown;
[0054] Figure 8 It shows Figure 2 The flowchart shown illustrates the root cause analysis based on tracking identifiers.
[0055] Figure 9 This application shows a structural block diagram of a service processing device under a parallel architecture of old and new systems in some embodiments;
[0056] Figure 10 A structural block diagram of a computer device in some embodiments of this application is shown.
[0057] [Explanation of Labels in the Attached Image]
[0058] 10. Client-side;
[0059] 20. Server-side;
[0060] 30. New system;
[0061] 40. Old system;
[0062] 91. Request receiving module;
[0063] 92. Request the traffic splitting module;
[0064] 93. First identification module;
[0065] 94. Second identification module;
[0066] 95. Diversion Decision Module;
[0067] 1002. Computer equipment;
[0068] 1004, Processor;
[0069] 1006. Memory;
[0070] 1008. Drive mechanism;
[0071] 1010. Input / output interface;
[0072] 1012. Input devices;
[0073] 1014. Output devices;
[0074] 1016. Presentation device;
[0075] 1018. Graphical User Interface;
[0076] 1020. Network interface;
[0077] 1022. Communication link;
[0078] 1024. Communication bus. Detailed Implementation
[0079] To enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this application.
[0080] It should be noted that in the embodiments of this application, 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, data stored, data displayed, etc.) involved are all information and data authorized and agreed upon by the user and fully authorized by all parties. That is, the acquisition, transmission, storage, use, and processing of data in the technical solution of this application all comply with the relevant provisions of national laws and regulations.
[0081] Figure 1 The diagram illustrates an application environment in some embodiments of this application. This application environment includes a client 10, a server 20, a new system 30, and an old system 40. The client 10 can send a processing request to the server 20; the server 20 can receive the processing request; and, according to a routing configuration, routes the processing request to a target system for processing. The target system includes at least one of the new system 30 and the old system 40. When the new system 30 fails to process the processing request, the failure category is identified using a white-box model; when the white-box model fails to identify the failure category, the failure category is identified using a black-box model; and a decision is made to re-route the processing request based on the identified failure category. Under the parallel architecture of the new and old systems, the processing burden and unnecessary processing overhead of the old system can be reduced through the embodiments of this application.
[0082] In some embodiments of this application, the client 10 can be a self-service terminal device, a mobile terminal (i.e., a smartphone), a display, a desktop computer, a tablet computer, a laptop computer, a digital assistant, or a smart wearable device, etc. Among these, smart wearable devices can include smart bracelets, smartwatches, smart glasses, or smart helmets, etc. Of course, the client 10 is not limited to the aforementioned physical electronic devices; it can also be software running on the aforementioned electronic devices.
[0083] In some embodiments of this application, the server 20 can be an electronic device with computing and network interaction functions; or it can be software running on the electronic device that provides business logic for data processing and network interaction.
[0084] In some embodiments of this application, both the new system 30 and the old system 40 are business systems. Specifically, the new system 30 is a new version of the business system, and the old system 40 is an older version of the business system. Both the new system 30 and the old system 40 can be electronic devices with computing and network interaction functions; they can also be software running on the electronic device that provides business logic for data processing and network interaction.
[0085] This application provides a business processing method under a parallel architecture of old and new systems, which can be applied to the server side described above. (Refer to...) Figure 2 As shown in some embodiments of this application, the business processing method under the parallel architecture of the old and new systems may include the following steps:
[0086] Step 201: Receive processing request.
[0087] Step 202: Distribute the processing request to the target system for processing according to the diversion configuration; the target system includes at least one of the new system and the old system.
[0088] Step 203: When the new system fails to process the processing request, identify the failure category of the processing failure according to the white-box model.
[0089] Step 204: When the white-box model fails to identify the failure category, the failure category of the processing failure is identified according to the black-box model.
[0090] Step 205: Determine the rerouting of the processing request based on the identified failure category.
[0091] In this embodiment, under the parallel architecture of the old and new systems, when the new system fails to process a request, it first identifies the failure category based on the white-box model. If the white-box model cannot identify the failure category, it then identifies the failure category based on the black-box model. Based on this, it decides whether to re-distribute the request according to the identified failure category. This reduces or avoids directly switching back to the old system when the new system fails to process a request, thus increasing the processing pressure on the old system. Furthermore, it reduces or avoids the problem that certain failure categories (such as incorrect information input) not only have difficulty being processed successfully when switched back to the old system but also incur additional unnecessary processing overhead. Moreover, in this embodiment, by using a white-box model as the primary method (i.e., white-box model priority) and a black-box model as a secondary method (i.e., black-box model as a fallback), not only can the failure category be identified, but the identified failure categories also become more interpretable and traceable.
[0092] In this embodiment, the parallel architecture of new and old systems refers to a system architecture in which the new system and the old system run in parallel to achieve a smooth upgrade of the business system and reduce the production risk of the new system. Under this parallel architecture, a traffic splitting strategy (i.e., a custom traffic splitting configuration) can be pre-configured as needed to ensure that different requests are processed by either the new or old system as expected. The traffic splitting configuration may include: traffic splitting configurations for different request categories, traffic splitting configurations for different splitting ratios for the same request category, and traffic splitting configurations for different request subclasses within the same request category.
[0093] refer to Figure 3 As shown in some embodiments of this application, routing processing requests to a target system for processing according to a routing configuration may include the following steps:
[0094] Step 301: Identify the request type corresponding to the processing request.
[0095] In some embodiments of this application, the received processing request can be a parameter-type request or a business-type request. A parameter-type request refers to a processing request used to maintain and update system parameters (such as rates, daily transaction limits, etc.). A business-type request refers to a processing request used to implement specific business logic (such as transaction processing, etc.).
[0096] In some embodiments of this application, the request type to which the processing request belongs can be marked in the message type of the request message. After receiving the processing request, the request type to which the processing request belongs can be obtained by parsing the request message.
[0097] Step 302: When the processing request is a parameter-type request, the processing request is diverted to the new system and the old system for processing.
[0098] In some embodiments of this application, parameter-type requests are characterized by the need to be effective in both the new and old systems simultaneously. Therefore, when the processing request is a parameter-type request, the processing request can be diverted to the new system and the old system for processing, so that the system parameters corresponding to the parameter-type request can be effective in both the new and old systems simultaneously, preventing business logic confusion caused by inconsistencies in system parameters in different systems and ensuring the consistency of processing results.
[0099] Step 303: When the processing request is a business request, query the diversion configuration according to the business element corresponding to the processing request, and divert the processing request to the new system or the old system for processing according to the query result.
[0100] In some embodiments of this application, compared to parameter-based requests, business-based requests are the core processing objects of the business system, not only in number but also in subcategories. To reduce the production risk of a new system, for business-based requests, a traffic distribution configuration can be queried based on the business elements corresponding to the processing request, and the processing request can be distributed to the new system or the old system for processing based on the query results. The traffic distribution configuration specifies the traffic distribution mapping relationship between business elements and the new and old systems. When the processing request is a business-based request, the corresponding target system can be determined by querying the traffic distribution configuration based on the business elements corresponding to the processing request, and then the processing request can be distributed to the target system.
[0101] In some embodiments of this application, business elements may include, but are not limited to, organization identifiers (such as server identifiers), user identifiers, channel identifiers (i.e., request initiation channel identifiers) and / or transaction codes.
[0102] refer to Figure 4 As shown, in some embodiments of this application, identifying the failure category of processing failure based on the white-box model may include the following steps:
[0103] Step 401: Convert the original log text corresponding to the processing failure into feature encoding according to the sparse vectorization model.
[0104] In this embodiment, the sparse vectorization model refers to a vectorization model that converts text into sparse vectors; where a sparse vector is a vector in which most of its elements are 0, and only a very small number of non-zero elements. By converting the original log text corresponding to the processing failure into feature encoding according to the sparse vectorization model, a large amount of memory can be saved and the computational efficiency is high.
[0105] In some embodiments of this application, any suitable sparse vectorization model can be selected as needed. For example, taking the One-Hot encoding model as an example of a sparse vectorization model, the One-Hot encoding model is a feature vector representation method in text classification, which can encode the original log text corresponding to processing failures into One-Hot encoding. In specific implementation, the One-Hot encoding model can maintain a global keyword dictionary (a total of N words). The model scans the current log, and if the i-th keyword appears, the i-th bit is set to 1, otherwise it is 0. The vector representation of the current log is [x1,x2,...,xn-1,xn], where xi={0,1}, xi=0 indicates that the i-th word in the keyword dictionary does not appear in the log, and xi=1 indicates that the i-th word in the keyword dictionary appears in the log. For example, in an exemplary embodiment, the keyword dictionary is shown in Table 1 below:
[0106] Table 1
[0107]
[0108] If the original log text corresponding to the processing failure is "2025-08-23 11:02:33 Transaction failed: connection failed, please check the log", then according to Table 1 above, its one-hot encoding is [1, 0, 0, ..., 0], with only the first bit being 1 and the rest being 0.
[0109] Step 402: Input the feature encoding into the decision tree model to obtain the first-level failure category; the first-level failure category includes one of the following: program defect, infrastructure failure, information input error and unknown error.
[0110] Decision tree models are classification and regression methods in machine learning. They are graphical methods that construct decision trees based on the conditions required for various scenarios to maximize expected value. The tree structure of decision tree models resembles a human-readable if-else structure. In some embodiments of this application, by using decision tree models to identify the failure types of processing failures, the identification results are interpretable and traceable, making them particularly suitable for business areas such as payment transactions where auditing and supervision are highly demanding. Moreover, considering the limited information in logs, by converting the original log text corresponding to processing failures into one-hot encoding and using it as input features for the decision tree model, and then using the decision tree model for classification reasoning, the computation is very lightweight and extremely fast, which can more effectively meet the real-time response requirements of business systems with ultra-low latency.
[0111] For example, in Figure 5In the decision tree model of the exemplary embodiment shown, it first determines whether the original log text contains the keyword X0 from the keyword dictionary (i.e., whether X0 equals 1); if it does, the failure category is identified as: infrastructure failure; if it does not, the log text further determines whether it contains the keyword X1 from the keyword dictionary (i.e., whether X1 equals 1); if it does, the failure category is identified as: information input error; if it does not, the subsequent judgment continues until it determines whether the original log text contains the last keyword X150 from the keyword dictionary (i.e., whether X150 equals 1); if it does, the failure category is identified as: program defect; if it still does not, the unknown exception (or other) is output, that is, the decision tree model failed to identify the failure category.
[0112] refer to Figure 6 As shown, in some embodiments of this application, identifying the failure category of the processing failure based on a black-box model may include the following steps:
[0113] Step 601: Convert the original log text corresponding to the failed processing request into a semantic vector according to the dense vectorization model.
[0114] In this embodiment of the application, the dense vectorization model refers to a vectorization model that converts text into a dense vector; wherein, a dense vector is a vector that has meaningful, non-zero real values in most dimensions; these real values are not preset to 0 or 1 during encoding, but are obtained through model learning and contain arbitrary real values (e.g., positive numbers, negative numbers, or decimals) that contain semantic information.
[0115] In some embodiments of this application, the dense vectorization model can be, for example, a word embedding model (e.g., Word2vec, GloVe, FastText, etc.). The keyword dictionary in a one-hot encoding model is manually selected based on expert experience, and may contain erroneous keywords that experts have not encountered or have overlooked. One-hot encoding is more like a blacklist / whitelist approach; it only focuses on whether a keyword appears, but loses the semantic information in the natural language implicit in the error log. Unlike one-hot encoding, word embedding can transform high-dimensional, sparse discrete representations into low-dimensional, continuous semantic vector representations, enabling classifier models to better understand and process complex semantic information. This representation method is not only computationally efficient but also has powerful semantic capture capabilities.
[0116] Step 602: Input the semantic vector into the KNN model to obtain the second-level processing failure categories; the second-level processing failure categories include: program defects (such as program bugs), infrastructure failures (such as database connection anomalies, communication failures, network jitter, etc.) and information input errors.
[0117] The KNN model, or K-Nearest Neighbors algorithm, is a supervised learning algorithm. Its core idea is that if the majority of the K most similar samples in the training dataset belong to a certain class, then the sample to be classified also belongs to that class. In short, the KNN model uses similarity as a voting mechanism to determine the class of a sample. The KNN model generally follows these steps:
[0118] 1. Calculate the distance between the sample to be classified and each sample in the training set.
[0119] 2. Select the K samples with the smallest distance; these samples are called "neighbors".
[0120] 3. Based on the category labels of these neighbors, determine the category of the sample to be classified through voting or weighted averaging.
[0121] In some embodiments of this application, similarity algorithms such as cosine distance can be selected as standards to measure the distance between the semantic vector of the log identified as "unknown anomaly" by the decision tree model and the semantic vectors corresponding to "infrastructure failure", "program defect" and "information input error", and the closest one is determined as the failure category to which the processing failure belongs.
[0122] Considering that the KNN model is time-consuming with large samples and that the failure rate of being classified as "unknown anomaly" by the decision tree model is very low, some embodiments of this application use small samples to train the KNN model. For example, the 10 most frequent logs from each category, totaling 40 logs, can be selected as training samples; and n is set to 5, meaning that the category of the sample to be classified is determined by voting among the 5 nearest neighbors of the sample to be classified (setting n to 5 is to consider a certain degree of noise resistance and low computational cost). During model training, the cosine distance between the sample to be classified and the 40 selected training samples is calculated, and the 5 nearest neighbors are used for voting. If 3 or more of the 5 neighbors belong to the same category, the sample to be classified is classified into that category; otherwise (e.g., a 1:2:2 situation), it is classified as "unknown" and no retry is performed. Due to the non-parametric nature of KNN, training the KNN model based on small samples can avoid the problem of overfitting the training model on small data.
[0123] In some embodiments of this application, the decision to redistribute the processing request based on the identified failure category may include: when the failure category is a program defect or infrastructure failure, the processing request is redistributed to an older system for processing; or when the failure category is an information input error, an error reason prompt is returned.
[0124] This application provides another business processing method under a parallel architecture of old and new systems, referencing... Figure 7 As shown in some embodiments of this application, the business processing method under the parallel architecture of the old and new systems may include the following steps:
[0125] Step 701: Receive processing request.
[0126] Step 702: Query the traffic splitting configuration.
[0127] Querying the traffic splitting configuration means: querying the traffic splitting configuration based on the request type in the processing request to determine the target system to which the processing request should be split.
[0128] Step 703: Distribute and process requests.
[0129] Request routing refers to routing processing requests to a new or old system for processing based on query results.
[0130] Step 704: The new system processes the request.
[0131] The new system processing request means that the new system processes the aforementioned processing request.
[0132] Step 705: Determine whether the processing was successful.
[0133] Determining whether the processing was successful means determining whether the new system successfully processed the processing request.
[0134] If successful, proceed to step 706; otherwise, proceed to step 707.
[0135] Step 706: Return the processing result.
[0136] Step 707: Identify failure categories using a decision tree model.
[0137] When the new system fails to process the processing request, it uses the One-Hot code of the corresponding failure log as input and employs a decision tree model to identify the failure category. The failure category is one of "basic setup failure", "program defect", "information input error" or "unknown exception". When the failure category is "information input error", proceed to step 708; when the failure category is "unknown exception", proceed to step 709; when the failure category is either "basic setup failure" or "program defect", proceed directly to step 710.
[0138] Step 708: Return to the error message.
[0139] When the failure category of the processing failure is "information input error", there is no need to redistribute the processing request to the old system for processing (since it is an information input error, it is difficult to succeed even if it is redistributed to the old system, and it would waste network resources). Instead, the error reason prompt is returned to remind the user to enter the correct information through the client.
[0140] When a processing failure falls under the failure category of "infrastructure failure" or "program defect", the processing request can be redistributed to the old system for processing.
[0141] Step 709: Use the KNN model to identify failure categories.
[0142] When the failure category to which the processing failure belongs is "unknown exception", the KNN model can be used to identify the failure category by taking the semantic vector of the log corresponding to the processing failure as input.
[0143] In this embodiment, the decision tree model based on One-Hot encoding can handle the vast majority of errors (especially known ones), ensuring processing efficiency and strong interpretability and traceability. When the decision tree model based on One-Hot encoding cannot classify (unknown anomalies), a KNN model based on semantic vectors is introduced to identify the failure category of the "unknown anomaly," greatly enhancing the system's ability to generalize to unknown errors. Therefore, the decision tree model based on One-Hot encoding, in conjunction with the KNN model based on semantic vectors, forms a two-level classification pipeline, achieving maximum synergy in processing efficiency, interpretability, and intelligence level for handling failure categories under the parallel architecture of the old and new systems.
[0144] Step 710: Request redistribution to the old system.
[0145] Step 711: The old system processes the request.
[0146] "Old system processing request" means that the old system processes the aforementioned processing request.
[0147] refer to Figure 8 As shown in some other embodiments of this application, the business processing method under the parallel architecture of the old and new systems may further include the following steps:
[0148] Step 801: Assign a globally unique tracking identifier to process the request.
[0149] Upon receiving a processing request, a globally unique trace ID can be assigned to it. This trace ID can be passed throughout the entire lifecycle of the request, regardless of whether it is routed to a new or old system, or how many microservices it calls within the system. The trace ID can be used for root cause analysis after processing failures.
[0150] Step 802: During the process of the new system processing the processing request, record the key information of each span that the processing request passes through, and associate the key information of the span with the tracking identifier.
[0151] Each span traversed by the processing request refers to every microservice, processing component, and / or processing node through which the request is processed. Key span information may include: Span ID, service name, host IP, processing start time, processing end time, processing time, key business identifiers (such as transaction code, account), error messages (if any), and return status. All of this key span information can be collected and stored in real time.
[0152] Step 803: Construct a tree-like call chain based on the span key information associated with the tracking identifier.
[0153] The call chain is constructed in a tree-like structure according to the processing logic order (tree-like call chain). Each node in the tree-like call chain is a processing node (service node), and directed edges represent the dependencies between processing nodes. The attribute information of each processing node includes the aforementioned key span information and Trace ID.
[0154] Step 804: When the new system fails to process the processing request, perform root cause analysis by traversing the tree-like call chain based on the tracing identifier.
[0155] The tree-like call chain clearly displays which services were called to process the request, the order in which the services were called, and the time and status of each service. The Trace ID can be used to locate the corresponding tree-like call chain for the request, and traversing the tree-like call chain can identify the cause of failure.
[0156] For example, when a processing failure is a single-processing failure, the service node (processing node) at the end of the tree-like call chain is identified as the root cause of the processing failure. If the request is successfully processed at the current service node, the processing result will be transferred to the next service node (if any) for further processing according to the processing logic. If the request fails to process at the current service node, the processing result will not be transferred to the next service node (even if there is one), meaning that the processing of the request will terminate at the current service node. Therefore, when a processing failure is a single-processing failure, the service node (processing node) at the end of the tree-like call chain can be identified as the root cause of the processing failure.
[0157] For example, when a processing failure is a multi-processing failure, all processing requests identified as belonging to the same failure category within a specified time window (e.g., within 5 minutes) are aggregated; the root cause corresponding to each of the multiple processing requests is determined, forming a root cause sequence; when the proportion of the root cause sequence pointing to the same service node reaches a threshold, that service node is determined as the root cause of the multiple processing requests. For example, if it is found that these different transactions and different entry points all point to the same service node in their failure call chains (e.g., 70% of the failed transactions timed out or reported errors when calling the "risk control service"), then the "risk control service" can be determined with high confidence as a suspected root cause, rather than simply reporting a large number of independent transaction failures.
[0158] Therefore, based on Figure 8 The illustrated embodiment, under the parallel architecture of the old and new systems, not only achieves maximum synergy in processing efficiency, interpretability, and intelligence level for processing failure categories, but also enables root cause analysis processing based on end-to-end tracing.
[0159] Corresponding to the aforementioned business processing method under the parallel architecture of old and new systems, this application embodiment also provides a business processing apparatus under the parallel architecture of old and new systems, which can be configured on the aforementioned server, see reference. Figure 9 As shown in some embodiments of this application, the service processing apparatus under the parallel architecture of the old and new systems may include:
[0160] Request receiving module 91 is used to receive and process requests;
[0161] The request routing module 92 is used to route the processing request to a target system for processing according to the routing configuration; the target system includes at least one of a new system and an old system.
[0162] The first identification module 93 is used to identify the failure category of the processing failure according to the white-box model when the new system fails to process the processing request.
[0163] The second identification module 94 is used to identify the failure category of the processing failure according to the black box model when the white box model fails to identify the failure category;
[0164] The rerouting decision module 95 is used to decide on the rerouting of the processing request based on the identified failure category.
[0165] Although the process described above includes multiple operations that occur in a specific order, it should be clearly understood that these processes may include more or fewer operations that can be executed sequentially or in parallel (e.g., using parallel processors or a multithreaded environment).
[0166] For ease of description, the above devices are described separately by function as various units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.
[0167] Embodiments of this application also provide a computer device. For example... Figure 10 As shown, in some embodiments of this application, the computer device 1002 may include one or more processors 1004, such as one or more central processing units (CPUs) or graphics processing units (GPUs), each of which may implement one or more hardware threads. The computer device 1002 may also include any memory 1006 for storing any kind of information such as code, settings, data, etc. In one specific embodiment, a computer program on the memory 1006 and executable on the processor 1004, when run by the processor 1004, can execute instructions of the business processing method under the parallel architecture of the new and old systems described in any of the above embodiments. Without limitation, for example, the memory 1006 may include any type of RAM, any type of ROM, flash memory, hard disk, optical disk, etc. More generally, any memory can use any technology to store information. Furthermore, any memory can provide volatile or non-volatile retention of information. Furthermore, any memory may represent a fixed or removable component of the computer device 1002. In one scenario, when processor 1004 executes associated instructions stored in any memory or combination of memories, computer device 1002 can perform any operation of the associated instructions. Computer device 1002 also includes one or more drive mechanisms 1008 for interacting with any memory, such as hard disk drive mechanisms, optical disk drive mechanisms, etc.
[0168] Computer device 1002 may also include an input / output interface 1010 (I / O) for receiving various inputs (via input device 1012) and providing various outputs (via output device 1014). A specific output mechanism may include a presentation device 1016 and an associated graphical user interface 1018 (GUI). In other embodiments, the input / output interface 1010 (I / O), input device 1012, and output device 1014 may be omitted, and the device may function solely as a computer device within a network. Computer device 1002 may also include one or more network interfaces 1020 for exchanging data with other devices via one or more communication links 1022. One or more communication buses 1024 couple the components described above together.
[0169] The communication link 1022 can be implemented in any way, such as via a local area network, a wide area network (e.g., the Internet), a point-to-point connection, or any combination thereof. The communication link 1022 may include any combination of hardwired links, wireless links, routers, gateway functions, name servers, etc., governed by any protocol or combination of protocols.
[0170] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), computer-readable storage media, and computer program products according to some embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processor to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processor, create a machine for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0171] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processor to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0172] These computer program instructions may also be loaded onto a computer or other programmable data processor, causing a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable device for implementing the process. Figure 1One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0173] In a typical configuration, a computer device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.
[0174] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.
[0175] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by computer equipment. As defined in this application, computer-readable media does not include transient media, such as modulated data signals and carrier waves.
[0176] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, embodiments of this application can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of this application can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0177] The embodiments of this application can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. The embodiments of this application can also be practiced in distributed computing environments where tasks are performed by remote processors connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.
[0178] It should also be understood that, in the embodiments of this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.
[0179] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.
[0180] In the description of this application, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of the embodiments of this application. In this application, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described may be combined in a suitable manner in any one or more embodiments or examples. Furthermore, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this application, as well as the features of different embodiments or examples.
[0181] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.
Claims
1. A business processing method under a parallel architecture of old and new systems, characterized in that, include: Receive and process requests; The processing request is routed to the target system for processing according to the routing configuration; The target system includes at least one of a new system and an old system; When the new system fails to process the processing request, it identifies the failure category based on a white-box model, including: converting the original log text corresponding to the processing failure into feature encoding based on a sparse vectorization model; inputting the feature encoding into a decision tree model to obtain a first-level processing failure category; the first-level processing failure category includes one of: program defect, infrastructure failure, information input error, and unknown error; When the white-box model fails to identify the failure category, the black-box model is used to identify the failure category of the processing failure, including: converting the log text corresponding to the processing request failure into a semantic vector according to the dense vectorization model; inputting the semantic vector into the KNN model to obtain the second-level processing failure category; the second-level processing failure category includes one of: program defect, infrastructure failure and information input error; The processing request is rerouted based on the identified failure category.
2. The business processing method as described in claim 1, characterized in that, The step of routing the processing request to the target system for processing according to the routing configuration includes: Identify the request type corresponding to the processing request; When the processing request is a parameter-based request, the processing request will be routed to the new system and the old system for processing; When the processing request is a business request, the traffic distribution configuration is queried according to the business element corresponding to the processing request, and the processing request is distributed to the new system or the old system for processing according to the query result.
3. The business processing method as described in claim 2, characterized in that, The business elements include at least one of the following: Organizational logo; User ID; Channel identification; Transaction code.
4. The business processing method as described in claim 1, characterized in that, The step of rerouting the processing request based on the identified failure category includes: When the failure category is a program defect or infrastructure failure, the processing request will be diverted to the legacy system for processing; When the failure category is "incorrect information input", an error reason message will be returned.
5. The business processing method as described in claim 1, characterized in that, After receiving the processing request, it also includes: Assign a globally unique tracking identifier to the processing request; During the processing of the processing request by the new system, key information of the span of each span traversed by the processing request is recorded, and the key information of the span is associated with the tracking identifier; A tree-like call chain is constructed based on the span key information associated with the tracking identifier; When the new system fails to process the processing request, it performs root cause analysis by traversing the tree-like call chain based on the tracing identifier.
6. The business processing method as described in claim 5, characterized in that, The step of traversing the tree-like call chain based on the tracking identifier to perform root cause analysis includes: When a processing failure is a single processing failure, the service node corresponding to the end of the tree-like call chain is determined as the root cause of the processing failure; When a processing failure is a multiple processing failure, aggregate all processing requests identified as belonging to the same failure category within a specified time window; Determine the root cause corresponding to each of the plurality of processing requests to form a root cause sequence; When the proportion of the root cause sequence pointing to the same service node reaches a threshold, that service node is identified as the root cause of the multiple processing requests.
7. A business processing device under a parallel architecture of old and new systems, characterized in that, include: The request receiving module is used to receive and process requests; The request routing module is used to route the processing request to the target system for processing according to the routing configuration; The target system includes at least one of a new system and an old system; The first identification module is used to identify the failure category of the processing failure according to a white-box model when the new system fails to process the processing request, including: converting the original log text corresponding to the processing failure into feature encoding according to a sparse vectorization model; inputting the feature encoding into a decision tree model to obtain a first-level processing failure category; the first-level processing failure category includes one of: program defect, infrastructure failure, information input error, and unknown error; The second identification module is used to identify the failure category of the processing failure according to the black box model when the white box model fails to identify the failure category. This includes: converting the log text corresponding to the processing request failure into a semantic vector according to the dense vectorization model; inputting the semantic vector into the KNN model to obtain the second-level processing failure category; the second-level processing failure category includes one of the following: program defect, infrastructure failure, and information input error. The rerouting decision module is used to decide on the rerouting of the processing request based on the identified failure category.
8. A computer device comprising a memory, a processor, and a computer program stored in the memory, characterized in that, When the computer program is run by the processor, it executes the instructions of the method according to any one of claims 1-6.