Service resource management method, device and equipment for enterprise business distributed application, and medium

Abstract

The application discloses a service resource management method and device for enterprise business distributed application, equipment and medium, relates to the technical field of enterprise business, and comprises the following steps: collecting resource interface data of each business service instance through a pre-deployed monitoring agent; any business service instance is independently deployed with a monitoring agent; after the resource interface data is preprocessed through a target edge node, the target cloud aggregates and stores the data according to a preset monitoring dimension to obtain target monitoring data; if it is judged that the preset service reorganization condition is met based on the target monitoring data, a service reorganization operation is performed; if it is judged that the preset service expansion condition is met based on the target monitoring data, a component list of the object to be expanded is determined, and based on the component list and a preset expansion security mechanism, a new business service instance is deployed; the component list comprises a business component for realizing the business logic of the object to be expanded, and the business logic and the interface calling logic are mutually decoupled.

Description

Technical Field

[0001] This invention relates to the field of enterprise business technology, and in particular to a method, apparatus, equipment and medium for managing service resources in distributed enterprise business applications. Background Technology

[0002] The cloud computing field is developing rapidly, and there is an increasing amount of research on cloud resource management platforms and scheduling algorithms for distributed enterprise applications. The core of these platforms adopts a coarse-grained resource allocation, passive scaling of entire instances, and fixed service binding model, which can only be based on the overall load scheduling of instances / modules. Because the existing fixed and coarse-grained resource allocation methods can lead to problems such as resource fragmentation, over-allocation, and low cluster resource utilization, and because the scaling process only focuses on the efficiency of adding resources and lacks encryption and verification mechanisms, it is prone to security risks such as instance configuration tampering and data transmission interception, which affect the stability of distributed applications and can no longer meet the requirements of high resource utilization and secure operation of distributed applications.

[0003] In summary, optimizing service resource management methods for enterprise distributed applications to meet the demands for high resource utilization and secure operation is a pressing issue that needs to be addressed. Summary of the Invention

[0004] In view of this, the purpose of this invention is to provide a service resource management method, apparatus, device, and medium for enterprise business distributed applications, which can optimize the service resource management method for enterprise business distributed applications to meet the requirements of high resource utilization and secure operation of distributed applications. The specific solution is as follows: Firstly, this application provides a service resource management method for a distributed enterprise business application, applied to a target distributed enterprise business application. The target distributed enterprise business application includes several business domains, and each business domain deploys several business service instances, so that the business domain provides corresponding enterprise business services through the business service interfaces carried by the business service instances; wherein, the method includes: Resource interface data of each of the aforementioned business service instances are collected through a pre-deployed monitoring agent; each of the aforementioned business service instances independently deploys one of the aforementioned monitoring agents; After the resource interface data is preprocessed by the target edge node, it is aggregated and summarized by the target cloud according to the preset monitoring dimensions and stored locally to obtain the target monitoring data; If, based on the target monitoring data, it is determined that the current distributed application of the target enterprise business meets the preset service reorganization conditions, then the corresponding service reorganization operation is performed for each of the business service instances. If, based on the target monitoring data, it is determined that the current distributed application of the target enterprise business meets the preset service expansion conditions, then a component list of the object to be expanded is determined. Based on the component list and the preset expansion security mechanism, a new business service instance is deployed for the object to be expanded. The object to be expanded includes the business domain to be expanded and the business service interface to be expanded. The component list includes business components used to implement the business logic of the object to be expanded, and the business logic and the interface call logic are decoupled from each other.

[0005] Optionally, the step of collecting resource interface data of each of the business service instances through a pre-deployed monitoring agent includes: By using a pre-deployed monitoring agent, resource interface data of each of the aforementioned business service instances are collected, and the resource interface data is statistically analyzed to obtain interface-related data of each business service interface carried by the business service instance. Accordingly, after preprocessing the resource interface data through the target edge node, the data is aggregated and summarized by the target cloud according to preset monitoring dimensions and stored locally to obtain target monitoring data, including: By using the target edge node, outliers in the resource interface data and the interface-related data are removed, and the removed data is sent to the target cloud. Through the target cloud, the interface-related data in the removed data is aggregated and calculated to obtain business service interface-level monitoring data, and the instance indicator data in the removed data is aggregated and calculated to obtain business service instance-level monitoring data, and the interface-related data and instance indicator data under the same business domain in the removed data are aggregated and calculated to obtain business domain-level monitoring data. The target monitoring data is stored locally according to preset monitoring dimensions through the target cloud; the target monitoring data includes the business service interface level monitoring data, the business service instance level monitoring data, and the business domain level monitoring data.

[0006] Optionally, if based on the target monitoring data, it is determined that the current distributed application of the target enterprise business meets the preset service reorganization conditions, then corresponding service reorganization operations are performed for each of the business service instances, including: If it is determined based on the target monitoring data that a first business service interface exists in the business service interface, then it is determined that the current target enterprise business distributed application meets the preset service reorganization conditions, and the service scope of the first business service instance is extended to the first business service interface; If it is determined based on the target monitoring data that a second business service interface exists in the business service interface, then it is determined that the current target enterprise business distributed application meets the preset service reorganization conditions, and the service capability of the second business service instance to the second business service interface is reduced. Wherein, the first business service interface is a business service interface whose average load is higher than a preset average load threshold; the first business service instance is a business service instance that meets preset expansion conditions; the preset expansion conditions are that the current resource usage is lower than a preset resource usage threshold, and the current resource can support a call volume that is not lower than the upper limit of the call frequency of the first business service interface; the second business service interface is a business service interface whose average load is lower than a preset average load threshold throughout a first preset time period; the second business service instance is a business service instance that carries the second business service interface.

[0007] Optionally, if based on the target monitoring data, it is determined that the current distributed application of the target enterprise business meets the preset service reorganization conditions, then corresponding service reorganization operations are performed for each of the business service instances, including: If it is determined based on the target monitoring data that a first business domain exists among the plurality of business domains, then it is determined that the current target enterprise business distributed application meets the preset service reorganization conditions, and the third business service interface and the fourth business service interface under the first business domain are determined. In the first business domain, the target resources occupied by the third business service interface are migrated to the fourth business service interface; Wherein, the first business domain is the business domain that carries the third business service interface and the fourth business service interface, and the resource utilization rate of the business domain is lower than the first preset resource utilization rate threshold; the third business service interface is the business service interface whose interface resource utilization rate is lower than the second preset resource utilization rate threshold throughout the second preset time period; the fourth business service interface is the business service interface whose interface resource utilization rate is higher than the third preset resource utilization rate threshold throughout the second preset time period; the third preset resource utilization rate threshold is greater than the second preset resource utilization rate threshold.

[0008] Optionally, if based on the target monitoring data, it is determined that the current distributed application of the target enterprise business meets the preset service expansion conditions, then a component list of the objects to be expanded is determined, and based on the component list and the preset expansion security mechanism, a new business service instance is deployed for the objects to be expanded, including: If, based on the target monitoring data, it is determined that there are objects to be scaled up in the target enterprise business distributed application, then it is determined that the current target enterprise business distributed application meets the preset service scaling conditions, a new business service instance is created, and the first component list of the objects to be scaled up is determined; the objects to be scaled up are those whose load is continuously higher than a preset load threshold within a third preset time period. Dependency analysis is performed on the objects to be scaled up based on the first component list to identify the affected objects and adjust the routing of the affected objects to the new business service instance; Based on the second component list of the newly added business service instance, corresponding component summary information is generated, and the component summary information is digitally signed to obtain the corresponding component signature data; The second component list and the component signature data are packaged to generate the new business service instance cluster package of the new business service instance; Deploy the newly added business service instance cluster package, verify the identity of the newly added business service instance, and after the identity verification is successful, verify the integrity of the newly added business service instance cluster package, so as to start the newly added business service instance after the integrity verification is successful.

