Java microservice intelligent degradation and elastic scaling methods, devices, equipment, and storage media

Abstract

This invention relates to the field of Java microservice operation and maintenance technology, and discloses a method, apparatus, device, and storage medium for intelligent degradation and elastic scaling of Java microservices, to solve the problems of passive lag and disconnect between resource allocation and business demands in existing solutions. This invention identifies service business attributes and marks importance levels during the compilation or startup phase; collects service operation indicators and business parameters during the runtime phase, quantifying request value weights; integrates static and dynamic data to form a decision-making system; and, based on a business pressure index that integrates system indicators and request value weights, triggers early degradation when indicators approach a fault threshold, and prioritizes core links when the overall cluster business pressure index exceeds a threshold, performing elastic scaling based on the business pressure index, business importance level, and request value weights.

Description

Technical Field

[0001] This invention relates to the field of Java microservice operation and maintenance technology, specifically to a method, apparatus, device, and storage medium for intelligent degradation and elastic scaling of Java microservices. Background Technology

[0002] Currently, mainstream Java microservice degradation and elastic scaling solutions in the industry all use basic system operation indicators such as CPU utilization, memory utilization, QPS (queries per second), and service response time as the sole decision-making basis. By setting fixed thresholds, non-core services are degraded when the service operation indicators reach the fault threshold, while cluster resources are expanded and shrunk in fixed steps.

[0003] This solution has several key flaws in practical applications: First, it adopts a reactive degradation model, only performing operations after service performance has deteriorated, failing to anticipate failures or proactively prevent them, resulting in a significant lag in core business support. Second, its decision-making is too simplistic, failing to consider inherent business priorities and the value of individual requests, leading to a situation where non-core business and low-value requests consume large amounts of cluster resources, while core business and high-value transaction requests suffer from insufficient resources, resulting in a severe disconnect between resource allocation and core business needs. Third, it fails to analyze the full-link call dependencies between services, making it impossible to identify potential performance bottlenecks downstream of the core business link in advance, easily causing the entire core link to be blocked due to downstream dependency failures. Fourth, many solutions require intrusive deployment into business code, resulting in high access and maintenance costs, and some solutions also generate continuous performance overhead during runtime, affecting the normal response of business services.

[0004] Therefore, there is an urgent need for a non-intrusive Java microservice intelligent degradation and elastic scaling solution that combines inherent business attributes with real-time operational status to address the aforementioned shortcomings of existing technologies, achieve proactive prevention of service failures, end-to-end protection of core business links, and reasonable and efficient allocation of cluster resources, and adapt to Java microservice deployment scenarios with high protection requirements and significant traffic fluctuations. Summary of the Invention

[0005] In view of this, the present invention provides a Java microservice intelligent degradation elastic scaling method, device and storage medium to solve the problems of passive and lagging operation and maintenance solutions, disconnect between resource allocation and core business requirements and insufficient core business protection in the existing Java microservice operation and maintenance solutions, so as to achieve proactive fault prevention, reasonable resource allocation and reduce operation and maintenance costs.

[0006] Firstly, this invention provides a Java microservice intelligent degradation and elastic scaling method, applied to electronic devices deploying Java microservice applications. The method includes: during the compilation or startup phase of the Java microservice application, analyzing the business attributes of service methods, marking business importance levels, clarifying call dependencies between services, and constructing a static business baseline; during the application runtime phase, acquiring service execution data using a non-intrusive collection method, the service execution data including business semantic data and service runtime data, assigning service request value weights based on business semantic data, and assigning service request pressure weights based on service runtime data; integrating the static business baseline and dynamic service execution data to form a decision-making system, calculating a comprehensive business pressure index characterizing the service business value and runtime pressure; based on the business pressure index and combined with the business importance level, performing intelligent degradation operations, prioritizing the stability of core business links, and dynamically adjusting service runtime resources according to the comparison results of the business pressure index and a preset threshold, ensuring that resource allocation aligns with core business needs, wherein service methods corresponding to core businesses do not participate in scaling down operations.

[0007] In one optional implementation, the labeling of business importance levels specifically involves: based on business characteristics in the code, distinguishing between core and non-core businesses, and labeling service methods with different levels of business priority, including core transaction level, important service level, and degradeable service level, wherein the service methods corresponding to the core transaction level constitute the core business link, and their stable operation is given priority.

[0008] In one optional implementation, the non-intrusive collection method specifically involves collecting service execution data through JavaAgent technology without modifying the business code. The service execution data includes at least one of QPS, response time, exception rate, CPU utilization, and concurrency. The request value weight is quantified based on at least one of business type, transaction amount, and user level, and the weight allocation rules can be flexibly adjusted according to the core business requirements.

[0009] In one optional implementation, the intelligent degradation operation specifically includes: monitoring service performance change trends; when a service does not fail but shows a tendency to degrade in performance, performing degradation operations on the service methods corresponding to the degradable service level; when system pressure reaches a preset threshold, implementing traffic control based on request value weights, prioritizing the execution of service methods corresponding to high-value requests, and performing rate limiting or degradation operations on service methods corresponding to low-value requests; the service dependency relationship is used to identify the upstream and downstream connections of the core business link; when the downstream dependent service of the core business link shows a tendency to abnormal performance, the degradation operation is triggered in advance to avoid affecting the operation of the core business.

[0010] In one optional implementation, the dynamic adjustment of service operation resources specifically involves: prioritizing service methods based on the business pressure index and the level of business importance; allocating resources to high-priority services during expansion; and reclaiming resources only for service methods corresponding to non-core business levels during contraction, while service methods corresponding to core business levels do not participate in the contraction operation.

