Business request processing method and device based on fusing mechanism, equipment and medium

Abstract

The invention belongs to the field of research and development, and relates to a service request processing method based on a fusing mechanism, comprising: receiving a service request sent by an external system, the request carrying a service parameter including a target service type and an external system priority; and according to the target service type, obtaining the operation state of the corresponding service processing link from the fusing component, and obtaining the current load state of the service processing link at the same time. And fusing judgment is carried out on the service processing link in a target time period by combining the two to obtain a result. If the result is fusing, obtaining a preset degradation strategy according to the priority of the external system, carrying out degradation processing on the service processing link and the service request, and returning a failure prompt; and if the result is not fused, processing the request by the service processing link, and returning a calling result. The invention further provides a device, equipment and a medium. The method and the device can be applied to the business fields of medical treatment, financial science and technology, insurance and the like, and can realize parameter-level business processing link fusing processing.

Description

Technical Field

[0001] The present application relates to the field of R&D technology and is applied to online processing business scenarios such as medical care, financial technology, and insurance, and in particular to a business request processing method, device, equipment, and medium based on a circuit breaker mechanism. Background Art

[0002] In internet software system architecture, interfaces are the core bridges for interaction between different software systems. As software systems in sectors like healthcare, fintech, and insurance continue to expand in scale and become increasingly complex, the same interface often needs to connect to numerous external software systems. These external systems vary significantly across different sectors. For example, within the healthcare sector, the information system technology architectures and privacy protection requirements of different medical institutions differ significantly. Large hospitals may employ advanced distributed architectures, while small clinics may use relatively simple stand-alone systems. In the fintech sector, the business rules and security standards of various financial institutions vary significantly. For example, different banks have different regulations for risk assessment and transaction processes. In the insurance industry, the functional focus and data formats of the core business systems of various insurance companies vary greatly, with some focusing on life insurance and others on property and casualty insurance.

[0003] These differences mean that when handling requests from different external systems, the interface must route requests to different business processing links based on input parameters. However, this architecture is highly susceptible to service performance issues. In the healthcare sector, unstable requests from medical institutions' systems can also place a heavy burden on servers. In FinTech scenarios, if external financial services suffer from poor stability and performance, their requests can overconsume server resources. In the insurance industry, system performance issues at some insurance companies can lead to a large influx of requests, placing pressure on servers. Given limited server resources, excessive consumption can degrade overall service performance and significantly reduce platform processing efficiency, impacting the external services themselves. This can lead to obstacles in patient information query and processing, reduced financial transaction efficiency, and slower policy processing. It can also trigger a chain reaction, affecting integration with other service providers and jeopardizing the stability and reliability of the entire software system. This problem is particularly acute when using thread pools to handle requests. A large influx of requests can quickly fill up the thread pool, preventing new requests from being processed promptly, further deteriorating service performance.

[0004] Currently, most of the degraded and throttling components commonly used in the industry are designed at the interface level. These interface-based degraded and throttling components have limitations. They cannot flexibly break circuits for requests at different parameter levels, making it difficult to precisely control traffic and protect services based on specific business scenarios and request characteristics. They struggle to meet complex and changing business needs and the actual demands of external system environments, and they cannot effectively ensure the stable operation of software systems. Summary of the Invention

[0005] The purpose of the embodiments of the present application is to propose a business request processing method, device, computer equipment and storage medium based on a fuse mechanism to solve the existing problem that it is impossible to flexibly perform fuse processing on the interface routing to different business processing links for requests with different parameter levels to ensure the stability and reliability of the software system.

[0006] First, a method for processing service requests based on a circuit breaker mechanism is provided, which adopts the following technical solutions:

[0007] Receive a business request sent by an external system, which carries business parameters including the target business type and external system priority; based on the target business type, obtain the operating status of the business processing link corresponding to the business request from the fuse component; obtain the current load status of the business processing link, and based on the operating status and load status, perform a fuse judgment on the business processing link in the target time period, and obtain the fuse judgment result of the business processing link in the target time period; if the fuse judgment result is a fuse, obtain the preset degradation strategy according to the external system priority, and based on the degradation strategy, downgrade the business processing link and the business request, and return a prompt message of the request failure to the external system; if the fuse judgment result is not a fuse, call the business processing link to process the business request, obtain the call result, and return the call result to the external system.

[0008] In a second aspect, a service request processing device based on a fuse mechanism is provided, which adopts the following technical solution:

[0009] The receiving module is used to receive business requests sent by external systems. The business requests carry business parameters, which include the target business type and the priority of the external system.

[0010] The acquisition module is used to obtain the running status of the business processing link corresponding to the business request from the circuit breaker component based on the target business type;

[0011] A judgment module is used to obtain the current load status of the business processing link, and based on the operation status and load status, perform a fuse judgment on the business processing link in the target period, and obtain a fuse judgment result of the business processing link in the target period;

[0012] The processing module is used to obtain a preset degradation strategy based on the priority of the external system if the circuit breaker judgment result is a circuit breaker, and based on the degradation strategy, downgrade the service processing link and service request, and return a prompt message of request failure to the external system;

[0013] The calling module is used to call the business processing link to process the business request if the fuse judgment result is not blown, obtain the calling result, and return the calling result to the external system.

[0014] In a third aspect, a computer device is provided, which adopts the following technical solution:

[0015] Receive a business request sent by an external system, which carries business parameters including the target business type and external system priority; based on the target business type, obtain the operating status of the business processing link corresponding to the business request from the fuse component; obtain the current load status of the business processing link, and based on the operating status and load status, perform a fuse judgment on the business processing link in the target time period, and obtain the fuse judgment result of the business processing link in the target time period; if the fuse judgment result is a fuse, obtain the preset degradation strategy according to the external system priority, and based on the degradation strategy, downgrade the business processing link and the business request, and return a prompt message of the request failure to the external system; if the fuse judgment result is not a fuse, call the business processing link to process the business request, obtain the call result, and return the call result to the external system.

[0016] In a fourth aspect, a computer-readable storage medium is provided, which adopts the following technical solution:

[0017] Receive a business request sent by an external system, which carries business parameters including the target business type and external system priority; based on the target business type, obtain the operating status of the business processing link corresponding to the business request from the fuse component; obtain the current load status of the business processing link, and based on the operating status and load status, perform a fuse judgment on the business processing link in the target time period, and obtain the fuse judgment result of the business processing link in the target time period; if the fuse judgment result is a fuse, obtain the preset degradation strategy according to the external system priority, and based on the degradation strategy, downgrade the business processing link and the business request, and return a prompt message of the request failure to the external system; if the fuse judgment result is not a fuse, call the business processing link to process the business request, obtain the call result, and return the call result to the external system.

[0018] Compared with the prior art, the embodiments of the present application mainly have the following beneficial effects: when processing business requests sent by different external systems, the operating status of the corresponding business processing link is obtained according to the target business type in the business parameters, and the fuse judgment of the target time period is performed in combination with the current load status. This dynamic and accurate judgment method can more timely and accurately identify abnormal situations that may occur in the business processing link, and avoid the problem of overall service performance degradation caused by the instability of a certain external service. When the fuse judgment result is a fuse, the preset degradation strategy is obtained according to the priority of the external system for degradation processing, and a request failure prompt message is returned, which not only ensures the stable operation of the core functions of the system, but also provides differentiated processing according to the importance of the external system and reasonably allocates resources. When the fuse is not blown, the request is processed normally and the result is returned, ensuring the normal flow of business. Compared with the existing interface-level degradation and current limiting method, this solution realizes flexible fuse processing for requests of different parameter levels routed to different business processing links on the interface, effectively coping with complex business scenarios and external system environments. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order to more clearly illustrate the solutions in this application, a brief introduction will be given below to the drawings required for use in the description of the embodiments of this application. Obviously, the drawings described below are some embodiments of this application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0020] Figure 1 is an exemplary system architecture diagram to which the present application may be applied;

