Micro-service governance method and device, electronic equipment and storage medium

Abstract

The invention discloses a micro-service governance method and device, electronic equipment and a storage medium. The micro-service governance method comprises the steps of obtaining operation data of a micro-service system; analyzing the operation data, and determining a governance object in the micro-service system; generating a governance strategy corresponding to the governance object, and executing a governance operation on the governance object based on the governance strategy; and according to the monitored governance effect index, adjusting algorithm parameters required for analyzing the operation data or triggering rollback of the governance operation. By applying the technical scheme provided by the invention, the dynamic management of the micro service can be realized, the improvement of the overall management efficiency is facilitated, and the normal operation of the micro service system is ensured.

Description

Technical Field

[0001] This application belongs to the field of computer application technology, specifically relating to a microservice governance method, apparatus, electronic device, and storage medium. Background Technology

[0002] With the widespread application of microservice architecture in various enterprise systems, system complexity is constantly increasing, posing significant challenges to microservice governance.

[0003] Currently, traditional microservice governance methods mainly rely on manual maintenance and static rule configuration, which are difficult to adapt to the dynamic changes and real-time governance needs of microservice systems. They are prone to overlooking key issues or causing misoperations, resulting in low overall governance efficiency. Summary of the Invention

[0004] The purpose of this application is to provide a microservice governance method, apparatus, electronic device, and storage medium to automatically identify governance objects in a microservice system, dynamically generate governance strategies, dynamically adjust algorithm parameters, or trigger the rollback of governance operations, thereby helping to improve overall governance efficiency.

[0005] To solve the above-mentioned technical problems, this application provides the following technical solution: Firstly, a microservice governance approach is provided, including: Obtain runtime data from the microservice system; The operational data is analyzed to determine the governance objects in the microservice system; Generate a governance strategy corresponding to the governance object, and perform governance operations on the governance object based on the governance strategy; Based on the monitored governance effectiveness indicators, the algorithm parameters required for analyzing the operational data are adjusted or the governance operation is rolled back.

[0006] Optionally, the runtime data includes relevant data corresponding to the application programming interface (API), and the analysis of the runtime data to determine the governance objects in the microservice system includes: For each API of the microservice system, the relevant data corresponding to the current API is analyzed to obtain the data feature value of the current API. The data feature value includes at least one of the following: call frequency value, business importance value, and dependency relationship value. Based on the data feature values ​​of the current API, determine the resource value score of the current API; Based on the relationship between the resource value score of the current API and the first threshold, it is determined whether the current API is a governance object in the microservice system.

[0007] Optionally, if it is determined that the current API is a governance object in the microservice system, the current API is not an API in the preset API list, and the APIs included in the API list are predetermined non-governance objects.

[0008] Optionally, adjusting the algorithm parameters required for analyzing the operational data based on the monitored governance effectiveness indicators includes at least one of the following: If the governance effectiveness index is within a preset first range, the first threshold is increased by a preset first step length; If the governance effect index is within a preset second range, the first threshold is reduced by a preset second step size; Among them, the governance effectiveness indicators in the first range are better than those in the second range.

[0009] Optionally, the operational data includes configuration change-related data, and the analysis of the operational data to determine the governance objects in the microservice system includes: For each configuration item in the microservice system, determine whether the parameter value of the current configuration item has changed; When the parameter value of the current configuration item changes, semantic analysis is performed on the configuration change-related data corresponding to the current configuration item to determine the degree of impact of the parameter value change of the current configuration item on at least one dimension of security, performance, and functionality. Based on the degree of impact, determine whether the current configuration item is a governance object in the microservice system.

[0010] Optionally, the governance object includes target configuration items, and generating the governance strategy corresponding to the governance object includes: Based on the impact of the parameter value change of the target configuration item on at least one dimension of security, performance, and functionality, and the historical governance data corresponding to the target configuration item, a governance strategy corresponding to the target configuration item is generated.

[0011] Optionally, the operational data includes business log data, and the analysis of the operational data to determine the governance objects in the microservice system includes: Determine the business corresponding to the business log data; For each business, determine whether the log corresponding to the current business is a governance object in the microservice system based on whether the log of the current business meets the target conditions; The target conditions include a log sampling rate greater than or equal to a second threshold and a log duplication rate greater than or equal to a third threshold.

[0012] Optionally, the governance object includes the logs of the target business, and the generation of the governance policy corresponding to the governance object includes: Based on at least one of the value of the logs of the target business and the load status of the microservice system, a governance strategy corresponding to the logs of the target business is generated. The governance strategy corresponding to the logs of the target business includes at least one of sampling rate adjustment and log level adjustment. The value of the logs for the target service is determined based on the importance of the target service.

[0013] Optionally, the operational data includes API-related data, configuration change-related data, and business log data. Analyzing the operational data to determine the governance objects in the microservice system includes: The relevant data corresponding to the API, the relevant data of the configuration change, and the business log data are analyzed respectively to obtain API-level abnormal events, configuration-level change events, and log-level abnormal events. Based on the chronological order of occurrence of the API-level anomaly events, the configuration-level change events, and the log-level anomaly events, as well as the impact propagation path within the microservice system, determine the causal confidence of the API-level anomaly events, the configuration-level change events, and the log-level anomaly events. Based on the confidence level of the causal relationship, the governance objects in the microservice system are determined.

[0014] Optionally, determining the causal confidence of the API-level anomaly event, the configuration-level change event, and the log-level anomaly event based on their chronological order and the impact propagation path within the microservice system includes: The temporal correlation is determined based on the chronological order of occurrence of the API-level anomaly events, the configuration-level change events, and the log-level anomaly events. Determine the path directness based on the impact propagation path within the microservice system; The product of the time correlation, the path directness, and the pre-obtained historical verification is determined as the causal confidence of the API dimension anomaly event, the configuration dimension change event, and the log dimension anomaly event.

[0015] Optionally, performing governance operations on the governance object based on the governance strategy includes: Based on the governance strategy, governance operations are performed on the governance objects in stages; The stages for performing governance operations include the test environment verification stage, the pre-production grayscale execution stage, and the full production execution stage.

[0016] Optionally, after generating the governance policy corresponding to the governance object and before performing governance operations on the governance object based on the governance policy, the method further includes: Send an approval request for the governance strategy corresponding to the governance object; The step of performing governance operations on the governance object based on the governance strategy includes: If the governance strategy corresponding to the governance object is approved, governance operations are performed on the governance object based on the governance strategy.

[0017] Secondly, a microservice governance device is provided, including: The data acquisition module is used to acquire runtime data of the microservice system; The object determination module is used to analyze the runtime data and determine the governance objects in the microservice system; The governance module is used to generate a governance strategy corresponding to the governance object, and to perform governance operations on the governance object based on the governance strategy. The adjustment module is used to adjust the algorithm parameters required for analyzing the operational data or trigger the rollback of the governance operation based on the monitored governance effect indicators.

[0018] Thirdly, an electronic device is provided, comprising a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method as described in the first aspect.

[0019] Fourthly, a readable storage medium is provided, on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method as described in the first aspect.

[0020] Fifthly, a program product is provided, the program product including instructions stored in a readable storage medium and adapted to be read and executed by a processor to cause a device having the processor to perform the steps of the method as described in the first aspect.

