A cloud-native-based interface parameter dynamic configuration method, device and medium

Abstract

The application discloses a kind of interface parameter dynamic configuration method, equipment and medium based on cloud native, it is related to interface configuration technical field, including, obtain application code, and execute parameter extraction and version identification embedding, obtain interface call configuration parameter, interface call configuration parameter is associated with device running state corresponding, form state association parameter;For state association parameter copy multiple parallel interface requests, the interface return information returned to each parallel request is compared for consistency, obtain consistent interface return information, based on return state feature, return data feature and error information feature are combined to determine, to identify whether interface call is abnormal, corresponding repair strategy is matched, form repair parameter;Time interval division and interval switching control are executed to repair parameter, form repair timing control result.The application executes item-by-item comparison in interface return information set and filters out difference information, so that interface exception handling has definiteness and controllability.

Description

Technical Field

[0001] This invention relates to the field of interface configuration technology, and in particular to a cloud-native method, device and medium for dynamic configuration of interface parameters. Background Technology

[0002] With the continuous development of cloud-native architecture, microservice-based API call mechanisms have gradually become the mainstream implementation method in distributed systems. Under this architecture, API parameter configuration has evolved from an early static embedding method to a centralized and dynamic management model. API URLs, parameter rules, and timeout parameters are typically maintained through a unified configuration carrier and dynamically loaded and updated in conjunction with runtime environment information. Simultaneously, monitoring and adjustment technologies surrounding API operation are constantly improving. Research is increasingly focusing on state awareness of API call behavior, parsing of multi-source return information, and policy-driven configuration adjustment mechanisms. In this process, computer and auxiliary equipment repair technologies are gradually being integrated into the API operation management system to support parameter repair and operational adjustment under abnormal API conditions.

[0003] Existing technologies typically rely on the result of a single interface call for anomaly detection during dynamic configuration of interface parameters, and then directly perform configuration adjustments accordingly. This lacks consistency analysis and timing control mechanisms for the results of multiple calls, which can easily lead to misjudgments or frequent adjustments when the interface's running status fluctuates or there are occasional differences in the returned information. This affects the stability of interface calls and the accuracy of configuration adjustments. Summary of the Invention

[0004] In view of the aforementioned existing problems, the present invention is proposed.

[0005] Therefore, this invention provides a cloud-native method for dynamically configuring interface parameters to solve the problem of easy misjudgment or frequent adjustments.

[0006] To solve the above-mentioned technical problems, the present invention provides the following technical solution: In a first aspect, the present invention provides a cloud-native method for dynamically configuring interface parameters, comprising, The application code is obtained, and parameter extraction and version identifier embedding are performed to obtain the interface call configuration parameters. The interface call configuration parameters are associated with the device running status to form a status association parameter. The device running status is the status information that represents the current running status of the interface device. Multiple parallel interface requests are copied for the state association parameters. The interface return information returned by each parallel request is compared for consistency to obtain consistent interface return information. Return status features, return data features, and error information features are extracted from the consistent interface return information. Based on the return status features, return data features, and error information features, a combined judgment is made to identify whether the interface call is abnormal. When the identification result is abnormal, the corresponding repair strategy is matched to form repair parameters. The return status feature is formed by verifying whether the return status code in the consistent interface return information belongs to the set of success status codes, and is used to characterize the interface execution status; the return data feature is formed by verifying whether the field names in the consistent interface return information are complete and whether the field types are consistent, and is used to characterize the interface return data structure. The repair parameters are divided into time intervals and the interval switching control is performed to form the repair timing control result; By controlling the repair timing, the interface call configuration parameters are version-switched and the repair strategy is adjusted to form a repair record chain.

[0007] As a preferred embodiment of the cloud-native-based dynamic configuration method for interface parameters described in this invention, the parameter extraction is the process of parsing the URL, parameter rules, and timeout parameters from the interface call configuration in the application code. The version identifier embedding is used to write a version identifier that marks the version of the interface call configuration parameters.

[0008] As a preferred embodiment of the cloud-native-based dynamic configuration method for interface parameters described in this invention, wherein: the formation of state-related parameters specifically refers to... Assign context identifiers to the configuration parameters of the API call to form a set of configuration parameters with context identifiers; The configuration parameters of the interface calls in the configuration parameter set are synchronously transmitted, and the device operating status is recorded at the interface device to form a device status set; Based on the context identifier, the operating status of the device in the device status set is located and bound to the configuration parameter set item by item to form status association parameters.

[0009] As a preferred embodiment of the cloud-native-based dynamic configuration method for interface parameters described in this invention, wherein: the formation of repair parameters specifically refers to... Inject state-related parameters into the interface request and trigger the interface call. At the same time, copy the interface request to form a parallel call branch. The API calls are sent to the API in parallel branches, and the API return information is received from the API. The returned information from the API is collected and organized to form a set of API return information. Perform a step-by-step comparison of the returned information from the API in the API return information set, and mark the consistent and different fields; When there are completely identical interface return messages in the set of interface return messages, one of the completely identical interface return messages will be regarded as the consistent interface return message. When there are no completely consistent interface return information in the set of interface return information, count the number of different fields in each interface return information and select the interface return information with the fewest different fields as the consistent interface return information. Anomaly feature analysis is performed on the consistent interface return information. Based on the anomaly feature analysis results, the anomaly type is determined for the anomaly features in the consistent interface return information, and anomaly identification results are formed. Based on the anomaly identification results, repair strategies are retrieved from the repair strategy set, and the repair strategies are matched and confirmed to form repair parameters.