[0009] Optionally, the step of packaging the second component list and the component signature data to generate the new business service instance cluster package of the new business service instance further includes: Based on the component summary information and the instance identifier of the newly added business service instance, and using the target encryption algorithm, a temporary instance identity certificate for the newly added business service instance is generated. Accordingly, the identity verification of the newly added business service instance includes: Obtain the pre-generated root certificate and intermediate certificate; The identity of the newly added business service instance is verified based on the root certificate, the intermediate certificate, and the temporary instance identity certificate, and according to the target certificate chain.

[0010] Optionally, the step of generating corresponding component summary information based on the second component list of the newly added business service instance, and digitally signing the component summary information to obtain corresponding component signature data, further includes: Determine the instance configuration file list of the newly added business service instance, and generate a baseline configuration file summary for each configuration file in the instance configuration file list to obtain a baseline instance configuration file list including the baseline configuration file summary; Generate a baseline configuration file summary of the instance configuration file list, and digitally sign the baseline configuration file summary to obtain the corresponding configuration signature data; The baseline instance configuration file list, the baseline configuration file summary, and the configuration signature data are encapsulated into a baseline verification package for the newly added business service instance; Accordingly, verifying the integrity of the newly added business service instance cluster package includes: Obtain the list of benchmark instance configuration files, the total summary of the benchmark configuration files, and the configuration signature data from the benchmark verification package; The configuration signature data is signed and verified, and after the verification is successful, the total local configuration file summary of the local configuration file list of the newly added business service instance cluster package is calculated. The total summary of the local configuration files is compared with the total summary of the baseline configuration files. After determining that the list of local configuration files has not been tampered with based on the comparison results, the local configuration file summary of each local configuration file in the list of local configuration files is calculated. The local configuration file summary is compared with the baseline configuration file summary in the baseline instance configuration file list to verify the integrity of each local configuration file.

[0011] Secondly, this application provides a service resource management device for a distributed enterprise business application, applied to a target distributed enterprise business application. The target distributed enterprise business application includes several business domains, and each business domain deploys several business service instances, so that the business domain provides corresponding enterprise business services through the business service interfaces carried by the business service instances; wherein, the device includes: The data acquisition module is used to collect resource interface data of each of the aforementioned business service instances through a pre-deployed monitoring agent; each of the aforementioned business service instances independently deploys one of the aforementioned monitoring agents; The data storage module is used to preprocess the resource interface data through the target edge node, aggregate and summarize it through the target cloud according to the preset monitoring dimensions, and store it locally to obtain target monitoring data. The operation execution module is used to perform corresponding service reorganization operations for each of the business service instances if it is determined, based on the target monitoring data, that the current distributed application of the target enterprise business meets the preset service reorganization conditions. The instance deployment module is used to determine the component list of the target enterprise business distributed application to be expanded if, based on the target monitoring data, it is determined that the current target enterprise business distributed application meets the preset service expansion conditions. Based on the component list and the preset expansion security mechanism, the module deploys new business service instances for the target business application to be expanded. The target business application to be expanded includes the business domain to be expanded and the business service interface to be expanded. The component list includes business components used to implement the business logic of the target business application to be expanded, and the business logic and the interface call logic are decoupled.

[0012] Thirdly, this application provides an electronic device, comprising: Memory, used to store computer programs; A processor is used to execute the computer program to implement the aforementioned service resource management method for distributed enterprise business applications.

[0013] Fourthly, this application provides a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned service resource management method for distributed enterprise business applications.

[0014] In this application, resource interface data of each business service instance is collected through a pre-deployed monitoring agent; each business service instance independently deploys a monitoring agent; after the resource interface data is preprocessed through the target edge node, it is aggregated and summarized by the target cloud according to a preset monitoring dimension and stored locally to obtain target monitoring data; if, based on the target monitoring data, it is determined that the current target enterprise business distributed application meets the preset service reorganization conditions, then the corresponding service reorganization operation is performed for each business service instance; if, based on the target monitoring data, it is determined that the current target enterprise business distributed application meets the preset service expansion conditions, then a component list of the object to be expanded is determined, and based on the component list and the preset expansion security mechanism, a new business service instance is deployed for the object to be expanded; the object to be expanded includes the business domain to be expanded and the business service interface to be expanded; the component list includes business components used to implement the business logic of the object to be expanded, and the business logic and the interface call logic are decoupled. As can be seen from the above, this application collects resource interface data of each business service instance by deploying a monitoring agent independently for each business service instance. After preprocessing by the target edge node, the data is uploaded to the cloud and aggregated and stored according to preset monitoring dimensions to form target monitoring data. Then, based on the target monitoring data, if the current target enterprise business distributed application meets the preset service reorganization conditions, a service reorganization operation is performed. If the preset service expansion conditions are met, a list of components to be expanded is determined and new business service instances are deployed in conjunction with the expansion security mechanism. The business components in the component list are used to implement business logic, and the business logic is decoupled from the interface call logic. In this way, through the process described in this application, monitoring agents are independently deployed to collect data for each business service instance, enabling fine-grained and interference-free resource data collection and ensuring the integrity and independence of monitoring data collection. By preprocessing at edge nodes and aggregating and storing data in the cloud, the processing pressure on the cloud can be reduced and the regularity and availability of monitoring data can be improved. Based on the monitoring data, automatic judgment and execution of service reorganization can be performed, allowing distributed applications to dynamically adapt to the business operation status and improve system stability. Instance deployment based on the decoupled component list and expansion security mechanism can ensure that business logic and interface logic do not interfere with each other during expansion, and can also improve the security and deployment efficiency of the expansion process. This optimizes the service resource management method of enterprise business distributed applications to meet the needs of high resource utilization and secure operation of distributed applications. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0016] Figure 1 This application discloses a flowchart of a service resource management method for distributed enterprise business applications. Figure 2 This is a schematic diagram of the system architecture design for a service resource management method for distributed enterprise business applications disclosed in this application. Figure 3 This is a schematic diagram of a layered system architecture for a service resource management method for distributed enterprise business applications disclosed in this application. Figure 4 This is a schematic diagram of a single-component structure disclosed in this application; Figure 5 This is a schematic diagram of a cross-component dependency structure disclosed in this application; Figure 6 This is a schematic diagram of a secure expansion process disclosed in this application. Figure 7 This is a schematic diagram of the service resource management device for a distributed enterprise business application disclosed in this application. Figure 8 This is a structural diagram of an electronic device disclosed in this application. Detailed Implementation

[0017] 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, and 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.

[0018] The cloud computing field is developing rapidly, and there is an increasing amount of research on cloud resource management platforms and scheduling algorithms for distributed enterprise applications. The core of these platforms adopts a coarse-grained resource allocation, passive scaling of entire instances, and fixed service binding model, which can only be based on the overall load scheduling of instances / modules. Because the existing fixed and coarse-grained resource allocation methods can lead to problems such as resource fragmentation, over-allocation, and low cluster resource utilization, and because the scaling process only focuses on the efficiency of adding resources and lacks encryption and verification mechanisms, it is prone to security risks such as instance configuration tampering and data transmission interception, which affect the stability of distributed applications and can no longer meet the requirements of high resource utilization and secure operation of distributed applications.

[0019] To overcome the aforementioned technical problems, this application provides a service resource management method for enterprise business distributed applications, which can optimize the service resource management method for enterprise business distributed applications to meet the needs of high resource utilization and secure operation of distributed applications.

[0020] See Figure 1 As shown, this invention discloses a service resource management method for enterprise business distributed applications, applied to a target enterprise business distributed application. The target enterprise business distributed application includes several business domains, and each business domain deploys several business service instances, so that the business domain provides corresponding enterprise business services through the business service interfaces carried by the business service instances. The method includes: Step S11: Collect resource interface data of each of the business service instances through a pre-deployed monitoring agent; each of the business service instances independently deploys one of the monitoring agents.