[0021] By applying the technical solution provided in the embodiments of this application, after obtaining the running data of the microservice system, the running data is automatically analyzed to identify and determine the governance objects in the microservice system, dynamically generate the governance strategies corresponding to the governance objects, and perform governance operations on the governance objects based on the governance strategies. Then, the governance effect indicators are monitored, and the algorithm parameters required for analyzing the running data are adjusted or the rollback of the governance operations is triggered based on the monitored governance effect indicators. This can realize dynamic governance of microservices, help improve the overall governance efficiency, and ensure the normal operation of the microservice system.

[0022] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments or related technologies of this application, the drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 This is a flowchart illustrating the implementation of a microservice governance method in an embodiment of this application. Figure 2 This is a flowchart illustrating the process of determining whether an API is a governance object in this application embodiment; Figure 3 This is a flowchart illustrating the configuration item governance process in this application embodiment; Figure 4 This is a flowchart illustrating the log governance process in an embodiment of this application. Figure 5 This is a schematic diagram of the overall architecture in the embodiments of this application; Figure 6 This is a schematic diagram of the structure of a microservice governance device in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0025] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0026] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first" and "second" are generally of the same class, not limited in number; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0027] The following description, in conjunction with the accompanying drawings, details a microservice governance method provided by the embodiments of this application through specific implementations and application scenarios.

[0028] See Figure 1 The diagram shown is an implementation flowchart of a microservice governance method provided in this application embodiment. The method may include the following steps: S110: Obtain runtime data of the microservice system.

[0029] In this embodiment, data collection can be performed during the operation of the microservice system to obtain its runtime data. The runtime data may include at least one of the following: data related to the Application Programming Interface (API), configuration change-related data, and business log data. Specifically, API-related data may include API call log data, API business metadata, dependency graphs, etc. Configuration change-related data may include configuration change log data, configuration item metadata, etc. For any configuration item, if it is a multi-environment configuration item and has corresponding configuration change-related data, its parameter values ​​may be inconsistent across multiple environments, posing a production risk. Business log data can be obtained by collecting logs generated during business operations.

[0030] Among them, multi-environment configuration items can be understood as configuration items that exist in multiple environments, which may include production environment, pre-production environment, test environment, etc.

[0031] S120: Analyze the runtime data to identify the governance objects in the microservice system.

[0032] After obtaining the operational data of the microservice system, this data can be analyzed. Based on the analysis results, governance objects within the microservice system can be identified and determined—that is, which objects need to be governed. If the operational data includes API-related data, this API-related data can be analyzed, identifying one or more APIs as governance objects. Governing these APIs helps save system resources. If the operational data includes configuration change-related data, this configuration change-related data can be analyzed, identifying one or more configuration items as governance objects. Governing these configuration items helps reduce production risks caused by chaotic configuration management. If the operational data includes business log data, this business log data can be analyzed, identifying one or more business logs as governance objects. Governing these logs helps reduce storage costs. If the operational data includes API-related data, configuration change-related data, and business log data, these data can be combined for analysis. This identifies one or more APIs, one or more configuration items, or one or more business logs as governance objects. Governing these identified governance objects improves the performance of the microservice system.

[0033] S130: Generate the governance strategy corresponding to the governance object, and perform governance operations on the governance object based on the governance strategy.

[0034] In this embodiment, after analyzing the operational data of the microservice system and identifying the governance objects within the system, governance strategies corresponding to these objects can be dynamically generated. Optionally, governance strategies can be automatically generated based on the type of the governance object, the analysis results, and a pre-defined governance rule base.

[0035] After generating the governance strategy corresponding to the governance object, an execution plan can be formulated based on the governance strategy to perform governance operations on the governance object.

[0036] Optionally, after generating the governance strategy corresponding to the governance object, a risk assessment can be performed on the governance strategy to determine its impact level, execution priority, etc. For example, the governance object may include a target API, and the governance strategy for the target API may have a low impact level and a high execution priority. Based on the impact level and execution priority of the governance strategy, governance operations can be performed more effectively.

[0037] S140: Based on the monitored governance effectiveness indicators, adjust the algorithm parameters required for analyzing the operational data or trigger the rollback of the governance operation.

[0038] In the embodiments of the application, after performing governance operations on the governance object based on the governance strategy, governance effectiveness indicators can be monitored. Optionally, system resource indicators such as the central processing unit (CPU), memory, storage, and network can be collected based on Prometheus, and governance effectiveness indicators can be determined based on these indicators. Governance effectiveness indicators may include at least one of the following: governance success rate, false positive rate, business anomaly rate, number of rollbacks, error rate, resource utilization rate, number of user complaints, and frequency of user complaints.

[0039] Based on the monitored governance effectiveness indicators, the actual effects of the executed governance operations can be confirmed. Based on the actual effects, the algorithm parameters required for analyzing the running data can be adjusted, such as adjusting relevant thresholds. Alternatively, if the actual effects are poor or anomalies occur, the governance operations can be rolled back to avoid affecting the normal operation of the microservice system.

[0040] By applying the method provided in the embodiments of this application, after obtaining the running data of the microservice system, the running data is automatically analyzed to identify and determine the governance objects in the microservice system, dynamically generate the governance strategies corresponding to the governance objects, and perform governance operations on the governance objects based on the governance strategies. Then, the governance effect indicators are monitored, and the algorithm parameters required for analyzing the running data are adjusted or the rollback of the governance operations is triggered based on the monitored governance effect indicators. This can realize dynamic governance of microservices, help improve the overall governance efficiency, and ensure the normal operation of the microservice system.

[0041] In some embodiments of this application, the runtime data includes relevant data corresponding to the application programming interface (API). Step S120, which analyzes the runtime data to determine the governance objects in the microservice system, may include the following steps: For each API in the microservice system, analyze the relevant data corresponding to the current API to obtain the data feature value of the current API. The data feature value includes at least one of the following: call frequency value, business importance value, and dependency relationship value. Determine the resource value score of the current API based on its data feature values; Based on the relationship between the current API's resource value score and the first threshold, determine whether the current API is a governance object in the microservice system.

[0042] For ease of description, the above steps will be combined for explanation.

[0043] In this embodiment, the obtained operational data of the microservice system may include relevant data corresponding to the API, such as API call log data, API business metadata, and dependency graphs. For each API of the microservice system, the relevant data corresponding to the current API can be analyzed to obtain the data feature values ​​of the current API. The current API is the API targeted by the current operation. Optionally, relevant data corresponding to the API can be collected based on the OpenTelemetry standard (an open-source observability framework) through API call tracing.

[0044] Data characteristic values ​​may include at least one of the following: call frequency value, business importance value, and dependency value.

[0045] Specifically, by analyzing the call data of the current API, we can determine the number of times the current API has been called within the most recent time period, and thus determine the call frequency of the current API. The higher the call frequency of the current API, the greater its importance.

[0046] Optionally, the call frequency value of the current API can be the ratio of the number of calls to the current API in the most recent first time period to the duration of the first time period. For example, if the current API is / api / legacy / user / info, and the number of calls to the current API in the past 30 days is 0, then the call frequency value of the current API = number of calls in the past 30 days / 30 days = 0.0.

[0047] Optionally, the call frequency of the current API can be obtained by mapping the call count of the current API in the most recent first time period to the 0-1 interval using a logarithmic normalization formula, such as log(calls+1) / log(max_calls+1). Here, `calls` represents the call count of the current API in the most recent first time period, and `max_calls` represents the call count of all APIs in the most recent first time period.

[0048] The first time period can include one or more time windows, such as 30 days, 7 days, 1 day, etc. The current API call volume can be counted by sliding the time window, and the call trend can be identified by the sliding window algorithm.

[0049] The business metadata of the current API can be used to obtain the business tags of the current API, and the dependency relationship of the current API can be obtained based on the dependency graph of the current API.