[0010] As a preferred embodiment of the cloud-native-based dynamic configuration method for interface parameters described in this invention, wherein: the formation of the anomaly identification result specifically refers to, The consistent interface return information is split into a return status field, a return data field, and an error information field; Perform anomaly feature extraction on the return status field, return data field, and error message field to generate return status feature results, return data feature results, and error message feature results; Perform status comparison on the returned status feature results to form a status judgment result; perform integrity check and type matching on the returned data feature results to form a data judgment result; and perform keyword matching on the error message feature results to form an error judgment result. The status determination result, data determination result, and error determination result are combined for judgment: When at least two types of judgment results represent an abnormal state, the consistent interface return information is judged as the abnormal interface return information, and the judgment results representing the abnormal state are collected and the abnormal identification result is output. When at least two types of judgment results indicate a normal state, the consistent interface return information is judged as normal interface return information, and a normal state identifier is output. When there is a conflict among the three types of judgment results, priority verification processing is performed on the status judgment result, data judgment result and error judgment result, and the final judgment result is determined according to the preset priority order, and the corresponding recognition result is output.

[0011] As a preferred embodiment of the cloud-native-based dynamic configuration method for interface parameters described in this invention, wherein: the formation of the repair timing control result specifically comprises, The repair parameters are time-stamped and arranged in chronological order to form a repair parameter sequence; The repair parameter sequence is divided into continuous time intervals, and the repair parameters in adjacent time ranges in the repair parameter sequence are assigned to the corresponding continuous time intervals to form a set of time intervals; In the set of time intervals, the start and end positions of each time interval are delineated, and the switching relationship between adjacent time intervals is established to form an interval switching sequence; Based on the interval switching sequence, interval switching control is performed on the repair parameters, and the repair parameters are activated in different time intervals to form the repair timing control result.

[0012] As a preferred embodiment of the cloud-native-based dynamic interface parameter configuration method of the present invention, wherein: the formation of the repair record chain specifically refers to, Based on the time interval in the repair timing control results, the interface call configuration parameters are matched for interval, and the corresponding version number is identified for the interface call configuration parameters within the matched time interval. The configuration parameters for API calls with version numbers are enabled or disabled according to time intervals, forming a version switching sequence; By using a version switching sequence, the repair strategy is matched and adjusted, and a corresponding relationship is established with the configuration parameters of the interface call with version number, thus forming a repair strategy adjustment sequence; The version switching sequence and the repair strategy adjustment sequence are linked and linked in chronological order to form a repair record chain.

[0013] As a preferred embodiment of the cloud-native-based dynamic configuration method for interface parameters described in this invention, the interface request includes request information containing a URL, parameter rules, and timeout parameters. The repair strategy is a pre-defined strategy rule used to adjust the interface call configuration parameters.

[0014] In a second aspect, the present invention provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the computer program, when executed by the processor, implements any step of the cloud-native interface parameter dynamic configuration method described in the first aspect of the present invention.

[0015] Thirdly, the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein: when the computer program is executed by a processor, it implements any step of the cloud-native interface parameter dynamic configuration method described in the first aspect of the present invention.

[0016] The beneficial effects of this invention are as follows: By performing item-by-item comparison and filtering out discrepancies in the set of interface return information to form consistent interface return information, anomaly identification is based on the consistency of multiple interface call results, thereby ensuring the stability and uniformity of the anomaly judgment criteria; by performing anomaly feature analysis and anomaly type determination based on consistent interface return information, the anomaly identification process has a clear classification path and judgment logic, enabling the computer and auxiliary equipment repair process to respond in a targeted manner according to the determined anomaly type and form a clearly structured anomaly identification result, thereby making interface anomaly handling clear and controllable, while maintaining the stable evolution of the interface operating state during changes. Attached Figure Description

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

[0018] Figure 1 This is a flowchart of a cloud-native method for dynamically configuring interface parameters.

[0019] Figure 2 A flowchart generated for state-related parameters.

[0020] Figure 3 A flowchart for generating parameters for anomaly identification and repair.

[0021] Figure 4 A flowchart for generating repair timing control and repair record chain. Detailed Implementation

[0022] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0023] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0024] Secondly, the term "one embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in one embodiment" appearing in different places in this specification does not necessarily refer to the same embodiment, nor is it a single or selective embodiment that is mutually exclusive with other embodiments.

[0025] Reference Figures 1-4 This is one embodiment of the present invention, which provides a cloud-native method for dynamically configuring interface parameters, including the following steps: S1. Obtain the application code and perform parameter extraction and version identifier embedding to obtain the interface call configuration parameters. Associate the interface call configuration parameters with the device running status to form status association parameters. The device running status is the status information that represents the current running status of the interface device.

[0026] S1.1. The application code is read from the code storage location in the application runtime environment. The application code storage location includes three sources: the source code directory, the build artifact directory, and the runtime loading path. The source code directory corresponds to the set of source code files saved during the development phase; the build artifact directory corresponds to the set of executable files or bytecode files generated after compilation; and the runtime loading path corresponds to the location of the application code files loaded when the interface call is actually executed. After determining the application code storage location, the application code files are read one by one according to the file path, and the application code files are filtered according to file type identification rules. The file type identification rules determine the range of parsable code files based on the file extension and file header identifier, such as application code files corresponding to extensions like ".java", ".py", or ".class". The content of the filtered application code files is read and parsed according to a unified character encoding format. The character encoding format adopts the default encoding of the application runtime environment or the encoding method declared in the configuration file, thereby forming application code that can be used for subsequent parameter extraction.