[0021] In this embodiment, a lightweight monitoring agent is independently deployed for each business service instance (regardless of which module (i.e., business domain) it belongs to or which interfaces it carries). This agent serves as the source of all monitoring data. Each monitoring agent collects resource interface data of the corresponding business service instance at a frequency of 1-5 seconds per instance, avoiding excessive resource consumption by the monitoring itself. For multi-module (business domain) distributed applications, this embodiment establishes a three-level monitoring dimension: module (business domain) - service interface - resource metric. Module (business domain) level: monitors the overall CPU (Central Processing Unit) utilization, memory usage, and network bandwidth of each functional module (such as the order module and logistics module); Interface level: focuses on the call frequency, response time, and error rate of each service interface under the module (such as the order creation interface and order query interface of the order module); Resource metric level: refined to the computing resources (such as the number of threads) and storage resources (such as temporary cache usage) corresponding to the interface.

[0022] Specifically, resource interface data of each business service instance is collected through a pre-deployed monitoring agent, and the resource interface data is statistically analyzed to obtain interface-related data of each business service interface carried by the business service instance. In other words, resource interface data of each business service instance is collected through pre-deployed monitoring agents. Only the resource and interface data of the current instance are collected to avoid cross-instance interference, and the collection frequency is controlled at 1-5 seconds / time to ensure lightweight and non-intrusiveness. The collected content specifically includes: overall instance resources: CPU utilization, memory utilization, network bandwidth (basic data for module-level monitoring); fine-grained interface-level data: call frequency, response time, error rate of each interface, and resource indicators such as the number of threads and temporary cache usage corresponding to the interface. Subsequently, the resource interface data is statistically analyzed. The monitoring agent splits and aggregates the data of the current instance according to the interface dimension. For example, if an instance simultaneously hosts an order creation interface and an order query interface, the monitoring agent will separately statistically analyze: the call count, average response time, error rate of each interface, and resource indicators such as the number of threads processing each interface request and the temporary cache size occupied by the interface, to obtain the interface-related data of each business service interface hosted by the corresponding instance, that is, interface-level resource data. This interface-level data will be directly reported to the cloud to accurately locate which interface has a load bottleneck, so as to achieve interface-level monitoring.

[0023] It should be noted that, in order to address the problems caused by existing fixed, coarse-grained resource allocation methods, such as resource fragmentation, over-allocation, and low cluster resource utilization, and the lack of cryptographic security protection in the expansion process, which can no longer meet the requirements of high resource utilization and secure operation of distributed applications, this application proposes a method for dynamic allocation and secure expansion of service resources based on module-level fine-grained monitoring for large-scale enterprise-level distributed applications. This is essentially a service resource management method for enterprise business distributed applications, belonging to the fields of cloud-native computing, microservice architecture resource scheduling, and distributed system observability technology. It is particularly applicable to business scenarios with stringent requirements for high concurrency, high availability, and high security, such as e-commerce trading platforms, core financial trading systems, government cloud service clusters, and cross-border e-commerce back-end systems. It enables fine-grained monitoring of resource occupancy, accurately perceiving the resource consumption and load status of each service interface under a module; establishes a dynamic service reorganization mechanism based on resource load, which can adjust the service capacity of instances according to interface-level load, breaking the limitations of fixed deployment architectures; and incorporates instance integrity protection measures during dynamic expansion to avoid configuration tampering and data security risks, while simultaneously improving cluster resource utilization. Figure 2The diagram shows a system architecture design of a service resource management method for enterprise business distributed applications provided in this application. It consists of six core components: a signature verification service system, a component management system, an application packaging system, a service operation and maintenance system, a CA (Certification Authority), and a cryptographic machine. These systems collaborate to complete module-level fine-grained monitoring, dynamic allocation of service resources, and secure expansion. Specifically, the cryptographic machine provides hardware-level cryptographic operation support for the entire system, enabling low-level cryptographic operations such as data encryption, decryption, signing, and verification, ensuring key security and computational reliability. The CA (Certification Authority) is responsible for issuing and managing digital certificates for service instances and various systems, providing basic identity authentication capabilities and certificate support for instance legitimacy verification during expansion. The signature verification service system, based on the cryptographic machine and CA certificates, performs digital signatures and verifications on service instance configurations, expansion commands, and data interaction messages, ensuring data integrity and tamper-proofing; it is the core verification unit for secure expansion. The component management system is responsible for managing the functional modules of the distributed application. The system maintains a three-tiered component list of modules (business domains) – interfaces – resources, providing component metadata for fine-grained monitoring and dynamic reconfiguration. The application packaging system, based on the component list from the component management system, packages service interfaces, runtime environments, and security configurations into dynamically deployable service instance packages, supporting on-demand interface combination and dynamic adjustment of instance service capabilities. The service operation and maintenance system, as the core of overall scheduling and management, enables fine-grained resource monitoring, load analysis, dynamic service reconfiguration, resource allocation decisions, and expansion process scheduling at the module / interface level, while also linking with other systems to complete instance deployment, configuration updates, and security verification.

[0024] It should be pointed out that, as Figure 3The diagram illustrates a layered system architecture for a service resource management method for distributed enterprise business applications provided in this application. It comprises three core processes and six systems, with each module working collaboratively to achieve fine-grained monitoring, dynamic service reconfiguration, and secure scaling: Top-level process (administrator side): The administrator initiates operation commands, which flow sequentially through the component management system, signature verification service system, and application packaging system, ultimately delivering to the service operation and maintenance system for configuration distribution and instance management. This enables the administrator to control the entire process of components, signing, packaging, and operation and maintenance. Middle-level process (developer side): Developers submit code and configurations, which are then processed through the component management system (developer version), signature verification service system (developer version), and application packaging system (developer version) to complete the development, signing, and packaging of application components, ensuring component integrity and traceability during the development phase. Bottom-level process (business operation side): The component management system maintains multiple business components and distributes component metadata and dependencies to the service operation and maintenance system. The service operation and maintenance system is divided into multiple service units, and component instances are dynamically scheduled according to the load. Each service unit interacts with the application packaging system through the signature verification service system to generate and verify instance packages, which are ultimately deployed as multiple business instances (Service Instance 1~5) to provide services to the outside world, thereby achieving fine-grained scheduling at the component level, dynamic instance splitting, and secure scaling. Supporting systems: CA (Certificate Authority): Provides digital certificates for the entire system for identity authentication and signature verification. Cryptographic machine: Provides hardware-level cryptographic computing capabilities to ensure the security and trustworthiness of signature, encryption, and other operations. In this way, this embodiment deploys monitoring agents independently for each business service instance, enabling dedicated collection and isolation of resource interface data, avoiding mutual interference between data collection from different instances, and improving the accuracy and stability of data collection. Statistical processing of the collected data can extract effective relevant data from each business service interface, providing reliable data support for subsequent monitoring and analysis. A three-level fine-grained monitoring system is established to accurately perceive interface-level load and resource consumption, solving the problem of coarse-grained monitoring in existing technologies, significantly improving cluster resource utilization, and reducing resource waste and system overhead.

[0025] Step S12: After preprocessing the resource interface data through the target edge node, the target cloud aggregates and summarizes the data according to the preset monitoring dimensions and stores it locally to obtain target monitoring data.

[0026] In this embodiment, the target edge node first preprocesses the resource interface data, and then the target cloud aggregates and summarizes the data according to the preset monitoring dimensions and stores it locally to form target monitoring data.