[0011] Secondly, the present invention provides a Java microservice intelligent degradation and elastic scaling device, applied to an electronic device for deploying Java microservice applications, for implementing the Java microservice intelligent degradation and elastic scaling method described in the first aspect above. The device includes: a static priority configuration module, used to identify the business attributes of each service method based on business attribute-related code features at any stage during the Java application compilation and startup phases, and configure a core business layer and at least one non-core business layer for at least one service method; and a runtime collection and weight calculation module, used to collect service execution data during the application runtime phase, and assign request value weight and request pressure weight to each service method based on preset rules. The service execution data includes business semantic data and service runtime data, wherein the business semantic data includes business attribute information corresponding to the business method input parameters (such as payment amount values, product popularity corresponding to product identifiers, etc.), and the service runtime data... This includes QPS (Requests Per Second), response time, and anomaly rate; an intelligent degradation module for performing predictive degradation based on business priority and differentiated degradation based on system pressure and request value weights; the predictive degradation is performed on service method calls corresponding to non-core business layers when a service performance degradation trend is detected but no failure or anomaly occurs; the differentiated degradation is implemented when system pressure reaches a preset threshold, based on the value weight threshold in preset rules to implement traffic control, prioritizing the execution of service methods corresponding to requests with a request value weight higher than the value weight threshold, and performing rate limiting or degradation operations on service methods corresponding to requests with a request value weight lower than the value weight threshold; and an elastic scaling control module for dynamically adjusting service operation resources based on the comparison results of the business pressure index with preset expansion thresholds and preset shrinkage thresholds, and prioritizing resource allocation for service methods corresponding to core business layers, rather than scaling based solely on system hardware indicators.

[0012] Thirdly, the present invention provides a computer device. It includes: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the computer instructions to perform the Java microservice intelligent degradation elastic scaling method of the first aspect above or any corresponding embodiment.

[0013] Fourthly, the present invention provides a computer-readable storage medium. The computer-readable storage medium stores computer instructions for causing the computer to execute the Java microservice intelligent degradation elastic scaling method of the first aspect above or any corresponding embodiment.

[0014] Fifthly, the present invention provides a computer program product, It includes computer instructions that cause a computer to execute the Java microservice intelligent degradation elastic scaling method of the first aspect above or any corresponding implementation thereof.

[0015] This invention addresses the issue by triggering early degradation when service infrastructure system performance metrics approach preset fault thresholds. This departs from the passive mitigation model that only addresses performance degradation after it occurs, allowing for early prediction of potential fault risks and reducing the probability of failures in core business processes. By labeling business importance levels and quantifying the request value weight of individual requests, the invention incorporates inherent business attributes and request value into the degradation and scaling decision-making system. This combined static business benchmarks and real-time operational status assessment reduces the excessive consumption of cluster resources by non-core business and low-value requests, preventing unintended degradation of core services and ensuring resource allocation aligns with core business needs. Furthermore, by constructing a full-link service dependency graph through static bytecode analysis, the invention can identify potential performance bottlenecks in downstream dependencies of core business processes in advance, enabling targeted degradation operations. To prevent the entire core transaction chain from being blocked due to the performance degradation of downstream dependent services, a business pressure index is constructed by integrating basic system operation indicators and request value. A two-dimensional scaling priority is set, and the amount of resources to be expanded or contracted is dynamically adjusted according to the actual business pressure of the service. When expanding, the resource needs of high-pressure and high-priority core businesses are prioritized, and when contracting, idle resources of non-core and low-pressure services are released first, reducing the phenomenon of over-allocation or under-release of resources and improving the overall resource utilization of the cluster. Business identification and dependency graph construction are completed through static analysis during the compilation or startup phase without modifying the core business code, reducing the cost of solution access and subsequent maintenance, while avoiding the additional performance overhead caused by continuous dynamic analysis at runtime, and reducing the impact on the normal response speed of business services. Attached Figure Description

[0016] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0017] Figure 1This is a schematic diagram of the overall process of a Java microservice intelligent degradation and elastic scaling method according to an embodiment of the present invention; Figure 2 This is a detailed flowchart illustrating a Java microservice intelligent degradation and elastic scaling method according to an embodiment of the present invention. Figure 3 This is a schematic diagram of the structure of a Java microservice intelligent degradation elastic scaling device according to an embodiment of the present invention; Figure 4 This is a structural block diagram of a Java microservice intelligent degradation and elastic scaling device according to an embodiment of the present invention. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention. Example

[0019] This embodiment provides a Java microservice intelligent degradation and elastic scaling method, which can be used in the above-mentioned Java microservice application, which is deployed on a server cluster (such as a transaction service cluster in the e-commerce field, including core service modules such as payment, order, and inventory). Figure 1 This is a flowchart of a Java microservice intelligent degradation and elastic scaling method according to an embodiment of the present invention, such as... Figure 1 As shown, the process includes the following steps: Step S101: Static Business Identification and Service Dependency Graph Construction. During the compilation and startup phases of the Java microservice application, corresponding business identification capabilities are configured. Adopting a priority rule of "compilation first, startup supplement," business code is analyzed using bytecode enhancement technology or annotation processors to extract at least one of the following: custom annotations, method names, parameter types, return value types, and call chain relationships. The business attributes of each service method are identified and labeled with preset and adjustable business importance level tags (including but not limited to S-level - core transaction, A-level - important service, B-level - degradeable service). Simultaneously, static bytecode analysis (using commonly used static bytecode analysis frameworks in this field such as ASM) is used to analyze the call dependencies between service methods, constructing a complete service dependency graph. Specifically, the identification of business importance level labels prioritizes reading the custom business annotations (including but not limited to @CoreBusiness (core) annotation and @DegradableService (degradable non-core) annotation) on service methods. Methods annotated with core transaction class annotations are classified as S-level - core transactions. Methods without custom annotations are classified as S-level - core transactions or A-level - important services based on method name, parameter type, return value type, and business link affiliation. Methods within the core links such as payment, order, and inventory deduction are classified as S-level - core transactions or A-level - important services. Methods used only for log statistics, product collection, personalized recommendations, and other auxiliary experience improvement are classified as B-level - degradable services. The construction of the service dependency graph is completed through static bytecode analysis, which clarifies the upstream caller and downstream dependency of each service method, covers the entire service call link, and is executed only once during the compilation or startup phase, without generating continuous runtime performance overhead.