[0027] S1.2, parameter extraction is the process of parsing the URL, parameter rules, and timeout parameters from the interface call configuration in the application code; version identifier embedding is the process of writing a version identifier that marks the interface call configuration version into the interface call configuration parameters, specifically, The API call statements in the application code are used as the identification entry point. The code segment corresponding to the API call statement is structurally split. The structural splitting is based on the programming language syntax, which separates the API address, parameter construction, and timeout control expression into independent fields. The API address corresponds to the URL field, the parameter construction expression corresponds to the parameter rule field, and the timeout control expression corresponds to the timeout parameter field.

[0028] During field identification, the field range is determined by a combination of keyword matching and syntax location. Keyword matching identifies the name of the API call function and the name of the parameter identifier, while syntax location determines the position of the field in the function call expression, thus avoiding confusion between different fields. Consistency checks are performed on the identified URL field, parameter rule field, and timeout parameter field. The consistency checks include whether the fields exist simultaneously, whether the field types match, and whether the field values ​​conform to the API call format constraints. When a field is missing or the field type does not match, the corresponding API call statement is marked as invalid and excluded, and it does not participate in the generation of API call configuration parameters. When all fields are complete and the types match, the URL field, parameter rule field, and timeout parameter field are combined in a fixed field order to form structured API call configuration parameters. The fixed field order is determined according to the parameter arrangement order of the API call statement in the application code, which is the index order of the API address, parameter rule, and timeout parameter in the parameter list of the API call statement.

[0029] It should be noted that the field value conformance to the interface call format constraint is used to verify whether the field values ​​of the URL field, parameter rule field, and timeout parameter field conform to the format registered in the interface definition document. Fields that pass the verification are used in the combination of structured interface call configuration parameters, while the corresponding interface call statements of fields that fail the verification are marked as invalid and excluded. The interface definition document is an interface description file in the application code that describes the field names, field types, and field value formats of the interface address, parameter rules, and timeout parameters.

[0030] A version identifier is written for each set of structured interface call configuration parameters. The version identifier consists of a time identifier and a sequence identifier. The time identifier comes from the time information recorded when the application code reads the data, and the sequence identifier is generated according to the order in which the interface call configuration appears in the application code. The combination of the time identifier and the sequence identifier forms a unique version identifier. The version identifier is then bound to the structured interface call configuration parameters one by one to complete the generation of the interface call configuration parameters.

[0031] S1.3. Assign context identifiers to the interface call configuration parameters to form a set of configuration parameters with context identifiers. Specifically, A context identifier is written to the interface call configuration parameters to distinguish the execution environment and call source of the interface call configuration parameters. The context identifier consists of the interface call location identifier, the call environment identifier, and the call time identifier. The interface call location identifier comes from the combination of file path and function name in the application code. The call environment identifier comes from the environment variable information in the application runtime environment, including the runtime environment name and instance identifier. The call time identifier comes from the time information recorded when the interface call configuration parameters are generated.

[0032] The interface call location identifier, call environment identifier, and call time identifier are combined in the order of the fields to form a context identifier. The context identifier is then written into the corresponding field position in the interface call configuration parameter. By binding the context identifier to the interface call configuration parameter, each set of interface call configuration parameters has a unique environment mark and source mark, thus forming a configuration parameter set with a context identifier.

[0033] It should be noted that the field order is: API call location identifier, call environment identifier, and call time identifier. The API call location identifier is used to determine the call source, the call environment identifier is used to determine the scope of the running environment, and the call time identifier is used to determine the time dimension location. They are arranged in a logical hierarchical order of source, environment, and time.

[0034] S1.4. Synchronously transmit the interface call configuration parameters in the configuration parameter set, and record the device operating status at the interface device to form a device status set. Specifically, Using a set of configuration parameters with context identifiers as the transmission object, a transmission identifier is established for the interface call configuration parameters and synchronous transmission is performed according to the transmission identifier. Synchronous transmission is completed through the interface call request sending channel. The interface call request sending channel comes from the interface call communication path in the application runtime environment. The communication path includes communication location information formed by the combination of network connection address and request sending port.

[0035] During synchronous transmission, the interface call configuration parameters are encapsulated into request messages and written into communication location information, so that the interface call configuration parameters can reach the corresponding interface devices in sequence.

[0036] After receiving the request message corresponding to the interface call configuration parameters, the interface device records the current operating status of the interface device. The recorded content includes the interface device processing status, interface response status, and resource occupancy status. The interface device processing status is obtained through the interface execution return flag, the interface response status is obtained through the interface return code, and the resource occupancy status is obtained through the interface device operation monitoring information. The interface device operation monitoring information comes from the operation status record information in the operating environment where the interface device is located.

[0037] The interface device processing status, interface response status, and resource occupancy status are bound to the corresponding interface call configuration parameters one by one, and encapsulated according to a unified field order to form a device status set.

[0038] S1.5. Based on the context identifier, locate the device operating status in the device status set, and bind it item by item with the configuration parameter set to form status association parameters, specifically, Context identifiers are used to establish the correspondence between device operating status and interface call configuration parameters. For each device operating status in the device status set, the interface call location identifier, call environment identifier, and call time identifier recorded in the device operating status are read and compared with the corresponding fields in the configuration parameter set item by item. The interface call location identifier is used to limit the consistency of the interface call source, the call environment identifier is used to limit the consistency of the operating environment, and the call time identifier is used to limit the time matching relationship.