[0027] Specifically, outliers in the resource interface data and interface-related data are removed through the target edge node, and the resulting removed data is sent to the target cloud. The target cloud then aggregates and calculates the interface-related data from the removed data to obtain business service interface-level monitoring data, aggregates and calculates the instance indicator data from the removed data to obtain business service instance-level monitoring data, and aggregates and calculates the interface-related data and instance indicator data within the same business domain from the removed data to obtain business domain-level monitoring data. The target monitoring data is then stored locally according to preset monitoring dimensions through the target cloud. The target monitoring data includes the business service interface-level monitoring data, the business service instance-level monitoring data, and the business domain-level monitoring data. In other words, the target edge node performs preliminary filtering on the resource interface data and the interface-related data to remove outliers (such as instantaneous CPU spikes) to avoid misjudgments. Then, it sends the data to the target cloud. The target cloud summarizes and calculates the interface-related data and instance indicator data in the filtered data to obtain business service interface-level monitoring data and business service instance-level monitoring data. It also summarizes and calculates the two types of data under the same business domain in the filtered data to obtain business domain-level monitoring data. The full amount of time-series data is stored locally in a time-series database (such as InfluxDB) according to preset monitoring dimensions. The average interface load within 5 minutes is calculated based on the sliding window algorithm as the basis for resource adjustment, which ensures data real-time performance and avoids misscheduling caused by short-term fluctuations. In other words, for module-level monitoring, after receiving the reported data from all service instances, the cloud will perform aggregation calculations according to the module dimension: Resource dimension: Summing / averaging the CPU, memory, and network bandwidth data of all service instances under the same module to obtain the overall resource utilization of the module; Interface dimension: Aggregating the call frequency, response time, error rate, and other data of all interfaces under the same module to obtain the overall interface-level performance of the module. For example, if there are 10 service instances under the order module, the cloud will take the average CPU utilization of the 10 instances as the overall CPU utilization of the order module, and simultaneously aggregate the call volume of all order-related interfaces to obtain a module-level interface traffic overview. For resource metric-level monitoring, the monitoring agent will directly bind resource metrics to interfaces during collection. For example, if the order creation interface occupies 80% of the instance threads, the monitoring agent will record the correspondence between the interface and the number of threads. When aggregating data, the cloud can view the resource consumption details of a single interface, as well as the sum / percentage of resource metrics for all interfaces under the module, achieving the finest-grained resource tracking.In this way, the edge node preprocessing in this embodiment can effectively reduce the computing pressure on the cloud and improve data processing efficiency. By aggregating and storing the data in the cloud according to preset monitoring dimensions, the monitoring data can be standardized and unified, making it easy to query and analyze, and providing a reliable data foundation for subsequent business judgment. The edge node first removes outliers, which can improve the accuracy of subsequent data and reduce the amount of invalid computing in the cloud. The cloud summarizes and calculates the data according to three dimensions: interface, instance, and business domain, and stores it according to the dimension, which can form multi-granular and hierarchical monitoring indicators. This can accurately locate bottlenecks, realize fine-grained resource allocation, avoid resource waste, and make the monitoring data structure clear, easy to retrieve and use for decision-making. The monitoring architecture of lightweight monitoring agent collection combined with edge computing preprocessing has low monitoring resource consumption. Combined with the sliding window algorithm, it can realize stable load judgment, reduce the complexity of scheduling decisions, and improve the overall performance and scheduling efficiency of the system.

[0028] Step S13: If, based on the target monitoring data, it is determined that the current target enterprise business distributed application meets the preset service reorganization conditions, then the corresponding service reorganization operation is performed for each of the business service instances.

[0029] In this embodiment, the target enterprise's distributed business application is judged based on the target monitoring data to determine whether it meets the preset service reorganization conditions. If it does, the corresponding service reorganization operation is performed on each of the business service instances. It should be noted that the preset service reorganization conditions in this embodiment include multiple conditions such as interface-level, module-level, and cluster-level conditions, corresponding to multiple service reorganization operations. Among them, the interface-level condition is the average load of a service interface within a sliding window over a certain period of time, including three core indicators: call frequency: the total number of times the interface is called per unit time (times / minute), response time: the average time taken for the interface to process requests (ms), and error rate: the proportion of failed requests to the total number of requests (%). Its trigger threshold is when the average load exceeds a preset threshold within the time window. The module-level condition is the difference in resource utilization between service interfaces within a module. Resource utilization can be selected from core indicators such as CPU utilization, thread count ratio, and memory utilization. The specific calculation formula is as follows: Resource utilization difference = max(Ri) - min(Ri); Where Ri represents the resource utilization rate (%) of the i-th interface within the module, max represents the maximum value, and min represents the minimum value. That is, the resource utilization difference is the absolute difference (percentage points) between the interface with the highest and lowest resource utilization within the module. The difference in resource utilization represents the difference in resources consumed by the two interfaces when they are called. Its trigger threshold is that if the difference exceeds the threshold, it indicates that under certain circumstances, the interface with higher resource consumption needs to be deployed separately, or when consolidating resources, the interface with lower resource consumption can be consolidated. For example, if the resource utilization difference of a module is set to >30%, such as interface A having a CPU utilization rate of 60% and interface B only 20%, when resource consolidation is needed, interface B can be consolidated with other instances with lower resource consumption. When resources need to be expanded to meet the calls of interface A, interface A needs to be deployed separately, or it can be further clustered into the interface A module. The cluster level is the average resource utilization rate (a comprehensive weighted average of CPU / memory / network bandwidth) of all service instances within the cluster. Its trigger threshold is that when the resource utilization rate is too high or too low, resources need to be adjusted. For example, if the overall cluster resource utilization rate is <40%, idle resources need to be reduced.

[0030] It is understandable that this embodiment can also establish an instance service capability pool, abstracting the service capabilities of each service instance into a set of quantifiable metrics: Supported interface list: the identifier of the service interface currently carried by the instance; Call frequency limit: the maximum number of calls a single instance can support for each interface (times / minute); Response time threshold: the maximum allowed average response time (ms) for a single instance to process requests for each interface; Resource limits: hardware resource constraints such as the number of CPU cores, memory size, and maximum thread pool capacity of a single instance. For example, instance 1 can support "order query interface (maximum 800 times / minute, response threshold 400ms) + order cancellation interface (maximum 300 times / minute, response threshold 300ms)," with a CPU limit of 2 cores and a memory limit of 4GB. Subsequently, the instance service scope and module resource migration are dynamically adjusted.

[0031] In one specific implementation, this embodiment can perform interface-level service reorganization operations to dynamically adjust the service scope of instances. The processing flow is as follows: If it is determined based on the target monitoring data that a first business service interface exists among the business service interfaces, then it is determined that the current target enterprise business distributed application meets the preset service reorganization conditions, and the service scope of the first business service instance is extended to the first business service interface; If it is determined based on the target monitoring data that a second business service interface exists among the business service interfaces, then it is determined that the current target enterprise business distributed application meets the preset service reorganization conditions, and the service capacity of the second business service instance to the second business service interface is reduced; wherein, the first business service interface is a business service interface whose average load is higher than a preset average load threshold; the first business service instance is a business service instance that meets preset expansion conditions; the preset expansion conditions are that the current resource consumption is lower than a preset resource consumption threshold, and the current resource can support a call volume that is not lower than the upper limit of the call frequency of the first business service interface; the second business service interface is a business service interface whose average load is lower than a preset average load threshold within a first preset time period; the second business service instance is a business service instance that carries the second business service interface. In other words, based on the target monitoring data, if a first business service interface (such as interface A) has a load average exceeding a threshold within a certain time period, such as within 5 minutes (e.g., call frequency > 1000 times / minute, or response time > 500ms), then an instance with sufficient remaining resources is selected from the service capacity pool. For example, if the current resource usage is < 70% of the resource limit, the service scope of the first business service instance with sufficient resources is expanded to the first business service interface. The allocated service capacity must meet the following requirements: the upper limit of the new call frequency ≤ the number of calls that the remaining resources of the instance can support; and ensure that the overall resource usage of the expanded instance does not exceed the upper limit to avoid overload. If a second business service interface has a long-term low load, such as a load average below 70% of the threshold for three consecutive time windows (15 minutes), then the service capacity of the corresponding second business service instance for the second business service interface is gradually reduced (e.g., the upper limit of the call frequency is reduced from 200 times / minute to 100 times / minute), releasing resources to other high-load interfaces, thereby completing the service reorganization.