[0050] The business importance value of an API can be determined based on its business tag. A higher business importance value indicates greater API importance. There is a pre-defined mapping relationship between business tags and business importance values. For example, if a business is tagged as core business, its importance value is between 0.9 and 1.0; if it's tagged as important business, its importance value is between 0.6 and 0.8; if it's tagged as general business, its importance value is between 0.3 and 0.5; and if it's tagged as testing / debugging business or a legacy interface, its importance value is between 0.0 and 0.2. Of course, core business, important business, general business, and testing / debugging business can each be further subdivided, corresponding to different business importance values.

[0051] Based on the dependencies of the current API, we can determine the number of other services that call the current API, i.e., the number of services that depend on the current API. Furthermore, based on the number of services that depend on the current API, we can determine the dependency value of the current API. The larger the dependency value of the current API, the greater its importance.

[0052] Optionally, the dependency value of the current API can be determined using a linear normalization formula, such as min(count / N, 1.0), where count represents the number of dependent services of the current API, and N represents the maximum number of dependent services corresponding to a perfect score. For example, N=10 means that the dependency value of the current API is considered to be perfect if the number of dependent services is 10. Optionally, there is a preset mapping relationship between the number of other services calling an API and the dependency value of that API. For example, if the number of other services calling the current API is 0, the dependency value of the current API is 0.0; if the number of other services calling the current API is 1 or 2, the dependency value of the current API is 0.1; and if the number of other services calling the current API is 3, 4, or 5, the dependency value of the current API is 0.3. Other examples are omitted to avoid redundancy.

[0053] For example, in a microservice system like a travel system, the order query API ( / api / order / query) has an average daily call volume of 5,000 times over the past 30 days, originating from driver, passenger, and management backend clients. This results in a call frequency of 0.8, classifying it as a high-frequency call. The business importance rating is "core," with a calculated business importance value of 0.9, indicating it is a core business function. Furthermore, it is depended upon by multiple services, resulting in a dependency relationship value of 0.7.

[0054] After obtaining the data feature values ​​of the current API, the resource value score of the current API can be determined based on these features. Optionally, the resource value score of the current API can be obtained by weighted summation of the data feature values.

[0055] Optionally, historical sample data can be collected first, including manually labeled valid and invalid API samples. Each historical sample data has corresponding data feature values ​​such as call frequency, business importance, and dependency relationship, as well as the final judgment result. Using the historical sample data, a classification model is trained using algorithms such as Random Forest or eXtreme Gradient Boosting (XGBoost). This classification model can automatically calculate the contribution of each data feature (such as call frequency, business importance, and dependency relationship) to the judgment result, thereby obtaining a quantitative ranking of data feature importance. The ranking of data feature importance provides a data basis for weight allocation. Based on this, fine-tuning is performed in combination with business conditions and expert experience to finally determine the weight of each data feature. For example, business importance, as the primary judgment criterion, is given the highest weight. Next, the weight configuration can be verified through A / B testing. For example, different weight configuration schemes are run in the test environment to compare accuracy, recall, and false positive rate. The goal is to control the false positive rate within a certain value, such as below 1%, while maximizing recall and accuracy. In subsequent applications, iterative optimization can be continuously performed based on actual governance results. For example, if the false positive rate is high, the weight of business importance can be increased.

[0056] For example, if the weight of call frequency is 0.3, the weight of business importance is 0.5, the weight of dependency is 0.0, the call frequency of the current API is 0.0, the business importance is 0.1, the dependency is 0.0, and the resource value score of the current API is 0.0×0.3+0.1×0.5+0.0×0.2=0.05.

[0057] For example, if the current API call frequency is 0.8, the business importance is 0.9, and the dependency is 0.7, then the current API resource value score is 0.8 × 0.3 + 0.9 × 0.5 + 0.7 × 0.2 = 0.83.

[0058] Based on the relationship between the current API's resource value score and the first threshold, it can be determined whether the current API is a governance object in the microservice system. The first threshold is predetermined, such as 0.6. The initial first threshold can be set based on experience and subsequently adjusted according to governance effectiveness indicators and system load. The range of the first threshold can be between 0.3 and 0.8 to avoid being too aggressive or conservative.

[0059] Optionally, if the resource value score of the current API is greater than or equal to the first threshold, the current API can be considered to have high importance and cannot be used as a governance object. If the resource value score of the current API is less than the first threshold, the current API can be considered to have low importance and can be identified as a governance object in the microservice system. APIs identified as governance objects can be considered invalid APIs or invalid resources, while APIs not identified as governance objects can be considered valid APIs or valid resources.

[0060] For example, if the resource value score of the current API is 0.05, which is less than the first threshold of 0.6, then the current API is determined to be an invalid API and a governance object. It can be marked as a resource to be governed and governance operations need to be performed on it. If the resource value score of the current API is 0.83, which is greater than the first threshold of 0.6, then the current API is determined to be a valid API and is retained.

[0061] Determining resource value scores based on API data feature values ​​quantifies the importance of APIs and can quickly and accurately identify which APIs are governance objects in a microservice system.

[0062] In some embodiments of this application, when it is determined that the current API is a governance object in the microservice system, the current API is not an API in the preset API list, and the APIs included in the API list are predetermined non-governance objects.

[0063] Optionally, analyzing the relevant data corresponding to the current API to obtain the data feature values ​​of the current API may include the following steps: Determine whether the current API is an API in the preset API list, which includes APIs that are pre-determined non-governance objects; If the current API is not in the API list, analyze the relevant data corresponding to the current API to obtain the data feature values ​​of the current API.

[0064] For ease of description, the above steps will be combined for explanation.

[0065] In this embodiment, an API list can be pre-defined. The APIs in this list have specific functions or have been pre-confirmed to not require governance; that is, the APIs included in this list are pre-determined non-governance objects. For example, the API list may include core business APIs and security-related interfaces. The pre-defined API list can also be called a pre-defined non-governance API list.

[0066] For each API in a microservice system, we can first determine whether the current API is in a pre-defined API list. If the current API is not in the list, we can analyze the relevant data for the current API to obtain its data characteristic values, and then execute subsequent steps. If the current API is in the list, we can skip the current API and not analyze its relevant data to avoid accidental deletion, save computing resources, and improve analysis efficiency.

[0067] Optionally, determining whether the current API is a governance object in the microservice system based on the relationship between the current API's resource value score and a first threshold may include the following steps: Determine whether the resource value score of the current API is less than the first threshold; If the resource value score of the current API is less than the first threshold, determine whether the current API is an API in the preset API list; If the current API is not in the API list, then the current API is identified as a governance object in the microservice system.

[0068] This ensures that the APIs in the pre-defined API list are protected, preventing accidental operations from affecting the normal operation of the microservice system.

[0069] like Figure 2 As shown, for each API, data features can be extracted from the dependency graph, API business metadata, and API call log data. The data features of the API are then fused using a feature fusion algorithm, and a weighted score is calculated with reference to the business rule base to obtain the resource value score of the API. The resource value score is compared with a dynamic threshold (i.e., the first threshold). If the resource value score is greater than or equal to the dynamic threshold, the status quo is maintained. If the resource value score is less than the dynamic threshold, it is determined whether to mark the API as a governance API, i.e., whether the API is a governance object, based on the preset list of non-governance APIs.

[0070] In some embodiments of this application, the governance object includes the target API, and the governance strategy corresponding to the governance object includes at least one of the following: deleting the target API, taking offline the related code corresponding to the target API, and reclaiming the resources corresponding to the target API.