[0039] When the interface call location identifier, call environment identifier, and call time identifier all match, the corresponding device running status is determined as the matching result and retained. When any field does not match, the corresponding device running status is removed.

[0040] For the device running status in the matching results, according to the field order of the interface call configuration parameters, the interface device processing status, interface response status and resource occupancy status are written into the corresponding field positions in the interface call configuration parameters one by one, so that the device running status information and the interface call configuration parameters form a one-to-one correspondence. Status association parameters are generated by merging fields.

[0041] It should be noted that the interface call configuration parameters are centrally managed through a unified configuration center in the distributed runtime environment and synchronously transmitted to each runtime instance through the interface call communication path. Each runtime instance independently loads and executes the interface call configuration parameters according to the context identifier, thereby ensuring the consistent application of the interface call configuration parameters in a multi-instance environment.

[0042] S2. Copy multiple parallel interface requests for the state association parameters, perform consistency comparison on the interface return information returned by each parallel request to obtain consistent interface return information, extract return status features, return data features and error information features from the consistent interface return information, and combine and judge based on the return status features, return data features and error information features to identify whether the interface call is abnormal. When the identification result is abnormal, match the corresponding repair strategy to form repair parameters.

[0043] S2.1 Inject state-related parameters into the interface request and trigger the interface call. At the same time, copy the interface request to form a parallel call branch. The interface request contains request information including URL, parameter rules and timeout parameters. Send the interface request to the calling interface through the parallel call branch and receive the interface return information returned by the calling interface. Collect and organize the returned interface return information to form an interface return information set.

[0044] S2.2, Perform a step-by-step comparison of the interface return information in the interface return information set, and mark the consistent and differing fields. Specifically, For multiple API return messages in the API return message set, each API return message is structurally aligned. The structural alignment includes three types of fields: return status field, return data field, and error message field. These three types of fields are then arranged in a uniform field order.

[0045] Consistency comparison is performed item by item according to the field position. The consistency comparison adopts the method of completely consistent field value. When the field value of the same field position is completely consistent in the information returned by different interfaces, the corresponding field is marked as a consistent field and retained. When the field value is inconsistent, the corresponding field is marked as a difference field and the source of the difference is recorded.

[0046] After all fields have been matched for consistency, the interface return information containing discrepancies is filtered out. The filtering rule is to retain only the interface return information where all fields are consistent. When there are multiple completely consistent interface return information in the set of interface return information, one of the multiple interface return information is retained as the consistent interface return information according to the same field order. When there are no completely consistent interface return information in the set of interface return information, the number of discrepancies in each interface return information is counted, and the interface return information with the fewest discrepancies in the fewest discrepancies is selected as the consistent interface return information.

[0047] It should be noted that consistent interface return information refers to interface return information where all fields are consistent when there is completely consistent interface return information, and to interface return information with the fewest differences and fixed positions when there is no completely consistent interface return information. Interface return information obtained by filtering for the fewest differences maintains consistency in non-difference fields and is used as the basis for unified processing.

[0048] S2.3. Perform anomaly feature analysis on the consistent interface return information, and determine the anomaly type based on the anomaly feature analysis results in the consistent interface return information to form an anomaly identification result. Specifically, S2.31. The consistent interface return information is split into a return status field, a return data field, and an error message field; exception feature extraction is performed on the return status field, return data field, and error message field to form return status feature results, return data feature results, and error message feature results, specifically, The return status code in the return status field is compared item by item with the set of success status codes recorded in the interface definition document. If the comparison matches, it is marked as a status match mark, and if the comparison does not match, it is marked as a status exception mark. The status match marks and status exception marks are written into a fixed structure in the order of the fields to form the return status feature result.

[0049] The field names and values ​​in the returned data fields are verified against the set of field names and the set of field types registered in the interface definition document. Field names that match completely are marked as complete, and fields that are missing are marked as missing. Field types that match completely are marked as consistent, and fields that are inconsistent are marked as abnormal. The complete, missing, consistent, and abnormal field types are written into a fixed structure in the order of the fields to form the returned data feature results.

[0050] The error message text in the error message field is matched item by item with the set of abnormal keywords. Successful matches are marked as keyword hits, and unmatched matches are marked as keyword misses. The keyword hit and keyword miss marks are written into a fixed structure to form the error message feature result.

[0051] Among them, the return status feature is formed by verifying whether the return status code in the consistent interface return information belongs to the set of success status codes, which is used to characterize the interface execution status; the return data feature is formed by verifying whether the field names in the consistent interface return information are complete and whether the field types are consistent, which is used to characterize the interface return data structure.

[0052] S2.32. Perform state comparison on the returned status feature results to form a status judgment result; perform integrity check and type matching on the returned data feature results to form a data judgment result; and perform keyword matching on the error message feature results to form an error judgment result. Specifically, The system locates and compares the consistent state markers and abnormal state markers from the returned state feature results. When an abnormal state marker exists, the corresponding result is recorded as an abnormal state determination result. When only a consistent state marker exists, the corresponding result is recorded as a normal state determination result to form a state determination result.