[0021] Figure 2 A flowchart of an embodiment of a method for processing a service request based on a fuse mechanism according to the present application;

[0022] Figure 3 This is a structural diagram of an embodiment of a service request processing device based on a fuse mechanism according to the present application;

[0023] Figure 4 It is a structural diagram of an embodiment of a computer device according to the present application. DETAILED DESCRIPTION

[0024] Unless otherwise defined, all technical and scientific terms used herein have the same meanings as commonly understood by those skilled in the art to which this application belongs. The terms used in the specification of the application are for the purpose of describing specific embodiments only and are not intended to limit this application. The terms "including" and "having" and any variations thereof in the specification and claims of this application and the above-mentioned drawings are intended to cover non-exclusive inclusions. The terms "first", "second", etc. in the specification and claims of this application or the above-mentioned drawings are used to distinguish different objects, not to describe a specific order.

[0025] References herein to "embodiments" mean that a particular feature, structure, or characteristic described in connection with the embodiments may be included in at least one embodiment of the present application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor does it constitute an independent or alternative embodiment that is mutually exclusive of other embodiments. It is understood, both explicitly and implicitly, by those skilled in the art that the embodiments described herein may be combined with other embodiments.

[0026] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the accompanying drawings.

[0027] like Figure 1 As shown, system architecture 100 may include a terminal device 101, a network 102, and a server 103. Terminal device 101 may be a laptop computer 1011, a tablet computer 1012, or a mobile phone 1013. Network 102 is a medium for providing a communication link between terminal device 101 and server 103. Network 102 may include various connection types, such as wired or wireless communication links or fiber optic cables.

[0028] The user can use the terminal device 101 to interact with the server 103 via the network 102 to receive or send messages, etc. Various communication client applications can be installed on the terminal device 101, such as web browser applications, shopping applications, search applications, instant messaging tools, email clients, social platform software, etc.

[0029] The terminal device 101 can be various electronic devices with a display screen and supporting web browsing. In addition to the laptop computer 1011, tablet computer 1012 or mobile phone 1013, the terminal device 101 can also be an e-book reader, an MP3 player (Moving Picture Experts Group Audio Layer III), an MP4 (Moving Picture Experts Group Audio Layer IV) player, a laptop computer and a desktop computer, etc.

[0030] The server 103 may be a server that provides various services, such as a background server that provides support for web pages displayed on the terminal device 101 .

[0031] It should be noted that the service request processing method based on the fuse mechanism provided in the embodiment of the present application is generally executed by a server / terminal device. Accordingly, the service request processing device based on the fuse mechanism is generally set in the server / terminal device.

[0032] It should be understood that Figure 1 The number of terminal devices, networks and servers in the embodiment is merely illustrative. Any number of terminal devices, networks and servers may be provided as required.

[0033] Continue to refer Figure 2 , shows a flow chart of an embodiment of a method for processing service requests based on a fuse mechanism according to the present application. The method for processing service requests based on a fuse mechanism includes the following steps:

[0034] Step S201: receiving a service request sent by an external system. The service request carries service parameters, and the service parameters include a target service type and an external system priority.

[0035] External systems refer to independent software systems that interact with the target interface of the current internet software system and conduct business transactions. For example, payment systems and logistics systems in e-commerce systems interact with the main e-commerce system as external systems, processing payment and logistics-related business requests, respectively.

[0036] A business request is a request sent by an external system to the target interface of the current internet software system, requesting data and information to perform specific business operations. For example, in an online shopping scenario, a user initiates an order submission request through an external client system. This request is a business request, which allows the e-commerce system to process order creation and other related operations.

[0037] Business parameters are key data carried in business requests that describe the characteristics and details of the business. They represent the specific attributes and requirements of a business request and guide the system in accurately understanding and processing it. For example, in an order submission request, business parameters might include information such as the product ID, purchase quantity, and delivery address. These parameters specify the product the user wishes to purchase and related delivery information.

[0038] The target business type is the business category determined by categorizing business requests based on business parameters. This helps the system quickly locate and invoke the appropriate business processing logic. For example, in an e-commerce system, business requests can be categorized into target business types such as product inquiry, order processing, and payment settlement based on business parameters, allowing the system to perform targeted processing for each type.

[0039] External system priority is an indicator used to measure the importance and business urgency of different external systems within the current system. It is derived from the assessment and configuration of external systems by system administrators or business rules. For example, a higher priority can be assigned to the external systems of core partners to ensure that their business requests are prioritized and critical business operations are carried out smoothly.

[0040] Step S202: Based on the target service type, the running status of the service processing link corresponding to the service request is obtained from the fuse component.

[0041] The circuit breaker component is a functional module or software component used to implement the circuit breaker mechanism in current Internet software systems. It is a component specially developed during system design to ensure system stability and reliability.

[0042] The business processing chain refers to the sequence of module, service, or component calls that a business request passes through from entry to exit in the system. The business processing chain represents the flow path of a business request within the system, clearly illustrating the various steps and dependencies of business processing. For example, in the business processing chain of a user registration request, the user authentication service, data storage service, message notification service, and other modules may be sequentially passed through to complete the entire user registration process.

[0043] The operating status refers to the working state of the service processing link at a specific moment. The operating status can be normal, semi-broken, or broken. It is derived from the real-time monitoring and judgment of the service processing link by the circuit breaker component.

[0044] Step S203 , obtaining the current load status of the service processing link, and performing a fuse judgment on the service processing link in a target period based on the operation status and the load status, to obtain a fuse judgment result of the service processing link in the target period.

[0045] The load status refers to the current business pressure and resource usage of the business processing link. It is used to assist the system in making circuit breakers and resource allocation decisions.

[0046] The target period refers to a specific time interval set when making a circuit breaker judgment, which is used to determine whether a circuit breaker operation needs to be performed on the service processing link within the time period.

[0047] Among them, the fuse judgment is an evaluation and decision-making process based on the operating status and load status of the business processing link to determine whether the business processing link needs to be fused within the target time period.

[0048] The circuit breaker result is the conclusion, drawn after the circuit breaker process, on whether the service processing link is broken. For example, the circuit breaker result may be broken or not broken. Depending on the result, the system will implement corresponding processing strategies, such as downgrading for broken results and processing service requests normally for non-broken results.

[0049] Step S204: If the fuse judgment result is blown, a preset degradation strategy is obtained according to the priority of the external system, and based on the degradation strategy, the service processing link and the service request are downgraded, and a prompt message of request failure is returned to the external system.

[0050] Among them, circuit breaking refers to a protection mechanism in which the system actively cuts off the business processing link and stops processing new business requests when the business processing link meets specific conditions.

[0051] Among them, the degradation strategy is a series of processing rules and methods pre-set to ensure the overall availability of the system when the business processing link is broken.

[0052] Among them, degradation processing is a series of operations taken on service requests and service processing links according to the degradation policy when the service processing link is broken.

[0053] When a service processing link is disconnected, the system returns a prompt to the external system to explain the current status and guide user operations. For example, when a service processing link is disconnected, the system may return a prompt message such as "Current service is busy, please try again later," informing the external system that the request is currently unavailable and suggesting that it try again after a while.

[0054] Step S205: If the fuse judgment result is not blown, the service processing link is called to process the service request, a call result is obtained, and the call result is returned to the external system.

[0055] Among them, no melting means that within the target period, after the melting judgment, the system believes that the business processing link is in normal working condition, there is no need to cut off the link, and the business request can continue to be processed normally.