[0071] In this embodiment, the governance object includes the target API, and the governance strategy for the generated governance object may include at least one of deleting the target API, taking offline the related code corresponding to the target API, and reclaiming the resources corresponding to the target API. Correspondingly, based on the governance strategy, the governance operation performed on the target API may include at least one of deleting the target API, taking offline the related code corresponding to the target API, and reclaiming the resources corresponding to the target API. This can reduce the maintenance cost of the target API and reduce its resource consumption. For example, if the backend service instance associated with the target API occupies 50MB of memory and approximately 2MB of related code and configuration files, after performing the governance operation on the target API, it is detected that the resources of the associated service instance of the target API are released, memory usage decreases by 50MB, CPU utilization decreases by 2%, and no business anomaly reports are received.

[0072] In some embodiments of this application, step S140 adjusts the algorithm parameters required for analyzing the operational data based on the monitored governance effectiveness indicators, including at least one of the following: If the governance effectiveness indicators are within the preset first range, the first threshold is increased according to the preset first step length; If the governance effectiveness indicators are within a preset second range, the first threshold is reduced by a preset second step size; Among them, the governance effectiveness indicators in the first range are better than those in the second range.

[0073] For ease of description, the above steps will be combined for explanation.

[0074] In this embodiment of the application, for each API of the microservice system, it is determined whether the current API is a governance object in the microservice system based on the relationship between the resource value score of the current API and a first threshold. The larger the first threshold, the more APIs can be identified as governance objects, and the smaller the first threshold, the fewer APIs can be identified as governance objects.

[0075] After performing governance operations on the APIs identified as governance targets, monitor the governance effectiveness metrics. Optionally, the governance effectiveness metrics can be monitored after completing a preset number of governance operations (e.g., 100 times).

[0076] If the governance effectiveness metrics are good and within the preset first range, the first threshold can be increased by the preset first step length. This allows more APIs to be governed when governance operations are needed again, expanding the governance scope and optimizing the microservice system. If the governance effectiveness metrics are average and within the preset second range, the first threshold can be decreased by the preset second step length. This reduces the number of APIs being governed when governance operations are needed again, tightening the governance scope and avoiding impacting the normal operation of the microservice system.

[0077] The length of the first step and the length of the second step can be set and adjusted according to the actual situation, and this application embodiment does not limit this.

[0078] The embodiments of this application can automatically adjust the judgment threshold for similar scenarios based on governance effectiveness indicators, and can also learn successful governance patterns to be applied to the identification and processing of other invalid APIs.

[0079] In some embodiments of this application, the runtime data includes configuration change-related data. Step S120 analyzes the runtime data to determine the governance objects in the microservice system, which may include the following steps: For each configuration item in the microservice system, determine whether the parameter value of the current configuration item has changed; When the parameter value of the current configuration item changes, semantic analysis is performed on the configuration change-related data corresponding to the current configuration item to determine the degree of impact of the parameter value change of the current configuration item on at least one dimension of security, performance, and functionality. Based on the degree of impact, determine whether the current configuration item is a governance object in the microservice system.

[0080] For ease of description, the above steps will be combined for explanation.

[0081] In this embodiment, the obtained operational data of the microservice system may include configuration change-related data. Optionally, configuration change-related data can be obtained by real-time monitoring of configuration change events in the configuration center.

[0082] For each configuration item in a microservice system, we can first determine whether the parameter value of the current configuration item has changed. If it has changed, we can then perform semantic analysis on the configuration change-related data corresponding to the current configuration item. Optionally, we can use the Bidirectional Encoder Representations from Transformers (BERT) model to perform semantic analysis on the keys and values ​​of the current configuration item.

[0083] If the current configuration item is a multi-environment configuration item, and its parameter values ​​change, the parameter values ​​may differ across environments. For example, if the initial parameter value of the current configuration item is value A in both the production and testing environments, but the parameter value changes during operation, the parameter value will become inconsistent between the production and testing environments, leading to configuration confusion and potential production risks.

[0084] The current configuration item refers to the configuration item that the current operation is targeting.

[0085] After performing semantic analysis on the configuration change-related data corresponding to the current configuration item, the impact of the parameter value change on at least one dimension—security, performance, or functionality—can be determined. Optionally, the impact on security can be assessed by factors such as whether security policies have been downgraded or whether the attack surface has expanded. The impact on performance can be assessed by factors such as system resource usage and service effectiveness. The impact on functionality can be assessed by factors such as whether core business functions have failed, whether external dependencies have been incorrectly invoked, or whether the data source has been contaminated. The degree of impact can be quantified using evaluation metrics across each dimension.

[0086] Based on the degree of impact, it can be determined whether the current configuration item is a governance object in the microservice system. Optionally, if it is determined that the parameter value change of the current configuration item has an impact on at least two dimensions of security, performance, and functionality, the impact on at least two dimensions can be weighted and summed to obtain the final impact degree, and this can be used to determine whether the current configuration item is a governance object in the microservice system. Alternatively, it can be determined whether the current configuration item is a governance object in the microservice system based on the impact degree of the dimension with the highest impact degree.

[0087] Based on the impact of changes to configuration item parameter values ​​on at least one dimension of security, performance, or functionality, it is possible to quickly and accurately determine which configuration items are governance objects in a microservice system.

[0088] In some embodiments of this application, the governance object includes a target configuration item, and step S130, generating the governance policy corresponding to the governance object, may include the following steps: Based on the degree of impact of the difference in parameter values ​​of the target configuration item on at least one dimension of security, performance, or functionality, and the historical governance data corresponding to the target configuration item, a governance strategy corresponding to the target configuration item is generated.

[0089] In this embodiment of the application, the governance object in the determined microservice system may include target configuration items. The historical governance data corresponding to the target configuration items may include historical governance strategies and historical governance performance indicators.

[0090] Based on the impact of the parameter value change of the target configuration item on at least one dimension of security, performance, or functionality, and the historical governance data corresponding to the target configuration item, a governance strategy for the target configuration item can be generated. The governance strategy for the target configuration item may include at least one of the following: adjusting the parameter value of the target configuration item in one environment to bring it closer to the parameter value of the target configuration item in another environment; adjusting the parameter value of the target configuration item to be consistent across different environments; or adjusting the parameter value of the target configuration item back to its original value before the change.

[0091] For example, based on the impact of changes to the parameter values ​​of a target configuration item on at least one dimension of security, performance, or functionality, it can be determined that the parameter values ​​of the target configuration item in the production environment should be adjusted. If it is known from the historical governance data corresponding to the target configuration item that reducing the parameter values ​​of the target configuration item in the production environment results in better governance indicators, then it can be determined that the parameter values ​​of the target configuration item in the production environment should be reduced.

[0092] Based on the degree of impact of the differences in parameter values ​​of the target configuration item on at least one dimension of security, performance, or functionality, and the historical governance data corresponding to the target configuration item, a governance strategy corresponding to the target configuration item is dynamically generated, which helps to achieve effective governance of the target configuration item.

[0093] like Figure 3 As shown, for each configuration item, the relevant data corresponding to that configuration item is parsed. The BERT model is used to perform semantic analysis on the key and value of the configuration item. Based on semantic understanding, the difference detection algorithm is used to detect the parameter value differences of the configuration item in different environments. Based on the business rule base, the impact of the parameter value differences is assessed to determine the degree of impact of the parameter value differences of the configuration item in at least one dimension of security, performance, and functionality. Based on the degree of impact and historical governance data, a governance strategy is generated and the governance operation is executed, such as modifying the parameter value of the configuration item in the target environment.