[0032] In another specific implementation, this embodiment can perform a service reorganization operation at the business domain level to migrate module (business domain) resources. The processing flow is as follows: If it is determined based on the target monitoring data that a first business domain exists among the several business domains, then it is determined that the current target enterprise business distributed application meets the preset service reorganization conditions, and the third business service interface and the fourth business service interface under the first business domain are determined; the target resources occupied by the third business service interface in the first business domain are migrated to the fourth business service interface; wherein, the first business domain is the business domain that carries the third business service interface and the fourth business service interface, and the business domain resource utilization rate is lower than the first preset resource utilization rate threshold; the third business service interface is the business service interface whose interface resource utilization rate is lower than the second preset resource utilization rate threshold for a second preset time period; the fourth business service interface is the business service interface whose interface resource utilization rate is higher than the third preset resource utilization rate threshold for a second preset time period; the third preset resource utilization rate threshold is greater than the second preset resource utilization rate threshold. That is, if the overall load of a module is continuously too high, the instance resources of the low-load interface under the module are automatically migrated to the high-load interface to avoid resource fragmentation within the module. Specifically, based on the target monitoring data, if there is a first business domain with low overall resource utilization, and the resource utilization of the low-load third business service interface in this domain is consistently below a preset threshold while the resource utilization of the high-load fourth business service interface is consistently above a preset threshold, then the target resources occupied by the third business service interface will be migrated to the fourth business service interface to complete service reorganization. For example, if the resource utilization of the high-load interface in the module is consistently >80%, and the resource utilization of the low-load interface in the same module is <30%, while the overall resource utilization of the module is <70%, then the idle resources (such as the number of threads and memory shards) occupied by the low-load interface will be migrated to the high-load interface. For example, after migration, the resource utilization of the target interface will be controlled between 60% and 80%, and the resource utilization of the low-load interface will not be less than 20%, achieving dynamic resource balancing within the module and eliminating resource fragmentation.In this way, this embodiment can achieve accurate perception of the operating status of distributed applications by automatically judging based on target monitoring data; automatically triggering and executing service reorganization according to preset conditions can dynamically adapt system resources to business needs, improving the stability and resource utilization of application operation; differentiated service reorganization based on interface load and instance resource status can accurately match service capabilities with actual business pressure; dynamically expanding the service scope of high-load interfaces and reducing the service capacity of low-load interfaces can achieve reasonable resource allocation and improve the overall operating efficiency and resource utilization of distributed applications; dynamically migrating resources based on the resource utilization of business domains and interfaces, and allocating low-load interface resources to high-load interfaces can accurately identify and revitalize idle resources, effectively balance the resource allocation within the business domain, and improve the overall resource utilization and service stability; based on fine-grained monitoring time-series data and sliding window algorithm, resource scheduling is triggered in advance to optimize resource configuration, break the limitations of rigid traditional deployment architecture and fixed service capabilities, support dynamic adjustment of instance service scope and resource migration within modules, and eliminate resource fragmentation.

[0033] Step S14: If, based on the target monitoring data, it is determined that the current target enterprise business distributed application meets the preset service expansion conditions, then a component list of the object to be expanded is determined. Based on the component list and the preset expansion security mechanism, a new business service instance is deployed for the object to be expanded. The object to be expanded includes the business domain to be expanded and the business service interface to be expanded. The component list includes business components used to implement the business logic of the object to be expanded, and the business logic and the interface call logic are decoupled from each other.

[0034] In this embodiment, when the target enterprise business distributed application meets the preset service expansion conditions based on the target monitoring data, a list of components for the business domain and business service interface to be expanded is determined, and a new business service instance is deployed in conjunction with the preset expansion security mechanism. The component list includes business components used to implement the business logic of the object to be expanded, and the business logic of the business components and the interface call logic are decoupled from each other.

[0035] It should be noted that, such as Figure 4The diagram illustrates a single-component structure provided in this application. A complete business domain includes multiple components implementing different capabilities. Each gray square in the diagram represents a component, with ModuleService serving as the component container. Following the interface-oriented design principle, it separates the interface from the implementation, allowing the same set of business capabilities to freely switch invocation methods depending on the scenario. The core structure is as follows: SDK-Interface (SDK (Software Development Kit) interface): Serves as the unified abstract interface to the outside world of the component, defining the component's capability contract and independent of specific implementation methods. Local-Impl (SDK local invocation implementation): Implements the local invocation logic of the interface, directly binding to Bis-service (business implementation) through local invocation, suitable for low-resource-consumption, locally deployed scenarios. Remote-Impl (SDK remote invocation implementation): Implements the remote invocation logic of the interface, binding to Bis-service (business implementation) through remote invocation, suitable for high-resource-consumption, independently deployed scenarios. Bis-service (business implementation): Carries the specific business logic and is the final implementation carrier of the component's capabilities. It is decoupled from the invocation method and can be reused by local or remote implementations. Figure 5 The diagram illustrates a cross-component dependency structure provided in this application. Taking two business components, ModuleService-A and ModuleService-B, as examples, it demonstrates the flexible composition capability across components: each component follows the same abstract structure: Abstract-SDK (abstract interface) → Local-Impl / Remote-Impl (invocation implementation) → Bis-service (business implementation). ModuleService-A's Remote-Impl-A remotely calls ModuleService-B's Abstract-SDK-B through dependencies, achieving cross-component capability reuse. This design allows: the resource-intensive ModuleService-B to be deployed independently, with ModuleService-A depending on ModuleService-B via remote calls; and low-resource-intensive components to package Local-Impl and business implementation in the same process, reducing remote call overhead.

[0036] Specifically, if, based on the target monitoring data, it is determined that there are objects to be scaled up in the target enterprise business distributed application, then the current target enterprise business distributed application meets the preset service scaling conditions, a new business service instance is created, and a first component list of the objects to be scaled up is determined; the objects to be scaled up are those whose load continuously exceeds a preset load threshold within a third preset time period; dependency analysis is performed on the objects to be scaled up based on the first component list to identify affected objects, and the routing of the affected objects is adjusted to the new business service instance; corresponding component summary information is generated based on the second component list of the new business service instance, and the component summary information is digitally signed to obtain corresponding component signature data; the second component list and the component signature data are packaged to generate a new business service instance cluster package; the new business service instance cluster package is deployed, and the identity of the new business service instance is verified, and after the identity verification is passed, the integrity of the new business service instance cluster package is verified, so that the new business service instance is started after the integrity verification is passed. That is, as... Figure 6 The diagram illustrates a process for secure instance scaling provided in this application. Based on the target monitoring data, an object with persistently high load is identified as meeting the preset service scaling conditions. A new business service instance is created, and the first component list of the object to be scaled is determined. This triggers a new module instance service splitting process, initiating the new instance creation process. The process analyzes other business modules (business domains) or business service interfaces that depend on the high-consumption module, i.e., the object to be scaled. Affected callers are identified, and the remote call interfaces of the affected other modules or business service interfaces are modified to redirect traffic to the newly created business service instance. Finally, based on the new business service instance maintained by the component management system... The second component list generates a total component list and a summary of component information, i.e., component summary information. A signature verification service system and a cryptographic machine are used to digitally sign the component summary information, generating immutable component signature data. The application packaging system packages the components, configurations, and signature information based on the second component list and the component signature data, creating a deployable new business service instance cluster package. After deployment, the service operation and maintenance system sequentially performs identity verification, signature legality and integrity verification to ensure the instance has not been tampered with. Upon successful verification, the new business service instance is started and traffic is connected, completing secure expansion. It is understood that during expansion, new instances are added to the cluster, synchronizing core data such as interface routing, service capabilities, load balancing strategies, and cluster topology with existing instances to ensure coordinated cluster operation.

[0037] It should be noted that the processing flow for generating the new business service instance cluster package of the newly added business service instance further includes: generating a temporary instance identity certificate for the newly added business service instance based on the component summary information and the instance identifier of the newly added business service instance and through the target encryption algorithm; correspondingly, the processing flow for verifying the identity of the newly added business service instance is as follows: obtaining the pre-generated root certificate and intermediate certificate; verifying the identity of the newly added business service instance based on the root certificate, the intermediate certificate, and the temporary instance identity certificate and according to the target certificate chain. The certificate is a digital identity credential issued by a CA center and encrypted based on the national cryptographic SM4 algorithm (a block cipher algorithm), used to uniquely identify the legitimate identity of the service instance and prevent unauthorized instances from accessing the cluster; the target certificate chain is a three-level trusted verification system composed of the root certificate → intermediate certificate → instance certificate, used to verify the legitimacy and trustworthiness of the certificate at each level. In other words, when generating the new business service instance cluster package, the new instance (new business service instance) initiates an identity verification request to the resource management platform: combining the component digest information and instance identifier, a temporary instance identity certificate is generated by calling the target encryption algorithm (such as the SM4 algorithm) through a cryptographic machine. The certificate is issued by the CA center. In addition, the root certificate and intermediate certificate are pre-made and trusted by the platform, eliminating the need to generate a dedicated certificate for each new instance in advance. During identity verification, the pre-generated root certificate, intermediate certificate, and temporary instance identity certificate are used to verify the issuing entity, validity period, and integrity of the new business service instance certificate through a three-level target certificate chain of root certificate → intermediate certificate → instance certificate, confirming whether the new business service instance is a legitimate instance authorized by the platform. It is understood that if any link in the target certificate chain fails verification, the platform will immediately refuse unauthorized instance access to the cluster, blocking the risk of malicious access.