[0053] The system identifies and jointly judges field completeness markers, field missingness markers, type consistency markers, and type anomaly markers from the returned data feature results. When a field missingness marker or a type anomaly marker exists, the corresponding result is recorded as an abnormal data judgment result. When both a field completeness marker and a type consistency marker exist, the corresponding result is recorded as a normal data judgment result to form a data judgment result.

[0054] Locate and distinguish keyword hit markers and keyword miss markers from the error message feature results. When a keyword hit marker exists, record the corresponding result as an abnormal error judgment result. When a keyword miss marker exists and a keyword hit marker does not exist, record the corresponding result as a normal error judgment result to form an error judgment result.

[0055] S2.33, Combine the status determination result, data determination result, and error determination result for judgment: When at least two types of judgment results both indicate an abnormal state, the consistent interface return information is judged as the abnormal interface return information, and the judgment results indicating the abnormal state are aggregated and the abnormal identification result is output. Specifically, The status determination results, data determination results, and error determination results are marked as abnormal status determination results or normal status determination results respectively when they are generated. The determination method is as follows: the presence of a status abnormality mark in the status determination result indicates an abnormal status, and the presence of only a status consistency mark indicates a normal status; the presence of a field missing mark or a type abnormality mark in the data determination result indicates an abnormal status, and the presence of both a field complete mark and a type consistency mark indicates a normal status; the presence of a keyword hit mark in the error determination result indicates an abnormal status, and the presence of only a keyword mishit mark indicates a normal status.

[0056] After completing the status identification, the number of status judgment results, data judgment results, and error judgment results is counted. When the number of judgment results representing abnormal status reaches two categories, the consistent interface return information is identified as abnormal interface return information. All judgment results representing abnormal status are classified and summarized according to the judgment source, where the status judgment result corresponds to the status abnormal type, the data judgment result corresponds to the data abnormal type, and the error judgment result corresponds to the error abnormal type. The classified and summarized abnormal type set is written into a unified structure as the output of abnormal identification results.

[0057] When at least two judgment results indicate a normal state, the consistent interface return information is judged as normal interface return information, and a normal state identifier is output. Specifically, Based on the statistical analysis of the number of judgment results representing the normal state among the three types of judgment results, when the number of judgment results representing the normal state reaches two types, the consistent interface return information is determined as the normal interface return information; the result determined as the normal interface return information is written into the normal state identifier, which is recorded using a unified tag field, and the tag content is the normal state tag value, such as "normal". The normal state identifier and the consistent interface return information are encapsulated to form the final output result.

[0058] When the three types of judgment results conflict, priority verification processing is performed on the state judgment result, data judgment result, and error judgment result, and the final judgment result is determined according to the preset priority order, and the corresponding recognition result is output. Specifically, When the state determination result, data determination result, and error determination result simultaneously contain determination results that represent both abnormal and normal states, the three types of determination results are identified as conflicting states.

[0059] A priority sequence is established for conflict states. The priority sequence is arranged in the order of error judgment result, data judgment result, and status judgment result. The priority sequence is set based on the fact that the error information field directly reflects the interface execution exception information, the data field reflects the structural integrity and type consistency of the returned content, and the status field reflects the interface execution result identifier, thus forming a judgment priority relationship from high to low.

[0060] The corresponding judgment results are read sequentially according to the priority sequence. When a judgment result representing an abnormal state is read, the corresponding judgment result is determined as the final judgment result and subsequent reading stops. When all judgment results in the priority sequence represent normal states, the last judgment result read is determined as the final judgment result. The corresponding identification result is output according to the state type of the final judgment result. When the final judgment result is an abnormal state, the abnormal identification result is output. When the final judgment result is a normal state, the normal state identifier is output.

[0061] It should be noted that the normal status identifier is written into the identifier field corresponding to the consistent interface return information and encapsulated and stored together with the consistent interface return information. It is used to record the normal status of the current interface return information. It does not participate in the generation of repair parameters in subsequent steps, but is only retained as a status record.

[0062] S2.4. Based on the anomaly identification results, retrieve the repair strategy from the repair strategy set, match and confirm the repair strategy, and form repair parameters, specifically, Using the anomaly type in the anomaly identification results as the search criteria, each repair strategy in the repair strategy set is matched and filtered item by item. Each repair strategy in the repair strategy set includes the applicable anomaly type, strategy action content, and priority identifier.

[0063] When the applicable anomaly type in the repair strategy matches the anomaly type in the anomaly identification result, the corresponding repair strategy is retained and a candidate repair strategy set is formed. When the applicable anomaly type does not match, the corresponding repair strategy is excluded.

[0064] In the candidate repair strategy set, based on the anomaly field positions marked in the anomaly identification results, field coverage verification is performed on the strategy action content. Field coverage verification is used to determine whether the adjustment fields involved in the strategy action content contain the corresponding positions of the anomaly fields. When the strategy action content contains the anomaly field positions, the corresponding repair strategy is determined as a matching repair strategy; when the strategy action content does not contain the anomaly field positions, the corresponding repair strategy is removed. When there are multiple matching repair strategies, the matching repair strategies are sorted according to priority identifiers, and the repair strategy with the highest priority is selected. The strategy action content in the selected repair strategy is encapsulated with the anomaly identification results to form repair parameters. Among them, the priority identifiers are divided according to the impact range of the anomaly type on the interface call results. Anomaly types involving interface call failure or inability to return results correspond to high priority identifiers, anomaly types involving missing returned data or field anomalies correspond to medium priority identifiers, and anomaly types involving only error message prompts but not affecting the interface call results correspond to low priority identifiers.