[0094] For example, consider a configuration item with the parameter `spring.datasource.hikari.connection-timeout=30000ms` in the production environment and `5000ms` in the test environment. Semantic analysis identifies this as a database connection performance configuration item, assessing it as high-risk. Excessive timeouts in the production environment could lead to connection pool exhaustion. Differential impact analysis shows that a 30-second timeout in the production environment is too long and can easily cause connection pool blocking under high concurrency scenarios. The proposed governance strategy could be to adjust the parameter value of this configuration item to 5000ms in the production environment and verify this through a gradual rollout.

[0095] In some embodiments of this application, the runtime data includes business log data. Step S120 analyzes the runtime data to determine the governance objects in the microservice system, which may include the following steps: Determine the business corresponding to the business log data; For each business, determine whether the logs corresponding to the current business are governance objects in the microservice system based on whether the logs corresponding to the current business meet the target conditions; The target conditions include a log sampling rate greater than or equal to a second threshold and a log duplication rate greater than or equal to a third threshold.

[0096] For ease of description, the above steps will be combined for explanation.

[0097] In this embodiment, the obtained operational data of the microservice system includes business log data. Optionally, system logs can be collected and processed in real time using message queues such as Kafka (a high-throughput distributed publish-subscribe messaging system) to obtain business log data.

[0098] Business log data can be analyzed to determine the corresponding business. Optionally, the business can be determined based on tags or other information associated with the business log data. Alternatively, a robustly optimized BERT (RoBERTa) model can be used to identify the business meaning and information value of the business log data.

[0099] For each business operation, it can be determined whether the logs corresponding to the current business operation are governance objects in the microservice system based on whether they meet the target conditions. The current business operation refers to the operation being performed.

[0100] The target conditions can include a log sampling rate greater than or equal to a second threshold and a log duplication rate greater than or equal to a third threshold. If the logs corresponding to the current business meet the target conditions, then the log sampling rate and log duplication rate corresponding to the current business can be considered too high. This will lead to duplicate logs occupying too much storage space, and the logs corresponding to the current business can be identified as governance objects in the microservice system.

[0101] Among them, high-frequency duplicate logs can be identified through Term Frequency-Inverse Document Frequency (TF-IDF) and text similarity algorithms.

[0102] If the logs corresponding to the current business do not meet the target conditions, it can be considered that there is no need to manage the logs corresponding to the current business for the time being.

[0103] By determining whether the logs corresponding to a business function meet the target conditions, it is possible to quickly and accurately determine whether the logs corresponding to that business function are governance objects.

[0104] In some embodiments of this application, the governance object includes the logs of the target service. Step S130, generating the governance policy corresponding to the governance object, may include the following steps: Based on at least one of the value of the logs of the target business and the load status of the microservice system, generate a governance strategy corresponding to the logs of the target business. The governance strategy corresponding to the logs of the target business includes at least one of sampling rate adjustment and log level adjustment. The value of the target business's logs is determined by the importance of the target business.

[0105] It is understandable that the value of logs varies depending on the importance of the business. In this embodiment, the governance object may include the logs of the target business, and the value of the target business's logs can be determined based on the importance of the target business. Optionally, a mapping relationship between the importance of a business and the value of its logs can be pre-defined, and the value of the target business's logs can be determined based on the importance of the target business and this mapping relationship. Optionally, the value of the target business's logs can be evaluated based on information entropy and business relevance. This quantifies the contribution of logs to system monitoring and problem troubleshooting.

[0106] Based on at least one of the following: the value of the target business's logs and the load status of the microservice system, a governance policy corresponding to the target business's logs can be generated. This governance policy may include at least one of: sampling rate adjustment and log level adjustment. Specifically, the lower the value of the target business's logs, the smaller the sampling rate and the lower the log level; the higher the value of the target business's logs, the larger the sampling rate and the higher the log level. Similarly, the higher the load of the microservice system, the smaller the sampling rate; and the lower the load of the microservice system, the larger the sampling rate.

[0107] Based on at least one of the value of the target business's logs and the load status of the microservice system, a governance strategy corresponding to the target business's logs can be accurately generated.

[0108] like Figure 4 As shown, for each business, the business log data corresponding to that business is parsed to extract key information. The extracted key information is normalized based on the log template library. Then, semantic analysis is performed using a semantic analysis engine to identify high-frequency repetitive logs. The value of the logs is determined using a value assessment model. Based on the value of the logs and at least one of the system load status, a governance strategy is generated to dynamically adjust the log sampling rate.

[0109] Taking driver location update log analysis as an example, monitoring revealed that the driver-backend-config service outputs 1.2 million duplicate debug logs per hour: [DEBUG] Processing driver location update for driverId:{}. Semantic analysis identified the characteristics of this log: high frequency of repetition, low information density, and limited business value, classifying it as "low-value duplicate logs." A quality assessment of the logs showed that approximately 28.8 million such logs are generated daily, accounting for 35% of the total service logs and consuming approximately 1.8 GB of storage space per day.

[0110] Governance strategy: Change the DEBUG level log to the TRACE level. In the production environment, the log will be output in a sampled manner (e.g., sampling rate of 15%).

[0111] Expected optimization results: The service log volume will be reduced by 85%, storage costs will be reduced by approximately 1.5GB / day, and overall system performance will be improved.

[0112] In some embodiments of this application, the runtime data includes API-related data, configuration change-related data, and business log data. Step S120 analyzes the runtime data to determine the governance objects in the microservice system, which may include the following steps: Analyze the runtime data to obtain at least two of the following: API-level abnormal events, configuration-level change events, and log-level abnormal events. Based on the chronological order of occurrence of at least two of the API-level abnormal events, configuration-level change events, and log-level abnormal events, as well as the impact propagation path within the microservice system, determine the causal confidence of at least two of the API-level abnormal events, configuration-level change events, and log-level abnormal events. Based on the confidence level of causal relationships, the governance objects in the microservice system are identified.

[0113] For ease of description, the above steps will be combined for explanation.

[0114] In this embodiment, the runtime data may include at least two of the following: API-related data, configuration change-related data, and business log data. Analyzing the API-related data can reveal API-level anomalies, such as an increase in the response time of ` / api / order / query` from 100ms to 2000ms. Analyzing the configuration change-related data can reveal configuration-level change events, such as a change in the database connection pool configuration from 20 to 5 15 minutes ago. Analyzing the business log data can reveal log-level anomalies, such as a large number of "connection timeout" errors displayed in the logs.

[0115] Optionally, the relevant data for the API, the configuration change-related data, and the business log data can be data within a preset time period. Analyzing this data within this time period will result in stronger correlation between API-level abnormal events, configuration-level change events, and log-level abnormal events.

[0116] API-level exceptions, configuration-level change events, and log-level exceptions occur in a sequential order; the impact of an earlier event may lead to the occurrence of a later event. For example, the order of occurrence of API-level exceptions, configuration-level change events, and log-level exceptions is: configuration-level change event — API-level exception event — log-level exception event.

[0117] Within a microservice system, these events correspond to impact propagation paths. For example, the impact propagation path might be: configuration center — application instance — database connection pool — API performance.

[0118] Based on the chronological order of occurrence of at least two of the API-level abnormal events, configuration-level change events, and log-level abnormal events, as well as the impact propagation path within the microservice system, the causal relationship between at least two of the API-level abnormal events, configuration-level change events, and log-level abnormal events can be determined. That is, which event caused the occurrence of other events. Furthermore, the confidence level of the causal relationship between at least two of the API-level abnormal events, configuration-level change events, and log-level abnormal events can be determined.

