Service processing method and device, electronic equipment and storage medium
By real-time monitoring of load status and dynamic adjustment strategies, combined with plugin metadata to optimize resource control in the financial market system, the problem of business losses and resource waste caused by the one-size-fits-all control in existing technologies has been solved, and stability and resource utilization have been improved under high load scenarios.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- 深圳华云信息系统科技股份有限公司
- Filing Date
- 2025-12-29
- Publication Date
- 2026-05-12
Smart Images

Figure CN122019138A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, and in particular to a service processing method, apparatus, electronic device and storage medium. Background Technology
[0002] With the development of the Internet, financial market data systems, as the core infrastructure of financial transactions, need to process massive amounts of data and perform complex calculations in real time. Existing financial market data systems typically adopt a plug-in architecture to decompose functions, encapsulating different business logics into independent business plug-ins, thereby improving the system's flexibility and scalability.
[0003] However, existing technologies typically employ a one-size-fits-all approach when the load is too high, directly limiting or downgrading all plugins. This results in both core and non-core business plugins being affected simultaneously, disrupting the normal operation of core services and causing significant business losses. Furthermore, existing technologies often rely on the experience and judgment of operations personnel when selecting plugins for control, which is prone to misjudgments and further exacerbates system operational risks. Summary of the Invention
[0004] This application provides a service processing method, apparatus, electronic device, and storage medium to solve the technical problems of blind operation of business plug-in in the prior art, low operation and maintenance efficiency, which leads to the inability to dynamically adapt to load changes, poor business stability, and low resource utilization.
[0005] In a first aspect, this application provides a service processing method, the method comprising: In response to service requests, detect the current load status of the system; When the current load state meets the set control triggering conditions, the control priority of each business plugin is determined based on the metadata of each business plugin in the business system, and the target control strategy is determined according to the current load state. Based on the target control strategy and the control priority of each business plugin, control operations are performed on the selected business plugins, and the control operations are used to control the resource consumption of the business plugins. After performing the control operation, monitor the load changes of the business system and perform resource expansion based on the load changes; Based on the system load status after resource expansion, the target control strategy is adjusted, and the adjusted system resources are used to process the service requests.
[0006] In one possible implementation, the method further includes: In response to a registration request from a business plugin, obtain the metadata of the business plugin; The validity of the metadata is verified, and it is detected whether the metadata conflicts with the metadata already registered in the business plugin registry. If the metadata passes the validity verification and no conflict is detected, the business plugin and its metadata are registered to the business plugin registry.
[0007] In one possible implementation, determining the control priority of each business plugin based on the metadata of each business plugin in the business system includes: The following processing is performed on each business plugin in the aforementioned business system: Obtain the business priority, resource consumption level, and historical control effect data from the metadata of the business plugin; Based on the weighting coefficients associated with the current load status, the business priority, the resource consumption level, and the historical control effect data are weighted and calculated to obtain the control priority of the business plugin.
[0008] In one possible implementation, determining the target control strategy based on the current load state includes: Obtain system load metrics that characterize the current load state; The system load index is compared with multiple preset control level thresholds; The target control level is determined based on the comparison results, and the target control level corresponds to the target control strategy. The target control level includes at least the following: The first level of control corresponds to the control strategy of simplifying the functions of the selected business plug-ins or reusing the results. The second downgrade level corresponds to the control strategy of disabling the function or simplifying the algorithm of the selected business plug-in. The third downgrade level corresponds to a control strategy that retains only core business plugins and disables a large number of non-core business plugins.
[0009] In one possible implementation, the step of performing control operations on selected service plugins based on the target control strategy and the control priority of each service plugin includes: Based on the aforementioned target control strategy, determine the target control priority range; The service plugin whose control priority falls within the target control priority range is identified as the first selected service plugin, and a downgrade control operation is performed on the first selected service plugin according to the target control strategy, wherein the downgrade control operation is used to limit the resource consumption of the service plugin.
[0010] In one possible implementation, the step of performing control operations on selected service plugins based on the target control strategy and the control priority of each service plugin further includes: Based on the aforementioned target control strategy, determine the target control priority range; The service plugin whose control priority falls outside the target control priority range is identified as the selected second service plugin, and a recovery control operation is performed on the selected second service plugin according to the target control strategy; wherein, the recovery control operation is used to restore the resource consumption of the service plugin.
[0011] In one possible implementation, performing resource scaling based on the load changes includes: Determine the target resource expansion strategy based on the load changes; Perform resource expansion according to the target resource expansion strategy; Wherein, when the load change indicates that the system load state meets the first change trend, the set first resource expansion strategy is determined as the target resource expansion strategy, and the first resource expansion strategy indicates that the first level resource pool is enabled. When the load change indicates that the system load state meets the second change trend, the set second resource expansion strategy is determined as the target resource expansion strategy, and the second resource expansion strategy indicates that the second-level resource pool is enabled. If the load change indicates that the system load state meets the third trend, the set third resource expansion strategy is determined as the target resource expansion strategy, and the third resource expansion strategy indicates that the third-level resource pool is enabled. The capacity of the first-level resource pool is greater than that of the second-level resource pool, and the resource capacity of the second-level resource pool is greater than that of the third-level resource pool.
[0012] Secondly, this application provides a service processing apparatus, the apparatus comprising: The load status detection module is used to detect the current load status of the system in response to service requests; The target control strategy determination module is used to determine the control priority of each business plugin based on the metadata of each business plugin in the business system when the current load state meets the set control triggering conditions, and to determine the target control strategy according to the current load state. The control operation execution module is used to perform control operations on selected business plugins according to the target control strategy and the control priority of each business plugin. The control operations are used to control the resource consumption of the business plugins. The resource expansion module is used to monitor the load changes of the business system after the control operation is performed, and to perform resource expansion according to the load changes. The service request processing module is used to adjust the target control strategy based on the system load status after resource expansion, and to process the service request using the adjusted system resources.
[0013] In one possible implementation, the device is further used for: In response to a registration request from a business plugin, obtain the metadata of the business plugin; The validity of the metadata is verified, and it is detected whether the metadata conflicts with the metadata already registered in the business plugin registry. If the metadata passes the validity verification and no conflict is detected, the business plugin and its metadata are registered to the business plugin registry.
[0014] In one possible implementation, the target control strategy determination module is specifically used for: The following processing is performed on each business plugin in the aforementioned business system: Obtain the business priority, resource consumption level, and historical control effect data from the metadata of the business plugin; Based on the weighting coefficients associated with the current load status, the business priority, the resource consumption level, and the historical control effect data are weighted and calculated to obtain the control priority of the business plugin.
[0015] In one possible implementation, the target control strategy determination module is specifically used for: Obtain system load metrics that characterize the current load state; The system load index is compared with multiple preset control level thresholds; The target control level is determined based on the comparison results, and the target control level corresponds to the target control strategy. The target control level includes at least the following: The first level of control corresponds to the control strategy of simplifying the functions of the selected business plug-ins or reusing the results. The second downgrade level corresponds to the control strategy of disabling the function or simplifying the algorithm of the selected business plug-in. The third downgrade level corresponds to a control strategy that retains only core business plugins and disables a large number of non-core business plugins.
[0016] In one possible implementation, the control operation execution module is specifically used for: Based on the aforementioned target control strategy, determine the target control priority range; The service plugin whose control priority falls within the target control priority range is identified as the first selected service plugin, and a downgrade control operation is performed on the first selected service plugin according to the target control strategy, wherein the downgrade control operation is used to limit the resource consumption of the service plugin.
[0017] In one possible implementation, the control operation execution module is further configured to: Based on the aforementioned target control strategy, determine the target control priority range; The service plugin whose control priority falls outside the target control priority range is identified as the selected second service plugin, and a recovery control operation is performed on the selected second service plugin according to the target control strategy; wherein, the recovery control operation is used to restore the resource consumption of the service plugin.
[0018] In one possible implementation, the resource expansion module is specifically used for: Determine the target resource expansion strategy based on the load changes; Perform resource expansion according to the target resource expansion strategy; Wherein, when the load change indicates that the system load state meets the first change trend, the set first resource expansion strategy is determined as the target resource expansion strategy, and the first resource expansion strategy indicates that the first level resource pool is enabled. When the load change indicates that the system load state meets the second change trend, the set second resource expansion strategy is determined as the target resource expansion strategy, and the second resource expansion strategy indicates that the second-level resource pool is enabled. If the load change indicates that the system load state meets the third trend, the set third resource expansion strategy is determined as the target resource expansion strategy, and the third resource expansion strategy indicates that the third-level resource pool is enabled. The capacity of the first-level resource pool is greater than that of the second-level resource pool, and the resource capacity of the second-level resource pool is greater than that of the third-level resource pool.
[0019] Thirdly, this application provides an electronic device, including: a processor and a memory, wherein the processor is configured to execute a service processing program stored in the memory to implement the service processing method described in any one of the first aspects.
[0020] Fourthly, this application provides a storage medium storing one or more programs that can be executed by one or more processors to implement the service processing method described in any one aspect.
[0021] Compared with the prior art, the technical solution provided in this application has the following advantages: The method provided in this application, in response to a service request, determines the control priority of each business plugin based on the metadata of each business plugin in the business system when the current load state meets the set control triggering conditions, and determines the target control strategy according to the current load state; performs control operations on the selected business plugins according to the target control strategy and the control priority of each business plugin, and performs resource expansion according to the load changes of the business system; adjusts the target control strategy based on the system load state after resource expansion, and uses the adjusted system resources to process service requests. By monitoring load status in real time and dynamically determining control priorities and appropriate control strategies based on plugin metadata, precise control operations are executed. Then, the tiered resource pool is expanded as needed. Based on the expanded load, the strategy is adjusted and business functions are restored. This ensures the stable operation of core businesses and reduces the impact on users, while also achieving efficient resource utilization and elastic system adaptation. It effectively solves the problems of system lag, function failure, and resource waste in high-load scenarios, improves service reliability and user experience, and thus achieves the triple goals of ensuring an ultimate user experience, maximizing resource utilization, and reducing operational complexity in highly volatile and real-time scenarios such as financial markets. Attached Figure Description
[0022] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.
[0023] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0024] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.
[0025] Figure 1 A flowchart illustrating an embodiment of a service processing method provided in this application; Figure 2A flowchart illustrating another service processing method provided in this application; Figure 3 A flowchart illustrating another embodiment of the service processing method provided in this application; Figure 4 A structural block diagram of a service processing apparatus provided in this application; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation
[0026] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0027] The following disclosure provides numerous different embodiments or examples for implementing various structures of this application. To simplify the disclosure, specific examples of components and arrangements are described below. These are merely examples and are not intended to limit the scope of this application. Furthermore, reference numerals and / or letters may be repeated in different examples. Such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed.
[0028] To address the shortcomings of existing technologies in regulating business plugins—namely, their blindness, low operational efficiency, inability to dynamically adapt to load changes, poor business stability, and low resource utilization—this application provides a service processing method, device, electronic device, and storage medium. By real-time monitoring of load status and dynamically determining regulation priorities and appropriate regulation strategies based on plugin metadata, precise regulation operations are executed. Afterward, a tiered resource pool is expanded as needed, and the strategy is adjusted and business functions restored based on the expanded load. This ensures stable operation of core businesses, minimizes user-perceived impact, and achieves efficient resource utilization and system elasticity. It effectively solves the problems of system lag, functional failure, and resource waste under high load scenarios, improving service reliability and user experience. Thus, in highly volatile and real-time scenarios such as financial markets, it simultaneously achieves the triple goals of ensuring an optimal user experience, maximizing resource utilization, and reducing operational complexity.
[0029] Figure 1 A flowchart illustrating an embodiment of a service processing method provided in this application includes the following steps: Step 101: In response to the service request, detect the current load status of the system.
[0030] A service request can refer to an operation initiated by a user or system that requires processing by the business system. Examples include: an image compression task, a calculation task submission, and a real-time order query.
[0031] Current load status refers to a quantitative indicator of resource usage at the moment a request is received. For example, the current load status can be determined based on CPU utilization, memory utilization, disk I / O, network bandwidth, request queue length, and response latency. Essentially, it serves as a basis for determining whether the current business system requires resource adjustment.
[0032] In one embodiment, the system's built-in monitoring agent collects various resource metrics in real time. When a request enters the system's unified entry point (such as a load balancer), a trigger takes a snapshot of the current load metrics and determines the current load status of the business system based on these metrics.
[0033] For example, suppose a financial market data system receives 1,000 concurrent real-time stock price query requests. The system immediately checks the load: CPU 78%, memory 82%, 200 requests are queued, and the response latency increases from the normal 50ms to 280ms. Therefore, it can be clearly seen that the current business system is under very high load and is very busy.
[0034] Step 102: If the current load condition meets the set control triggering conditions, determine the control priority of each business plugin based on the metadata of each business plugin in the business system, and determine the target control strategy according to the current load condition.
[0035] The control trigger condition refers to the judgment rule that determines whether to activate the degradation / control mechanism. It is usually a threshold for one or more load indicators. For example: CPU > 75% and latency > 100ms. This is merely an example; the embodiments of this application do not impose limitations on this. A single load indicator threshold can be set as the control trigger condition, or a comprehensive load threshold for multiple load indicators can be set.
[0036] A business plugin refers to a functional unit or module within a business system that is responsible for handling business operations and can be independently controlled. Examples include order query plugins and market data calculation plugins. Essentially, it can be understood as encapsulating a specific calculation task or functional module, representing the smallest unit responsible for performing a calculation or a certain function.
[0037] Metadata refers to data describing plugin attributes. Essentially, it can be understood as an identity profile for each plugin and is the core basis for determining control priorities. For example, metadata can include: business plugin priority, used to quantify the importance of the business functions carried by the plugin; higher priority means stronger business importance. Specifically, it can be represented by Bx, where a smaller x value indicates a higher business priority. Resource consumption is a quantitative indicator used to pre-assess or actually measure the level of system resources consumed when a plugin executes; specifically, it can be represented by Lx, where a smaller x value indicates lower resource consumption. Dependencies describe the preceding business plugins that a business plugin depends on for normal operation. Historical control effects are quantitative assessment data recorded and analyzed by the system, showing the actual system benefits and business impacts after performing control operations on a specific plugin in the past; specifically, it can be represented by Ex, where a larger x value indicates a greater impact of the historical control operations performed on that business plugin on the entire business system. E0 indicates that the business plugin has not undergone any historical control operations.
[0038] Control priority refers to the quantified value by which the system determines the order in which plugins are controlled (such as downgraded or restored). Specifically, it can be represented by Bx, where a larger x value indicates a higher control priority, and the plugin should be controlled more preferentially.
[0039] Targeted control strategies can refer to control schemes with different levels of intensity, categorized according to the severity of the load.
[0040] In one embodiment, when the current load state meets the set control triggering conditions, the plugin registry is traversed. For each plugin, a weight coefficient is dynamically determined based on its metadata and the current load state. Based on this weight coefficient, the business priority, consumption level, and historical control effects in each plugin's metadata are weighted and calculated to determine the control priority of each plugin. According to the severity of the load state, the corresponding target control strategy is selected from the prioritized strategy library.
[0041] For example, the correspondence between control strategies and load metrics in the pre-defined strategy library is shown in Table 1 below: Table 1
[0042] For example, suppose the system determines that the current CPU utilization of 85% has triggered the regulation condition. The engine begins to calculate the regulation priority of each plugin: Plugin A (B1, L4, E0) may have a priority of 72, and plugin B (B3, L5, E0) has a regulation priority of P0. Plugin B is a core functional business plugin, and generally, plugins with a regulation priority of P0 will not be regulated. Although plugin B's business is not important (B3), it consumes a lot of resources (L5), so under the current load, its regulation priority is higher at P4, and it will be regulated before business plugins with regulation priorities of P3, P2, and P1. Since the load indicator CPU > 85%, a heavy regulation strategy is determined according to Table 1 above. This is just an example; for the specific method of determining the regulation priority of each business plugin, please refer to the description of the relevant embodiments below.
[0043] Step 103: Based on the target control strategy and the control priority of each business plugin, perform control operations on the selected business plugins.
[0044] The target control strategy can refer to the specific control method for the current load. The selected service plugins can refer to the set of service plugins whose control priority falls within the range defined by the target control strategy.
[0045] Control operations can refer to specific downgrade or recovery actions targeting business plugins. Essentially, they can be understood as stopping or restoring the resource consumption of related business plugins, such as: disabling plugins, switching to simplified algorithms, reducing calculation frequency, returning cached results, limiting the number of concurrent threads, and restoring the business functions of plugins.
[0046] In one embodiment, based on a pre-set control strategy, as shown in Table 1 above, a service plugin within the control priority range corresponding to the target control strategy is selected, and a control operation is performed on the selected service plugin.
[0047] For example, referring to Table 1 above, assuming the target control strategy corresponds to a heavy control level, all non-core plugins within the control priority range of P1-P4 are selected. These plugins are then sorted in descending order of their calculated control priority (higher priority plugins are listed first). The control operations defined by the strategy are executed on the plugins sequentially. For example, plugin B (high control priority) is disabled first, immediately releasing the CPU and memory it occupies. Then, the next plugin is processed until the resource release target expected by the strategy is reached or the list is completed. This is merely an example, and the embodiments of this application are not limited to this; control operations can also be performed on non-core plugins within the control priority range of P1-P4 simultaneously.
[0048] Step 104: After performing the control operation, monitor the load changes of the business system and perform resource expansion according to the load changes.
[0049] Load changes can refer to the real-time trends of key system indicators after a degradation is implemented. This includes whether the load is decreasing, stabilizing, or continuing to rise.
[0050] Resource expansion can refer to the behavior of dynamically adding additional computing resources (such as server instances, containers, CPU / memory quotas) to a business system.
[0051] In one embodiment, after a degradation operation, the monitoring system continuously observes metrics such as CPU and memory. The observation period may range from tens of seconds to several minutes. If the load drops rapidly and stabilizes within a normal range, scaling up is not triggered. If the load stops rising but remains at a high-risk level, or if it briefly drops and then spikes again due to a continuous influx of requests, scaling up is determined to be necessary. The elastic scaling component is invoked, and resources are allocated from different resource pools based on the urgency of the load trend. Specifically, if the trend is urgent: pre-running instances are started from the hot standby pool within seconds; if the trend is predictable: instances are quickly initialized and started from the warm standby pool; if there is a prolonged period of high load, capacity planning is performed, and cloud resources in the cold standby pool are activated.
[0052] For example, after disabling plugin B and simplifying plugin A, the system CPU dropped from 85% to 78%, but then rebounded to 82% within one minute due to a continuous influx of new requests. The monitoring system determined that the degradation was insufficient and triggered emergency scaling. The elastic scaling component immediately allocated two pre-warmed compute nodes from the hot standby pool to the cluster, adding approximately 20% of computing power. Furthermore, the hot standby pool has a readiness time of less than 5 seconds, effectively handling sudden traffic surges during emergency scaling. The warm standby pool has a readiness time of 1-3 minutes, and the cold standby pool can have a readiness time of 3-10 minutes. This is merely an example to emphasize that the readiness times of the hot, warm, and cold standby pools gradually increase.
[0053] Step 105: Based on the system load status after resource expansion, adjust the target control strategy and use the adjusted system resources to process service requests.
[0054] Adjusting the target control strategy can be done by relaxing or revoking the previously implemented strict degradation strategy based on the system capacity after the addition of resources, and gradually restoring services.
[0055] Utilizing adjusted system resources to process service requests can refer to the total resources available after expansion, as well as those released (or restored) through policy adjustments. The existing business plugins within the adjusted business system can then be used to process the corresponding service requests.
[0056] In one embodiment, after the expansion is completed, the system load decreases significantly (e.g., CPU usage drops from 82% to 60%). Since the load has entered a safe range, the system adjusts the target control strategy from heavy control to light control or disables control altogether. Based on the new strategy, previously disabled or downgraded plugins are gradually restored. Using the expanded resources and most of the restored service plugins, the system successfully processes user-triggered service requests.
[0057] For example, after the expansion node is added, the total CPU utilization of the system drops to 55%. The system automatically switches the strategy from heavy control level back to light control level (caching is only applied to P3-P4 plugins). Thus, the system restores the complete algorithm of plugin A, but plugin B (P3 auxiliary tool) may remain disabled or cached. At this point, the system has sufficient resources to successfully calculate and return the volatility surface data initially requested by the trader through the service. This is merely an example, and the embodiments of this application are not intended to limit the scope of the application.
[0058] The method provided in this application, in response to a service request, determines the control priority of each business plugin based on the metadata of each business plugin in the business system, and determines the target control strategy according to the current load state, provided that the current load state meets the set control trigger conditions. Based on the target control strategy and the control priority of each business plugin, control operations are performed on the selected business plugins, and resource expansion is performed according to the load changes of the business system. Based on the system load state after resource expansion, the target control strategy is adjusted, and the adjusted system resources are used to process service requests. By real-time monitoring of the load state, dynamically determining the control priority and the appropriate control strategy in conjunction with plugin metadata, executing precise control operations, and then calling the tiered resource pool for expansion as needed, and adjusting the strategy and restoring business functions according to the expanded load, this method ensures stable operation of core businesses, reduces the impact on user perception, and achieves efficient resource utilization and elastic system adaptation. It effectively solves the problems of system lag, function failure, and resource waste in high-load scenarios, improves service reliability and user experience, and thus simultaneously achieves the triple goals of ensuring an ultimate user experience, maximizing resource utilization, and reducing operational complexity in high-volatility, high-real-time scenarios such as financial market data.
[0059] In addition, this application provides an embodiment that mainly describes how to register a plugin to a plugin registry so that the business system can directly find the corresponding plugin and its metadata from the maintained plugin registry, thereby determining the control priority of each plugin.
[0060] In one embodiment, in response to a registration request from a business plugin, the metadata of the business plugin is obtained; the metadata is validated for legality, and it is detected whether the metadata conflicts with metadata already registered in the business plugin registry; if it is determined that the metadata has passed the legality validation and no conflict is detected, the business plugin and its metadata are registered to the business plugin registry.
[0061] A business plugin registration request can refer to a trigger signal or instruction that requests the system to include a new plugin in its management scope. It is typically initiated by the plugin developer, operations and maintenance system, or automated deployment pipeline during plugin installation or upgrades.
[0062] Metadata for business plugins can refer to structured data (such as business priority, resource consumption level, dependencies, etc.) that describes the plugin's attributes, capabilities, requirements, and behaviors. Essentially, it is a unique identifier or basis for the system to understand and use the plugin, independent of the plugin's own executable code.
[0063] Legality verification refers to checking the syntax and basic semantics of the metadata file itself to ensure its correct format, complete required fields, and valid value range. For example, this includes syntax verification to ensure the metadata conforms to the corresponding syntax format; pattern verification to verify that all required fields are included; and also verifying the dependencies of each business plugin's metadata dataset. If a plugin's dependency is F0, it means that the business plugin operates independently and does not depend on other business plugins; if the plugin's dependency is identified as a pricing service business plugin, it means that the business plugin's operation depends on the corresponding pricing service business plugin. This is just an example; other legality verification methods can be performed.
[0064] Conflict detection refers to a higher-level, system-wide logical consistency check performed on top of legitimacy verification. It ensures that new plugins do not compromise the existing stability and functional integrity of the system, and do not conflict with the metadata of other business plugins.
[0065] For example, suppose the automated deployment tool initiates a registration request for the next-generation prediction plugin V2. The system obtains the plugin's metadata, which declares its unique identifier as VolPredictorV2, business priority as B2, resource consumption level as L4, and dependency on the core pricing service. The system then first performs a validity check, confirming that the metadata format is standardized and that both B2 and L4 are within the predefined enumeration range. Next, a conflict detection is performed, verifying that the identifier VolPredictorV2 is not already in use, and that its prediction functionality does not overlap with existing plugins (such as older plugins focused on historical volatility calculations) in terms of functional definition. Its declared dependent service (the pricing service business plugin) is also ready. After all checks pass, the system officially persists the plugin's complete metadata to the central plugin registry. Thereafter, the plugin is included in the system's unified management scope, and the intelligent degradation engine can directly query its metadata to calculate control priorities during decision-making.
[0066] By verifying the legality of plugin metadata and detecting conflicts, we ensure that registered plugins are compliant and usable, and compatible with existing plugins in the system without conflicts. After plugins and their metadata are uniformly entered into the registry, it not only facilitates quick querying and calling by business systems, but also provides accurate metadata support for the intelligent degradation engine, efficiently determines the priority of plugin regulation, and ensures stable system operation and intelligent regulation efficiency.
[0067] The above embodiments, through an automated and standardized business plugin registration and management process, firstly ensure the high quality and reliability of metadata by verifying the legality of syntax, patterns, and dependencies at multiple levels, thus guaranteeing the accuracy of the data upon which subsequent intelligent decisions are based from the source. Secondly, they effectively guarantee the overall stability and consistency of the system by detecting conflicts in multiple dimensions such as identifiers, functions, and resources, thus effectively preventing runtime conflicts or functional disorders that may be caused by the introduction of new plugins. Thirdly, they greatly improve the efficiency and standardization of operation and maintenance management by replacing manual configuration with declarative metadata-driven methods, achieving automated, silent registration and unified management of plugins.
[0068] Figure 2 A flowchart illustrating another service processing method provided in this application is shown below. Figure 1 Based on the illustrated process, this section mainly describes how to determine the control priority and target control strategy for each business plugin, including the following steps: Step 201: In response to the service request, detect the current load status of the system.
[0069] For step 201 above, please refer to the above. Figure 1 Detailed description of the relevant embodiments.
[0070] Step 202: If the current load condition meets the set control triggering conditions, perform the following processing for each business plugin in the business system: Step 203: Obtain the business priority, resource consumption level, and historical control effect data from the metadata of the business plugin.
[0071] Step 204: Based on the weight coefficients associated with the current load status, perform weighted calculations on business priority, resource consumption level, and historical control effect data to obtain the control priority of the business plug-in.
[0072] The following is a unified explanation of steps 202-204 above: Business priority refers to a pre-defined level for each business plugin, used to quantify its business importance. It is typically represented by Bx, where x is a number; the smaller the value, the higher the priority and the more critical the business. For example, B0 represents the core market data calculation business plugin, and B4 represents the backend analysis business plugin.
[0073] Resource consumption level refers to a pre-assessment level of how much system resources (CPU, memory, I / O, etc.) a plugin consumes during runtime. It is usually represented by Lx, where x is a number; the higher the value, the more resources are consumed. For example, L1 represents very low consumption, and L5 represents very high consumption.
[0074] Historical control effect data refers to the quantitative evaluation of the actual effects produced after the system performed controls (such as downgrading) on the plugin in the past. It is usually represented by Ex, where x is a number. The higher the value, the greater the impact of the historical control effect on the system's business, indicating that the business plugin cannot be easily controlled. E0 indicates no historical records.
[0075] Weighting coefficients refer to the dynamic proportions allocated to the three dimensions of business priority, resource consumption level, and historical control effect when calculating control priority. These coefficients (usually denoted as α, β, γ) are not fixed, but are dynamically adjusted according to the urgency of the current system load state to meet the optimization objectives in different scenarios (such as prioritizing resource release under high load).
[0076] The control priority refers to a comprehensive value obtained through the above weighted calculation. This comprehensive value corresponds to the control priority Px. The larger this comprehensive value is, the more the business plugin should be controlled, and therefore the higher the corresponding control priority. That is, the higher the x value, the more the plugin should be controlled first.
[0077] In one embodiment, when the system detects that the current load state meets the preset control triggering conditions, it will initiate a control priority calculation process for all business plugins in the business system: First, for each business plugin, the system extracts the business priority (Bx, the smaller the x value, the more core the business), resource consumption level (Lx, the larger the x value, the more resource consumption), and historical control effect data (Ex, the higher the x value, the greater the impact of control on the business; E0 indicates no historical records) recorded in its metadata from the business plugin registry; then, based on the urgency of the current system load state, the system dynamically determines the weight coefficients (α, β, γ) assigned to the three dimensions of business priority, resource consumption level, and historical control effect, where the sum of α+β+γ is a fixed value of 1; finally, based on the above dynamic weight coefficients, the extracted business priority, resource consumption level, and historical control effect data are weighted and calculated to obtain a comprehensive value for each business plugin. This comprehensive value corresponds to the control priority Px, and the larger the comprehensive value, the higher the corresponding control priority Px, that is, the more priority the business plugin should be controlled.
[0078] Specifically, the control priority of each business plugin can be calculated using the decision function shown in Formula (I): ………………………Formula (1) Wherein, P(x) represents the quantified value of the control priority, that is, the above comprehensive value, which can be used to determine the corresponding control priority; B(x) represents the quantified value of the business priority, which can be specifically quantified into a specific value according to preset rules; α represents the weight coefficient of the business priority; L(x) represents the quantified value of the resource consumption level, which can be specifically quantified into a specific value according to preset rules; β represents the weight coefficient of the resource consumption level; E(x) represents the quantified value of the historical control effect, which can be specifically quantified into a specific value according to preset rules; β represents the weight coefficient of the historical control effect.
[0079] In addition, a corresponding comprehensive value threshold can be set for each control priority. For example, the comprehensive value corresponding to the control priority of P0 is below 50 points, the comprehensive value corresponding to the control priority of P1 is 50-70 points, the comprehensive value corresponding to the control priority of P2 is 70-80 points, the comprehensive value corresponding to the control priority of P3 is 80-90 points, and so on. This is just an example, and the embodiments of this application do not limit it.
[0080] For example, suppose that in an emergency situation where the financial market data system experiences a sudden surge in traffic and CPU utilization spikes to 88%, the system triggers a control process. Assume that the system dynamically determines the weighting coefficients based on the severity of the current load as follows: business priority (α=0.2), resource consumption level (β=0.7), and historical control effect (γ=0.1). The system then reads the metadata of three plugins to be evaluated from the plugin registry: Plugin X (business priority P1: quantified value 80, resource consumption L3: quantified value 60, historical effect E80: quantified value 80), Plugin Y (business priority P3: quantified value 40, resource consumption L5: quantified value 100, historical effect E50: quantified value 50), and Plugin Z (business priority P2: quantified value 60, resource consumption L4: quantified value 80, historical effect E90: quantified value 90). After numerical mapping of the above data (e.g., P1=80 points, L3=60 points, E80=80 points), weighted calculations are performed based on the decision function shown in Formula (I): Plug-in X score = 0.2×80 + 0.7×60 + 0.1×80 = 66, Plug-in Y score = 0.2×40 + 0.7×100 + 0.1×50 = 83, Plug-in Z score = 0.2×60 + 0.7×80 + 0.1×90 = 71. The final priority ranking is: Plug-in Y (P3) > Plug-in Z (P2) > Plug-in X (P1). This result clearly shows that although Plug-in Y has the lowest business priority, its extremely high resource consumption makes it the most priority target for regulation in the current decision-making process, which prioritizes resource release. This vividly demonstrates the system's ability to make multi-dimensional intelligent decisions based on dynamic weights.
[0081] Step 205: Obtain the system load index that represents the current load status; and compare the system load index with multiple preset control level thresholds.
[0082] Step 206: Determine the target control level based on the comparison results. The target control level corresponds to the target control strategy.
[0083] The following is a unified explanation of steps 205-206 above: System load metrics are key performance data used to quantify the current workload and resource pressure of a business system. Examples include CPU utilization, memory utilization, disk I / O latency, network throughput, request queue length, and average response latency. For illustrative purposes, this application embodiment uses CPU utilization as an example.
[0084] The control level threshold can refer to a pre-configured critical value of the system load index used to classify different control intensity levels. The target control level can refer to the intensity level of the current control action determined by comparing the current system load index with the preset control threshold. For example, the CPU value range corresponding to the load index shown in Table 1 above can be used as the control level threshold. Each control level threshold corresponds to a control level, each control level corresponds to a control strategy, and each control strategy is associated with a corresponding control priority range.
[0085] The target control levels include at least the following: the first control level, whose corresponding control strategy is to simplify the function or reuse the results of the selected business plugins; the second downgrade level, whose corresponding control strategy is to disable the function or simplify the algorithm of the selected business plugins; and the third downgrade level, whose corresponding control strategy is to retain only the core business plugins and disable a large number of non-core business plugins.
[0086] In one embodiment, after calculating the priority of business plug-in control, key indicators that can characterize the current load status (such as CPU utilization, memory utilization, response latency, etc.) are collected first. Then, these indicators are compared with pre-configured multi-level control thresholds. Finally, the corresponding target control level is determined according to the threshold range to which the indicator belongs. This level will automatically match the preset control strategy to clarify the specific intensity and execution direction of this control.
[0087] For example, the system acquires core indicators representing the current load status (such as CPU utilization) in real time and compares them with multiple preset control level thresholds. Based on the comparison results, the corresponding target control level is determined: if the CPU utilization is within the first threshold range (e.g., 60%-70%), it is determined to be at the first control level, with the corresponding strategy being to simplify the function of selected plugins or reuse the results; if it is within the second threshold range (e.g., 70%-85%), it is determined to be at the second control level, with the corresponding strategy being to disable the function of selected plugins or simplify the algorithm; if it exceeds the third threshold (e.g., >85%), it is determined to be at the third control level, with the corresponding strategy being to retain only core business plugins and disable a large number of non-core business plugins. Thus, the system maps continuous load values to clear, tiered control action instructions. Here, only one key indicator of the load status is used to determine the target control level. In practical applications, multiple load indicator data can be compared according to the corresponding control level thresholds; this embodiment does not impose such limitations.
[0088] Step 207: Based on the target control strategy and the control priority of each business plugin, perform control operations on the selected business plugins. The control operations are used to control the resource consumption of the business plugins.
[0089] Step 208: After performing the control operation, monitor the load changes of the business system and perform resource expansion according to the load changes.
[0090] Step 209: Based on the system load status after resource expansion, adjust the target control strategy and use the adjusted system resources to process service requests.
[0091] For steps 207-209 above, please refer to the above. Figure 1 Detailed description of the relevant embodiments.
[0092] Through the above Figure 2 The description of the illustrated embodiment demonstrates that by using a quantified calculation of priority control based on plugin metadata and dynamic weights, combined with a hierarchical control strategy mechanism that matches load indicators with preset thresholds, precise and intelligent control of business plugins is achieved. This prioritizes the stable operation of core business plugins while rapidly releasing system resources for non-core, high-resource-consuming plugins in high-load scenarios. Furthermore, this process is closely integrated with subsequent resource expansion and dynamic strategy adjustments, effectively balancing system load pressure and business service quality, and significantly improving the system's stability, elastic adaptability, and resource utilization efficiency under high concurrency and sudden traffic scenarios.
[0093] Figure 3 A flowchart illustrating another embodiment of the service processing method provided in this application is shown below. Figure 1 Based on the illustrated process, this section mainly describes how to execute control operations according to the target control strategy and how to perform resource expansion, including the following steps: Step 301: In response to the service request, detect the current load status of the system.
[0094] Step 302: If the current load condition meets the set control triggering conditions, determine the control priority of each business plugin based on the metadata of each business plugin in the business system, and determine the target control strategy according to the current load condition.
[0095] For steps 301-302 above, please refer to the above. Figure 1 Detailed description of the relevant embodiments.
[0096] Step 303: Determine the priority range of target control based on the target control strategy.
[0097] Step 304: The business plugins whose control priority falls within the target control priority range are identified as the first selected business plugins, and a downgrade control operation is performed on the first selected business plugins in accordance with the target control strategy. The downgrade control operation is used to limit the resource consumption of the business plugins.
[0098] Step 305: Identify the business plugins whose control priority falls outside the target control priority range as the selected second business plugins, and perform a recovery control operation on the selected second business plugins according to the target control strategy; wherein, the recovery control operation is used to restore the resource consumption of the business plugins.
[0099] The following steps 303-305 are described uniformly: The target control priority range can refer to the numerical range or set of control priority (Px) of the business plug-ins that need to be affected by this control operation, as defined by the target control strategy. For example, see the control priority range of the business plug-ins corresponding to each control strategy shown in Table 1 above.
[0100] The selected first business plugin can refer to the plugin whose control priority (Px) falls within the target control priority range. These are the plugins whose resource consumption needs to be limited (degradation control operation) in this instance.
[0101] Downgrade control refers to a series of specific technical actions aimed at proactively and temporarily reducing the resource consumption of business plugins. Its essence is "subtraction," reducing the resource consumption of business plugins or directly disabling them.
[0102] The selected second business plugin refers to the plugin whose control priority (Px) does not fall within the target control priority range. These are typically core plugins with higher business priorities (e.g., P0, P1), and they are the objects that need to be protected or restored in a degradation scenario. Furthermore, during the recovery phase (as described in step 305), a recovery operation is performed on the second business plugin. The logic is to restore plugins that were restricted by the previous control policy but are now allowed to recover under the new control policy (those business plugins that may have been incorrectly included in the scope or can be recovered after the policy relaxation).
[0103] Recovery and control operations refer to specific technical actions aimed at reversing downgrade effects and restoring business plugins to normal working status. Essentially, it involves "adding" or "restoring," such as restoring common business functions.
[0104] In one embodiment, the system reads the target control policy, parses out the control priority range specified in the policy, iterates through all plugins, compares the control priority (Px) of each plugin, and marks plugins with Px values within the control priority range as first service plugins (to be downgraded). Plugins with Px values outside the control priority range are marked as second service plugins (to be protected / restored). The first service plugins are sorted from high to low Px values (prioritizing the service plugins with the highest control priority), and the downgrade control operations defined in the policy are executed sequentially, such as sending batch disable commands or switching algorithm commands. The second service plugins are then subjected to a recovery control operation.
[0105] For example, taking the execution of a moderate control strategy in a financial market system as an example, the target control priority range corresponding to this strategy is P2-P4. The system first reads and parses this range, then traverses all business plugins in the plugin registry, compares the control priority Px value of each plugin, and marks the historical market statistics plugin, stock price alert push plugin, and market data visualization plugin with Px values in the P2-P4 range as the first business plugin. Then, it sorts them from high to low Px values and performs downgrade control operations on them in turn, such as disabling functions, switching cached results, and simplifying visualization algorithms. At the same time, the real-time stock price calculation plugin (P0 core plugin) and the trading instruction processing plugin (P1 important plugin) with Px values outside the range are marked as the second business plugin. The trading instruction processing plugin, which was previously restricted in concurrency due to heavy control, is restored to full concurrency. The real-time stock price calculation plugin is kept in normal operation. In this way, the control objective of accurately downgrading non-core plugins and protecting and restoring the functions of core plugins is achieved.
[0106] Step 306: After performing the control operation, monitor the load changes of the business system, determine the target resource expansion strategy based on the load changes, and execute the resource expansion according to the target resource expansion strategy.
[0107] Load changes can refer to the trend and rate of change of key system performance indicators (such as CPU and memory utilization) over time after a degradation control operation is performed. For example: rapid decline and stabilization, slow decline but still above the safety line, and a brief decline followed by a rapid rebound.
[0108] The target resource expansion strategy refers to the resource allocation plan decided based on the observed load change trend. The core is to decide which resource pool to use, at what speed, and how many resources to activate.
[0109] Specifically, when the load change indicates that the system load status meets a first trend, the first resource expansion strategy is determined as the target resource expansion strategy, and the first resource expansion strategy instructs the activation of the first-level resource pool; when the load change indicates that the system load status meets a second trend, the second resource expansion strategy is determined as the target resource expansion strategy, and the second resource expansion strategy instructs the activation of the second-level resource pool; when the load change indicates that the system load status meets the second trend, the third resource expansion strategy is determined as the target resource expansion strategy, and the third resource expansion strategy instructs the activation of the third-level resource pool; the capacity of the first-level resource pool is greater than that of the second-level resource pool, and the resource capacity of the second-level resource pool is greater than that of the third-level resource pool.
[0110] The first trend could be that the load does not improve significantly after degradation and continues to rise rapidly, indicating that degradation is insufficient to cope with traffic surges and requires a second-level emergency response.
[0111] The second trend could be that the load stops rising rapidly but remains at a high level or rises slowly, indicating that the pressure will continue and minute-level resource replenishment is needed to stabilize the system.
[0112] The second trend could refer to a periodic, predictable, long-term high load (such as active trading throughout the day), requiring long-term capacity planning with cost optimization.
[0113] The first-level resource pool can refer to a collection of instances that have been preheated and are in a standby state. The readiness time is extremely short (e.g., <5 seconds), and the cost is high. It is used to deal with the first change trend.
[0114] The second-level resource pool can refer to a collection of instances whose resources have been initialized but not fully started, with a moderate readiness time (e.g., 1-3 minutes) and moderate cost, used to cope with the second trend of change.
[0115] The third-level resource pool can refer to elastic resources that have not yet been created and need to be applied for on demand from the cloud platform. They have a longer readiness time (e.g., 5-15 minutes) and are billed based on usage. They are used to cope with the third trend of change.
[0116] In one embodiment, after the control operation is performed, the system continuously monitors the time change trend and rate of key performance indicators such as CPU and memory utilization. Based on the first, second or third change trend satisfied by the load change, the first, second or third resource expansion strategy corresponding to the activation of the first, second or third level resource pool is determined as the target resource expansion strategy, and then the resource expansion is performed according to the strategy (the capacity of the three level resource pools increases sequentially, and the ready time is extended as the capacity increases).
[0117] For example, after completing the downgrade control operation, the system enters the real-time monitoring and intelligent expansion phase. The system collects key indicators such as CPU utilization at a rate of seconds and analyzes their change curves to determine the trend: if the indicators continue to rise rapidly after downgrade, it is determined to be the first trend, and the first resource expansion strategy is immediately activated. The instruction is issued to the first-level resource pool (hot standby pool), and several pre-warmed and ready computing instances are started and added to the cluster within seconds to achieve emergency stoppage; if the indicators stop rising sharply but remain at a high level and continue to fluctuate or rise slowly, it is determined to be the second trend, and the second resource expansion strategy is activated. The instruction is issued to the second-level resource pool (warm standby pool), and a batch of instances are initialized and launched within 1-3 minutes to provide stable support; if the business cycle prediction model determines that the load will remain at a high level for a long time, it is determined to be the third trend, and the third-level resource expansion strategy is activated. The instruction is issued to the third-level resource pool (cold standby pool), triggering the cloud platform resource application and automated deployment process for long-term capacity planning with cost optimization. In this way, the system can accurately match resource supply with different readiness times and cost characteristics according to the urgency and duration of load reduction, and achieve flexible coverage from second-level emergency response to long-term planning.
[0118] Step 307: Based on the system load status after resource expansion, adjust the target control strategy and use the adjusted system resources to process service requests.
[0119] For step 307 above, please refer to the above. Figure 1 Detailed description of the relevant embodiments.
[0120] Through the above Figure 3 The description of the illustrated embodiment describes a process where, by first defining a priority range based on the target control strategy, the first business plugin is precisely selected for degradation, and the second business plugin is restored, thus achieving precise control over the resource consumption of non-core plugins and effective protection of the functions of core plugins. Then, by matching the load change trend after control with the three-tiered resource pool for differentiated expansion, balancing emergency response speed and long-term cost optimization, the control strategy is dynamically adjusted to adapt to the expanded load state, forming a closed loop of precise control, intelligent expansion, and strategy adaptation. This significantly improves the accuracy and stability of the system's load response in high-concurrency scenarios, optimizes resource utilization efficiency, and ensures the continuity of core business and user experience.
[0121] Figure 4 A structural block diagram of a service processing apparatus provided in this application, the apparatus comprising: The load status detection module 41 is used to detect the current load status of the system in response to service requests; The target control strategy determination module 42 is used to determine the control priority of each business plugin based on the metadata of each business plugin in the business system when the current load state meets the set control triggering conditions, and to determine the target control strategy according to the current load state. The control operation execution module 43 is used to perform control operations on selected business plugins according to the target control strategy and the control priority of each business plugin. The control operations are used to control the resource consumption of the business plugins. The resource expansion module 44 is used to monitor the load changes of the business system after the control operation is performed, and to perform resource expansion according to the load changes. The service request processing module 45 is used to adjust the target control strategy based on the system load status after resource expansion, and to process the service request using the adjusted system resources.
[0122] In one possible implementation, the device is further used for: In response to a registration request from a business plugin, obtain the metadata of the business plugin; The validity of the metadata is verified, and it is detected whether the metadata conflicts with the metadata already registered in the business plugin registry. If the metadata passes the validity verification and no conflict is detected, the business plugin and its metadata are registered to the business plugin registry.
[0123] In one possible implementation, the target control strategy determination module 42 is specifically used for: The following processing is performed on each business plugin in the aforementioned business system: Obtain the business priority, resource consumption level, and historical control effect data from the metadata of the business plugin; Based on the weighting coefficients associated with the current load status, the business priority, the resource consumption level, and the historical control effect data are weighted and calculated to obtain the control priority of the business plugin.
[0124] In one possible implementation, the target control strategy determination module 42 is specifically used for: Obtain system load metrics that characterize the current load state; The system load index is compared with multiple preset control level thresholds; The target control level is determined based on the comparison results, and the target control level corresponds to the target control strategy. The target control level includes at least the following: The first level of control corresponds to the control strategy of simplifying the functions of the selected business plug-ins or reusing the results. The second downgrade level corresponds to the control strategy of disabling the function or simplifying the algorithm of the selected business plug-in. The third downgrade level corresponds to a control strategy that retains only core business plugins and disables a large number of non-core business plugins.
[0125] In one possible implementation, the control operation execution module 43 is specifically used for: Based on the aforementioned target control strategy, determine the target control priority range; The service plugin whose control priority falls within the target control priority range is identified as the first selected service plugin, and a downgrade control operation is performed on the first selected service plugin according to the target control strategy, wherein the downgrade control operation is used to limit the resource consumption of the service plugin.
[0126] In one possible implementation, the control operation execution module 43 is further configured to: Based on the aforementioned target control strategy, determine the target control priority range; The service plugin whose control priority falls outside the target control priority range is identified as the selected second service plugin, and a recovery control operation is performed on the selected second service plugin according to the target control strategy; wherein, the recovery control operation is used to restore the resource consumption of the service plugin.
[0127] In one possible implementation, the resource expansion module 44 is specifically used for: Determine the target resource expansion strategy based on the load changes; Perform resource expansion according to the target resource expansion strategy; Wherein, when the load change indicates that the system load state meets the first change trend, the set first resource expansion strategy is determined as the target resource expansion strategy, and the first resource expansion strategy indicates that the first level resource pool is enabled. When the load change indicates that the system load state meets the second change trend, the set second resource expansion strategy is determined as the target resource expansion strategy, and the second resource expansion strategy indicates that the second-level resource pool is enabled. If the load change indicates that the system load state meets the third trend, the set third resource expansion strategy is determined as the target resource expansion strategy, and the third resource expansion strategy indicates that the third-level resource pool is enabled. The capacity of the first-level resource pool is greater than that of the second-level resource pool, and the resource capacity of the second-level resource pool is greater than that of the third-level resource pool.
[0128] like Figure 5 As shown in the figure, this application provides an electronic device, including a processor 111, a communication interface 112, a memory 113, and a communication bus 114, wherein the processor 111, the communication interface 112, and the memory 113 communicate with each other through the communication bus 114. Memory 113 is used to store computer programs; In one embodiment of this application, when the processor 111 executes a program stored in the memory 113, it implements the service processing method provided in any of the foregoing method embodiments, including: In response to service requests, detect the current load status of the system; When the current load state meets the set control triggering conditions, the control priority of each business plugin is determined based on the metadata of each business plugin in the business system, and the target control strategy is determined according to the current load state. Based on the target control strategy and the control priority of each business plugin, control operations are performed on the selected business plugins, and the control operations are used to control the resource consumption of the business plugins. After performing the control operation, monitor the load changes of the business system and perform resource expansion based on the load changes; Based on the system load status after resource expansion, the target control strategy is adjusted, and the adjusted system resources are used to process the service requests.
[0129] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the service processing method provided in any of the foregoing method embodiments.
[0130] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.
[0131] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software plus a general-purpose hardware platform, or of course, using hardware. Based on this understanding, the above technical solutions, in essence or the parts that contribute to the related technology, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.
[0132] It should be understood that the terminology used herein is for the purpose of describing particular exemplary embodiments only and is not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “described” as used herein may also mean including the plural forms. The terms “comprising,” “including,” “containing,” and “having” are inclusive and therefore indicate the presence of the stated features, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, elements, components, and / or combinations thereof. The method steps, processes, and operations described herein are not construed as requiring them to be performed in a particular order described or illustrated unless the order of performance is explicitly indicated. It should also be understood that additional or alternative steps may be used.
[0133] The above description is merely a specific embodiment of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.
Claims
1. A service processing method, characterized in that, The method includes: In response to service requests, detect the current load status of the system; When the current load state meets the set control triggering conditions, the control priority of each business plugin is determined based on the metadata of each business plugin in the business system, and the target control strategy is determined according to the current load state. Based on the target control strategy and the control priority of each business plugin, control operations are performed on the selected business plugins, and the control operations are used to control the resource consumption of the business plugins. After performing the control operation, monitor the load changes of the business system and perform resource expansion based on the load changes; Based on the system load status after resource expansion, the target control strategy is adjusted, and the adjusted system resources are used to process the service requests.
2. The method according to claim 1, characterized in that, The method further includes: In response to a registration request from a business plugin, obtain the metadata of the business plugin; The validity of the metadata is verified, and it is detected whether the metadata conflicts with the metadata already registered in the business plugin registry. If the metadata passes the validity verification and no conflict is detected, the business plugin and its metadata are registered to the business plugin registry.
3. The method according to claim 1, characterized in that, The determination of the control priority of each business plugin based on the metadata of each business plugin in the business system includes: The following processing is performed on each business plugin in the aforementioned business system: Obtain the business priority, resource consumption level, and historical control effect data from the metadata of the business plugin; Based on the weighting coefficients associated with the current load status, the business priority, the resource consumption level, and the historical control effect data are weighted and calculated to obtain the control priority of the business plugin.
4. The method according to claim 1, characterized in that, The step of determining the target control strategy based on the current load status includes: Obtain system load metrics that characterize the current load state; The system load index is compared with multiple preset control level thresholds; The target control level is determined based on the comparison results, and the target control level corresponds to the target control strategy. The target control level includes at least the following: The first level of control corresponds to the control strategy of simplifying the functions of the selected business plug-ins or reusing the results. The second downgrade level corresponds to the control strategy of disabling the function or simplifying the algorithm of the selected business plug-in. The third downgrade level corresponds to a control strategy that retains only core business plugins and disables a large number of non-core business plugins.
5. The method according to claim 1, characterized in that, The step of performing control operations on selected business plugins based on the target control strategy and the control priority of each business plugin includes: Based on the aforementioned target control strategy, determine the target control priority range; The service plugin whose control priority falls within the target control priority range is identified as the first selected service plugin, and a downgrade control operation is performed on the first selected service plugin according to the target control strategy, wherein the downgrade control operation is used to limit the resource consumption of the service plugin.
6. The method according to claim 1, characterized in that, The step of performing control operations on selected business plugins based on the target control strategy and the control priority of each business plugin further includes: Based on the aforementioned target control strategy, determine the target control priority range; The service plugin whose control priority falls outside the target control priority range is identified as the selected second service plugin, and a recovery control operation is performed on the selected second service plugin according to the target control strategy; wherein, the recovery control operation is used to restore the resource consumption of the service plugin.
7. The method according to claim 1, characterized in that, The step of performing resource expansion based on the load change includes: Determine the target resource expansion strategy based on the load changes; Perform resource expansion according to the target resource expansion strategy; Wherein, when the load change indicates that the system load state meets the first change trend, the set first resource expansion strategy is determined as the target resource expansion strategy, and the first resource expansion strategy indicates that the first level resource pool is enabled. When the load change indicates that the system load state meets the second change trend, the set second resource expansion strategy is determined as the target resource expansion strategy, and the second resource expansion strategy indicates that the second-level resource pool is enabled. If the load change indicates that the system load state meets the third trend, the set third resource expansion strategy is determined as the target resource expansion strategy, and the third resource expansion strategy indicates that the third-level resource pool is enabled. The capacity of the first-level resource pool is greater than that of the second-level resource pool, and the resource capacity of the second-level resource pool is greater than that of the third-level resource pool.
8. A service processing apparatus, characterized in that, The device includes: The load status detection module is used to detect the current load status of the system in response to service requests; The target control strategy determination module is used to determine the control priority of each business plugin based on the metadata of each business plugin in the business system when the current load state meets the set control triggering conditions, and to determine the target control strategy according to the current load state. The control operation execution module is used to perform control operations on selected business plugins according to the target control strategy and the control priority of each business plugin. The control operations are used to control the resource consumption of the business plugins. The resource expansion module is used to monitor the load changes of the business system after the control operation is performed, and to perform resource expansion according to the load changes. The service request processing module is used to adjust the target control strategy based on the system load status after resource expansion, and to process the service request using the adjusted system resources.
9. An electronic device, characterized in that, include: A processor and a memory, the processor being configured to execute a service processing program stored in the memory to implement the service processing method of any one of claims 1-7.
10. A storage medium, characterized in that, The storage medium stores one or more programs, which can be executed by one or more processors to implement the service processing method according to any one of claims 1-7.