[0038] It should be further noted that this embodiment also employs a dual security mechanism of multi-file list layered SHA-256 (a cryptographic hash function algorithm) digest + certificate-based digital signature verification to achieve configuration anti-tampering, anti-forgery, and anti-replacement. Specifically, the process of generating component digest information and performing digital signatures to obtain the corresponding component signature data further includes: determining the instance configuration file list of the newly added business service instance, and generating a baseline configuration file digest for each configuration file in the instance configuration file list to obtain a baseline instance configuration file list including the baseline configuration file digests; generating a total baseline configuration file digest of the instance configuration file list, and digitally signing the total baseline configuration file digest to obtain the corresponding configuration signature data; encapsulating the baseline instance configuration file list, the total baseline configuration file digest, and the configuration signature data into a baseline verification package for the newly added business service instance; correspondingly, the process of verifying the integrity of the cluster package of the newly added business service instance... The process is as follows: Obtain the benchmark instance configuration file list, the benchmark configuration file summary, and the configuration signature data from the benchmark verification package; verify the configuration signature data, and after successful verification, calculate the local configuration file summary of the local configuration file list of the newly added business service instance cluster package; compare the local configuration file summary with the benchmark configuration file summary, and after confirming that the local configuration file list has not been tampered with based on the comparison results, calculate the local configuration file summary for each local configuration file in the local configuration file list; compare the local configuration file summary with the benchmark configuration file summary in the benchmark instance configuration file list to verify the integrity of each local configuration file. The benchmark verification package is pre-generated trusted verification data from the platform, containing a configuration file list, a summary, and a digital signature, and is the sole legal basis for instance configuration verification; the instance configuration file list is a list of index files recording the names of all instance configuration files and their corresponding summaries, used for unified integrity verification of multiple file configurations.In other words, during the generation of component digests and signatures, which is the application packaging stage on the platform side, a baseline verification package also needs to be generated. Specifically, the instance configuration file list of the newly added business service instance is first determined. The component management system outputs a complete list of instance configuration files, including all configuration files, interface lists, resource limits, component dependencies, etc. The application packaging system calculates the SHA-256 digest for each configuration file in the list, which is the baseline configuration file digest, and generates a baseline instance configuration file list consisting of the filename and the single file digest. The SHA-256 digest is then calculated again for the entire configuration file list to obtain the baseline configuration file digest. The signature verification service system calls the cryptographic machine and uses the CA center's private key to digitally sign the baseline configuration file digest, generating a configuration signature. The baseline instance configuration file list, the baseline configuration file summary, and the configuration signature data are encapsulated into a baseline verification package and pre-stored in the resource management platform as a unique trusted baseline. After a new instance successfully passes identity authentication and accesses the platform, an integrity verification is forcibly performed before officially starting business services. First, the baseline verification package is obtained from the platform, and the configuration signature data is signed and verified using the CA public key to confirm that the summary comes from a trusted platform and has not been forged. After the signature verification is passed, the SHA-256 value of the local configuration file list, i.e., the local configuration file summary, is calculated and compared with the baseline configuration file summary to confirm that the list has not been tampered with. All configuration files in the list are traversed, and the local file summary is calculated for each one and compared with the list records to confirm that all configuration files are complete and unmodified. It is understood that if any step of the verification fails, the configuration is determined to have been tampered with or forged, and the platform refuses to start the new instance.

[0039] In this way, this embodiment automatically determines expansion needs based on monitoring data, enabling on-demand elastic expansion and avoiding resource waste. The component list, decoupling business logic from interface call logic, makes expansion deployment more flexible and less coupled. The flexible combination design of components, with both local and remote implementations, allows for free splitting or merging of components according to resource consumption scenarios, enabling dynamic and flexible adjustment of the deployment architecture and simplifying large-scale resource scheduling and management. Combined with expansion security mechanism deployment examples, the security and stability of the expansion process are ensured, improving system reliability and expansion efficiency, addressing the risks of existing expansion mechanisms lacking security protection and being easily tampered with, and safeguarding distributed applications. The system is stable and reliable; it adjusts routes through dependency analysis to ensure smooth and uninterrupted business calls after expansion; it uses component digest digital signatures and packaged deployment, and performs identity verification and integrity verification to improve the security of expansion packages, effectively prevent tampering risks, and ensure reliable deployment and secure operation of new instances; it uses a certificate chain combined with root and intermediate certificates to complete identity verification, which can effectively verify the legitimacy of new instances, prevent unauthorized instances from accessing the system, and improve the security and reliability of expansion deployment; it uses a step-by-step comparison and verification of the total digest and single file digest to accurately locate the tampering location, improve the granularity and reliability of integrity verification, and ensure the security of new instance deployment.

[0040] As can be seen from the above, this application embodiment collects resource interface data of each business service instance by deploying a monitoring agent independently for each business service instance. After preprocessing by the target edge node, the data is uploaded to the cloud and aggregated and stored according to a preset monitoring dimension to form target monitoring data. Then, based on the target monitoring data, if the current target enterprise business distributed application meets the preset service reorganization conditions, a service reorganization operation is performed. If the preset service expansion conditions are met, a component list of the objects to be expanded is determined and new business service instances are deployed in conjunction with the expansion security mechanism. The business components in the component list are used to implement business logic, and the business logic is decoupled from the interface call logic. In this way, through the above-described process in the embodiments of this application, monitoring agents are independently deployed to collect data for each business service instance, enabling fine-grained and interference-free resource data collection and ensuring the integrity and independence of monitoring data collection. By preprocessing at edge nodes and aggregating and storing data in the cloud, the processing pressure on the cloud can be reduced and the regularity and availability of monitoring data can be improved. Automatic judgment and execution of service reorganization based on monitoring data allows distributed applications to dynamically adapt to business operation status, improving system stability. Instance deployment based on a decoupled component list and expansion security mechanism ensures that business logic and interface logic do not interfere with each other during expansion, while also improving the security and deployment efficiency of the expansion process. This optimizes the service resource management method for enterprise business distributed applications to meet the needs of high resource utilization and secure operation of distributed applications.

[0041] Accordingly, see Figure 7 As shown in the illustration, this application also provides a service resource management device for a distributed enterprise business application, applied to a target distributed enterprise business application. The target distributed enterprise business application includes several business domains, and each business domain deploys several business service instances, so that the business domain provides corresponding enterprise business services through the business service interfaces carried by the business service instances; wherein, the device includes: Data acquisition module 11 is used to collect resource interface data of each of the business service instances through a pre-deployed monitoring agent; each of the business service instances independently deploys one of the monitoring agents; The data storage module 12 is used to preprocess the resource interface data through the target edge node, aggregate and summarize it through the target cloud according to the preset monitoring dimensions, and store it locally to obtain target monitoring data. The operation execution module 13 is used to perform corresponding service reorganization operations for each of the business service instances if it is determined, based on the target monitoring data, that the current target enterprise business distributed application meets the preset service reorganization conditions. The instance deployment module 14 is used to determine the component list of the target enterprise business distributed application to be expanded if it is determined based on the target monitoring data that the current application meets the preset service expansion conditions. Based on the component list and the preset expansion security mechanism, the module deploys new business service instances for the target business application to be expanded. The target business application to be expanded includes the business domain to be expanded and the business service interface to be expanded. The component list includes business components used to implement the business logic of the target business application to be expanded, and the business logic and the interface call logic are decoupled.