[0056] The call result is the data or status information returned by the business processing link after processing the business request. It is used to feed back to the external system to inform it of the processing status of the business request.

[0057] When processing business requests sent by different external systems, the embodiment of the present application obtains the operating status of the corresponding business processing link based on the target business type in the business parameters, and performs a fuse judgment for the target time period in combination with the current load status. This dynamic and accurate judgment method can more timely and accurately identify abnormal situations that may occur in the business processing link, and avoid the problem of overall service performance degradation caused by the instability of a certain external service. When the fuse judgment result is a fuse, the preset degradation strategy is obtained according to the priority of the external system for degradation processing, and a request failure prompt message is returned, which not only ensures the stable operation of the core functions of the system, but also provides differentiated processing according to the importance of the external system and reasonably allocates resources. When the fuse is not blown, the request is processed normally and the result is returned, ensuring the normal flow of business. Compared with the existing interface-level degradation and current limiting method, this solution realizes flexible fuse processing for requests of different parameter levels routed to different business processing links on the interface, effectively coping with complex business scenarios and external system environments.

[0058] In some optional implementations of this embodiment, step S202, based on the target service type, obtains the running status of the service processing link corresponding to the service request from the circuit breaker component, specifically including the following steps:

[0059] Through the thread pool inside the circuit breaker component, an asynchronous merge counting operation is performed on the interface call result data reported to the circuit breaker component, and the interface call result data corresponding to each business type in the same second are accumulated according to the status type to obtain second-granularity data; based on the business request, the target time period is determined, and the data monitoring mechanism is triggered by the circuit breaker component to extract the new interface call result data corresponding to the target business type reported to the circuit breaker component before the target time period; the target second-granularity data corresponding to the target business type is obtained from the second-granularity data; based on the target second-granularity data and the new interface call data, the operating status of the business processing link in the target time period is calculated.

[0060] The thread pool is a mechanism used within the circuit breaker component to manage and schedule thread resources. For example, when the circuit breaker component needs to merge and count a large number of API call result data, the thread pool can allocate appropriate threads to handle these tasks in parallel, improving data processing efficiency.

[0061] The asynchronous mode refers to a data processing mode that does not block the current thread when performing the merge counting operation of the interface call result data, and allows the thread to continue processing other tasks while executing the operation.

[0062] Interface call result data refers to the data related to the execution status of the interface call that is fed back to the circuit breaker component after the external system calls the interface. For example, in an e-commerce system, when the user order interface is called, the data returned, such as the order creation success or failure information and the processing time, is interface call result data.

[0063] The merge count operation is the process of aggregating and counting the API call result data reported to the circuit breaker component through the thread pool. For example, accumulating the number of successful and failed order query calls in all order query APIs within one second is an example of a merge count operation.

[0064] The status type refers to the different status categories of the interface call execution reflected in the interface call result data. It is used to distinguish different situations such as the success, failure, and timeout of the interface call. For example, the status type in the interface call result data may include "success," "failure," "timeout," "partial success," etc. These status types can help the system quickly understand the execution status of the interface call.

[0065] Accumulation refers to the process of adding up the interface call result data corresponding to each business type within the same second according to the status type during the combined counting operation. For example, the number of successful payment calls in all order payment interfaces within one second can be accumulated to obtain the total number of successful order payment interface calls in that second.

[0066] Among them, second-granularity data refers to statistical data obtained by accumulating the interface call result data corresponding to each business type within the same second according to the status type, with seconds as the time unit.

[0067] The target time period refers to the time interval that requires focus and analysis when calculating the operational status of the service processing link. It is used to determine the operational status of the service processing link within a specific time period.

[0068] The data monitoring mechanism refers to a series of operations and rules triggered by the circuit breaker component that are used to extract and analyze interface call result data in real time or periodically. It is used to detect interface calls instantly or cyclically, extracting new interface call result data corresponding to the target business type. For example, the data monitoring mechanism can be set to trigger detection instantly (immediately when new data is reported) and cyclic detection (detection is performed at regular intervals) to ensure timely acquisition of the latest interface call information.

[0069] The new interface call result data refers to the interface call result data corresponding to the target business type and reported to the circuit breaker component before the target time period.

[0070] The target second-granularity data refers to second-granularity statistical data corresponding to the target service type obtained from the second-granularity data.

[0071] In one example, in the fintech field, consider an online payment system. This system has an online payment interface that handles payment requests from various business types, such as bank card payments and payments through third-party payment platforms (such as WeChat Pay and Alipay). A thread pool within the circuit breaker component asynchronously aggregates and counts the interface call result data reported to the circuit breaker component. Within the same second, the interface call result data corresponding to each business type, such as bank card payment, WeChat Pay, and Alipay payment, is accumulated according to status type (success, failure, or timeout) to generate second-granularity data. For example, if within a given second, bank card payments succeed 100 times, fail 5 times, and time out 2 times; WeChat payments succeed 80 times, fail 3 times, and time out 1 timeout; and Alipay payments succeed 120 times, fail 4 times, and time out 3 times, these data will all be accumulated into second-granularity data. Based on the business request, the target time period is determined to be the time period before the business request is received. For example, one second before the business request is received, new interface call result data within the target time period has not yet been converted to second-granularity data. The circuit breaker component triggers a data monitoring mechanism to extract new interface call result data corresponding to the target business type (e.g., bank card payment) reported to the circuit breaker component before the target time period. This interface call result data is not included in the interface call result data corresponding to the second-granularity data. The target second-granularity data corresponding to the bank card payment is obtained from the second-granularity data. Based on the target second-granularity data and the new interface call data, the operational status of the bank card payment business processing link within the target time period is calculated.

[0072] In one example, in the medical field, consider a hospital registration system. This system has a hospital registration interface that handles registration requests for various service types, such as general outpatient, specialist outpatient, and emergency room registrations. The thread pool of the circuit breaker component can asynchronously aggregate and count the reported interface call result data. Within the same second, the interface call result data corresponding to each service type, such as general outpatient, specialist outpatient, and emergency room registrations, is accumulated by status type (registration successful, registration failed, and queued) to obtain second-granularity data. For example, within a given second, general outpatient registrations succeed 200 times, fail 10 times, and are queued 5 times. Based on the registration requests, a target time period is determined. The circuit breaker component triggers a data monitoring mechanism to extract new interface call result data for the target service type (e.g., specialist outpatient registration) reported before the target time period. Target second-granularity data corresponding to specialist outpatient registrations is obtained from the second-granularity data. Based on the target second-granularity data and the new interface call data, the operating status of the specialist outpatient registration service processing link within the target time period is calculated.

[0073] In one example, in the financial insurance sector, consider an insurance claims system. This system has an insurance claims interface that handles claims requests for various business types, such as auto insurance claims, health insurance claims, and accident insurance claims. A circuit breaker component can asynchronously aggregate and count reported interface call result data using a thread pool. Within the same second, the interface call result data corresponding to each business type, such as auto insurance claims, health insurance claims, and accident insurance claims, is accumulated by status type (claim successful, claim failed, or under review) to generate second-granularity data. For example, within a given second, there may be 50 successful auto insurance claims, 2 failed, and 3 under review; and 30 successful health insurance claims, 1 failed, and 2 under review. Based on the business requests, a target time period is determined. The circuit breaker component triggers a data monitoring mechanism to extract new interface call result data for the target business type (e.g., auto insurance claims) reported before the target time period. The target second-granularity data corresponding to auto insurance claims is then obtained from the second-granularity data. Based on the target second-granularity data and new interface call data, calculate the operating status of the auto insurance claims processing link within the target time period.