[0020] Step S102: Runtime Data Collection and Request Value Weight Quantification. After the Java microservice application starts and enters the runtime phase, the JavaAgent bytecode enhancement module (which can use commonly used bytecode enhancement frameworks in this field such as ByteBuddy and ASM) mounted during the startup phase non-intrusively collects full service execution data of each service method without manually adding instrumentation code. The collected data is divided into two dimensions: First, the basic runtime indicators in the service execution data, covering the service's QPS, service response time, exception rate, concurrency, and the CPU utilization and memory utilization of the node, etc., to reflect the current running status and performance bottlenecks of the service, providing basic data support for subsequent risk assessment; Second, the semantic data of business parameters in the service execution data. For the input parameters of each request, semantic features are extracted according to the business meaning of the parameters, including the business type and business amount of transaction-type methods, and the user level of order-type methods. After data collection, the semantic data of business parameters are quantitatively analyzed to determine the request value weight of each service request. The quantification process adopts a linear weighted framework commonly used in this field. Value weights are assigned based on at least one of the business type, business amount, and user level corresponding to the business parameters. The weights can be flexibly adjusted according to the core business requirements. After standardizing the parameters of each dimension, a weighted sum is obtained to obtain the request value weight of each request. At the same time, the request pressure weight of each service method is determined based on the collected QPS, response time, and anomaly rate.

[0021] Step S103: Fusion of Static-Dynamic Dual-Dimensional Data System. The static data (business importance level labels, service dependency graph) obtained in step S101 is merged with the dynamic data (service execution data, request value weight, request pressure weight) obtained in step S102 to construct a complete decision profile for each service method, forming a static-dynamic dual-dimensional data system to support subsequent intelligent decision-making. Static data serves as a long-term, stable benchmark for business priority, changing infrequently during application operation; dynamic data provides feedback on the real-time operational status of services, updating in real-time with changes in business traffic and requests. The fusion of these two data sources reduces decision-making biases caused by a single data dimension, providing comprehensive data support for subsequent degradation and scaling decisions.

[0022] Step S104: Construction of Business Pressure Index. Based on the static-dynamic dual-dimensional data system fused in Step S103, the business pressure index is calculated by combining the request value weight and request pressure weight of each service method. The construction process adopts a dual-dimensional weighted fusion method: first, the basic operation indicators in the execution data of each service are standardized and then weighted and summed to obtain the basic value of service operation pressure; then, a second weighted fusion is performed with the request value weight and request pressure weight to obtain the final business pressure index. The weights in the fusion process can be flexibly adjusted according to the cluster scheduling strategy to ensure that the index can simultaneously reflect the actual operation pressure and business value of the service.

[0023] Step S105: Intelligent Early Degradation and Core Business Link Protection. Based on the dual-dimensional data system of step S103 and the business stress index constructed in step S104, the performance indicator trends of each service method are continuously monitored. When a service method has not reached the preset fault threshold, or only the service execution data or business stress index approaches the threshold, an early degradation operation is performed. The preset fault threshold can be flexibly set based on historical service operation data and service level agreement (SLA) requirements. The judgment of approaching the preset fault threshold can be set according to the business's tolerance for faults. It can be set to 70% to 95% of the preset fault threshold for service execution data or business stress index, or it can be predicted based on the continuous change trend of the indicator. When the indicator is detected to be continuously rising within the preset monitoring period (seconds to minutes, which can be flexibly adjusted) and about to reach the preset fault threshold, it is considered to be approaching the threshold. When early degradation is triggered, combined with the service dependency graph, methods marked as B-level - degradable services and services and requests with a request value weight lower than the preset value threshold are prioritized for degradation. When the sum of the business pressure indexes of all service methods in a Java microservice application exceeds a preset high-pressure threshold, resulting in overall cluster overload, the cluster will centrally allocate available resources to ensure the operation of S-level (core transaction service methods) and service links whose request value weights exceed the preset value threshold, while limiting or suspending resource allocation for B-level (degradable services). The preset high-pressure threshold is set based on the overall resource carrying capacity of the cluster and the upper limit of core business throughput, and can be flexibly adjusted according to the cluster resource redundancy and the business's tolerance for overload.

[0024] Step S106: Perform elastic scaling based on a two-dimensional priority. When allocating, adding, reclaiming, or reducing service runtime resources, a two-dimensional priority ranking rule is adopted: The first ranking dimension is the business pressure index, sorted from high to low; when multiple services have the same business pressure index, the second ranking dimension is the business importance level, sorted in the order of S-level (core transactions), A-level (important services), and B-level (degradable services); if multiple services are all S-level (core transactions) and have the same business pressure index, they are further sorted from high to low according to request value weight. During expansion, service runtime resources are allocated and increased in the order of this ranking; during shrinkage, service runtime resources are reclaimed and reduced in the reverse order of this ranking, prioritizing B-level (degradable services) and A-level (important services). S-level (core transactions) services do not participate in shrinkage. Meanwhile, based on the service's business pressure index and service execution data, the allocation or recovery of service operation resources for each service is dynamically determined. The corresponding resource gap is matched according to the difference between business pressure and service capacity limit, and the resource utilization rate reflected by service execution data is combined to avoid over-allocation or under-release of resources.