[0065] S3. Perform time interval division and interval switching control on the repair parameters to form the repair timing control result.

[0066] S3.1. Time-stamp the repair parameters and arrange them chronologically to form a repair parameter sequence. Specifically, Each repair record in the repair parameters is assigned a time identifier, which is formed by combining the interface call trigger time and the repair strategy generation time. The interface call trigger time comes from the time information recorded when the interface request is sent, and the repair strategy generation time comes from the time information recorded when the anomaly identification result is generated. The interface call trigger time and the repair strategy generation time are combined into a unified time identifier in the order of "interface call trigger time first, repair strategy generation time second" and written into the corresponding field position in the repair parameters.

[0067] For all repair parameters with a unified time identifier, they are sorted in ascending order according to the interface call trigger time in the unified time identifier. When the interface call trigger times are the same, the repair strategy generation time is used as the sorting basis. The repair parameter sequence is obtained by a two-level time sorting method. The two-level time sorting method is to first sort according to the interface call trigger time, and then sort according to the repair strategy generation time when the interface call trigger times are the same.

[0068] S3.2. Divide the repair parameter sequence into continuous time intervals, and group repair parameters within adjacent time ranges in the repair parameter sequence into their corresponding continuous time intervals to form a set of time intervals. Specifically, The interface call trigger time corresponding to adjacent repair parameters in the repair parameter sequence is used to determine the time interval. All adjacent time intervals are statistically analyzed to obtain the average interval level, and 1.2 times the average interval level is used as the time continuity judgment threshold. Starting from the first repair parameter in the repair parameter sequence, the time interval between adjacent repair parameters is judged one by one. When the time interval is less than or equal to the time continuity judgment threshold, the corresponding repair parameter is included in the current continuous time interval. When the time interval is greater than the time continuity judgment threshold, the current continuous time interval ends, and the current repair parameter is used as the starting point of the new continuous time interval. The entire repair parameter sequence is traversed according to the above division method, and each continuous time interval is recorded in chronological order to form a time interval set.

[0069] S3.3. Determine the start and end positions of each time interval in the set of time intervals, and establish the switching relationship between adjacent time intervals to form an interval switching sequence. Specifically, Each time interval in the time interval set is numbered in chronological order, and the start and end positions of each time interval are determined by the interface call trigger time corresponding to the first repair parameter in each time interval and the interface call trigger time corresponding to the last repair parameter in each time interval.

[0070] Connect adjacent time intervals in chronological order to establish a sequential connection between the previous and next time intervals. Record the sequential connection relationships of all adjacent time intervals in chronological order to obtain the interval switching sequence.

[0071] S3.4. Based on the interval switching sequence, perform interval switching control on the repair parameters, activating the repair parameters in different time intervals to form the repair timing control result, specifically as follows: Each sequential connection in the interval switching sequence corresponds to a pair of adjacent time intervals. For each time interval, the corresponding repair parameter range is determined in the repair parameter sequence based on the start and end positions of the time interval, and the repair parameters within the corresponding range are marked as currently enabled.

[0072] When a time interval changes, the repair parameters that were marked as enabled in the previous time interval are de-marked according to the sequential connection relationship recorded in the interval switching sequence, and the repair parameters in the corresponding range of the next time interval are updated to be enabled.

[0073] The switching process of the enable flag is executed sequentially for all time intervals according to the interval switching sequence, so that only the corresponding repair parameters in each time interval are enabled. The enabled repair parameters of each time interval are recorded in correspondence with the start and end positions of the time interval to obtain the repair timing control result.

[0074] S4. Based on the repair timing control results, the interface call configuration parameters are switched and the repair strategy is adjusted to form a repair record chain.

[0075] S4.1. Based on the time intervals in the repair sequence control results, perform interval matching on the interface call configuration parameters, and identify the corresponding version number of the interface call configuration parameters within the matched time intervals. Specifically, Each time interval in the repair timing control result includes a start position and an end position. The unified time identifier recorded in the interface call configuration parameters is compared item by item. The interface call trigger time in the unified time identifier is used to match the start and end positions of the time interval.

[0076] When the trigger time of an interface call is greater than or equal to the start position of the time interval and less than or equal to the end position of the time interval, the corresponding interface call configuration parameters will be determined to belong to that time interval. When the trigger time of an interface call is not within the range of that time interval, it will not participate in the matching of that time interval.

[0077] For interface call configuration parameters that match the same time interval, read the original version identifier in the interface call configuration parameters, and write the time interval number into the version identifier as the interval version mark. The version identifier of the interface call configuration parameters is updated by adding the interval version mark to the version identifier.

[0078] S4.2 Enable / disable the interface call configuration parameters with version numbers according to time intervals, forming a version switching sequence. Specifically, Using time intervals as the switching benchmark, the interface call configuration parameters that have been written with interval version tags are enabled on an interval-by-interval basis. For each time interval, the interface call configuration parameters whose interface call trigger time falls within the range of that time interval are filtered, and the filtered results are marked as enabled. At the same time, the interface call configuration parameters whose interface call trigger time does not fall within the range of that time interval are marked as disabled.

[0079] When time intervals switch sequentially, the enabled status of the interface call configuration parameters corresponding to the previous time interval is canceled, and the enabled status of the interface call configuration parameters corresponding to the next time interval is updated. The enabling status switching process is executed sequentially according to the time interval order, and the enabled interface call configuration parameters corresponding to each time interval are recorded with the time interval number to obtain the version switching sequence arranged in the order of time intervals.