[0074] The embodiment of the present application can perform a merge counting operation on the interface call result data in an asynchronous manner by utilizing the internal thread pool of the fuse component, and accumulate the data of different business types in the same second according to the status type to obtain second-granularity data. This operation realizes the efficient integration and preliminary analysis of massive interface call data, ensuring the timeliness and accuracy of data statistics. Based on the business request, the target time period is determined and the data monitoring mechanism is triggered, and the new interface call result data corresponding to the target business type is accurately extracted to further focus on the analysis. The target second-granularity data is obtained from the second-granularity data, and the running status of the business processing link is calculated in combination with the new interface call data, which can comprehensively and dynamically reflect the actual operation of the business processing link within the target time period.

[0075] In some optional implementations, the step of “accumulating the interface call result data corresponding to each service type within the same second according to the state type to obtain second-granularity data” specifically includes the following steps:

[0076] Extract second-level time information from the timestamp of the interface call result data; create a data structure for each business type to store data with second-level time as the key and status type count as the value; traverse the interface call result data one by one, and classify the interface call result data into the data structure of the corresponding business type according to the business type identifier in the data; update the corresponding count according to the call status of the interface call result data in the data container of each business type; after completing the traversal and count accumulation of all interface call result data, organize the data structure to obtain second-granularity data.

[0077] Second-level time information is extracted from the timestamp of the interface call result data, with a time identifier accurate to the second. For example, in an interface call record, the timestamp is "2024-07-15 14:30:45.678", and the extracted second-level time information is "2024-07-15 14:30:45". This information clearly indicates that the interface call occurred within this second, facilitating subsequent second-by-second data statistics and analysis.

[0078] The data structure is created for each business type and is used to store the logical organization of data in a specific format.

[0079] Using second-level time as a key means that in the data structure created for each business type, second-level time information is used as the key to identify the data storage location. For example, in a storage structure based on a hash table, the key is "2024-07-15 14:30:45", which can be used to quickly find the interface call result data set for the corresponding business type within that second.

[0080] The data with status type count as the value refers to data in the data structure that records the number of interface call results of different status types, with second-level time as the key. For example, in the above hash table, the key "2024-07-15 14:30:45" may correspond to the value "{Success: 10, Failure: 2, Timeout: 1}", indicating that the number of successful order creation interface calls in that second was 10, the number of failures was 2, and the number of timeouts was 1.

[0081] The call status refers to the status of the interface call execution process reflected by the interface call result data. For example, the call status in the interface call result data may include "success", "failure", "timeout", "partial success", etc.

[0082] Counting refers to the operation of incrementing the corresponding status type based on the call status of the interface call result data in each business type's data structure. For example, when processing the order creation interface call result data, when encountering a data entry with a call status of "success", the corresponding "success" status count in the business type data structure at the second-level time is incremented by 1. This counting operation can generate interface call status statistics for each business type at different second-level time points.

[0083] Sorting refers to a series of optimization and normalization operations performed on the data structure after traversing and counting all interface call result data. For example, after counting and accumulating all data, the data structure is checked to remove any duplicate or erroneous data, and the data is sorted and stored according to a specific format to obtain second-level data that is convenient for subsequent analysis and presentation.

[0084] In one example, in the fintech sector, a bank's online loan approval system has a core interface for processing approval requests for various loan types, such as personal consumption loans and small and micro-enterprise loans. The system receives a large number of loan approval requests daily and needs to process the interface call result data to analyze system performance and business conditions. Second-level time information is extracted from the timestamp of the interface call result data. For example, if the timestamp of a loan approval interface call result is "2024-07-20 10:15:23.456," the extracted second-level time information is "2024-07-20 10:15:23." Separate data structures are created for personal consumption loans and small and micro-enterprise loans to store data with second-level time as the key and status type counts as the value. For example, a hash table is created for personal consumption loans, with the key being the second-level time and the value being an object containing status type counts such as "success," "failure," and "under review." The interface call result data is traversed one by one, and the data is classified into the corresponding data structure based on the business type identifier in the data. For example, if the business type of a piece of data is identified as "Personal Consumer Loans," it is classified into the hash table for Personal Consumer Loans. Based on the call status of the interface call result data in each business type's data structure, the corresponding count is updated. If the approval result of a personal consumer loan is "Successful," the corresponding "Success" status count at the second level is incremented by 1. After traversing and accumulating counts for all interface call result data, the data structure is organized to remove possible duplicates or errors, resulting in second-granular data.

[0085] The embodiment of the present application can lay the foundation for accurate second-by-second statistics of subsequent data by extracting second-level time information from the interface call result data timestamp. A specific data structure is created for each business type, and data is stored with second-level time as the key and status type count as the value, thereby achieving efficient organization and classification of data. The data is traversed one by one and classified into the corresponding business type data structure to ensure accurate data placement. The corresponding count is updated according to the call status to achieve quantitative statistics of the interface call results. After completing the traversal and count accumulation, the data structure is sorted to obtain second-granularity data, which can clearly reflect the interface call status distribution of each business type in each second.

[0086] In some optional implementations, the step of “calculating the operating status of the service processing link within the target time period based on the target second-granularity data and the new interface call data” specifically includes the following steps:

[0087] Based on the target time period, determine the start time and end time of the merge window; merge the target second-granularity data and the data in the new interface call data that belong to the start time to the end time to obtain the merged data; based on the merged data, use the preset exception rate formula to calculate the exception rate within the merge window; obtain the preset fuse threshold range, compare the exception rate and the fuse threshold, and based on the comparison result, determine the operating status of the business processing link corresponding to the target business type.

[0088] The merging window is a specific time interval determined based on the target time period and is used to merge related data.

[0089] The merged data refers to the data set obtained by integrating the target second-granularity data and the data in the new interface call data that fall within the start time to the end time of the merge window.

[0090] The anomaly rate formula is a pre-set mathematical expression used to calculate the anomaly rate within the merged window. For example, the anomaly rate formula can be: "Anomaly rate = (number of abnormal interface calls / total number of interface calls) × 100%." ​​Using this formula, the number of abnormal interface calls and the total number of interface calls obtained within the merged window can be substituted into the calculation to obtain the anomaly rate of interface calls within that period.

[0091] Among them, the abnormality rate is obtained by calculating the merged data using the abnormality rate formula, and is an indicator used to measure the degree of abnormality of interface calls within the merge window.

[0092] The fuse threshold range is a set of pre-set value ranges used to compare with the abnormality rate to determine whether to trigger the fuse mechanism.

[0093] The comparison result is a conclusion obtained by comparing the calculated abnormality rate with the preset fuse threshold range.

[0094] In one example, in the fintech sector, a payment platform has an online payment interface that connects to numerous external merchant systems and processes various payment transactions, such as product purchases and service subscriptions. Due to differences in the business requirements, technical architecture, and operating environment of different merchant systems, the interface needs to route requests to different business processing links based on input parameters. In actual operation, a merchant system may experience poor stability, leading to a large influx of abnormal requests, impacting the performance of the entire payment platform. Based on the received business requests, a target time period is determined. The target second-granularity data and the new interface call data falling within the target time period are merged to generate merged data. For example, the merged data includes detailed statistical information and specific request records for each merchant's payment interface call during that time period. Based on this merged data, the default exception rate formula ("Exception rate = (number of failed interface calls + number of timed-out interface calls) / total number of interface calls × 100%) is used to calculate the exception rate within the merged window. Assuming a total of 1,000 interface calls, 30 failures, and 20 timeouts during that time period, the exception rate is 5%. A preset fuse threshold range of 3%-8% is obtained, the abnormal rate of 5% is compared with the fuse threshold range, and based on the comparison result, the operating status of the service processing link corresponding to the target service type is determined.