[0025] By establishing static identification and service dependency mapping in step S101, business priorities and service dependencies are clearly defined in advance, providing a stable benchmark for subsequent decisions and avoiding performance overhead from runtime dependency analysis. Through data collection and value quantification in step S102, service operation status and request value-related data are obtained, overcoming the shortcomings of existing technologies that only focus on system metrics. Data fusion in step S103 integrates static and dynamic data, reducing decision-making biases caused by single data dimensions. The construction of a business pressure index in step S104 provides a unified quantitative basis for subsequent decisions. Early degradation and core protection in step S105 reduce the probability of failures and ensure the normal operation of core businesses under extreme traffic scenarios. Elastic scaling in step S106 optimizes cluster resource allocation, improves cluster resource utilization, and reduces the phenomenon of insufficient core service resources and idle non-core service resources. The overall solution does not intrude into business code and has no additional continuous performance overhead at runtime. It can improve the problems of insufficient core business protection and the disconnect between resource allocation and business needs in existing technologies, and is suitable for Java microservice deployment scenarios such as e-commerce where there is a division between core and non-core businesses and significant traffic fluctuations. Example

[0026] This embodiment is a preferred embodiment of the present invention. Embodiment 1 is a basic embodiment under a general application scenario. Based on Embodiment 1, this embodiment provides a complete and detailed description of the technical solution of the present invention for a typical server cluster deployment scenario of Java microservice applications in the e-commerce field.

[0027] In the scenario described in this embodiment, the Java microservice application contains a complete transaction loop, with a clear distinction between core and non-core business processes. Business traffic exhibits significant peak-and-trough fluctuations, making it susceptible to sudden traffic spikes. This results in issues such as excessive cluster resource consumption by non-core businesses and insufficient stability of core business processes. The technical solution in this embodiment enables intelligent degradation and elastic scaling across the entire Java microservice chain, balancing the stability of core business services with efficient cluster resource utilization.

[0028] In both the compilation and startup phases of Java microservice applications, corresponding business identification capabilities are configured, ensuring compatibility with the development and deployment specifications of different teams without requiring mandatory adjustments to existing project release processes. Specifically, the compilation phase utilizes annotation processors to achieve static identification of business attributes, while the startup phase employs JavaAgent bytecode enhancement technology to perform supplementary identification and dependency analysis. Both of these technologies are existing, mature, and commonly used methods in the field, and their specific implementations are common knowledge to those skilled in the art, requiring no further elaboration.

[0029] The identification results in both phases adopt a priority rule of "compilation first, startup supplement." Methods that have already completed tagging and dependency analysis in the compilation phase are not repeated in the startup phase; only methods not covered in the compilation phase are supplemented with identification and tagging, balancing identification efficiency and coverage completeness. Neither of these identification methods requires modification of the core logic of the business code; information collection is completed non-intrusively, reducing the integration cost of the solution and decreasing the coupling between degradation and scaling logic and business code. To differentiate the impact of different service methods on the core business process, this embodiment predefines business importance levels to characterize the closeness of the association between the service method and the core transaction loop. These are custom business priority tags used in this embodiment to achieve intelligent degradation and elastic scaling, specifically divided into core-level and non-core-level categories. During compilation or startup, the system first identifies and labels the business attributes of each service method within the business code, assigning them a business importance level tag. The identification process prioritizes custom business annotations on the methods, directly classifying methods annotated with core transaction annotations as core-level business importance. For methods without custom annotations, a comprehensive assessment is made based on the method name, parameter types, return value types, and their relationship to the business chain. If the method is within a core chain directly impacting the transaction loop (e.g., payment, order processing, inventory deduction), it is classified as core-level business importance. If the method is only used for scenarios that do not affect the core transaction loop and are only used to enhance the user experience (e.g., log statistics, product collection, personalized recommendations), it is classified as non-core-level business importance. This automatic identification rule eliminates the need for business personnel to manually configure numerous rules, allowing for the early identification of business priority boundaries. This provides a fixed business benchmark for subsequent decisions, reducing the probability of runtime errors causing misoperations in core business processes. While labeling the importance of services, static bytecode analysis is simultaneously used to clarify the call dependencies between various service methods, identifying the upstream callers and downstream dependencies of each method. To achieve link-level risk prediction, this embodiment constructs a service dependency graph. This service dependency graph is a directed relationship graph obtained through static analysis, representing the call and called relationships between various service methods. It is a custom logical data structure defined in this embodiment to identify upstream and downstream risks in the core link. The graph is statically constructed during the compilation or startup phase, rather than dynamically analyzed at runtime, because static analysis only needs to be executed once when the application starts, avoiding continuous performance overhead during application operation and minimizing its impact on the normal response speed of business services. Furthermore, static analysis covers the entire service call chain, preventing dependency omissions due to runtime traffic not covering certain links, and fully reconstructing the entire business call logic, providing a complete basis for subsequent link-level risk prediction.