[0042] In some specific embodiments, the data acquisition module 11 may specifically include: The data statistics unit is used to collect resource interface data of each of the business service instances through a pre-deployed monitoring agent, and to perform statistics on the resource interface data to obtain interface-related data of each business service interface carried by the business service instance. Accordingly, the data storage module 12 may specifically include: The outlier removal unit is used to remove outliers from the resource interface data and the interface-related data through the target edge node, and send the removed data to the target cloud. The data aggregation unit is used to aggregate and calculate the interface-related data in the removed data through the target cloud to obtain business service interface-level monitoring data, aggregate and calculate the instance indicator data in the removed data to obtain business service instance-level monitoring data, and aggregate and calculate the interface-related data and instance indicator data under the same business domain in the removed data to obtain business domain-level monitoring data. The data storage unit is used to store target monitoring data locally according to preset monitoring dimensions through the target cloud; the target monitoring data includes the business service interface-level monitoring data, the business service instance-level monitoring data, and the business domain-level monitoring data.

[0043] In some specific embodiments, the operation execution module 13 may specifically include: The scope extension unit is used to determine that the current target enterprise business distributed application meets the preset service reorganization conditions if it is determined from the target monitoring data that there is a first business service interface in the business service interface, and to extend the service scope of the first business service instance to the first business service interface. The capability reduction unit is used to determine that the current target enterprise business distributed application meets the preset service reorganization conditions if it is determined based on the target monitoring data that there is a second business service interface in the business service interface, and to reduce the service capability of the second business service instance to the second business service interface. Wherein, the first business service interface is a business service interface whose average load is higher than a preset average load threshold; the first business service instance is a business service instance that meets preset expansion conditions; the preset expansion conditions are that the current resource usage is lower than a preset resource usage threshold, and the current resource can support a call volume that is not lower than the upper limit of the call frequency of the first business service interface; the second business service interface is a business service interface whose average load is lower than a preset average load threshold throughout a first preset time period; the second business service instance is a business service instance that carries the second business service interface.

[0044] In some specific embodiments, the operation execution module 13 may specifically include: An interface determination unit is used to determine if the target enterprise business distributed application meets the preset service reorganization conditions if a first business domain is determined to exist among the plurality of business domains based on the target monitoring data, and to determine the third business service interface and the fourth business service interface under the first business domain. The resource migration unit is used to migrate the target resources occupied by the third business service interface in the first business domain to the fourth business service interface. Wherein, the first business domain is the business domain that carries the third business service interface and the fourth business service interface, and the resource utilization rate of the business domain is lower than the first preset resource utilization rate threshold; the third business service interface is the business service interface whose interface resource utilization rate is lower than the second preset resource utilization rate threshold throughout the second preset time period; the fourth business service interface is the business service interface whose interface resource utilization rate is higher than the third preset resource utilization rate threshold throughout the second preset time period; the third preset resource utilization rate threshold is greater than the second preset resource utilization rate threshold.

[0045] In some specific implementations, the instance deployment module 14 may specifically include: The list determination unit is used to determine if, based on the target monitoring data, there are objects to be scaled up in the target enterprise business distributed application, then the target enterprise business distributed application meets the preset service scaling conditions, creates a new business service instance, and determines the first component list of the objects to be scaled up; the objects to be scaled up are objects whose load is continuously higher than a preset load threshold within a third preset time period. The routing adjustment unit is used to perform dependency analysis on the object to be expanded based on the first component list, to determine the affected objects, and to adjust the routing of the affected objects to the new business service instance. The digital signature submodule is used to generate corresponding component summary information based on the second component list of the newly added business service instance, and to digitally sign the component summary information to obtain the corresponding component signature data. The data packaging submodule is used to package the second component list and the component signature data to generate the new business service instance cluster package of the new business service instance; The instance startup submodule is used to deploy the newly added business service instance cluster package, verify the identity of the newly added business service instance, and verify the integrity of the newly added business service instance cluster package after the identity verification is successful, so as to start the newly added business service instance after the integrity verification is successful.

[0046] In some specific embodiments, the data packaging submodule may further include: The certificate generation unit is used to generate a temporary instance identity certificate for the new business service instance based on the component summary information and the instance identifier of the new business service instance and through the target encryption algorithm. Accordingly, the instance startup submodule may specifically include: The certificate acquisition unit is used to acquire pre-generated root certificates and intermediate certificates; The identity verification unit is used to verify the identity of the newly added business service instance based on the root certificate, the intermediate certificate, and the temporary instance identity certificate, and according to the target certificate chain.

[0047] In some specific embodiments, the digital signature submodule may further include: The summary generation unit is used to determine the instance configuration file list of the newly added business service instance, and generate a baseline configuration file summary for each configuration file in the instance configuration file list, so as to obtain a baseline instance configuration file list including the baseline configuration file summary. A digital signature unit is used to generate a base configuration file summary of the instance configuration file list and to digitally sign the base configuration file summary to obtain the corresponding configuration signature data. The data encapsulation unit is used to encapsulate the benchmark instance configuration file list, the benchmark configuration file summary, and the configuration signature data into a benchmark verification package for the newly added business service instance; Accordingly, the instance startup submodule may specifically include: The data acquisition unit is used to acquire the list of benchmark instance configuration files, the total summary of the benchmark configuration files, and the configuration signature data in the benchmark verification package; The digest calculation unit is used to perform signature verification on the configuration signature data, and after the signature verification is passed, calculate the total local configuration file digest of the local configuration file list of the newly added business service instance cluster package; The first summary comparison unit is used to compare the total summary of the local configuration files with the total summary of the benchmark configuration files, so that after determining that the list of local configuration files has not been tampered with based on the obtained comparison results, the local configuration file summary of each local configuration file in the list of local configuration files is calculated respectively. The second summary comparison unit is used to compare the local configuration file summary with the baseline configuration file summary in the baseline instance configuration file list to verify the integrity of each local configuration file.

[0048] Furthermore, embodiments of this application also disclose an electronic device, Figure 8 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application. The electronic device 20 may specifically include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the service resource management method for enterprise business distributed applications disclosed in any of the foregoing embodiments. Furthermore, the electronic device 20 in this embodiment may specifically be an electronic computer.

[0049] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0050] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk or optical disk, etc. The resources stored thereon can include operating system 221, computer program 222, etc., and the storage method can be temporary storage or permanent storage.

[0051] The operating system 221 is used to manage and control the various hardware devices on the electronic device 20 and the computer program 222, which may be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program capable of performing the service resource management method for enterprise business distributed applications executed by the electronic device 20 as disclosed in any of the foregoing embodiments, the computer program 222 may further include computer programs capable of performing other specific tasks.

[0052] Furthermore, this application also discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned service resource management method for distributed enterprise business applications. Specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0053] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0054] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0055] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0056] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0057] The technical solutions provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A service resource management method for distributed enterprise business applications, characterized in that, The method is applied to a distributed enterprise business application, which includes several business domains. Each business domain deploys several business service instances, so that the business domain provides corresponding enterprise business services through the business service interfaces carried by the business service instances. The method includes: Resource interface data of each of the aforementioned business service instances are collected through a pre-deployed monitoring agent; each of the aforementioned business service instances independently deploys one of the aforementioned monitoring agents; After the resource interface data is preprocessed by the target edge node, it is aggregated and summarized by the target cloud according to the preset monitoring dimensions and stored locally to obtain the target monitoring data; If, based on the target monitoring data, it is determined that the current distributed application of the target enterprise business meets the preset service reorganization conditions, then the corresponding service reorganization operation is performed for each of the business service instances. If, based on the target monitoring data, it is determined that the current distributed application of the target enterprise business meets the preset service expansion conditions, then a component list of the object to be expanded is determined. Based on the component list and the preset expansion security mechanism, a new business service instance is deployed for the object to be expanded. The object to be expanded includes the business domain to be expanded and the business service interface to be expanded. The component list includes business components used to implement the business logic of the object to be expanded, and the business logic and the interface call logic are decoupled from each other.