[0119] Optionally, the temporal correlation can be determined based on the chronological order of at least two of the API-level exception events, configuration-level change events, and log-level exception events. Determine the path directness based on the impact propagation path within the microservice system; The product of time correlation, path directness, and pre-obtained historical verification is used to determine the causal confidence of at least two of the following: API dimension abnormal events, configuration dimension change events, and log dimension abnormal events.

[0120] First, determine the time interval between at least two of the abnormal events in the API dimension, configuration dimension, and log dimension, based on their chronological order. Then, determine the time correlation based on the preset time window classification standard.

[0121] If the time intervals between API-level exception events, configuration-level change events, and log-level exception events are different, corresponding to different time correlations, then the time correlations of each pair of events can be averaged to obtain the final time correlation.

[0122] For example, the time window grading criteria are shown in Table 1: Table 1

[0123] For example, as can be seen from Table 1, if configuration dimension change events and API dimension exception events occur within 10-30 minutes, then the correlation level of these events can be considered as medium correlation, with a time correlation degree of 0.65.

[0124] If the configuration dimension change event and the API dimension change event occur within 10-30 minutes, the correlation level between these two events is medium, and the time correlation is 0.65. If the API dimension change event and the log dimension exception event occur within 30 minutes to 2 hours, the correlation level between these two events is weak, and the time correlation is 0.35. The average of these two time correlations is 0.50.

[0125] The path directness can be determined based on the impact propagation path within the microservice system. Optionally, the path directness can be determined based on the dependency relationship between adjacent items in the impact propagation path. Optionally, if adjacent items in the impact propagation path have a direct dependency, the path directness corresponding to these two items is 1.0; if adjacent items in the impact propagation path do not have a direct dependency, the path directness corresponding to these two items is a value less than 1.0 and greater than 0.0, which can be considered a preset value. The average of the path directness corresponding to each adjacent item in the impact propagation path is determined as the final path directness.

[0126] Historical verification score can be obtained, which can be determined based on the success rate of similar cases. For example, if there are 100 similar cases and 95 are successfully identified, the success rate is 95 / 100=0.95, and the historical verification score is 0.95.

[0127] The product of time correlation, path directness, and pre-obtained historical verification is used to determine the causal confidence of at least two of the following: API dimension abnormal events, configuration dimension change events, and log dimension abnormal events.

[0128] For example, if the temporal correlation is 0.65, the path directness is 1.0, and the historical validation is 0.95, then the confidence level of causality = temporal correlation × path directness × historical validation = 0.65 × 1.0 × 0.95 = 0.62 = 62%.

[0129] The reliability of causal relationship analysis results can be judged by the confidence level of the causal relationship. A higher confidence level indicates a more reliable causal relationship analysis. The confidence level can be compared with a preset fourth threshold. If the confidence level is greater than the fourth threshold, the causal relationship analysis result is considered to have extremely high reliability and can be implemented directly. If the confidence level is less than or equal to the fourth threshold but greater than the fifth threshold, the causal relationship analysis result is considered to have high reliability and can be used as a decision-making basis. If the confidence level is less than or equal to the fifth threshold but greater than the sixth threshold, the causal relationship analysis result is considered to have moderate reliability and requires manual review. If the confidence level is less than or equal to the sixth threshold, the causal relationship analysis result is considered to have low reliability and implementation is not recommended. The fourth, fifth, and sixth thresholds can be set and adjusted according to actual conditions, such as a fourth threshold of 90%, a fifth threshold of 80%, and a sixth threshold of 60%.

[0130] Once the root cause in the causal relationship is identified, the governance objects in the microservice system can be further determined. For example, if the root cause is a configuration dimension change event, the configuration item corresponding to that event can be identified as a governance object in the microservice system, and then a governance strategy can be determined, such as adjusting the parameter value of the configuration item or restoring its parameter value to its pre-change value.

[0131] For example, if a configuration change event is identified as the root cause through fusion analysis, the database connection pool configuration can be immediately rolled back from 5 to 20, and API performance recovery can be monitored. Within 5 minutes of the configuration rollback, the API response time should return to 100ms, the connection timeout error should disappear, and the system should resume normal operation.

[0132] By analyzing the causal relationships in at least two of the following dimensions—API, configuration, and business logs—more precise governance can be achieved, ensuring the normal operation of microservice systems.

[0133] In some embodiments of this application, step S130, which performs governance operations on the governance object based on the governance strategy, may include the following steps: Based on the governance strategy, governance operations are performed on the governance objects in stages; The stages for performing governance operations include the test environment verification stage, the pre-production grayscale execution stage, and the full production execution stage.

[0134] In this embodiment, after dynamically generating the governance strategy for the governance object, governance operations can be performed on the governance object in stages based on the governance strategy. First, the governance is verified in the test environment. After the verification is passed, a pre-production gray-scale execution is carried out to monitor a certain percentage (e.g., 10%) of traffic. If there are no abnormalities within a certain period of time, it indicates that the governance effect is good, and then a full production execution is carried out.

[0135] For example, if the governance target includes the target API, when performing governance operations on the target API, you can first disable the target API in the test environment, run automated tests to confirm that there is no impact, then perform a gray-scale implementation in the pre-production environment, monitor 10% of the traffic for 24 hours without any abnormalities, and then automatically perform cleanup in the production environment, such as deleting the routing configuration of the target API, taking the service instance of the target API offline, and cleaning up the code related to the target API.

[0136] Performing governance operations on governance objects in stages can effectively prevent governance operations from affecting the normal operation of the microservice system.

[0137] In some embodiments of this application, after generating the governance policy corresponding to the governance object and before performing governance operations on the governance object based on the governance policy, the method may further include the following steps: Send an approval request for the governance policy corresponding to the governance object; Based on the governance strategy, governance operations are performed on the governance objects, including: Once the governance strategy corresponding to the governance object is approved, governance operations are performed on the governance object based on the governance strategy.

[0138] In this embodiment, after generating the governance policy corresponding to the governance object, an approval request for the governance policy can be sent. Optionally, a risk assessment can be performed on the governance policy. If the governance policy includes high-risk operations, such as deleting core APIs or changing parameter values ​​of important configuration items, an approval request for the governance policy can be sent. If the governance policy corresponding to the governance object is approved, governance operations can be performed on the governance object based on the governance policy to ensure the security of the governance operations and avoid affecting the normal operation of the microservice system.

[0139] Of course, during the governance operations performed on the governance objects, operation logs can be recorded to facilitate operation auditing and problem tracing.

[0140] See Figure 5 The diagram shown is an overall architecture diagram of an embodiment of this application, mainly including a data acquisition module, an intelligent analysis engine, a governance strategy decision-making module, an automatic execution module, an effect monitoring module, and a feedback optimization module. The data acquisition module can collect operational data of the microservice system, such as API call logs, configuration data, system logs, and resource usage. The intelligent analysis engine analyzes the operational data and mainly includes an invalid API identification algorithm, a configuration difference analysis algorithm, and a log intelligent analysis algorithm. The governance strategy decision-making module can generate corresponding governance strategies for APIs, such as cleanup strategies; for configuration items, such as synchronization strategies; and for logs, such as optimization strategies. The automatic execution module executes governance operations based on the governance strategies generated by the governance strategy decision-making module. The effect monitoring module monitors the governance effect after the governance operation. The feedback optimization module feeds back the governance effect to the intelligent analysis engine to adjust the corresponding parameters.