[0030] After the Java microservice application completes startup and enters the runtime phase, the JavaAgent bytecode enhancement module mounted during startup non-intrusively collects full runtime data from each service method. This eliminates the need to manually add tracking code within business methods, reducing invasive modifications to business code while ensuring the integrity and real-time nature of the collected data. The collection process has two dimensions. The first dimension is the basic system operation metrics for each service method, covering service QPS, service response time, exception rate, concurrency, CPU utilization of the node, and memory utilization. These basic system operation metrics directly and objectively reflect the current running status and performance bottlenecks of the service methods, serving as core foundational data for determining whether the service is at risk of failure. The second dimension is the semantic data of the business parameters corresponding to the service methods. For each request's input parameters, semantic features are extracted based on the business meaning of the parameters, including the business type and amount for transaction-type methods, the user level for order-type methods, and the product category for query-type methods. The reason for collecting semantic data of business parameters is that existing degradation and scaling solutions only focus on the basic system operation indicators of services, without distinguishing the business value behind requests. This can easily lead to situations where low-value ordinary query requests consume a large amount of system resources, while high-value core transaction requests cannot be allocated enough resources. By collecting semantic data of business parameters, the business importance of each request can be accurately identified, providing business-level support for subsequent decisions and ensuring that degradation and scaling decisions are aligned with both the system's operational status and core business needs. After completing the collection of semantic data of business parameters, in order to quantify the actual contribution of a single request to the business, this embodiment defines a request value weight to characterize the business importance and revenue contribution of a single business request. This is a customized quantitative indicator in this embodiment to distinguish between high / low value requests. Quantitative analysis is performed to obtain the request value weight of each service request. The quantification process allocates value weights based on at least one of the business type, business amount, and user level corresponding to the business parameters. The weight allocation rules can be flexibly adjusted according to the core business needs, without the need for a fixed uniform weight value. For example, in scenarios where high-value transactions are prioritized, the value weight of the business amount dimension can be increased; in scenarios where the service experience of high-level users is prioritized, the value weight of the user level dimension can be increased. The above examples are only used to illustrate the flexibility and adaptability of the solution and do not constitute a limitation of the present invention. The calculation process adopts a linear weighted framework commonly used in the art. First, the business parameters of each dimension are standardized to a uniform order of magnitude, then multiplied by the value weight of the corresponding dimension, and finally the calculation results of each dimension are summed to obtain the request value weight of the request. The corresponding preset value threshold can be flexibly set according to the business degradation strategy. It can be set as a specified quantile value of the request value weight of all requests, or differentiated value thresholds can be set according to business type and user level, without the need for a fixed uniform value.This quantification method can accurately quantify the contribution of each request to the business, enabling subsequent degradation operations to accurately filter out requests that meet the criteria, while ensuring that the solution can be adapted to different types of business scenarios and has a certain degree of versatility.

[0031] After completing the construction of business importance level labels, service dependency graphs, and the collection of basic system operation indicators and request value weights, the four parts of data are merged to build a complete decision profile for each service method. To make decisions that combine both inherent business attributes and real-time operational status, this embodiment constructs a static-dynamic dual-dimensional data system. This system is a complete dataset supporting degradation and scaling decisions, consisting of static business attribute data and dynamic operational status data, forming a static-dynamic dual-dimensional data system that supports intelligent decision-making. The reason for choosing to merge static and dynamic data is that the two types of data are complementary: static business importance level labels and service dependency graphs are inherent attributes of the business and do not change frequently during application operation, providing a long-term and stable benchmark for business priority; dynamic basic system operation indicators and request value weights are the real-time operational status of services, changing in real time with traffic and business requests, providing accurate real-time operational feedback. After the two are integrated, every subsequent decision can simultaneously have a long-term basis for business priorities and precise support for real-time operational status. This can reduce the problems of rigid resource allocation and resource waste caused by relying solely on static tags, and also reduce the probability of core business being misoperated and link-level failures being unpredictable due to relying solely on dynamic indicators, thereby improving the accuracy and rationality of decision-making.

[0032] Based on the integrated static-dynamic dual-dimensional data system, the system continuously monitors the changing trends of basic system operation indicators for each service method, enabling proactive degradation operations and core link protection in extreme scenarios. Unlike existing technologies that only implement degradation after a service reaches a preset failure threshold, this embodiment performs degradation operations proactively when the basic system operation indicators of a service method have not yet reached the preset failure threshold, or are only approaching it. The reason for this design is that when the service's basic system operation indicators reach the preset failure threshold, the service has already experienced performance degradation, and users can already perceive issues such as slow response times and request failures. At this point, performing degradation cannot prevent a negative user experience. Proactive degradation, however, releases resources occupied by non-core businesses before performance degradation occurs, reserving sufficient resource margin for core services, reducing the probability of failure at its source, and achieving a shift from passive loss mitigation to proactive prevention. The preset fault threshold can be flexibly set based on historical service operation data and Service Level Agreement (SLA) requirements. The judgment rule for approaching the preset fault threshold can be flexibly set according to the business's tolerance for faults. It can be set to a range of 70% to 95% of the basic system operation indicators reaching the preset fault threshold, with the range freely adjustable according to business needs. Alternatively, it can be based on the continuous trend of the basic system operation indicators; when the basic system operation indicators are detected to be continuously rising within a preset monitoring period and about to reach the preset fault threshold, it can be considered as approaching the preset fault threshold. The preset monitoring period can be flexibly set from seconds to minutes according to the real-time requirements of the business. The trigger logic for early degradation is implemented in conjunction with the service dependency graph. The service dependency graph accurately identifies the upstream and downstream dependencies of the core business links, focusing on monitoring the basic system operation indicators of downstream dependent methods of the core links. When the basic system operation indicators of downstream dependent methods are detected to be approaching the preset fault threshold, early degradation operations are immediately triggered for services and requests marked as having a preset non-core business importance level or whose request value weight is lower than the preset value threshold. The focus on downstream dependencies in the core service chain stems from the fact that most failures in the core service chain are not due to problems with the core service itself, but rather to performance bottlenecks in its downstream dependent methods, thus hindering the response of the entire core chain. This end-to-end predictive approach allows for the early identification of potential risks in the core chain, enabling resource release through degrading non-core services in advance, ensuring the stability of the entire core chain. Furthermore, the use of parallel "OR" triggering logic covers both inherently non-core services and low-value requests within core services, reducing the excessive resource consumption of low-value requests within core services and further improving the accuracy of degradation operations.When the business pressure index of the entire Java microservice application exceeds a preset high-pressure threshold, resulting in an extreme scenario of cluster overload, the system no longer performs pre-emptive degradation only for single points of risk. Instead, it prioritizes the operation of core service links with core business importance levels marked by preset labeling rules or request value weights higher than preset value thresholds. All available resources within the cluster are concentrated on core links, while resource allocation for non-core businesses is restricted or even suspended. The preset high-pressure threshold is set based on the overall resource carrying capacity of the cluster and the upper limit of core business throughput. It can be set as a critical value for the overall resource utilization rate of the cluster or a cumulative critical value for the business pressure index of the entire cluster, and can be flexibly adjusted according to the cluster's resource redundancy and the business's tolerance for overload. The reason for this design is that when the cluster is overloaded, the total resources can no longer support the normal operation of all businesses. Priority allocation is needed to ensure the availability of the core transaction loop, avoiding a full service avalanche where all businesses cannot operate normally, and ensuring that the core revenue of the business and the core user experience are not affected under extreme traffic scenarios.