2. The service resource management method for distributed enterprise business applications according to claim 1, characterized in that, The process of collecting resource interface data for each of the aforementioned business service instances through a pre-deployed monitoring agent includes: By using a pre-deployed monitoring agent, resource interface data of each of the aforementioned business service instances are collected, and the resource interface data is statistically analyzed to obtain interface-related data of each business service interface carried by the business service instance. Accordingly, after preprocessing the resource interface data through the target edge node, the data is aggregated and summarized by the target cloud according to preset monitoring dimensions and stored locally to obtain target monitoring data, including: By using the target edge node, outliers in the resource interface data and the interface-related data are removed, and the removed data is sent to the target cloud. Through the target cloud, the interface-related data in the removed data is aggregated and calculated to obtain business service interface-level monitoring data, and the instance indicator data in the removed data is aggregated and calculated to obtain business service instance-level monitoring data, and the interface-related data and instance indicator data under the same business domain in the removed data are aggregated and calculated to obtain business domain-level monitoring data. The target monitoring data is stored locally according to preset monitoring dimensions through the target cloud; the target monitoring data includes the business service interface level monitoring data, the business service instance level monitoring data, and the business domain level monitoring data.

3. The service resource management method for distributed enterprise business applications according to claim 1, characterized in that, If, based on the target monitoring data, it is determined that the current distributed application of the target enterprise business meets the preset service reorganization conditions, then corresponding service reorganization operations are performed for each of the business service instances, including: If it is determined based on the target monitoring data that a first business service interface exists in the business service interface, then it is determined that the current target enterprise business distributed application meets the preset service reorganization conditions, and the service scope of the first business service instance is extended to the first business service interface; If it is determined based on the target monitoring data that a second business service interface exists in the business service interface, then it is determined that the current target enterprise business distributed application meets the preset service reorganization conditions, and the service capability of the second business service instance to the second business service interface is reduced. Wherein, the first business service interface is a business service interface whose average load is higher than a preset average load threshold; the first business service instance is a business service instance that meets preset expansion conditions; the preset expansion conditions are that the current resource usage is lower than a preset resource usage threshold, and the current resource can support a call volume that is not lower than the upper limit of the call frequency of the first business service interface; the second business service interface is a business service interface whose average load is lower than a preset average load threshold throughout a first preset time period; the second business service instance is a business service instance that carries the second business service interface.

4. The service resource management method for distributed enterprise business applications according to claim 1, characterized in that, If, based on the target monitoring data, it is determined that the current distributed application of the target enterprise business meets the preset service reorganization conditions, then corresponding service reorganization operations are performed for each of the business service instances, including: If it is determined based on the target monitoring data that a first business domain exists among the plurality of business domains, then it is determined that the current target enterprise business distributed application meets the preset service reorganization conditions, and the third business service interface and the fourth business service interface under the first business domain are determined. In the first business domain, the target resources occupied by the third business service interface are migrated to the fourth business service interface; Wherein, the first business domain is the business domain that carries the third business service interface and the fourth business service interface, and the resource utilization rate of the business domain is lower than the first preset resource utilization rate threshold; the third business service interface is the business service interface whose interface resource utilization rate is lower than the second preset resource utilization rate threshold throughout the second preset time period; the fourth business service interface is the business service interface whose interface resource utilization rate is higher than the third preset resource utilization rate threshold throughout the second preset time period; the third preset resource utilization rate threshold is greater than the second preset resource utilization rate threshold.

5. The service resource management method for distributed enterprise business applications according to any one of claims 1 to 4, characterized in that, If, based on the target monitoring data, it is determined that the current distributed application of the target enterprise business meets the preset service expansion conditions, then a list of components to be expanded is determined. Based on the component list and the preset expansion security mechanism, new business service instances are deployed for the objects to be expanded, including: If, based on the target monitoring data, it is determined that there are objects to be scaled up in the target enterprise business distributed application, then it is determined that the current target enterprise business distributed application meets the preset service scaling conditions, a new business service instance is created, and the first component list of the objects to be scaled up is determined; the objects to be scaled up are those whose load is continuously higher than a preset load threshold within a third preset time period. Dependency analysis is performed on the objects to be scaled up based on the first component list to identify the affected objects and adjust the routing of the affected objects to the new business service instance; Based on the second component list of the newly added business service instance, corresponding component summary information is generated, and the component summary information is digitally signed to obtain the corresponding component signature data; The second component list and the component signature data are packaged to generate the new business service instance cluster package of the new business service instance; Deploy the newly added business service instance cluster package, verify the identity of the newly added business service instance, and after the identity verification is successful, verify the integrity of the newly added business service instance cluster package, so as to start the newly added business service instance after the integrity verification is successful.

6. The service resource management method for distributed enterprise business applications according to claim 5, characterized in that, The step of packaging the second component list and the component signature data to generate the new business service instance cluster package of the new business service instance further includes: Based on the component summary information and the instance identifier of the newly added business service instance, and using the target encryption algorithm, a temporary instance identity certificate for the newly added business service instance is generated. Accordingly, the identity verification of the newly added business service instance includes: Obtain the pre-generated root certificate and intermediate certificate; The identity of the newly added business service instance is verified based on the root certificate, the intermediate certificate, and the temporary instance identity certificate, and according to the target certificate chain.

7. The service resource management method for distributed enterprise business applications according to claim 6, characterized in that, The process of generating corresponding component summary information based on the second component list of the newly added service instance, and digitally signing the component summary information to obtain corresponding component signature data, further includes: Determine the instance configuration file list of the newly added business service instance, and generate a baseline configuration file summary for each configuration file in the instance configuration file list to obtain a baseline instance configuration file list including the baseline configuration file summary; Generate a baseline configuration file summary of the instance configuration file list, and digitally sign the baseline configuration file summary to obtain the corresponding configuration signature data; The baseline instance configuration file list, the baseline configuration file summary, and the configuration signature data are encapsulated into a baseline verification package for the newly added business service instance; Accordingly, verifying the integrity of the newly added business service instance cluster package includes: Obtain the list of benchmark instance configuration files, the total summary of the benchmark configuration files, and the configuration signature data from the benchmark verification package; The configuration signature data is signed and verified, and after the verification is successful, the total local configuration file summary of the local configuration file list of the newly added business service instance cluster package is calculated. The total summary of the local configuration files is compared with the total summary of the baseline configuration files. After determining that the list of local configuration files has not been tampered with based on the comparison results, the local configuration file summary of each local configuration file in the list of local configuration files is calculated. The local configuration file summary is compared with the baseline configuration file summary in the baseline instance configuration file list to verify the integrity of each local configuration file.

8. A service resource management device for distributed enterprise business applications, characterized in that, The apparatus is applied to a distributed enterprise business application, which includes several business domains. Each business domain deploys several business service instances, so that the business domain provides corresponding enterprise business services through the business service interfaces carried by the business service instances. The apparatus includes: The data acquisition module is used to collect resource interface data of each of the aforementioned business service instances through a pre-deployed monitoring agent; each of the aforementioned business service instances independently deploys one of the aforementioned monitoring agents; The data storage module is used to preprocess the resource interface data through the target edge node, aggregate and summarize it through the target cloud according to the preset monitoring dimensions, and store it locally to obtain target monitoring data. The operation execution module is used to perform corresponding service reorganization operations for each of the business service instances if it is determined, based on the target monitoring data, that the current distributed application of the target enterprise business meets the preset service reorganization conditions. The instance deployment module is used to determine the component list of the target enterprise business distributed application to be expanded if, based on the target monitoring data, it is determined that the current target enterprise business distributed application meets the preset service expansion conditions. Based on the component list and the preset expansion security mechanism, the module deploys new business service instances for the target business application to be expanded. The target business application to be expanded includes the business domain to be expanded and the business service interface to be expanded. The component list includes business components used to implement the business logic of the target business application to be expanded, and the business logic and the interface call logic are decoupled.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the service resource management method for enterprise business distributed applications as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, Used to store computer programs; wherein, when the computer programs are executed by a processor, they implement the service resource management method for distributed enterprise business applications as described in any one of claims 1 to 7.

Images