[0141] As can be seen from the above, the embodiments of this application can automatically identify invalid APIs, abnormal configuration items, and abnormal logs in microservice systems through machine learning algorithms, reducing manual intervention and demonstrating a high degree of intelligence; they can automatically clean up invalid APIs, reducing system load and achieving good governance results; through unified environment configuration, they can effectively reduce production failure rates; by optimizing log output, they can reduce storage costs; they support dynamic threshold adjustment and policy optimization, adapting to microservice systems of different sizes and types; the phased execution and automatic rollback mechanism ensures the security of the governance process; and the modular design supports the rapid access and deployment of new governance strategies.

[0142] It should be noted that the microservice governance method provided in this application embodiment can be executed by a microservice governance device, or by a control module within the microservice governance device for executing the microservice governance method. This application embodiment uses the execution of the microservice governance method by a microservice governance device as an example to illustrate the microservice governance method provided in this application embodiment.

[0143] See Figure 6 The diagram shown is a structural schematic of the microservice governance device provided in this embodiment of the application, which includes the following modules: Data acquisition module 610 is used to acquire runtime data of the microservice system; The object determination module 620 is used to analyze runtime data and determine the governance objects in the microservice system; The governance module 630 is used to generate governance strategies corresponding to governance objects and to perform governance operations on the governance objects based on the governance strategies. The adjustment module 640 is used to adjust the algorithm parameters required for analyzing the operational data or trigger the rollback of the governance operation based on the monitored governance effect indicators.

[0144] By applying the apparatus provided in the embodiments of this application, after obtaining the operating data of the microservice system, the operating data is automatically analyzed to identify and determine the governance objects in the microservice system, dynamically generate the governance strategies corresponding to the governance objects, and perform governance operations on the governance objects based on the governance strategies. Then, the governance effect indicators are monitored, and the algorithm parameters required for analyzing the operating data are adjusted or the rollback of the governance operations is triggered according to the monitored governance effect indicators. This can realize dynamic governance of microservices, help improve the overall governance efficiency, and ensure the normal operation of the microservice system.

[0145] In some embodiments of this application, the runtime data includes relevant data corresponding to the application programming interface (API), and the object determination module 620 is specifically used for: For each API in the microservice system, analyze the relevant data corresponding to the current API to obtain the data feature value of the current API. The data feature value includes at least one of the following: call frequency value, business importance value, and dependency relationship value. Determine the resource value score of the current API based on its data feature values; Based on the relationship between the current API's resource value score and the first threshold, determine whether the current API is a governance object in the microservice system.

[0146] In some embodiments of this application, when it is determined that the current API is a governance object in the microservice system, the current API is not an API in the preset API list, and the APIs included in the API list are predetermined non-governance objects.

[0147] In some embodiments of this application, the governance object includes the target API, and the governance strategy corresponding to the governance object includes at least one of the following: deleting the target API, taking offline the related code corresponding to the target API, and reclaiming the resources corresponding to the target API.

[0148] In some embodiments of this application, the adjustment module 640 is specifically used to perform at least one of the following: If the governance effectiveness indicators are within the preset first range, the first threshold is increased according to the preset first step length; If the governance effectiveness indicators are within a preset second range, the first threshold is reduced by a preset second step size; Among them, the governance effectiveness indicators in the first range are better than those in the second range.

[0149] In some embodiments of this application, the runtime data includes configuration change-related data, and the object determination module 620 is specifically used for: For each configuration item in the microservice system, determine whether the parameter value of the current configuration item has changed; When the parameter value of the current configuration item changes, semantic analysis is performed on the configuration change-related data corresponding to the current configuration item to determine the degree of impact of the parameter value change of the current configuration item on at least one dimension of security, performance, and functionality. Based on the degree of impact, determine whether the current configuration item is a governance object in the microservice system.

[0150] In some embodiments of this application, the governance object includes a target configuration item, and the governance module 630 is specifically used to: generate a governance strategy corresponding to the target configuration item based on the degree of impact of the parameter value change of the target configuration item on at least one dimension of security, performance, and functionality, and the historical governance data corresponding to the target configuration item.

[0151] In some embodiments of this application, the runtime data includes business log data, and the object determination module 620 is specifically used for: Determine the business corresponding to the business log data; For each business, determine whether the logs corresponding to the current business are governance objects in the microservice system based on whether the logs corresponding to the current business meet the target conditions; The target conditions include a log sampling rate greater than or equal to a second threshold and a log duplication rate greater than or equal to a third threshold.

[0152] In some embodiments of this application, the governance object includes the logs of the target business. The governance module 630 is specifically used to: generate a governance strategy corresponding to the logs of the target business based on at least one of the value of the logs of the target business and the load status of the microservice system. The governance strategy corresponding to the logs of the target business includes at least one of sampling rate adjustment and log level adjustment. The value of the logs of the target business is determined according to the importance of the target business.

[0153] In some embodiments of this application, the runtime data includes at least two of the following: API-related data, configuration change-related data, and business log data. The object determination module 620 is specifically used for: Analyze the runtime data to obtain at least two of the following: API-level abnormal events, configuration-level change events, and log-level abnormal events. Based on the chronological order of occurrence of at least two of the API-level abnormal events, configuration-level change events, and log-level abnormal events, as well as the impact propagation path within the microservice system, determine the causal confidence of at least two of the API-level abnormal events, configuration-level change events, and log-level abnormal events. Based on the confidence level of causal relationships, the governance objects in the microservice system are identified.

[0154] In some embodiments of this application, the object determination module 620 is specifically used for: Determine the time correlation based on the chronological order of at least two of the following: API-level exception events, configuration-level change events, and log-level exception events. Determine the path directness based on the impact propagation path within the microservice system; The product of time correlation, path directness, and pre-obtained historical verification is used to determine the causal confidence of at least two of the following: API dimension abnormal events, configuration dimension change events, and log dimension abnormal events.

[0155] In some embodiments of this application, the governance module 630 is specifically used to: perform governance operations on the governance object in stages based on the governance strategy; the stages of performing the governance operations include the test environment verification stage, the pre-production grayscale execution stage, and the full production execution stage.

[0156] In some embodiments of this application, an approval module is also included, which is used to: after generating the governance strategy corresponding to the governance object and before performing governance operations on the governance object based on the governance strategy, send an approval request for the governance strategy corresponding to the governance object. The governance module 630 is specifically used to: perform governance operations on the governance object based on the governance strategy after the governance strategy corresponding to the governance object has been approved.

[0157] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the relevant method embodiments, and will not be repeated here to avoid repetition.

[0158] Corresponding to the above method embodiments, this application also provides an electronic device, including: Memory, used to store computer programs; A processor is used to implement the steps of the microservice governance method described above when executing computer programs.

[0159] like Figure 7 The diagram shows the structural composition of an electronic device, which may include a processor 10, a memory 11, a communication interface 12, and a communication bus 13. The processor 10, memory 11, and communication interface 12 all communicate with each other through the communication bus 13.

[0160] In this embodiment, the processor 10 may be a CPU, an application-specific integrated circuit, a digital signal processor, a field-programmable gate array, or other programmable logic devices.

[0161] The processor 10 can call programs stored in the memory 11. Specifically, the processor 10 can execute operations in the embodiments of the microservice governance method.

[0162] The memory 11 is used to store one or more programs. The programs may include program code, which includes computer operation instructions. In this embodiment, the memory 11 stores at least a program for implementing the following functions: Obtain runtime data from the microservice system; Analyze operational data to identify governance objects within the microservice system; Generate governance strategies corresponding to the governance objects, and perform governance operations on the governance objects based on the governance strategies; Based on the monitored governance effectiveness indicators, the algorithm parameters required for analyzing operational data are adjusted or the governance operation is rolled back.