[0033] During operation, a business stress index is constructed by simultaneously integrating basic system operation metrics such as QPS and service response time with request value weights, based on a static-dynamic dual-dimensional data system. The reason for not directly using a single basic system operation metric as the standard for scaling up or down is that a single metric cannot fully reflect the actual pressure and business value of the service. For example, some services may have low request concurrency, but each request consumes extremely high system resources; conversely, some services may have high concurrency, but these are all low-value, non-core requests. Judging solely by a single metric can easily lead to scaling up / down decisions that are out of touch with actual business needs. The business stress index, constructed by integrating basic system operation metrics and request value weights, can simultaneously reflect the actual operational pressure and business value of the service, ensuring that scaling up / down decisions align with both system load and core business requirements. The construction of the business stress index adopts a common two-dimensional weighted fusion method. First, the basic system operation metrics are standardized and then weighted and summed to obtain a basic value corresponding to the service's operational pressure. Then, this basic value is weighted and fused again with the request value weights to obtain the final business stress index. The weights during the integration process can be flexibly adjusted according to the cluster's scheduling strategy. In scenarios that prioritize business stability, the weight of the basic value of operational pressure can be increased. In scenarios that prioritize high-value business, the weight of the request value weight can be increased.

[0034] The business stress index is constructed using a two-dimensional weighted fusion approach. The "indicator standardization + weighted summation" method is a common mathematical approach in this field. This invention designs a practical fusion logic for Java microservice intelligent degradation and elastic scaling scenarios, ensuring that those skilled in the art can directly reproduce it. Step 1: Standardization of basic system operation metrics (taking e-commerce scenarios as an example).

[0035] For basic system performance metrics such as QPS, Response Time (RT), CPU utilization, memory utilization, and failure rate, Min-Max standardization (or Z-score standardization, which is not limited in this invention) is used to map each metric to the [0,1] interval, eliminating dimensional differences. The calculation formula is as follows: ; in: Minimum / maximum values ​​of the metrics: determined based on the service's historical operating data over the past 30 days (e.g., the minimum QPS is 0, and the maximum value is the service's peak QPS). Reverse metric adaptation: Service response time and anomaly rate are reverse metrics that are "the higher the value, the worse the situation". After standardization, the complement (1 - the standardized value) is taken to ensure that "the higher the value of all metrics, the greater the pressure".

[0036] Step 2: Calculation of basic service operation pressure values ​​(weighted for the first dimension).

[0037] The standardized basic system operation indicators are linearly weighted and summed using the following formula: ; The total weight is 1. In e-commerce scenarios, the default weight configuration is: CPU utilization (0.3) + memory utilization (0.2) + QPS (0.2) + RT (0.2) + anomaly rate (0.1). Those skilled in the art can adjust it according to the cluster strategy (e.g., when prioritizing stability, the CPU / RT weight can be increased to 0.4 / 0.3).

[0038] Step 3: Secondary weighted fusion (base value + request value weight).

[0039] The service operation pressure baseline value (denoted as S) and the request value weight (denoted as V) are then weighted twice to obtain the final business pressure index (denoted as P), as follows:

[0040] The weighting coefficient α ranges from [0.5, 0.8], and the adaptation rules are clear: priority is given to scenarios that ensure business stability (such as peak sales during promotions): α=0.8 (focusing on system operating pressure); priority is given to scenarios that ensure high-value business (such as high-value transactions): α=0.5 (focusing on request value weight); general scenarios: α=0.7 (balancing system pressure and business value).

[0041] The weights during the fusion process can be flexibly adjusted according to the cluster's scheduling strategy. The adjustment rules only require modifying the aforementioned weight coefficients / α values, without changing the core fusion logic, thus adapting to the degradation and scaling requirements of different business scenarios.

[0042] When allocating resources for scaling up or down, a two-dimensional priority ranking rule is adopted. The specific execution logic is as follows: First, the business pressure index is used as the first dimension, and the service methods are ranked from high to low according to the business pressure index, with the service methods with higher business pressure indices ranking higher. When multiple service methods have the same business pressure index, the business importance level is used as the second dimension for ranking, with core-level service methods ranking higher than non-core-level service methods. If multiple service methods are all core-level and have the same business pressure index, they are further ranked from high to low according to the request value weight, with core-level service methods with higher request value weight ranking higher.

[0043] Taking an e-commerce scenario as an example, the cluster contains five service methods: payment interface (business pressure index 9.5, core level, request value weight 0.95), order generation interface (business pressure index 9.5, core level, request value weight 0.90), inventory deduction interface (business pressure index 8.8, core level, request value weight 0.85), product collection interface (business pressure index 7.2, non-core level, request value weight 0.20), and log statistics interface (business pressure index 6.5, non-core level, request value weight 0.10). After sorting according to the above rules, the final priority is: payment interface > order generation interface > inventory deduction interface > product collection interface > log statistics interface.

