An industrial big data microservice API structure optimization method, medium and system
By using machine learning models to analyze and optimize the API interface in the industrial big data microservice system, the problem of unreasonable division of API interface responsibilities is solved, and the system performance and maintainability are improved.
Patent Information
- Application Number
- CN202510104935.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2025-01-23
- Publication Date
- 2025-04-15
- Estimated Expiration
- 2045-01-23
AI Technical Summary
In industrial big data microservice systems, the responsibilities of API interfaces are not reasonable enough, resulting in overlapping functions or overly broad responsibilities, which affects the reliability, maintainability and scalability of the system.
The first machine learning model based on long and short time memory units is used to analyze the scope of responsibilities of the API interface, extract the call link indicators, and optimize the API interface structure by establishing the API interface dependency analysis module and version management module, combining the second machine learning model based on attention mechanism.
It realizes the objectivity and automation of the division of responsibilities of API interfaces, optimizes the call relationship and version management of API interfaces, improves the performance and maintainability of the system, and reduces the risks during the version upgrade process.
Smart Images

Figure CN119537190B_ABST
Abstract
Description
Technical Field
[0001] The present invention belongs to the technical field of industrial big data, and specifically, relates to an industrial big data microservice API structure optimization method, medium and system. Background Art
[0002] In recent years, the rapid development of industrial Internet technology has promoted the widespread popularization of industrial big data applications. Industrial enterprises have achieved massive collection and accumulation of production process data by deploying a large number of IoT devices. These massive industrial big data contain various types of information such as production equipment status, process parameters, product quality, etc., providing enterprises with valuable data resources. Based on the analysis and application of industrial big data, enterprises can gain insight into the entire production process, optimize production plans, improve product quality, reduce operating costs, etc., thereby achieving the goals of intelligent manufacturing and lean management. However, the main challenge facing industrial big data applications is that there are many technical bottlenecks in the collection, storage, processing and service delivery of massive heterogeneous data. In order to solve these challenges, industrial Internet platforms have adopted microservice architecture to reconstruct industrial big data applications. Microservice architecture splits complex industrial big data application systems into multiple microservice modules with single responsibilities and low coupling, and realizes collaboration and data exchange between modules through standardized API interfaces. This service-oriented architecture design improves the flexibility, scalability and maintainability of the system.
[0003] However, in actual applications, due to the lack of comprehensive analysis of API functions, performance and dependencies, the division of responsibilities of API interfaces is not reasonable, and there are overlapping functions or overly broad responsibilities. This problem affects the reliability, maintainability and scalability of industrial big data microservice systems, and restricts the application and promotion of industrial Internet technology in actual production. Therefore, it is urgent to study an innovative method that can automatically optimize the structure of industrial big data microservice APIs to improve the performance and maintainability of the system. Summary of the invention
[0004] In view of this, the present invention provides an industrial big data microservice API structure optimization method, medium and system, which can solve the problem that the existing technology lacks a comprehensive analysis of API functions, performance and dependencies, resulting in unreasonable division of API interface responsibilities.
[0005] The present invention is achieved in that:
[0006] The present invention provides an industrial big data microservice API structure optimization method, which includes the following steps: analyzing data collection API, data preprocessing API, data analysis API, and data display API in an industrial big data scenario, and dividing the industrial big data microservice API into a data access layer microservice module, a data processing layer microservice module, and a data service layer microservice module; using a first machine learning model based on a long short-term memory unit to analyze the API interface responsibility scope of the data access layer microservice module, and extracting API interface call link indicators; establishing an API interface dependency analysis module, and constructing an API interface call relationship graph; performing input and output parameter standardization processing on the data processing layer microservice module; establishing an API interface version management module, and collecting API interface change records; using a second machine learning model based on an attention mechanism to analyze the API interface version evaluation model; determining a version number allocation strategy according to an API interface change impact value; establishing an API interface optimization equation group including a responsibility division equation, a dependency analysis equation, and a granularity optimization equation, establishing an API interface optimization evaluation function based on the API interface optimization equation group, executing an API interface structure reorganization operation, and realizing the optimization of the industrial big data microservice API structure.
[0007] The first machine learning model adopts a recurrent neural network structure, including input layer nodes, hidden layer nodes, and output layer nodes, wherein the hidden layer nodes are composed of a plurality of long short-term memory units, and each of the long short-term memory units comprises a forget gate unit, an input gate unit, and an output gate unit;
[0008] The step of establishing a training data set for the first machine learning model specifically includes:
[0009] Collect historical API call data, including API call frequency data, API response time data, and API error rate data;
[0010] Clean the historical API call data to remove outliers and noise data;
[0011] Extract API interface feature vectors, including API interface function description vectors, API interface performance indicator vectors, and API interface call relationship vectors;
[0012] Constructing training sample pairs, taking the API interface feature vector as input data, and taking manually annotated API interface optimization suggestions as output data;
[0013] The training steps of the first machine learning model specifically include:
[0014] Initializing network parameters in the recurrent neural network structure;
[0015] Inputting the training sample pairs into the first machine learning model;
[0016] Calculating a loss function value between a predicted output and an actual output of the first machine learning model;
[0017] Adopting a back propagation algorithm to optimize and update the network parameters;
[0018] Iterate the training until the loss function value converges;
[0019] The second machine learning model adopts an attention mechanism neural network structure, including an encoder unit, a decoder unit, and an attention calculation layer unit, and the attention calculation layer unit is used to calculate the call correlation degree between different API interfaces in the data service layer microservice module;
[0020] The step of establishing a training data set for the second machine learning model specifically includes:
[0021] Collect historical data on API interface version changes, including API interface change type data, API interface change scope data, and API interface change impact data;
[0022] Performing data preprocessing on the API interface version change history data, including data standardization and data normalization;
[0023] Build an API interface version feature matrix, including API interface change features, API interface dependency features, and API interface impact features;
[0024] Generate training data labels and manually annotate them based on the actual impact of historical version changes;
[0025] The training steps of the second machine learning model specifically include:
[0026] Initialize the network parameters in the attention mechanism neural network structure;
[0027] Inputting the API interface version feature matrix into the second machine learning model;
[0028] Calculating the difference between the prediction result of the second machine learning model and the training data label;
[0029] updating the network parameters to minimize the prediction error;
[0030] Iterate training until the model converges;
[0031] The API interface optimization equation group includes a responsibility division equation, a dependency analysis equation, and a granularity optimization equation;
[0032] The responsibility division equation is used to calculate the API interface responsibility boundary, the input parameters include the API interface function description index, the API interface complexity index, and the API interface aggregation index, and the output parameter is the API interface responsibility division plan;
[0033] The dependency analysis equation is used to calculate the API interface call link index, the input parameters include the API interface call relationship graph, the API interface dependency relationship index, and the output parameter is the API interface dependency optimization solution;
[0034] The granularity optimization equation is used to calculate the optimal API interface granularity. The input parameters include the API interface complexity index, the API interface aggregation index, and the API interface call link index. The output parameter is the API interface granularity adjustment plan.
[0035] Compared with the prior art, the industrial big data microservice API structure optimization method, medium and system provided by the present invention integrate multiple technical means such as machine learning, mathematical modeling and system engineering, and have achieved remarkable progress in API interface responsibility division, call relationship optimization and version management.
[0036] First, the present invention adopts the first machine learning model of the recurrent neural network structure to automatically analyze the functional characteristics, performance indicators and call relationships of the API interface, and accurately extract key indicators such as the responsibility boundary, complexity and degree of dependence of the API interface. Based on these indicators, the present invention proposes an API interface responsibility division equation, a dependency analysis equation and a granularity optimization equation, and realizes the effective optimization of the API interface structure. Compared with the traditional method that relies on manual experience, this method has a stronger objectivity and automation level.
[0037] Secondly, the present invention constructs a second machine learning model based on the attention mechanism, which can accurately predict the impact of API interface changes on system compatibility. Combined with this prediction result, the present invention proposes a version number allocation strategy based on the impact of changes and a version-based routing mechanism, which effectively manages the evolution of API versions in large-scale industrial microservice systems. This intelligent version management method greatly reduces the risk in the API upgrade process.
[0038] In general, the industrial big data microservice API structure optimization method proposed in this paper has achieved significant progress in key links such as API interface design, call optimization and version management. Compared with traditional methods, this method has the following outstanding advantages:
[0039] 1. More objective and automated API interface optimization, avoiding the limitations of manual experience judgment.
[0040] 2. More comprehensive and systematic API performance optimization, taking into account multiple factors such as interface responsibilities, dependencies, and granularity to achieve overall optimization.
[0041] 3. More intelligent and accurate API version management effectively reduces the risks of large-scale microservice systems during version upgrades.
[0042] These innovative technical effects provide strong support for the reliability, maintainability and scalability of industrial big data microservice systems, and solve the problem that existing technologies lack comprehensive analysis of API functions, performance and dependencies, resulting in unreasonable division of API interface responsibilities. BRIEF DESCRIPTION OF THE DRAWINGS
[0043] Figure 1 A flow chart of the method provided by the present invention;
[0044] Figure 2 This is a comparison chart of API call performance indicators in the embodiment;
[0045] Figure 3 This is an analysis diagram of the impact of API version changes in the embodiment. DETAILED DESCRIPTION
[0046] In order to make the purpose, technical solution and advantages of the embodiments of the present invention more clear, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention.
[0047] like Figure 1 As shown, it is a flow chart of an industrial big data microservice API structure optimization method provided by the present invention, and the method comprises the following steps: S10, analyzing the data acquisition API, data preprocessing API, data analysis API, and data display API in the industrial big data scenario, dividing the industrial big data microservice API into a data access layer microservice module, a data processing layer microservice module, and a data service layer microservice module, establishing a microservice remote call mechanism based on the HTTP protocol, and formulating a microservice data exchange standard in JSON format;
[0048] S20, using the first machine learning model to analyze the API interface responsibility scope of the data access layer microservice module, extracting the API interface call link index, the API interface complexity index, and the API interface dependency index, and obtaining the API interface evaluation result, and merging and reconstructing the API interfaces with similar functions according to the API interface evaluation result to generate an API interface reconstruction rule set;
[0049] S30, establishing an API interface dependency analysis module, constructing an API interface call relationship graph according to the API interface call link indicator, identifying the circular dependency in the API interface call relationship graph, and splitting the API interface with the circular dependency into independent API interfaces;
[0050] S40, performing input and output parameter standardization processing on the API interface of the data processing layer microservice module, wherein the input and output parameter standardization processing includes parameter naming standardization, parameter type unification, and parameter verification regularization, and generating an API interface parameter specification;
[0051] S50, establish an API interface version management module, collect the API interface change records of the data service layer microservice module, the API interface abandonment records of the data service layer microservice module, and the API interface new records of the data service layer microservice module, and build an API interface version evaluation model;
[0052] S60. Analyze the output data of the API interface version evaluation model using a second machine learning model to obtain an API interface change impact value, where the API interface change impact value represents the degree of impact of the API interface change on system compatibility;
[0053] S70, determining a version number allocation strategy for the API interface according to the API interface change impact value, generating API interface version control data, inputting the API interface version control data into an API gateway routing module, and the API gateway routing module performs version routing on the service request according to the API interface version control data;
[0054] S80. Establish an API interface optimization evaluation function, calculate the simplification rate index between the number of API interfaces after optimization and the number of API interfaces before optimization, and execute an API interface structure reorganization operation when the simplification rate index exceeds a preset optimization threshold to achieve optimization of the industrial big data microservice API structure. The API interface structure reorganization operation includes merging redundant API interfaces, splitting overloaded API interfaces, and adjusting the API interface granularity.
[0055] The specific implementation methods of the above steps are described in detail below:
[0056] The specific implementation method of step S10 is as follows. First, analyze the data acquisition API, data preprocessing API, data analysis API and data display API in the industrial big data scenario. Through in-depth analysis of the responsibility boundaries and functional characteristics of these API interfaces, the industrial big data microservice API is divided into a data access layer microservice module, a data processing layer microservice module and a data service layer microservice module. In order to realize remote calls between microservices, the present invention establishes a microservice remote call mechanism based on the HTTP protocol. At the same time, a microservice data exchange standard in JSON format is formulated to ensure that the data interaction format between different microservices is unified. This design of API microservice division and remote call mechanism is conducive to improving the modularity and scalability of the industrial big data system.
[0057] The specific implementation of step S20 is as follows. First, the API interface of the data access layer microservice module is analyzed and evaluated using a first machine learning model. The first machine learning model adopts a recurrent neural network structure, including input layer nodes, hidden layer nodes, and output layer nodes. Among them, the hidden layer nodes are composed of multiple long short-term memory units (LSTM), and each LSTM unit includes a forget gate, an input gate, and an output gate.
[0058] When constructing the training data set, we first collect historical API interface call data, including API interface call frequency, response time, and error rate. We clean and preprocess the collected data to remove outliers and noise data. Then, we extract the API interface function description vector, performance indicator vector, and call relationship vector as feature vectors. Finally, we construct training sample pairs, using the API interface feature vector as input data and the manually annotated API interface optimization suggestions as output data.
[0059] In the model training process, the network parameters in the recurrent neural network structure are first initialized. Then, the training sample pairs are input into the model to calculate the loss function value between the predicted output and the actual output. The back propagation algorithm is used to optimize and update the network parameters until the loss function value converges.
[0060] After the training is completed, the first machine learning model can accurately extract the call link index, complexity index and dependency index of the API interface. According to the evaluation results of these indicators, the present invention merges and reconstructs API interfaces with similar functions to generate an API interface reconstruction rule set. This API interface analysis and reconstruction method based on machine learning can optimize the API structure more objectively and accurately, avoiding the limitations of relying on manual experience judgment.
[0061] The specific implementation of step S30 is as follows. First, an API interface dependency analysis module is established. The core of this module is to build an API interface call relationship graph. Specifically, this module calculates the dependency matrix between API interfaces based on the API interface call link indicators obtained from the first machine learning model. ,in Indicates The API interface is The dependency level of an API interface, the value range is .when When there is no dependency, It indicates a strong dependency.
[0062] Based on API interface dependency matrix The present invention constructs an API interface call relationship graph. Then, the call relationship graph is analyzed to identify the circular dependency relationship therein. For API interfaces with circular dependency relationships, they are split into independent API interfaces to eliminate the circular dependency problem.
[0063] This API interface dependency optimization method based on graph theory analysis can effectively solve the problems caused by complex dependencies in large-scale microservice systems and improve the maintainability and reliability of the system.
[0064] The specific implementation of step S40 is as follows. For the API interface of the data processing layer microservice module, the present invention performs standardized processing of input and output parameters, including the following three aspects:
[0065] 1. Standardize parameter naming. Standardize the naming of input and output parameters of the API interface and follow unified naming rules, such as camel case naming. This helps improve the readability and understandability of the API interface.
[0066] 2. Unify parameter types. Unify the data types of the input and output parameters of the API interface, such as unifying different integer parameters into int type, string parameters into String type, etc. Unifying parameter types helps simplify the implementation logic of the API interface.
[0067] 3. Parameter verification regularization. Establish unified verification rules for the input parameters of the API interface, such as parameter non-null check, value range check, format check, etc. This parameter verification regularization helps to improve the robustness and fault tolerance of the API interface.
[0068] Through the above standardization, the API interface parameter specifications of the data processing layer microservice module can be generated to improve the reusability and maintainability of the API interface. This is particularly important for large-scale industrial microservice systems, which can reduce the difficulty of API interface development and integration.
[0069] The specific implementation of step S50 is as follows. First, the present invention establishes an API interface version management module. This module is responsible for collecting API interface change records, discarded records, and newly added records of the data service layer microservice module. Then, an API interface version evaluation model based on an attention mechanism neural network is constructed.
[0070] When constructing the training data set, we first collect historical data on API version changes, including features such as change type, change scope, and change impact. We standardize and normalize these data to construct an API version feature matrix. Finally, we generate labels for the training data based on the actual impact of historical version changes.
[0071] In the model training process, the network parameters in the attention mechanism neural network structure are first initialized. Then, the API interface version feature matrix is input into the model, the difference between the prediction result and the training data label is calculated, and the network parameters are updated using the back propagation algorithm until the model converges.
[0072] After training, the version assessment model can predict the impact of API interface changes on system compatibility based on the change characteristics, dependency characteristics, and impact characteristics of the API interface. This version impact assessment method based on the attention mechanism can more accurately identify key influencing factors and provide a basis for version management.
[0073] The specific implementation of step S60 is as follows. The present invention uses a second machine learning model (attention mechanism neural network) to analyze the output data of the API interface version evaluation model obtained from step S50, that is, the API interface change impact value The calculation equation of this model is as follows:
[0074] ;
[0075] in, For the The version evaluation value of an API interface; For the Class influencing factors; For the The amount of changes to the API interface; For the The API interface and The relevance of the API interfaces; and is the weight coefficient; is the error term, and its range is .
[0076] In a specific implementation of the present invention, for the API interface version evaluation model, the influencing factors are and the amount of change The partial derivative relationship between reflects the sensitivity of the impact of API interface changes on various aspects of the system. Specifically, the influencing factors It mainly includes system compatibility impact (including forward compatibility and backward compatibility), performance impact (including response time, throughput, resource consumption), security impact (including authentication mechanism, permission control, data encryption), availability impact (including service availability, functional integrity, error handling), dependency impact (including upstream and downstream service dependencies, third-party component dependencies), etc. The amount of changes in the API interface These include interface parameter changes (including parameter type changes, parameter additions and deletions, and parameter renaming), return value changes (including return value type changes, data structure adjustments, and status code modifications), interface path changes (including URI changes, version number changes, and namespace adjustments), interface logic changes (including business logic modifications, process optimization, and exception handling improvements), and interface constraint changes (including access control changes, current limiting strategy adjustments, and timeout setting modifications). By calculating the partial derivatives of these influencing factors on the amount of change, we can quantitatively evaluate the impact of each specific change on each dimension of the system, thereby providing a decision-making basis for API interface version management. For example, changes in parameter types may have a greater impact on system compatibility, but less impact on performance; changes in interface logic may have a significant impact on both performance and availability. This sensitivity analysis method based on partial derivatives can help development teams better assess and control the risks of API interface changes.
[0077] The model first takes the feature matrix composed of API interface change features, dependency features and impact features as input. Then, the attention mechanism is used to calculate the call correlation degree between different API interfaces. Finally, combining the API interface change characteristics and correlation information, the impact of the API interface change on the system is predicted, and the API interface change impact value is obtained. .
[0078] This version impact assessment method based on the attention mechanism can more accurately identify the key influencing factors of API changes and provide a basis for subsequent version management.
[0079] The specific implementation of step S70 is as follows. First, according to the API interface change impact value obtained in step S60 , determine the version number allocation strategy of the API interface. When the API interface changes affect the system When it is larger (e.g. ), a higher version number should be assigned; otherwise, a lower version number should be assigned (for example ). This version number allocation strategy based on the impact of changes can effectively manage the version evolution of the API interface.
[0080] Then, the generated API interface version control data is input into the API gateway routing module. The module performs version routing for service requests based on the API interface version control data. Specifically, when a client initiates an API call request, the API gateway routing module forwards the request to the corresponding version of the API interface instance based on the version number information carried in the request. This version-based routing mechanism ensures that the system maintains backward compatibility when upgrading the API version.
[0081] Through the above-mentioned version number allocation strategy based on change impact and version-based routing mechanism, the present invention solves the compatibility problem of large-scale microservice systems during API version upgrades and improves the maintainability and reliability of the system.
[0082] The specific implementation of step S80 is as follows. First, the present invention establishes an API interface optimization evaluation function. This function is used to calculate the number of optimized API interfaces. Number of API interfaces before optimization Simplification rate index between , the calculation formula is:
[0083] ;
[0084] When the simplification rate index Exceeding a preset optimization threshold (e.g. ), the API interface structure reorganization operation is performed.
[0085] The API interface structure reorganization operation includes the following three methods:
[0086] 1. Merge redundant API interfaces. Identify API interfaces with similar functions and parameters, merge them into one API interface, and reduce the number of API interfaces.
[0087] 2. Split overloaded API interfaces. For API interfaces that are too complex or have too wide a scope of responsibilities, split them into multiple API interfaces with clearer responsibilities.
[0088] 3. Adjust the API interface granularity. According to the complexity index of the API interface , Degree of Polymerization and call link metrics , adjust the granularity of the API interface to achieve the best state. Among them, the complexity index The calculation formula is:
[0089] ;
[0090] Call chain indicators The calculation formula is:
[0091] ;
[0092] Through the above three reorganization operations, the structure of the API interface can be continuously optimized to improve the maintainability and scalability of the system. After the reorganization is completed, the simplification rate index of the optimization effect is calculated again. , until the indicator meets the preset threshold requirements.
[0093] The calculation process or equation involved in the present invention is described in detail below:
[0094] 1. Calculation of API interface call link indicators:
[0095] The calculation equation of the API interface call link indicator is specifically expressed as follows:
[0096] ;
[0097] In the formula, For the API interface call link indicators; For the API interface call Frequency of API interfaces; For the The API interface is The depth of API calls; For the Average response time of each API interface; is the weight coefficient and satisfies ; The total number of API interfaces in the system; The maximum call depth.
[0098] The process of establishing this equation first analyzes the API call characteristics in the microservice architecture. Through practical observation of large-scale industrial systems, it is found that the importance of API interfaces is mainly affected by three factors: call frequency, call depth, and response time. The call frequency reflects the degree of use of the interface and is expressed in cumulative form. Calculates the calling relationship between a single interface and all other interfaces in the system; the calling depth indicates the position of the interface in the calling chain, through The contribution of call depth at each level is calculated cumulatively; the response time directly reflects the performance of the interface, and the average response time is used. As an evaluation indicator. In order to balance the influence of these three dimensions, the weight coefficient is introduced Perform weighted summation, determine the initial weight value through a large amount of experimental data verification and expert experience, and then combine the machine learning model for dynamic optimization and adjustment.
[0099] The parameter acquisition method is: Through the log collection components deployed in the system, such as the ELK (Elasticsearch, Logstash, Kibana) architecture, call records within a fixed time window (such as 24 hours) are collected, and the call frequency matrix is obtained through MapReduce calculation; Based on the call chain data collected by the call chain tracking system (such as Zipkin and Jaeger), analyze the call stack of each request, extract the hierarchical relationship between API interfaces, and calculate the call depth; Rely on the interface response time data collected by the APM (application performance monitoring) tool, use a sliding window to calculate the average value, and the window size is generally set to 1 hour; weight coefficient The value of needs to consider the system characteristics. For interactive intensive systems, it is recommended The value is larger (0.4-0.5), and for computationally intensive systems, it is recommended The value is relatively large (0.4-0.5), and the initial value can be set to , and then optimize and adjust based on the actual operation data of the system through machine learning models.
[0100] 2. Calculation of API interface complexity index:
[0101] The calculation equation of the API interface complexity index is specifically expressed as follows:
[0102] ;
[0103] In the formula, For the The complexity index of the API interface; For the The number of parameters of an API interface; For the Number of lines of code per API interface; For the Number of exceptions handled by API interfaces; They are the maximum number of parameters, the maximum number of code lines, and the maximum number of exceptions handled for all API interfaces in the system; is the weight coefficient and satisfies ; is the error term, ranging from 0.01 to 0.05.
[0104] The process of establishing this equation is based on software metrics theory and microservice design principles, and comprehensively considers the characteristics of the API interface in three dimensions: interface definition, implementation complexity, and exception handling. First, the key factors affecting the complexity of the API are analyzed: the parameter scale reflects the input and output complexity of the interface, the code scale reflects the implementation complexity, and the number of exception handling reflects the complexity of the business scenario. In order to solve the dimensionality problem of indicators in different dimensions, the maximum value normalization processing is introduced to convert the indicators of each dimension to the interval [0,1]. Taking into account the complexity factors that may be difficult to quantify in the actual system, such as the inherent complexity of the business logic and implicit dependencies with other components, the error term is introduced. Make compensation.
[0105] The parameter acquisition method is: Automatically extract parameter information in the interface definition through API document parsing tools (such as Swagger parser), including path parameters, query parameters, request body parameters, etc., and count the total number; Use code static analysis tools (such as SonarQube) to calculate the number of effective lines of code for interface implementation code, excluding comments and blank lines; Use code scanning tools to count the number of exception handling structures (try-catch blocks, throw statements, etc.) in interface-related codes; Obtain the maximum value of each indicator by regularly scanning the entire system API; weight coefficient The initial value can be set to , and then optimize and adjust by analyzing historical reconstruction data and expert evaluation results; error term The value range of is determined based on statistical analysis of a large amount of experimental data, and is generally between 0.01 and 0.05. The specific value can be adjusted according to the complexity of the system and the accuracy requirements of the assessment.
[0106] 3. Calculation of API interface dependency indicators:
[0107] The matrix of the API interface dependency indicators is as follows:
[0108] ;
[0109] In the formula, Indicates The API interface is The dependency degree of an API interface is in the range of [0,1]. When there is no dependency, It indicates a strong dependency.
[0110] The process of establishing the matrix adopts the methods of graph theory and matrix analysis. First, a directed graph model of API call relationships is constructed, in which nodes represent API interfaces and edges represent call relationships. The call chain is analyzed by the depth-first search algorithm to identify direct and indirect dependencies, and the call frequency and data flow characteristics are analyzed in combination with runtime data. The quantification process of the degree of dependency comprehensively considers multiple dimensions: the direct call relationship is obtained through static code analysis and is assigned a basic weight of 0.6; the indirect call relationship is obtained through call chain analysis, and the weight decays with the length of the call chain, with the decay factor set to 0.3; the data dependency is obtained by analyzing the data model and state shared between interfaces, with a weight of 0.4; the concurrent access mode must also be considered. If there are concurrent constraints, the weight value of 0.2 is increased. Finally, the weights of each dimension are normalized to obtain a dependency value in the range of [0,1].
[0111] The parameter acquisition method is as follows: direct dependencies use static code analysis tools (such as dependency analyzers) to scan the system code base and extract the call statements and data flow relationships between APIs; indirect dependencies require the deployment of distributed tracing systems (such as OpenTelemetry) to collect complete call chain data in the production environment; concurrent access patterns are identified by analyzing system logs and performance monitoring data; data model dependencies are obtained by analyzing the input and output model definitions of the API interface. For large-scale systems, it is recommended to adopt an incremental update strategy, update local data of the dependency matrix regularly (such as every day), and perform a full update once a week. The calculation of the degree of dependency needs to take into account the time decay factor, and an exponential decay function can be used to give the most recent dependencies a higher weight.
[0112] 4.API interface function description vector:
[0113] The API interface function description vector is specifically expressed as follows:
[0114] ;
[0115] In the formula, For the A functional description vector of an API interface; For the Functional feature words in TF-IDF value in the API interface description; is the total number of functional feature words.
[0116] The process of establishing this vector combines natural language processing and information retrieval technology. First, multiple dimensions of API information are collected: interface name, interface description document, code comments, parameter naming and comments, return value description, etc. The collected text is preprocessed, including word segmentation, part-of-speech tagging, stop word removal, stem extraction, etc. Then a feature dictionary is constructed, and keywords with business significance are extracted by combining domain dictionaries and statistical methods. For each API interface, the word frequency (TF) of each feature word in its text description is calculated, and the importance of the feature word is quantified by the TF-IDF algorithm combined with the inverse document frequency (IDF) of the feature word in the entire API set. In order to improve the representation effect of the vector, word embedding technology is also introduced, and the feature word is semantically enhanced using a pre-trained word vector model (such as Word2Vec or BERT), and finally a vector representation that can accurately express the functional characteristics of the API is obtained.
[0117] The parameter acquisition method is as follows: first, use the natural language processing tool chain to perform text preprocessing, including using a word segmenter (such as jieba or Stanford NLP) for word segmentation, using a part-of-speech tagger to identify important parts of speech such as nouns and verbs, and using a stop word list to filter meaningless words; then extract keywords based on a pre-defined domain dictionary and statistical methods. The dictionary includes three levels: technical terms, business terms, and general vocabulary; the TF-IDF value calculation of the feature word requires the statistical distribution of the word frequency of the entire API document collection. For newly added APIs, the IDF value needs to be dynamically updated; the total number of functional feature words k is determined by a feature selection algorithm, such as a method based on information gain or chi-square test, to select the most representative feature words, generally ranging from 100 to 300, and the specific value needs to be adjusted according to the system scale and business complexity.
[0118] 5.API interface version evaluation model:
[0119] The calculation equation of the API interface version evaluation model is specifically expressed as follows:
[0120] ;
[0121] In the formula, For the The version evaluation value of an API interface; For the Class influencing factors; For the The amount of changes to the API interface; For the The API interface and The relevance of the API interfaces; is the weight coefficient; is the error term, ranging from 0.1 to 0.3.
[0122] The establishment process of this model is based on the theory of change impact analysis, and adopts the analysis methods of calculus and graph theory. First, identify the factors affecting the API version change, including interface contract changes (parameter type, return value type, authentication method, etc.), functional semantic changes (business logic, processing flow, exception handling, etc.), performance characteristics changes (response time, resource consumption, concurrency, etc.), and dependency changes (call relationship, data dependency, message communication, etc.). For each type of influencing factor, establish a change sensitivity analysis model and use partial derivatives Indicates the degree of impact of interface changes on various aspects of the system. At the same time, considering the correlation effect between APIs, a correlation correction term is introduced , the propagation impact of the change is calculated through recursive analysis. In order to deal with uncertain factors, such as unknown client usage scenarios, potential compatibility issues, etc., an error term is introduced for risk compensation. The entire model is trained by machine learning methods to obtain various weight coefficients, using historical version change data as training samples.
[0123] The parameter acquisition method is: influencing factors The quantification is achieved through a multi-dimensional indicator system, including: the degree of interface contract change (based on interface definition comparison, the change rate is between 0-1), the degree of functional change (based on code difference analysis, considering the proportion of changed lines and key path changes), the performance change range (based on benchmark test results, calculating the percentage of change in key performance indicators), the dependency impact range (based on dependency graph analysis, calculating the number of affected direct and indirect dependencies); the amount of change Obtained through the difference analysis tool of the version control system (such as Git), including the number of code line changes, file changes, configuration changes, etc.; correlation Based on the call relationship graph and data flow analysis, the weight of direct call is 0.8, the weight of indirect call is 0.4 (decaying with the length of the call chain), and the weight of data dependency is 0.6; the weight coefficient It is obtained through gradient descent algorithm training, using the actual impact data of historical version changes as training labels; error term The value range of is determined based on statistical analysis of historical data, and is generally between 0.1 and 0.3. The larger error range reflects the uncertainty of version change impact assessment.
[0124] 6. Separation of responsibilities equation:
[0125] The division of responsibilities equation is specifically expressed as follows:
[0126] ;
[0127] In the formula, For the The responsibility boundary value of each API interface; For the The API interface and The similarity of functional domains; For the The importance of each functional domain; For the The complexity index of the API interface; For the The degree of aggregation of API interfaces; is the weight coefficient.
[0128] The process of establishing this equation is based on the theory of domain-driven design (DDD) and microservice design principles, and comprehensively considers the three dimensions of functional responsibilities, complexity, and aggregation. First, the system functions are divided into different functional domains through domain analysis methods, and each functional domain represents a class of related business capabilities. For each API interface, its similarity with each functional domain is calculated. The similarity calculation adopts the cosine similarity method based on the functional description vector. The quantification of the importance of the functional domain takes into account factors such as business value, access frequency, and associated dependencies. The interface complexity index reflects the complexity of the interface implementation, while the aggregation degree indicates the degree of cohesion between the interface and the functional domain to which it belongs. The combination of these three dimensions can comprehensively evaluate whether the responsibility boundary of the API interface is reasonable.
[0129] 7. Dependency analysis equation:
[0130] The dependency analysis equation is specifically expressed as follows:
[0131] ;
[0132] In the formula, For the The dependency optimization value of an API interface; is the element in the dependency matrix; For the API interface call link indicators; For the The API interface is in The position weight on the call path; is the weight coefficient.
[0133] The process of establishing this equation combines graph analysis and system reliability theory. The core idea is to optimize dependencies by analyzing the topological structure of the API call relationship network. First, an API call relationship graph is constructed, and a depth-first search algorithm is used to identify all possible call paths. For each API interface, consider its two roles as the caller and the callee: When acting as the caller, The dependency weight is multiplied by the call link index of the target interface to reflect the importance of the dependency. The weight of the position in different call paths is evaluated by the weighted combination of these two parts, which reflects the importance of the context of the call chain. The role and optimization value of the API interface in the dependency network can be comprehensively evaluated.
[0134] The parameter acquisition method is: dependency matrix element Obtained through a combination of code static analysis and runtime monitoring. Static analysis provides basic dependencies (weight 0.6), and runtime monitoring provides actual call intensity (weight 0.4); call link indicators Inherited from the result of the call link indicator calculation equation; position weight Calculated using an exponential decay function: ,in is the call chain depth, is the attenuation coefficient (usually 0.5); weight coefficient Determined by analyzing historical optimization cases, the general value range is , .
[0135] 8. Particle size optimization equation:
[0136] The particle size optimization equation is specifically expressed as follows:
[0137] ;
[0138] In the formula, For the The optimal granularity value of each API interface; is the complexity index; is the degree of polymerization; It is the call link indicator; is the weight coefficient; is the error term, ranging from 0.05 to 0.15.
[0139] The process of establishing this equation is based on the granularity division principle in microservice design theory, and the interface granularity optimization problem is formalized through mathematical modeling methods. It is to penalize high complexity and prevent the interface from becoming too complex; the inverse of the degree of aggregation It reflects the design principle of high aggregation and low coupling. The higher the aggregation, the smaller its inverse, and the smaller the penalty for granularity optimization. The call link indicator is added as a linear term to balance the access characteristics of the interface. Through the combination of these three items, the optimal granularity balance can be achieved while maintaining the functional integrity of the interface. Error term Used to deal with factors that cannot be quantified in the model, such as business semantic integrity, team development efficiency, etc.
[0140] The parameter acquisition method is: complexity index Inherited from the result of the complexity index calculation equation; aggregation degree By analyzing the mapping relationship between the API interface and the domain model, the number of data entities operated by the interface, the complexity of business rules and other factors are considered; call link indicators Inherited from the result of the call link indicator calculation equation; weight coefficient It needs to be determined through a lot of practical experience. The recommended initial values are 0.4, 0.3, and 0.3, respectively, and then dynamically adjusted according to the system operation effect; the error term The value range of needs to be determined through statistical analysis of historical optimization data, which is generally between 0.05-0.15. The smaller error range reflects the relative certainty of the granularity optimization decision.
[0141] The industrial big data microservice API structure optimization method proposed in this invention has significant advantages over traditional methods. The following is a detailed analysis of the traditional methods and the innovative points and effects of this invention:
[0142] Traditional method 1: API structure optimization based on manual experience
[0143] Traditional manual experience methods mainly rely on the subjective judgment and historical experience of development team members to optimize API structure. Developers adjust and reconstruct API interfaces based on experience through code review, performance test result analysis, problem feedback, etc. The limitations of this method are: the optimization results are highly dependent on personal experience and lack objective quantitative standards; it is difficult to deal with the complex dependencies of large-scale microservice systems; it is impossible to accurately predict the impact of API changes; the optimization process is time-consuming, inefficient, and prone to human bias.
[0144] Traditional method 2: API optimization strategy based on fixed thresholds
[0145] This method determines whether the API needs to be optimized by setting a series of fixed thresholds, such as response time threshold, error rate threshold, concurrency threshold, etc. When the monitoring indicator exceeds the preset threshold, the corresponding optimization operation is triggered. The shortcomings of this method are: the setting of thresholds lacks theoretical basis and is often too simple and mechanical; it is impossible to dynamically adjust the optimization strategy according to the business scenario; it does not consider the relationship between APIs and the overall system architecture; the optimization operation is relatively extensive, which may lead to local optimization and overall performance degradation.
[0146] Traditional method 3: API reconstruction method based on resource utilization
[0147] This method focuses on the usage of system resources, including CPU usage, memory usage, network bandwidth, etc., and refactors the API when resource usage exceeds a certain limit. The problems with this method are: it focuses too much on optimization at the resource level and ignores the optimization needs at the business logic level; it cannot effectively handle the functional overlap and division of responsibilities between APIs; it lacks a management mechanism for API version evolution; and it has a single optimization goal and cannot achieve a balance between multiple goals.
[0148] In contrast, the method proposed in the present invention has the following advantages and innovative effects:
[0149] 1. Innovative effect of the equation system:
[0150] The API interface optimization equations (including the responsibility division equation, dependency analysis equation, and granularity optimization equation) constructed by the present invention form a complete mathematical model, which can achieve the following effects:
[0151] First, the responsibility division equation establishes an objective responsibility boundary assessment mechanism by comprehensively considering the functional description index, complexity index and aggregation index of the API interface. This equation can not only quantify the scope of responsibility of the API interface, but also dynamically adjust the weight coefficient according to the actual business scenario, avoiding the deviation caused by subjective judgment in traditional methods.
[0152] Secondly, the dependency analysis equation builds a systematic dependency optimization model by introducing call link indicators and dependency relationship indicators. This equation can accurately identify and process complex dependencies between APIs, effectively solving the problem that traditional methods are difficult to deal with dependencies in large-scale microservice systems.
[0153] Finally, the granularity optimization equation achieves precise adjustment of the API interface granularity by establishing the mathematical relationship between complexity index, aggregation index and call link index. This equation uses a nonlinear optimization method to find the optimal API interface granularity while ensuring system performance, avoiding the problem of over-splitting or over-aggregation in traditional methods.
[0154] 2. Innovative effects of two neural networks:
[0155] The effect of the first machine learning model (recurrent neural network):
[0156] The model uses an LSTM (Long Short-Term Memory) structure, which can effectively capture the temporal characteristics of API call sequences. By analyzing historical API call data, the model can: accurately predict API interface call patterns and usage trends; identify potential associations between API interfaces; automatically extract API interface performance characteristics; and generate optimization suggestions with higher accuracy than traditional empirical judgments;
[0157] Effect of the second machine learning model (attention mechanism neural network): This model uses the attention mechanism to accurately evaluate the impact of API version changes. Specific effects include:
[0158] It can automatically identify the key factors affecting API changes; accurately assess the impact of changes on various parts of the system; predict potential compatibility issues; and provide the best version upgrade path;
[0159] 3. The comprehensive effect of the overall approach:
[0160] The present invention organically combines the equation group and the neural network model to form a complete API structure optimization framework, which has the following significant effects:
[0161] Adaptive optimization: The system can automatically adjust the optimization strategy based on actual operation data, no longer relying on fixed threshold judgment. This adaptive mechanism makes the optimization process more flexible and intelligent, and can adapt to different business scenarios and load conditions.
[0162] Global Optimization: Through the synergy of the equation set, the system is able to find the global optimal solution while considering multiple objectives, thus avoiding the problem of overall performance degradation that may be caused by local optimization in traditional methods.
[0163] Accurate prediction: The combination of two neural network models greatly improves the accuracy of predictions about API behavior and the impact of changes. This predictive capability helps development teams identify and resolve potential problems in advance.
[0164] Continuous optimization: The system continuously learns and accumulates experience, and the optimization effect will continue to improve over time. This continuous improvement feature is not available in traditional methods.
[0165] From the above analysis, it can be seen that the present invention not only overcomes the limitations of traditional methods, but also makes significant progress in the accuracy, efficiency and scalability of API structure optimization. Especially when dealing with large-scale industrial microservice systems, the advantages of the present invention are more obvious, and it can provide strong technical support for the continuous evolution of the system.
[0166] Specifically, the principle of the present invention is to construct an intelligent method that can automatically evaluate and optimize the API interface structure by analyzing and mining massive amounts of historical API call data.
[0167] First, the present invention adopts a recurrent neural network (RNN) structure as the first machine learning model. The model can effectively capture the timing characteristics of the API call sequence and conduct in-depth analysis of the functions, performance and dependencies of the API interface. Among them, the long short-term memory (LSTM) unit in the RNN model can memorize historical API call information and accurately predict future call patterns. By training this RNN model, the present invention extracts the call link index, complexity index and dependency index of the API interface, providing a key basis for subsequent API optimization.
[0168] Secondly, the present invention aims at the API version management problem and constructs a neural network model based on the attention mechanism as the second machine learning model. Through the attention calculation layer unit, the model can automatically identify the degree of association between different API interfaces, and combine the API change characteristics to accurately predict the impact of the change on system compatibility. This version impact assessment method based on the attention mechanism overcomes the problem that traditional methods are difficult to comprehensively assess the risk of changes.
[0169] In terms of mathematical modeling, the present invention designs a series of optimization equations, including responsibility division equations, dependency analysis equations, and granularity optimization equations. These equations fully absorb engineering practice experience and integrate multiple factors such as the functional characteristics, performance indicators, and dependency relationships of the API interface. By solving these equations, the present invention can automatically determine the optimal responsibility boundaries, dependency relationships, and granularity of the API interface, and achieve comprehensive optimization of the API structure.
[0170] In addition, the present invention also proposes a version number allocation strategy based on change impact and a version-based routing mechanism. This intelligent version management method based on prediction results ensures that large-scale industrial microservice systems maintain good compatibility and reliability when performing API version upgrades.
[0171] In order to better understand and implement the present invention, an embodiment of a specific application scenario of the present invention is provided below: An industrial Internet enterprise is developing an industrial big data analysis platform for the automobile manufacturing industry. The platform adopts a microservice architecture, including multiple microservice modules such as data collection service, data preprocessing service, data analysis service and data visualization service. In order to improve the reliability, scalability and maintainability of the platform, the enterprise decided to optimize the structure of the microservice API.
[0172] First, the enterprise comprehensively sorted out and analyzed the existing API interfaces of the platform. The data collection service API includes workshop equipment data collection API, process parameter collection API and product quality data collection API; the data preprocessing service API includes data cleaning API, data format conversion API and data aggregation API; the data analysis service API includes fault diagnosis API, production optimization API and quality prediction API; the data visualization service API includes data dashboard API, abnormal alarm API and report generation API. Through in-depth analysis of the functions, performance and dependencies of these API interfaces, the enterprise divides the industrial big data microservice API into data access layer microservice module, data processing layer microservice module and data service layer microservice module. In order to realize remote calls between microservices, the enterprise established a microservice remote call mechanism based on the HTTP protocol and formulated a microservice data exchange standard in JSON format.
[0173] Next, the company used the first machine learning model (recurrent neural network) to analyze and evaluate the API interface of the data access layer microservice module. The model first collected historical API call data, including the call frequency of the workshop equipment data collection API was 1,000 times a day, the average response time was 0.5 seconds, and the error rate was 3%; the call frequency of the process parameter collection API was 2,000 times a day, the average response time was 0.8 seconds, and the error rate was 2%; the call frequency of the product quality data collection API was 1,500 times a day, the average response time was 0.6 seconds, and the error rate was 4%.
[0174] After cleaning and preprocessing these historical data, the company extracted the API interface function description vector, performance indicator vector and call relationship vector as feature vectors. Among them, the function description vector uses TF-IDF technology to convert the API text description into a numerical vector. For example, the function description vector of the workshop equipment data collection API is ,The functional description vector of the process parameter acquisition API is ,The functional description vector of the product quality data collection API is The performance indicator vector includes indicators such as call frequency, response time and error rate. The call relationship vector reflects the dependency between APIs. For example, the degree to which the workshop equipment data collection API depends on the process parameter collection API is 0.7, and the degree to which it depends on the product quality data collection API is 0.5.
[0175] like Figure 2 As shown in the figure, three key performance indicators of the three main APIs (workshop equipment data collection API, process parameter collection API and product quality data collection API) are shown: daily call frequency, average response time and error rate. This chart can be used to intuitively compare the performance characteristics of different APIs.
[0176] Based on these feature vectors, the company constructed training sample pairs, using the API feature vectors as input data and the manually annotated API optimization suggestions as output data. Then, the company initialized the network parameters in the recurrent neural network and iteratively optimized the parameters through the back propagation algorithm until the model converged.
[0177] After training, the first machine learning model can accurately extract the key indicators of the API interface. Specifically, the call link indicators of the workshop equipment data collection API , Complexity Index , dependency indicators ;Indicators of the call link of the process parameter collection API , Complexity Index , dependency indicators ; Product quality data collection API call link indicators , Complexity Index , dependency indicators .
[0178] Based on the evaluation results of these indicators, the company found that there was a certain overlap in the responsibilities of the workshop equipment data collection API and the process parameter collection API, and the complexity of the product quality data collection API was relatively low. Therefore, the company decided to reconstruct the API interface of the data access layer microservice module.
[0179] First, the company established an API interface dependency analysis module and built a dependency matrix based on the API interface dependency indicators. :
[0180] ;
[0181] Analyzing the dependency matrix, the company found that there was a strong dependency between the workshop equipment data collection API and the process parameter collection API ( ), so they were merged into a comprehensive data collection API interface. At the same time, the company also split the original product quality data collection API interface into two API interfaces with clearer responsibilities: one focused on quality data collection and the other focused on quality analysis. Through this merging and splitting of API interfaces, the company optimized the API structure of the data access layer microservice module and improved the clarity of interface responsibilities.
[0182] Next, the company standardized the API interface of the data processing layer microservice module. First, the parameter naming of the API interface was standardized, such as unifying "deviceId" as "device_id" and "productQuality" as "product_quality". Then, the data types of the input parameters and output parameters of the API interface were unified, such as unifying different integer parameters into int type and string parameters into String type. Finally, unified verification rules were formulated for the input parameters of the API interface, such as parameter non-null check, value range check and format check. Through the above standardization, the company generated the API interface parameter specification for the data processing layer microservice module, which improved the reusability and maintainability of the API interface.
[0183] In terms of API version management, the company has established an API interface version evaluation model based on an attention mechanism neural network. The model first collects historical API version change data, including:
[0184] 1. API interface change type: Data collection API version 1.0 upgraded to 2.0, the change type is function optimization; Quality analysis API version 2.0 upgraded to 3.0, the change type is performance optimization; Report generation API version 1.0 upgraded to 2.0, the change type is interface optimization;
[0185] 2. Scope of API interface changes: Version 2.0 of the data collection API modified 5% of the code; Version 3.0 of the quality analysis API modified 12% of the code; Version 2.0 of the report generation API modified 15% of the code;
[0186] 3. Impact of API interface changes: The 2.0 version upgrade of the data collection API caused 5% of system services to be incompatible; the 3.0 version upgrade of the quality analysis API caused 12% of system services to be incompatible; the 2.0 version upgrade of the report generation API caused 3% of system services to be incompatible.
[0187] After standardizing and normalizing these historical data, the company built an API interface version feature matrix, including change type features, change scope features, and change impact features. Then, labels were generated for the training data based on the actual impact caused by the historical version changes.
[0188] Next, the company initializes the network parameters of the attention mechanism neural network model, inputs the API interface version feature matrix into the model, calculates the difference between the prediction results and the training data labels, and uses the back-propagation algorithm to update the network parameters until the model converges.
[0189] After training, the version evaluation model can predict the impact of API interface changes on system compatibility based on the change characteristics, dependency characteristics, and impact characteristics of the API interface. Taking the 2.0 version upgrade of the data collection API as an example, the model predicts its change impact value , the 3.0 version of the Quality Analysis API upgrade predicts the impact value , Version 2.0 of the report generation API upgrade predicts impact values .
[0190] Based on these prediction results, the enterprise determines the API version number allocation strategy based on the change impact: When a higher version number is assigned (such as the major version number + 1); when When , assign a lower version number (such as minor version number + 1); when When a new version is created, the lowest version number (such as revision number + 1) is assigned.
[0191] At the same time, the enterprise has established an API gateway routing module, which performs version routing for service requests based on the version control data of the API interface. When the client initiates an API call request, the API gateway will forward the request to the corresponding version of the API interface instance based on the version number information carried in the request. This version-based routing mechanism ensures good backward compatibility when upgrading the API version.
[0192] Finally, the company established an API interface optimization evaluation function to calculate the simplification rate index of the number of API interfaces before and after optimization. :
[0193] ;
[0194] in, The total number of API interfaces before optimization. The total number of optimized API interfaces. When it exceeds 20%, the enterprise will perform API interface structure reorganization operations.
[0195] Specifically, the company first identified API interfaces with similar functions in the data collection API and quality analysis API, merged them into comprehensive interfaces, and reduced the number of API interfaces. At the same time, the company also found that some interfaces of the report generation API were too complex, so it split them into finer-grained interfaces. Through the above merging and splitting operations, the company optimized the structure of the API interface and improved the maintainability of the system. After optimization, the total number of API interfaces was reduced from 30 before optimization to 22, and the simplification rate reached 26.7%, meeting the optimization threshold requirements. Figure 3 As shown in the figure, the code modification ratio, system incompatibility ratio and predicted impact value of different API version upgrades are displayed, and the threshold line of version upgrade is marked.
[0196] Through the above series of optimization measures, the enterprise's industrial big data microservice API structure has been significantly improved. The specific performance is as follows:
[0197] 1. The responsibilities of the API interface are clearer, and the problems of overlapping functions and excessive coupling are effectively solved.
[0198] 2. The API interface calling relationship is more optimized, and the overall system performance is improved. There will be no situation where local optimization leads to overall performance degradation.
[0199] 3. API version management is more intelligent and reliable, greatly reducing the risks and compatibility issues during version upgrades.
[0200] 4. The overall API structure is more concise and efficient, and maintainability and scalability are significantly improved.
[0201] It should be noted that the variables involved in the present invention are described in detail in Table 1 below.
[0202] Table 1 Variable explanation table
[0203]
[0204] The above description is only a specific implementation mode of the present invention, but the protection scope of the present invention is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed by the present invention, which should be covered by the protection scope of the present invention.
Claims
1. A method for optimizing the structure of industrial big data microservice API, characterized in that: The following steps are involved: Analyze the data collection API, data preprocessing API, data analysis API, and data display API in industrial big data scenarios, and divide the industrial big data microservice API into data access layer microservice modules, data processing layer microservice modules, and data service layer microservice modules; A first machine learning model based on long short-term memory units is used to analyze the API interface responsibility scope of the data access layer microservice module, and extract API interface call link indicators; an API interface dependency analysis module is established to construct an API interface call relationship diagram; input and output parameters of the data processing layer microservice module are standardized; an API interface version management module is established to collect API interface change records; and a second machine learning model based on an attention mechanism is used to analyze the output data of the API interface version evaluation model; Determine the version number allocation strategy based on the impact of API interface changes; An API interface optimization equation group including a responsibility division equation, a dependency analysis equation and a granularity optimization equation is established; an API interface optimization evaluation function is established based on the API interface optimization equation group; an API interface structure reorganization operation is performed to achieve optimization of the industrial big data microservice API structure; wherein the API interface version evaluation model is constructed based on the API interface change record of the data service layer microservice module, the API interface discarded record of the data service layer microservice module, and the API interface new added record of the data service layer microservice module.
2. The method for optimizing the industrial big data microservice API structure according to claim 1, characterized in that: The first machine learning model adopts a recurrent neural network structure, including input layer nodes, hidden layer nodes, and output layer nodes. The hidden layer nodes are composed of multiple long short-term memory units, and each of the long short-term memory units includes a forget gate unit, an input gate unit, and an output gate unit.
3. The method for optimizing the industrial big data microservice API structure according to claim 2, characterized in that: The steps of establishing the training data set of the first machine learning model include: collecting historical API interface call data; performing data cleaning on the historical API interface call data; extracting API interface feature vectors; and constructing training sample pairs.
4. The method for optimizing the industrial big data microservice API structure according to claim 3, characterized in that: The training steps of the first machine learning model include: initializing the network parameters in the recurrent neural network structure; inputting the training sample pairs into the first machine learning model; calculating the loss function value; optimizing and updating using the back propagation algorithm; and iterating the training until convergence.
5. The method for optimizing the industrial big data microservice API structure according to claim 4, characterized in that: The second machine learning model adopts an attention mechanism neural network structure, including an encoder unit, a decoder unit, and an attention calculation layer unit. The attention calculation layer unit is used to calculate the call correlation degree between different API interfaces in the data service layer microservice module.
6. The method for optimizing the industrial big data microservice API structure according to claim 5, characterized in that: The steps of establishing the training data set of the second machine learning model include: collecting historical data of API interface version changes; performing data preprocessing on the historical data of API interface version changes; constructing an API interface version feature matrix; and generating training data labels.
7. The method for optimizing the industrial big data microservice API structure according to claim 6, characterized in that: The training steps of the second machine learning model include: initializing network parameters in the attention mechanism neural network structure; inputting the API interface version feature matrix into the second machine learning model; calculating the difference between the prediction results and the training data labels; updating the network parameters; and iterating the training until convergence.
8. The method for optimizing the industrial big data microservice API structure according to claim 7, characterized in that: The API interface optimization equation group includes a responsibility division equation, a dependency analysis equation, and a granularity optimization equation. The responsibility division equation is used to calculate the API interface responsibility boundary, the dependency analysis equation is used to calculate the API interface call link indicator, and the granularity optimization equation is used to calculate the optimal API interface granularity.
9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores program instructions, and when the program instructions are executed in a computer, they are used to execute the industrial big data microservice API structure optimization method described in any one of claims 1 to 8.
10. An industrial big data microservice API structure optimization system, characterized in that: A computer-readable storage medium comprising the computer-readable storage medium of claim 9.
Citation Information
Patent Citations
Microservices architecture
CN109144660A
Distributed interface defect detection method and system for micro-service architecture
CN119248632A