[0095] The embodiment of the present application determines the merge window based on the target time period, which can accurately focus on the interface call data within a specific time period and avoid interference from irrelevant data. The target second-granularity data and the data in the merge window in the new interface call data are merged to achieve effective data integration and provide a comprehensive and accurate data basis for subsequent analysis. The preset abnormality rate formula is used to calculate the abnormality rate within the merge window, which can quantify the degree of abnormality of the interface call and intuitively reflect the operating health of the system in this period. Obtaining the preset fuse threshold range and comparing it with the abnormality rate can make accurate judgments based on specific business scenarios and request characteristics. Based on the comparison results, the operating status of the business processing link corresponding to the target business type is determined, potential problems can be discovered in a timely manner, and the stable operation of the entire software system can be guaranteed.

[0096] In some optional implementations, the step of “determining the operating status of the service processing link corresponding to the target service type based on the comparison result” specifically includes the following steps:

[0097] If the abnormality rate is less than the minimum value of the fuse threshold range, the operating status of the business processing link corresponding to the target business type is determined to be normal; if the abnormality rate is within the fuse threshold range, the operating status of the business processing link corresponding to the target business type is determined to be semi-fuse state; if the abnormality rate is greater than the maximum value of the fuse threshold range, the operating status of the business processing link corresponding to the target business type is determined to be fuse state.

[0098] Normal status refers to the operational status of a service processing link, determined by comparing the anomaly rate with the circuit-breaking threshold. This status indicates that the service processing link corresponding to the target service type is operating smoothly within the target time period, that interface calls are processed normally, and that no significant performance issues or anomalies occur.

[0099] The "partially blown" state is a service processing link operating state determined when the anomaly rate is within the blow threshold. This indicates that the service processing link corresponding to the target service type has experienced some anomalies, but has not yet reached the point of a complete blow.

[0100] The "fuse-broken" state is determined when the exception rate exceeds the maximum value within the "fuse-broken" threshold. This indicates a serious anomaly in the service processing link corresponding to the target service type. Continuing to process requests could lead to a sharp drop in system performance or even a system crash.

[0101] In one example, based on the merged data, the preset exception rate formula "Exception rate = (number of failed interface calls + number of timed interface calls) / total number of interface calls" is used.

[0102] ×100%", after calculating the exception rate within the merged window. For example, assuming that the total number of interface calls in the period is 1000, with 30 failures and 20 timeouts, the exception rate is 5%. Assume that the preset fuse threshold range is 3%-8%. The exception rate of 5% can be compared with the fuse threshold range. If the result is that the exception rate is within the threshold range, it means that the operation status of the business processing link corresponding to the target business type is semi-fuse. Assuming the exception rate is 2% and the fuse threshold range is 3%-8%, the operation status of the business processing link corresponding to the target business type is normal; assuming the exception rate is 10% and the fuse threshold range is 3%-8%, the operation status of the business processing link corresponding to the target business type is fuse.

[0103] In the embodiment of the present application, when the abnormality rate is less than the minimum value of the fuse threshold range, it is determined to be in a normal state, indicating that the interface business processing link is operating well, the system can process requests normally, and ensure the efficient operation of the business. When the abnormality rate is within the fuse threshold range, it is determined to be in a semi-fuse state, which not only reminds the operation and maintenance personnel to pay attention to potential problems, but also prevents the abnormal situation from worsening by limiting the processing of some requests. When the abnormality rate is greater than the maximum value of the fuse threshold range, it is determined to be in a fuse state, which can prompt the fuse of the corresponding business processing link and the corresponding business request, and can effectively protect the stability and reliability of the entire software system.

[0104] In some optional implementations, step S203, based on the operating state and the load state, performs a fuse determination on the service processing link for the target period, and obtains a fuse determination result of the service processing link for the target period, specifically including the following steps:

[0105] Obtain the preset fuse judgment rule, and based on the fuse judgment rule, if the operating status is the fuse state, determine that the fuse judgment result of the business processing link in the target time period is blown; if the operating status is the semi-fuse state or the normal state, perform a fuse judgment on the business processing link in the target time period based on the load status; if the load status is low load, determine that the fuse judgment result of the business processing link in the target time period is not blown; if the load status is medium load, then when the operating status is normal, determine that the fuse judgment result of the business processing link in the target time period is not blown, and when the operating status is the semi-fuse state, randomly judge the fuse judgment result of the business processing link in the target time period according to a preset ratio; if the load status is high load, then when the operating status is normal, determine that the fuse judgment result of the business processing link in the target time period is not blown, and when the operating status is the semi-fuse state, determine that the fuse judgment result of the business processing link in the target time period is blown.

[0106] The fuse judgment rule is a series of pre-set judgment conditions and logic used to determine whether a service processing link should be subjected to a fuse operation within a target period.

[0107] Here, low load refers to a state in which the service request pressure and resource occupancy borne by the service processing link in the current period are at a low level.

[0108] Among them, medium load refers to a state in which the business request pressure and resource usage borne by the system or business processing link in the current period are at a medium level.

[0109] The preset ratio is a preset ratio value used to randomly determine whether the service processing link is blown in the target time period when the load is medium and the operating state is a semi-blown state.

[0110] High load refers to a state in which the system or business processing link is subjected to a high level of business request pressure and resource usage during a target period.

[0111] In one example, in the fintech sector, a securities trading platform provides a trading interface that connects to multiple external trading systems, such as third-party trading software and financial information platforms. The business requirements and technical architectures of these external systems vary significantly, and the interface must route requests to different business processing links based on input parameters. Based on business experience and system resource availability, pre-set circuit breaker judgment rules are established. When the operating status is "circuit-broken," the business processing link is directly determined to be circuit-broken during the target period. When the operating status is "partially circuit-broken" or "normal," further judgment is made based on load conditions. When the load is low, regardless of whether the operating status is semi-broken or normal, the business processing link is determined to be not blown during the target time period, and the business request is allowed to pass, and the business processing link is called to process the request; when the load is medium, when the operating status is normal, the business processing link is determined to be not blown during the target time period, and the business request is allowed to pass. When the operating status is semi-broken, it is randomly determined according to the preset ratio whether to allow the request to pass; when the load is high, when the operating status is normal, the business processing link is determined to be not blown during the target time period, and the business request is allowed to pass, and the business processing link is called to process the request. When the operating status is semi-broken, it is determined that the business processing link is blown during the target time period.

[0112] The embodiment of the present application directly determines that the circuit is blown when the operating state is the blown state, which can quickly cut off the corresponding business request and avoid excessive consumption of server resources. When the operating state is the semi-fuse state or the normal state, the judgment is made according to the load state: no circuit is blown under low load, ensuring normal business processing and making full use of system resources; under medium load, the normal state does not blow, and the semi-fuse state is randomly judged according to the preset ratio, which not only gives the system a certain buffer but also flexibly controls the flow; under high load, the semi-fuse state directly blows to prevent the system from overload and crash, and the normal state does not blow. It can achieve accurate decision-making for different situations, flexibly carry out circuit breaking processing, effectively respond to complex and changing business needs and external system environments, and ensure the stable operation of the software system.

[0113] In some optional implementations, in step S205, if the fuse determination result is not blown, the service processing link is called to process the service request. After obtaining the call result, the following steps are further included:

[0114] The call result is sent to the fuse component as the interface call result data of the business request, so that the fuse component can dynamically adjust the running status of the business processing link.