[0044] Scaling operations are strictly executed in the order of priority: when the cluster needs to add two server resources, the payment interface (ranked first) is allocated one full server resource first, followed by the order generation interface (ranked second) with the remaining server resource. Core services receive priority resource guarantees, while non-core services are not allocated scaling resources. Scaling operations are strictly executed in the reverse order of priority: when the cluster needs to release one idle server resource, only the server resource corresponding to the log statistics interface (ranked last) is released. Core services (payment, order, inventory) do not participate in the scaling resource release, ensuring that the resource usage of core businesses is not affected. Through these specific sorting and scaling execution rules, a resource scheduling effect of "prioritizing core services during scaling and not affecting core services during scaling" can be achieved, avoiding performance bottlenecks in core businesses due to resource allocation issues.

[0045] Simultaneously, based on the service's business pressure index and basic system operation indicators, the amount of resources to be expanded or reduced for each service is dynamically determined, rather than using a fixed expansion / reduction step. The general rule for dynamically determining the amount of resources to be expanded or reduced is: based on the difference between the business pressure index and the current service's maximum load capacity, the corresponding resource gap is matched, and combined with the resource utilization rate reflected by the basic system operation indicators, the final amount of resources to be expanded or reduced is determined, avoiding over-allocation or under-release of resources. Referring to the e-commerce scenario example above, if the business pressure index of the payment interface is 9.5, its maximum load capacity is 10.0, and the difference is 0.5, combined with the current CPU utilization rate of 80%, it can be determined that the payment interface needs to be expanded with one server (8 CPU cores + 16GB memory); if the business pressure index of the log statistics interface drops to 5.0, its minimum load capacity is 6.0, and combined with the current idle state of only 30% memory utilization, it can be determined that all idle resources of one server for this interface be released, achieving precise resource matching.

[0046] The technical solution of this embodiment enables intelligent degradation and elastic scaling based on business attributes and operational status without intruding on business code or incurring excessive runtime performance overhead. This solution effectively addresses the problems of insufficient core business protection and low matching between resource allocation and business needs when relying solely on basic system operational indicators for degradation and scaling decisions in existing technologies. It allows for early prediction of service failures, reducing the probability of failures in core business links; it improves the utilization rate of cluster resources and adapts to different business scenarios and traffic fluctuations. In addition to the e-commerce field, the technical solution of this embodiment can also be adapted to other Java microservice deployment scenarios with core / non-core business divisions, such as finance and government affairs. The adaptation methods for these other fields are consistent with the implementation logic of the e-commerce scenario disclosed in this embodiment.

[0047] Example 3 This embodiment provides a Java microservice intelligent degradation and elastic scaling device, such as... Figure 3 As shown, it includes: The tagging and graph construction module 301 is used in the compilation and startup phases of Java microservice applications. It adopts the priority rule of "compilation first, startup supplement" to identify the business attributes of each service method and mark the business importance level (core level / non-core level). At the same time, it analyzes the call dependencies between each service method through static bytecode analysis to build a complete service dependency graph.

[0048] The data acquisition and quantification module 302 is used to collect full runtime data of each service method non-intrusively through the JavaAgent bytecode enhancement module mounted during the startup phase of the Java microservice application. The runtime data includes basic system runtime indicators (QPS, response time, CPU utilization, memory utilization, exception rate, etc.) and business parameter semantic data (business type, transaction amount, user level, etc.). The module performs standardization and linear weighted quantification analysis on the business parameter semantic data to obtain the request value weight of each request.

[0049] The dual-dimensional system fusion module 303 is used to merge static data and dynamic data. The static data includes business importance level labels and service dependency graphs, while the dynamic data includes basic system operation indicators and request value weights. This constructs a complete decision profile for each service method, forming a static-dynamic dual-dimensional data system.

[0050] The intelligent decision execution module 304 is used to identify the upstream and downstream dependencies of the core service link based on the dual-dimensional data system and real-time business pressure index, combined with the service dependency graph, and simultaneously execute two continuous monitoring: (1) monitor the changing trend of the basic system operation indicators or business pressure index of each service method, and when the basic system operation indicators or business pressure index approach the preset fault threshold, identify the downstream risks and perform early downgrade operations, downgrade non-core level business and requests with request value weight lower than the preset value threshold based on the preset labeling rules; (2) Monitor the overall business pressure index of the Java microservice application cluster obtained by summarizing the business pressure index of each service method. When the overall business pressure index of the cluster exceeds the preset high threshold (overload of the cluster), concentrate available resources to ensure the operation of core-level business and core service links marked by preset annotation rules and whose request value weight is higher than the preset value threshold, and restrict or suspend the allocation of non-core business resources.

[0051] The elastic scaling control module 305 is used to construct the business pressure index of each service method in real time based on a dual-dimensional data system, integrating basic system operation indicators and request value weights (providing a unified data foundation for the intelligent decision execution module 304 and this module). It adopts a dual-dimensional priority sorting rule (first dimension: business pressure index from high to low; second dimension: business importance level from core level to non-core level; supplementary services within the core level are sorted by request value weight from high to low) to allocate resources for service expansion and contraction, and dynamically determines the amount of resources to be expanded or contracted for each service. During expansion, resources are allocated in ascending order of sorting, and during contraction, resources are released in descending order of sorting, and core-level services do not participate in contraction.

[0052] Further functional descriptions of the above modules are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0053] Example 4 In this embodiment, the Java microservice intelligent degradation elastic scaling device is presented in the form of a functional unit. Here, a unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.

[0054] This invention also provides a computer device having the above-described features. Figure 4 The Java microservice intelligent degradation elastic scaling device shown is illustrated.