[0080] S4.3. The repair strategy is adjusted and matched using a version switching sequence, establishing a correspondence with the interface call configuration parameters that have version numbers, thus forming a repair strategy adjustment sequence. The repair strategy is a pre-defined rule used to adjust the interface call configuration parameters. Specifically, The time interval number corresponds to the currently enabled interface call configuration parameter. The currently enabled interface call configuration parameter is matched and filtered against the repair strategies in the repair strategy set one by one.

[0081] Each repair strategy in the repair strategy set is given an applicable time interval number, strategy action content, and priority identifier. When the applicable time interval number is the same as the current time interval number, the corresponding repair strategy is included in the candidate range. When the applicable time interval number is different from the current time interval number, the corresponding repair strategy is excluded.

[0082] Within the candidate scope, the policy action content and the interface call configuration parameter fields are checked item by item. The checking method is to determine whether the adjustment field involved in the policy action content exists in the interface call configuration parameter fields. When the adjustment field exists, the corresponding repair policy and the interface call configuration parameter are established. When the adjustment field does not exist, the corresponding repair policy is removed.

[0083] When multiple repair strategies meet the conditions, they are sorted according to priority identifiers, and the repair strategy with the highest priority is selected. The selected repair strategy is then associated with the corresponding time interval number and interface call configuration parameters to form a repair strategy adjustment sequence.

[0084] It should be noted that the highest priority repair strategy is the repair strategy with the highest impact on the corresponding exception type in the repair strategy set. The impact is determined by the scope of the impact of the exception type on the interface call result. Among them, the exception type that causes the interface call to fail or cannot return a result corresponds to the highest impact, the exception type that causes the returned data to be abnormal corresponds to the medium impact, and the exception type that only generates prompt information and does not affect the interface call result corresponds to the lowest impact.

[0085] S4.4. Link and chain the version switching sequence and repair strategy adjustment sequence according to time sequence to form a repair record chain. Specifically, The time interval number is used as a unified sorting basis to align and organize the records in the version switching sequence and the repair strategy adjustment sequence. The alignment method is to establish a one-to-one correspondence according to the same time interval number, so that each time interval corresponds to a set of version switching results and a set of repair strategy adjustment results.

[0086] After alignment is completed, the records are associated one by one according to the order of the time interval numbers. Each record contains the time interval number, the version identifier of the corresponding interface call configuration parameter, and the policy action content of the corresponding repair policy. Sequential connection relationship is established between adjacent records. The connection method is to write the pointer identifier of the next time interval number to the record corresponding to the current time interval number, and at the same time, write the source identifier of the current time interval number to the record corresponding to the next time interval number.

[0087] By organizing all records sequentially according to the above connection relationship, the records form a sequential structure in chronological order, thus obtaining the repair record chain.

[0088] It should be noted that when the interface call configuration parameters are switched, the time interval number is used as the switching boundary. After the execution of the interface call configuration parameters in the current time interval is completed, the switch is made to the corresponding version in the next time interval. If abnormal interface call results are detected during the switching process, the current time interval version is not switched and the corresponding repair strategy is continued to be executed, thereby avoiding configuration failure during the switching process.

[0089] This embodiment also provides a computer device applicable to the dynamic configuration method of interface parameters based on cloud-native methods, including: a memory and a processor; the memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions to implement the dynamic configuration method of interface parameters based on cloud-native methods proposed in the above embodiments. The computer device can be a terminal, comprising a processor, memory, communication interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, carrier networks, NFC (Near Field Communication), or other technologies. The display screen can be an LCD screen or an e-ink screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad on the computer device's casing, or an external keyboard, touchpad, or mouse.

[0090] This embodiment also provides a storage medium storing a computer program that, when executed by a processor, implements the cloud-native interface parameter dynamic configuration method proposed in the above embodiments. The storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Red-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0091] In summary, this invention achieves consistent anomaly identification by performing item-by-item comparison and filtering of discrepancies in the interface return information set to form consistent interface return information. This ensures the stability and uniformity of the anomaly judgment criteria by establishing anomaly identification based on the consistency of multiple interface call results. Furthermore, by performing anomaly feature analysis and anomaly type determination based on the consistent interface return information, the anomaly identification process has a clear classification path and judgment logic. This allows the computer and auxiliary equipment repair process to respond specifically based on the determined anomaly type and form a clearly structured anomaly identification result. Consequently, interface anomaly handling becomes clear and controllable, while maintaining the stable evolution of the interface's operating state during changes.