[0115] In one example, in the fintech sector, a bank's online loan approval system provides a loan approval interface that connects to the systems of multiple external partner institutions, such as third-party credit assessment platforms and fintech data service companies. Different partner institutions have different business requirements, data quality, and call frequency. Therefore, the interface needs to route requests to different business processing links based on input parameters. A loan approval request is received from the external partner institution's system. This request carries business parameters, including the target business type (e.g., personal consumer loan approval) and the external system priority (e.g., set based on the partner institution's scale and historical collaboration history). Based on the target business type, the operating status of the business processing link corresponding to the request is retrieved from the circuit breaker component, assuming that the operating status is normal. The current load status of the business processing link, such as CPU usage and memory utilization, is retrieved. Based on the operating status and load status, a circuit breaker determination is performed on the business processing link for the target time period, resulting in a circuit breaker determination of "not tripping." The business processing link is then called to process the request, performing loan approval-related operations, such as credit assessment and risk calculation, and obtaining the call result (e.g., approval or rejection). The call result is sent to the fuse component as the interface call result data of the business request, and the call result is returned to the external cooperative organization system. After the fuse component receives the interface call result data, it dynamically adjusts the operating status of the business processing link based on the received interface call result data.

[0116] In the embodiment of the present application, in an architecture where multiple external systems are connected to the same interface and routed to different business processing links, different external systems behave differently. Based on the received interface call result data, the fuse component can fully understand the actual situation of each business processing link processing different business requests. Based on the received interface call result data, the fuse component dynamically adjusts the operating status of the business processing link, and can achieve flexible fuse processing for requests of different parameter levels and corresponding business processing links, realize precise flow control and service protection, and ensure stable system operation.

[0117] It should be emphasized that in order to further ensure the privacy and security of the above-mentioned business parameters, operating status, data load status, prompt information and call results, the above-mentioned component business parameters, operating status, data load status, prompt information and call results can also be stored in a blockchain node.

[0118] The blockchain referred to in this application is a new application model for computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. Blockchain is essentially a decentralized database, a series of data blocks generated using cryptographic methods. Each data block contains information about a batch of network transactions, which is used to verify the validity of this information (to prevent counterfeiting) and generate the next block. Blockchain can include the underlying blockchain platform, the platform product service layer, and the application service layer.

[0119] Those skilled in the art will appreciate that all or part of the processes in the above-described method embodiments can be implemented by instructing related hardware via computer-readable instructions. The computer-readable instructions can be stored in a computer-readable storage medium, and when the program is executed, it can include the processes in the above-described method embodiments. The aforementioned storage medium can be a non-volatile storage medium such as a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

[0120] It should be understood that although the steps in the flowcharts of the accompanying drawings are shown in sequence as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some of the steps in the flowcharts of the accompanying drawings may include multiple sub-steps or multiple stages, and these sub-steps or stages are not necessarily executed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be executed in turn or alternately with other steps or at least a portion of the sub-steps or stages of other steps.

[0121] Further references Figure 3 , as a response to the above Figure 2 The present application provides an embodiment of a service request processing device based on a fuse mechanism. Figure 2 Corresponding to the method embodiment shown, the device can be specifically applied to various electronic devices.

[0122] like Figure 3 As shown, the service request processing device 400 based on the fuse mechanism of this embodiment includes: a receiving module 401, an acquisition module 402, a judgment module 403, a processing module 404 and a calling module 405. Among them:

[0123] Receiving module 401, configured to receive a service request sent by an external system, the service request carrying service parameters including target service type and external system priority;

[0124] The acquisition module 402 is used to obtain the running status of the service processing link corresponding to the service request from the fuse component based on the target service type;

[0125] The judgment module 403 is used to obtain the current load status of the service processing link, and based on the operation status and load status, perform a fuse judgment on the service processing link in the target period, and obtain a fuse judgment result of the service processing link in the target period;

[0126] Processing module 404 is configured to, if the circuit breaker judgment result is a circuit breaker, obtain a preset degradation strategy based on the external system priority, degrade the service processing link and service request based on the degradation strategy, and return a prompt message indicating the request failure to the external system;

[0127] The calling module 405 is used to call the service processing link to process the service request if the fuse judgment result is not blown, obtain the calling result, and return the calling result to the external system.

[0128] In this embodiment, when processing business requests sent by different external systems, the operating status of the corresponding business processing link is obtained based on the target business type in the business parameters, and the fuse judgment of the target time period is performed in combination with the current load status. This dynamic and accurate judgment method can more timely and accurately identify abnormal situations that may occur in the business processing link, and avoid the problem of overall service performance degradation caused by the instability of a certain external service. When the fuse judgment result is a fuse, the preset degradation strategy is obtained according to the priority of the external system for degradation processing, and a request failure prompt message is returned, which not only ensures the stable operation of the core functions of the system, but also provides differentiated processing according to the importance of the external system and reasonably allocates resources. When the fuse is not blown, the request is processed normally and the result is returned, ensuring the normal flow of business. Compared with the existing interface-level degradation and current limiting method, this solution realizes flexible fuse processing for requests of different parameter levels routed to different business processing links on the interface, effectively coping with complex business scenarios and external system environments.

[0129] In one embodiment, the acquisition module 402 includes:

[0130] The execution submodule is used to perform a merge counting operation on the interface call result data reported to the circuit breaker component in an asynchronous manner through the thread pool inside the circuit breaker component. The interface call result data corresponding to each business type in the same second is accumulated according to the status type to obtain second-granularity data.

[0131] The extraction submodule is used to determine the target time period based on the business request, and trigger the data monitoring mechanism through the circuit breaker component to extract the new interface call result data corresponding to the target business type reported to the circuit breaker component before the target time period;

[0132] The acquisition submodule is used to obtain the target second-granularity data corresponding to the target business type from the second-granularity data;

[0133] The calculation submodule is used to calculate the operating status of the business processing link within the target time period based on the target second-granularity data and the new interface call data.

[0134] The embodiment of the present application can perform a merge counting operation on the interface call result data in an asynchronous manner by utilizing the internal thread pool of the fuse component, and accumulate the data of different business types in the same second according to the status type to obtain second-granularity data. This operation realizes the efficient integration and preliminary analysis of massive interface call data, ensuring the timeliness and accuracy of data statistics. Based on the business request, the target time period is determined and the data monitoring mechanism is triggered, and the new interface call result data corresponding to the target business type is accurately extracted to further focus on the analysis. The target second-granularity data is obtained from the second-granularity data, and the running status of the business processing link is calculated in combination with the new interface call data, which can comprehensively and dynamically reflect the actual operation of the business processing link within the target time period.

[0135] In one embodiment, the execution submodule is also used to extract second-level time information from the timestamp of the interface call result data; create a data structure for each business type to store data with second-level time as the key and status type count as the value; traverse the interface call result data one by one, and classify the interface call result data into the data structure of the corresponding business type according to the business type identifier in the data; update the corresponding count according to the call status of the interface call result data in the data container of each business type; after completing the traversal and count accumulation of all interface call result data, organize the data structure to obtain second-granularity data.

[0136] The embodiment of the present application can lay the foundation for accurate second-by-second statistics of subsequent data by extracting second-level time information from the interface call result data timestamp. A specific data structure is created for each business type, and data is stored with second-level time as the key and status type count as the value, thereby achieving efficient organization and classification of data. The data is traversed one by one and classified into the corresponding business type data structure to ensure accurate data placement. The corresponding count is updated according to the call status to achieve quantitative statistics of the interface call results. After completing the traversal and count accumulation, the data structure is sorted to obtain second-granularity data, which can clearly reflect the interface call status distribution of each business type in each second.

[0137] In one embodiment, the calculation submodule is also used to determine the start time and end time of the merge window based on the target time period; merge the target second-granularity data and the data in the new interface call data belonging to the start time to the end time to obtain the merged data; based on the merged data, use the preset exception rate formula to calculate the exception rate within the merged window; obtain the preset fuse threshold range, compare the exception rate and the fuse threshold, and determine the operating status of the business processing link corresponding to the target business type based on the comparison result.

[0138] The embodiment of the present application determines the merge window based on the target time period, which can accurately focus on the interface call data within a specific time period and avoid interference from irrelevant data. The target second-granularity data and the data in the merge window in the new interface call data are merged to achieve effective data integration and provide a comprehensive and accurate data basis for subsequent analysis. The preset abnormality rate formula is used to calculate the abnormality rate within the merge window, which can quantify the degree of abnormality of the interface call and intuitively reflect the operating health of the system in this period. Obtaining the preset fuse threshold range and comparing it with the abnormality rate can make accurate judgments based on specific business scenarios and request characteristics. Based on the comparison results, the operating status of the business processing link corresponding to the target business type is determined, potential problems can be discovered in a timely manner, and the stable operation of the entire software system can be guaranteed.

[0139] In one embodiment, the calculation submodule is also used to determine that the operating status of the business processing link corresponding to the target business type is normal if the abnormality rate is less than the minimum value of the fuse threshold range; if the abnormality rate is within the fuse threshold range, then the operating status of the business processing link corresponding to the target business type is semi-fuse state; if the abnormality rate is greater than the maximum value of the fuse threshold range, then the operating status of the business processing link corresponding to the target business type is fuse state.

[0140] In the embodiment of the present application, when the abnormality rate is less than the minimum value of the fuse threshold range, it is determined to be in a normal state, indicating that the interface business processing link is operating well, the system can process requests normally, and ensure the efficient operation of the business. When the abnormality rate is within the fuse threshold range, it is determined to be in a semi-fuse state, which not only reminds the operation and maintenance personnel to pay attention to potential problems, but also prevents the abnormal situation from worsening by limiting the processing of some requests. When the abnormality rate is greater than the maximum value of the fuse threshold range, it is determined to be in a fuse state, which can prompt the fuse of the corresponding business processing link and the corresponding business request, and can effectively protect the stability and reliability of the entire software system.

[0141] In one embodiment, the determination module 403 includes:

[0142] A first determination submodule is configured to obtain a preset fuse judgment rule and, based on the fuse judgment rule, determine that the fuse judgment result of the service processing link in the target time period is fuse if the operation state is fuse;

[0143] A judgment submodule, configured to judge the fuse of the service processing link for a target period based on the load status if the operating status is a semi-fuse state or a normal state;

[0144] A second determining submodule is configured to determine that a fuse determination result of the service processing link in the target time period is not blown if the load state is low load;

[0145] A third determination submodule is configured to, if the load state is medium load, determine that the fuse judgment result of the service processing link in the target time period is not blown when the operation state is normal, and to randomly determine the fuse judgment result of the service processing link in the target time period according to a preset ratio when the operation state is semi-blow;

[0146] The fourth determination submodule is used to determine that if the load state is high load, when the operating state is normal, the fuse judgment result of the business processing link in the target time period is not blown; when the operating state is semi-blown, the fuse judgment result of the business processing link in the target time period is blown.

[0147] The embodiment of the present application directly determines that the circuit is blown when the operating state is the blown state, which can quickly cut off the corresponding business request and avoid excessive consumption of server resources. When the operating state is the semi-fuse state or the normal state, the judgment is made according to the load state: no circuit is blown under low load, ensuring normal business processing and making full use of system resources; under medium load, the normal state does not blow, and the semi-fuse state is randomly judged according to the preset ratio, which not only gives the system a certain buffer but also flexibly controls the flow; under high load, the semi-fuse state directly blows to prevent the system from overload and crash, and the normal state does not blow. It can achieve accurate decision-making for different situations, flexibly carry out circuit breaking processing, effectively respond to complex and changing business needs and external system environments, and ensure the stable operation of the software system.

[0148] In one embodiment, the service request processing device 400 based on the fuse mechanism further includes:

[0149] The sending module is used to send the call result as the interface call result data of the business request to the fuse component, so that the fuse component can dynamically adjust the operating status of the business processing link.

[0150] In the embodiment of the present application, in an architecture where multiple external systems are connected to the same interface and routed to different business processing links, different external systems behave differently. Based on the received interface call result data, the fuse component can fully understand the actual situation of each business processing link processing different business requests. Based on the received interface call result data, the fuse component dynamically adjusts the operating status of the business processing link, and can achieve flexible fuse processing for requests of different parameter levels and corresponding business processing links, realize precise flow control and service protection, and ensure stable system operation.

[0151] To solve the above technical problems, the present application also provides a computer device. Figure 4 , Figure 4 This is a basic structural block diagram of the computer device in this embodiment.

[0152] The computer device 6 includes a memory 61, a processor 62, and a network interface 63 that are interconnected through a system bus. It should be noted that the figure only shows a computer device 6 having a memory 61, a processor 62, and a network interface 63, but it should be understood that it is not required to implement all the components shown, and more or fewer components can be implemented instead. Among them, those skilled in the art can understand that the computer device here is a device that can automatically perform numerical calculations and / or information processing according to pre-set or stored instructions, and its hardware includes but is not limited to a microprocessor, an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a digital signal processor (DSP), an embedded device, etc.

[0153] Computer devices can be desktop computers, laptops, PDAs, cloud servers, etc. Computer devices can interact with users through keyboards, mice, remote controls, touchpads, or voice-activated devices.

[0154] Memory 61 includes at least one type of readable storage medium, including flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic storage, magnetic disk, optical disk, etc. In some embodiments, memory 61 may be an internal storage unit of computer device 6, such as the hard disk or memory of computer device 6. In other embodiments, memory 61 may also be an external storage device of computer device 6, such as a plug-in hard disk, smart memory card (SMC), secure digital (SD) card, flash memory card, etc. equipped on computer device 6. Of course, memory 61 may also include both internal storage units and external storage devices of computer device 6. In this embodiment, memory 61 is generally used to store the operating system and various application software installed on computer device 6, such as computer-readable instructions for a service request processing method based on a fuse mechanism. In addition, the memory 61 can also be used to temporarily store various types of data that have been output or are to be output.

[0155] In some embodiments, the processor 62 may be a central processing unit (CPU), a controller, a microcontroller, a microprocessor, or other data processing chip. The processor 62 is generally used to control the overall operation of the computer device 6. In this embodiment, the processor 62 is used to execute computer-readable instructions stored in the memory 61 or process data, such as executing computer-readable instructions for a service request processing method based on a circuit breaker mechanism.

[0156] The network interface 63 may include a wireless network interface or a wired network interface. The network interface 63 is generally used to establish a communication connection between the computer device 6 and other electronic devices.

[0157] When processing business requests sent by different external systems, the embodiment of the present application obtains the operating status of the corresponding business processing link based on the target business type in the business parameters, and performs a fuse judgment for the target time period in combination with the current load status. This dynamic and accurate judgment method can more timely and accurately identify abnormal situations that may occur in the business processing link, and avoid the problem of overall service performance degradation caused by the instability of a certain external service. When the fuse judgment result is a fuse, the preset degradation strategy is obtained according to the priority of the external system for degradation processing, and a request failure prompt message is returned, which not only ensures the stable operation of the core functions of the system, but also provides differentiated processing according to the importance of the external system and reasonably allocates resources. When the fuse is not blown, the request is processed normally and the result is returned, ensuring the normal flow of business. Compared with the existing interface-level degradation and current limiting method, this solution realizes flexible fuse processing for requests of different parameter levels routed to different business processing links on the interface, effectively coping with complex business scenarios and external system environments.

[0158] The present application also provides another embodiment, namely, providing a computer-readable storage medium, which stores computer-readable instructions, and the computer-readable instructions can be executed by at least one processor to enable the at least one processor to perform the steps of the business request processing method based on the fuse mechanism as described above.

[0159] When processing business requests sent by different external systems, the embodiment of the present application obtains the operating status of the corresponding business processing link based on the target business type in the business parameters, and performs a fuse judgment for the target time period in combination with the current load status. This dynamic and accurate judgment method can more timely and accurately identify abnormal situations that may occur in the business processing link, and avoid the problem of overall service performance degradation caused by the instability of a certain external service. When the fuse judgment result is a fuse, the preset degradation strategy is obtained according to the priority of the external system for degradation processing, and a request failure prompt message is returned, which not only ensures the stable operation of the core functions of the system, but also provides differentiated processing according to the importance of the external system and reasonably allocates resources. When the fuse is not blown, the request is processed normally and the result is returned, ensuring the normal flow of business. Compared with the existing interface-level degradation and current limiting method, this solution realizes flexible fuse processing for requests of different parameter levels routed to different business processing links on the interface, effectively coping with complex business scenarios and external system environments.

[0160] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus the necessary general hardware platform, and of course can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes a number of instructions for enabling a terminal device (which can be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods of each embodiment of the present application.

[0161] Obviously, the embodiments described above are only some of the embodiments of the present application, rather than all of the embodiments. The preferred embodiments of the present application are given in the accompanying drawings, but they do not limit the patent scope of the present application. The present application can be implemented in many different forms. On the contrary, the purpose of providing these embodiments is to make the understanding of the disclosure of the present application more thorough and comprehensive. Although the present application has been described in detail with reference to the aforementioned embodiments, for those skilled in the art, it is still possible to modify the technical solutions described in the aforementioned specific embodiments, or to make equivalent replacements for some of the technical features therein. Any equivalent structure made using the contents of the present application specification and the accompanying drawings, directly or indirectly used in other related technical fields, is also within the scope of patent protection of the present application.

[0162] The non-Company software tools or components appearing in the embodiments of this application are merely examples and do not represent actual use.

Claims

1. A service request processing method based on a fuse mechanism, characterized in that: The steps include: Receiving a service request sent by an external system, the service request carrying service parameters, the service parameters including a target service type and an external system priority; Based on the target service type, obtaining the running status of the service processing link corresponding to the service request from the fuse component; Acquiring a current load state of the service processing link, and performing a fuse determination for the service processing link in a target time period based on the operating state and the load state, to obtain a fuse determination result for the service processing link in the target time period; If the circuit breaker judgment result is a circuit breaker, a preset downgrade strategy is obtained according to the priority of the external system, and based on the downgrade strategy, the service processing link and the service request are downgraded, and a prompt message indicating that the request failed is returned to the external system; If the fuse judgment result is not blown, the business processing link is called to process the business request, a call result is obtained, and the call result is returned to the external system.

2. The method according to claim 1, characterized in that The step of obtaining the running status of the service processing link corresponding to the service request from the fuse component based on the target service type specifically includes: Through the thread pool inside the circuit breaker component, an asynchronous merge counting operation is performed on the interface call result data reported to the circuit breaker component, and the interface call result data corresponding to each business type in the same second are accumulated according to the status type to obtain second-granularity data; Based on the service request, a target time period is determined, and a data monitoring mechanism is triggered by the fuse component to extract new interface call result data corresponding to the target service type reported to the fuse component before the target time period; Acquire target second-granularity data corresponding to the target service type from the second-granularity data; Based on the target second-granularity data and the new interface call data, the operating status of the service processing link within the target time period is calculated.

3. The method according to claim 2, characterized in that The step of accumulating the interface call result data corresponding to each service type within the same second according to the state type to obtain second-granularity data specifically includes: Extracting second-level time information from the timestamp of the interface call result data; Create a data structure for each business type to store data with second-level time as the key and status type count as the value; Traversing the interface call result data one by one, and classifying the interface call result data into a data structure of a corresponding business type according to the business type identifier in the data; Update the corresponding count according to the call status of the interface call result data in the data container of each business type; After completing the traversal and counting accumulation of all interface call result data, the data structure is sorted to obtain second-granularity data.

4. The method according to claim 2, characterized in that The step of calculating the operating status of the service processing link within the target time period based on the target second-granularity data and the new interface call data specifically includes: Determine the start time and end time of the merge window based on the target time period; Merging the target second-granularity data and the data in the new interface call data that fall within the time range from the start time to the end time to obtain merged data; Based on the merged data, a preset anomaly rate formula is used to calculate the anomaly rate within the merge window; A preset fuse threshold range is obtained, the abnormality rate is compared with the fuse threshold, and based on the comparison result, the operating status of the service processing link corresponding to the target service type is determined.

5. The method according to claim 4, characterized in that The step of determining the operating status of the service processing link corresponding to the target service type based on the comparison result specifically includes: If the abnormality rate is less than the minimum value of the fuse threshold range, it is determined that the operation status of the service processing link corresponding to the target service type is normal; If the abnormality rate is within the fuse threshold range, determining that the operation state of the service processing link corresponding to the target service type is a semi-fuse state; If the abnormal rate is greater than the maximum value of the fuse threshold range, it is determined that the operation state of the service processing link corresponding to the target service type is a fuse state.

6. The method according to any one of claims 1 or 5, characterized in that The step of performing a fuse determination for the service processing link in a target period based on the operating state and the load state, and obtaining a fuse determination result for the service processing link in the target period, specifically includes: Obtaining a preset fuse judgment rule, and based on the fuse judgment rule, if the operating state is a fuse state, determining that the fuse judgment result of the service processing link in the target time period is fuse; If the operating state is a semi-fuse state or a normal state, performing a fusing judgment for the target time period on the service processing link based on the load state; If the load state is low load, determining that the fuse judgment result of the service processing link in the target time period is not blown; If the load state is medium load, then when the operating state is normal, the fuse judgment result of the service processing link in the target time period is determined to be not blown; when the operating state is semi-blown, the fuse judgment result of the service processing link in the target time period is randomly determined according to a preset ratio; If the load state is high load, then when the operating state is normal, the fuse judgment result of the business processing link in the target time period is determined to be not blown; when the operating state is semi-blown, the fuse judgment result of the business processing link in the target time period is determined to be blown.

7. The method according to claim 1, characterized in that After the step of invoking the service processing link to process the service request if the fuse judgment result is not blown and obtaining the invoking result, the method further includes: The call result is sent to the fuse component as the interface call result data of the business request, so that the fuse component dynamically adjusts the running state of the business processing link.

8. A service request processing device based on a fuse mechanism, characterized in that: include: A receiving module, configured to receive a service request sent by an external system, wherein the service request carries service parameters including a target service type and an external system priority; An acquisition module, configured to acquire, from a fuse component, the running status of a service processing link corresponding to the service request based on the target service type; a judgment module, configured to obtain a current load state of the service processing link, and perform a fuse judgment on the service processing link in a target time period based on the operating state and the load state, to obtain a fuse judgment result of the service processing link in the target time period; a processing module configured to, if the fuse judgment result is a blown circuit, obtain a preset downgrade strategy according to the priority of the external system, downgrade the service processing link and the service request based on the downgrade strategy, and return a prompt message indicating a request failure to the external system; The calling module is used to call the business processing link to process the business request if the fuse judgment result is not blown, obtain the calling result, and return the calling result to the external system.

9. A computer device, characterized in that: It includes a memory and a processor, wherein the memory stores computer-readable instructions, and when the processor executes the computer-readable instructions, it implements the steps of the service request processing method based on the fuse mechanism as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer-readable instructions, which, when executed by a processor, implement the steps of the service request processing method based on the fuse mechanism as described in any one of claims 1 to 7.

Images