[0163] In one possible implementation, the memory 11 may include a program storage area and a data storage area, wherein the program storage area may store the operating system and applications required for at least one function; and the data storage area may store data created during use.

[0164] In addition, memory 11 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device or other volatile solid-state storage device.

[0165] Communication interface 12 can be an interface for the communication module, used to connect with other devices or systems.

[0166] Of course, it should be noted that, Figure 7 The structure shown does not constitute a limitation on the electronic device in the embodiments of this application. In practical applications, the electronic device may include more than Figure 7 More or fewer components as shown, or combinations of certain components.

[0167] This application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above method embodiments and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0168] The processor is the processor in the above-described electronic device embodiment. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0169] Furthermore, it should be noted that this application also provides a program product or program, which may include instructions that can be stored in a readable storage medium. The processor of the device reads the instructions from the readable storage medium and executes the instructions, causing the device to perform the descriptions in the corresponding method embodiments above; therefore, these will not be repeated here. Additionally, the beneficial effects of using the same method will also not be repeated. For technical details not disclosed in the program product or program embodiments involved in this application, please refer to the descriptions in the method embodiments of this application.

[0170] It should be noted that, in this document, 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 that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0171] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods of the various embodiments of this application.

[0172] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many different implementations and modifications to this application without departing from the spirit and scope of the claims. All such implementations, improvements and modifications are within the scope of protection of this application.

Claims

1. A microservice governance method, characterized in that, include: Obtain runtime data from the microservice system; The operational data is analyzed to determine the governance objects in the microservice system; Generate a governance strategy corresponding to the governance object, and perform governance operations on the governance object based on the governance strategy; Based on the monitored governance effectiveness indicators, the algorithm parameters required for analyzing the operational data are adjusted or the governance operation is rolled back.

2. The method according to claim 1, characterized in that, The operational data includes relevant data corresponding to the Application Programming Interface (API). Analyzing the operational data to determine the governance objects in the microservice system includes: For each API of the microservice system, the relevant data corresponding to the current API is analyzed to obtain the data feature value of the current API. The data feature value includes at least one of the following: call frequency value, business importance value, and dependency relationship value. Based on the data feature values ​​of the current API, determine the resource value score of the current API; Based on the relationship between the resource value score of the current API and the first threshold, it is determined whether the current API is a governance object in the microservice system.

3. The method according to claim 2, characterized in that, If it is determined that the current API is a governance object in the microservice system, the current API is not an API in the preset API list, and the APIs included in the API list are predetermined non-governance objects.

4. The method according to claim 2, characterized in that, The adjustment of algorithm parameters required for analyzing the operational data based on the monitored governance effectiveness indicators includes at least one of the following: If the governance effectiveness index is within a preset first range, the first threshold is increased by a preset first step length; If the governance effect index is within a preset second range, the first threshold is reduced by a preset second step size; Among them, the governance effectiveness indicators in the first range are better than those in the second range.

5. The method according to claim 1, characterized in that, The operational data includes configuration change-related data. Analyzing the operational data to determine the governance objects in the microservice system includes: For each configuration item in the microservice system, determine whether the parameter value of the current configuration item has changed; When the parameter value of the current configuration item changes, semantic analysis is performed on the configuration change-related data corresponding to the current configuration item to determine the degree of impact of the parameter value change of the current configuration item on at least one dimension of security, performance, and functionality. Based on the degree of impact, determine whether the current configuration item is a governance object in the microservice system.

6. The method according to claim 5, characterized in that, The governance object includes target configuration items, and the generation of the governance strategy corresponding to the governance object includes: Based on the impact of the parameter value change of the target configuration item on at least one dimension of security, performance, and functionality, and the historical governance data corresponding to the target configuration item, a governance strategy corresponding to the target configuration item is generated.

7. The method according to claim 1, characterized in that, The operational data includes business log data. Analyzing the operational data to determine the governance objects in the microservice system includes: Determine the business corresponding to the business log data; For each business, determine whether the log corresponding to the current business is a governance object in the microservice system based on whether the log of the current business meets the target conditions; The target conditions include a log sampling rate greater than or equal to a second threshold and a log duplication rate greater than or equal to a third threshold.

8. The method according to claim 7, characterized in that, The governance object includes the logs of the target business, and the generation of the governance strategy corresponding to the governance object includes: Based on at least one of the value of the logs of the target business and the load status of the microservice system, a governance strategy corresponding to the logs of the target business is generated. The governance strategy corresponding to the logs of the target business includes at least one of sampling rate adjustment and log level adjustment. The value of the logs for the target service is determined based on the importance of the target service.

9. The method according to claim 1, characterized in that, The operational data includes at least two of the following: API-related data, configuration change-related data, and business log data. Analyzing the operational data to determine the governance objects in the microservice system includes: Analyze the runtime data to obtain at least two of the following: API-level abnormal events, configuration-level change events, and log-level abnormal events. Based on the chronological order of occurrence of at least two of the API-dimensional anomaly events, configuration-dimensional change events, and log-dimensional anomaly events, and the impact propagation path within the microservice system, determine the causal confidence of at least two of the API-dimensional anomaly events, configuration-dimensional change events, and log-dimensional anomaly events. Based on the confidence level of the causal relationship, the governance objects in the microservice system are determined.

10. The method according to claim 9, characterized in that, The step of determining the causal confidence of at least two of the API-level anomaly events, configuration-level change events, and log-level anomaly events based on the chronological order of occurrence of at least two of them, and the impact propagation path within the microservice system, includes: The temporal correlation is determined based on the chronological order of occurrence of at least two of the API-level anomaly events, configuration-level change events, and log-level anomaly events. Determine the path directness based on the impact propagation path within the microservice system; The product of the time correlation, the path directness, and the pre-obtained historical verification is determined as the causal confidence of at least two of the API-dimensional anomaly events, the configuration-dimensional change events, and the log-dimensional anomaly events.

11. The method according to claim 1, characterized in that, The step of performing governance operations on the governance object based on the governance strategy includes: Based on the governance strategy, governance operations are performed on the governance objects in stages; The stages for performing governance operations include the test environment verification stage, the pre-production grayscale execution stage, and the full production execution stage.

12. The method according to any one of claims 1 to 11, characterized in that, After generating the governance policy corresponding to the governance object and before performing governance operations on the governance object based on the governance policy, the method further includes: Send an approval request for the governance strategy corresponding to the governance object; The step of performing governance operations on the governance object based on the governance strategy includes: If the governance strategy corresponding to the governance object is approved, governance operations are performed on the governance object based on the governance strategy.

13. A microservice governance device, characterized in that, include: The data acquisition module is used to acquire runtime data of the microservice system; The object determination module is used to analyze the runtime data and determine the governance objects in the microservice system; The governance module is used to generate a governance strategy corresponding to the governance object, and to perform governance operations on the governance object based on the governance strategy. The adjustment module is used to adjust the algorithm parameters required for analyzing the operational data or trigger the rollback of the governance operation based on the monitored governance effect indicators.

14. An electronic device, characterized in that, It includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the microservice governance method as described in any one of claims 1 to 12.

15. A readable storage medium, characterized in that, The program or instructions are stored on the readable storage medium, and when executed by a processor, the program or instructions implement the steps of the microservice governance method as described in any one of claims 1 to 12.

Images