[0092] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A cloud-native method for dynamically configuring interface parameters, characterized in that: include, The application code is obtained, and parameter extraction and version identifier embedding are performed to obtain the interface call configuration parameters. The interface call configuration parameters are associated with the device running status to form a status association parameter. The device running status is the status information that represents the current running status of the interface device. Multiple parallel interface requests are copied for the state association parameters. The interface return information returned by each parallel request is compared for consistency to obtain consistent interface return information. Return status features, return data features, and error information features are extracted from the consistent interface return information. Based on the return status features, return data features, and error information features, a combined judgment is made to identify whether the interface call is abnormal. When the identification result is abnormal, the corresponding repair strategy is matched to form repair parameters. The return status feature is formed by verifying whether the return status code in the consistent interface return information belongs to the set of success status codes, and is used to characterize the interface execution status; the return data feature is formed by verifying whether the field names in the consistent interface return information are complete and whether the field types are consistent, and is used to characterize the interface return data structure. The repair parameters are divided into time intervals and the interval switching control is performed to form the repair timing control result; By using the repair timing control results to switch versions of interface call configuration parameters and adjust repair strategies, a repair record chain is formed. Specifically... Based on the time interval in the repair timing control results, the interface call configuration parameters are matched for interval, and the corresponding version number is identified for the interface call configuration parameters within the matched time interval. The configuration parameters for API calls with version numbers are enabled or disabled according to time intervals, forming a version switching sequence; By using a version switching sequence, the repair strategy is matched and adjusted, and a corresponding relationship is established with the configuration parameters of the interface call with version number, thus forming a repair strategy adjustment sequence; The version switching sequence and the repair strategy adjustment sequence are linked and linked in chronological order to form a repair record chain.

2. The cloud-native-based dynamic configuration method for interface parameters as described in claim 1, characterized in that: The parameter extraction is the process of parsing the URL, parameter rules, and timeout parameters from the interface call configuration in the application code. The version identifier embedding is used to write a version identifier that marks the version of the interface call configuration parameters.

3. The cloud-native-based dynamic configuration method for interface parameters as described in claim 1, characterized in that: The formation state association parameters are specifically as follows: Assign context identifiers to the configuration parameters of the API call to form a set of configuration parameters with context identifiers; The configuration parameters of the interface calls in the configuration parameter set are synchronously transmitted, and the device operating status is recorded at the interface device to form a device status set; Based on the context identifier, the operating status of the device in the device status set is located and bound to the configuration parameter set item by item to form status association parameters.

4. The cloud-native-based dynamic configuration method for interface parameters as described in claim 1, characterized in that: The formation of repair parameters specifically refers to, Inject state-related parameters into the interface request and trigger the interface call. At the same time, copy the interface request to form a parallel call branch. The API calls are sent to the API in parallel branches, and the API return information is received from the API. The returned information from the API is collected and organized to form a set of API return information. Perform a step-by-step comparison of the returned information from the API in the API return information set, and mark the consistent and different fields; When there are completely identical interface return messages in the set of interface return messages, one of the completely identical interface return messages will be regarded as the consistent interface return message. When there are no completely consistent interface return information in the set of interface return information, count the number of different fields in each interface return information and select the interface return information with the fewest different fields as the consistent interface return information. Anomaly feature analysis is performed on the consistent interface return information. Based on the anomaly feature analysis results, the anomaly type is determined for the anomaly features in the consistent interface return information, and anomaly identification results are formed. Based on the anomaly identification results, repair strategies are retrieved from the repair strategy set, and the repair strategies are matched and confirmed to form repair parameters.

5. The cloud-native-based dynamic configuration method for interface parameters as described in claim 4, characterized in that: The formation of the anomaly identification result is specifically as follows: The consistent interface return information is split into a return status field, a return data field, and an error information field; Perform anomaly feature extraction on the return status field, return data field, and error message field to generate return status feature results, return data feature results, and error message feature results; Perform status comparison on the returned status feature results to form a status judgment result; perform integrity check and type matching on the returned data feature results to form a data judgment result; and perform keyword matching on the error message feature results to form an error judgment result. The status determination result, data determination result, and error determination result are combined for judgment: The status determination results, data determination results, and error determination results are marked as abnormal status determination results or normal status determination results respectively when they are generated. After the status identification is completed, the number of status determination results, data determination results, and error determination results is counted. When at least two types of judgment results represent an abnormal state, the consistent interface return information is judged as the abnormal interface return information, and the judgment results representing the abnormal state are collected and the abnormal identification result is output. When at least two types of judgment results indicate a normal state, the consistent interface return information is judged as normal interface return information, and a normal state identifier is output. When there are both judgment results representing abnormal states and judgment results representing normal states among the state judgment results, data judgment results and error judgment results, the three types of judgment results are identified as conflict states. When the three types of judgment results conflict, priority verification processing is performed on the state judgment results, data judgment results and error judgment results, and the final judgment result is determined according to the preset priority order, and the corresponding recognition result is output.

6. The cloud-native-based dynamic configuration method for interface parameters as described in claim 1, characterized in that: The formation of the repair timing control result specifically refers to... The repair parameters are time-stamped and arranged in chronological order to form a repair parameter sequence; The repair parameter sequence is divided into continuous time intervals, and the repair parameters in adjacent time ranges in the repair parameter sequence are assigned to the corresponding continuous time intervals to form a set of time intervals; In the set of time intervals, the start and end positions of each time interval are delineated, and the switching relationship between adjacent time intervals is established to form an interval switching sequence; Based on the interval switching sequence, interval switching control is performed on the repair parameters, and the repair parameters are activated in different time intervals to form the repair timing control result.

7. The cloud-native-based dynamic configuration method for interface parameters as described in claim 4, characterized in that: The interface request contains request information including the URL, parameter rules, and timeout parameters; The repair strategy is a pre-defined strategy rule used to adjust the interface call configuration parameters.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that: When the processor executes the computer program, it implements the steps of the cloud-native dynamic configuration method for interface parameters as described in any one of claims 1 to 7.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by the processor, it implements the steps of the cloud-native dynamic configuration method for interface parameters as described in any one of claims 1 to 7.

Images