[0055] Please see Figure 4 , Figure 4 This is a schematic diagram of the structure of a computer device provided in an optional embodiment of the present invention, such as... Figure 4 As shown, the computer device includes one or more processors 10, memory 20, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components communicate with each other via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the computer device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices (such as display devices coupled to the interfaces). In some alternative implementations, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple computer devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system). Figure 4 Take a processor 10 as an example.

[0056] Processor 10 may be a central processing unit, a network processor, or a combination thereof. Processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GDA), or any combination thereof.

[0057] The memory 20 stores instructions executable by at least one processor 10 to cause the at least one processor 10 to perform the method shown in the above embodiments.

[0058] The memory 20 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the computer device. Furthermore, the memory 20 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some alternative embodiments, the memory 20 may optionally include memory remotely located relative to the processor 10, and these remote memories may be connected to the computer device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0059] The memory 20 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, hard disk or solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0060] The computer device also includes a communication interface 30 for communicating with other devices or communication networks.

[0061] Example 5 This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.

[0062] Example 6 A portion of this application can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to this application through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0063] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A Java microservice intelligent degradation and elastic scaling method, applied to electronic devices deploying Java microservice applications, characterized in that, At any stage, during the compilation and startup phases of a Java application, the business priority of each service method is determined based on business-related information in the code. During the application runtime phase, service execution data is collected, and request value weights and request pressure weights are assigned to each service method based on preset rules. The preset rules are pre-defined quantitative rules used for weight assignment or business pressure index calculation. The preset rules include value weight thresholds, expansion thresholds, reduction thresholds, and system pressure thresholds. Predictive degradation is performed based on the business priority. Predictive degradation is a degradation operation when the service performance shows a deterioration trend but no failure or anomaly occurs. Differential degradation is performed based on system pressure and the value weight of the request, where system pressure is a comprehensive indicator reflecting the system's operating load; The business pressure index is calculated based on preset rules and the request value weight and request pressure weight. Service elastic scaling is then adjusted according to the business pressure index. The business pressure index is a comprehensive quantitative indicator that represents the business value and operational pressure of the service method.

2. The method according to claim 1, characterized in that, The determination of the business priority of each service method specifically includes: identifying the business attributes corresponding to each service method based on the business attribute-related code characteristics of any stage in the Java application compilation stage and startup stage, and configuring a core business layer and at least one non-core business layer for at least one service method.

3. The method according to claim 1, characterized in that, The service execution data collected at runtime assigns corresponding weights to each service method, specifically including: The data collection method includes a non-intrusive data collection method that does not modify the business code; the service execution data includes business semantic data and service operation data; wherein, the business semantic data includes business attribute information corresponding to the input parameters of the business method, and the service operation data includes QPS, response time, and exception rate; Requests are assigned value weights based on the business semantic data and pressure weights based on the service operation data. The request value weights represent the business importance of the request, and the request pressure weights represent the service's operational load.

4. The method according to claim 1, characterized in that, The predictive degradation based on business priority specifically includes: Monitor service performance trends. When performance deteriorates but no failures or anomalies occur, perform degradation operations on service method calls corresponding to non-core business layers based on business priority to ensure the stability of the core business chain composed of service methods corresponding to core business layers.

5. The method according to claim 1, characterized in that, The degradation based on system pressure and request value weights specifically includes: When the system pressure reaches a preset threshold, traffic control is implemented based on the value weight threshold in the preset rules. Priority is given to ensuring the execution of service methods corresponding to requests with a value weight higher than the value weight threshold, while rate limiting or degradation operations are performed on service methods corresponding to requests with a value weight lower than the value weight threshold.

6. The method according to claim 1, characterized in that, The process of implementing service elastic scaling and control based on the business stress index specifically includes: The service operation resources are dynamically adjusted based on the comparison results between the business pressure index and the preset expansion threshold and preset reduction threshold, and resources are allocated to the service methods corresponding to the core business level in a priority manner, rather than scaling up and down based solely on system hardware indicators.

7. A Java microservice intelligent degradation and elastic scaling device, applied to electronic devices deploying Java microservice applications, characterized in that, The device includes: The static priority configuration module is used to identify the business attributes of each service method based on the business attribute-related code characteristics at any stage of the Java application compilation and startup phases, and to configure a core business layer and at least one non-core business layer for at least one service method. The runtime data collection and weight calculation module is used to collect service execution data during the application runtime phase and assign request value weight and request pressure weight to each service method based on preset rules. The service execution data includes business semantic data and service operation data. The business semantic data includes business attribute information corresponding to the input parameters of the business method, and the service operation data includes QPS, response time, and exception rate. The intelligent degradation module is used to perform predictive degradation based on business priority and differentiated degradation based on system pressure and request value weight. The predictive degradation is to perform degradation operations on service method calls corresponding to non-core business layers when a service performance degradation trend is detected but no failure or anomaly occurs. The differentiated degradation is to implement traffic control based on the value weight threshold in the preset rules when the system pressure reaches the preset threshold, prioritizing the execution of service methods corresponding to requests with a request value weight higher than the value weight threshold, and performing rate limiting or degradation operations on service methods corresponding to requests with a request value weight lower than the value weight threshold. The elastic scaling control module is used to dynamically adjust service operation resources based on the comparison results between the business pressure index and the preset expansion threshold and preset reduction threshold, and prioritizes the allocation of resources for service methods corresponding to the core business level, rather than implementing scaling solely based on system hardware indicators.

8. A computer device, characterized in that, include: A memory and a processor are interconnected, the memory stores computer instructions, and the processor executes the computer instructions to perform the Java microservice intelligent degradation elastic scaling method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to execute the Java microservice intelligent degradation elastic scaling method according to any one of claims 1 to 6.

10. A computer program product, characterized in that, It includes computer instructions for causing a computer to execute the Java microservice intelligent degradation elastic scaling method according to any one of claims 1 to 6.

Images