An object verification method, apparatus, device, medium, and program product

Abstract

The present application provides an object verification method, device, equipment, medium and program product, and relates to the technical field of computers. The method comprises the following steps: obtaining a data set, wherein the data set comprises metadata identifiers and record contents, the metadata identifiers are used for identifying verification objects, and the record contents are used for describing the verification objects; selecting a verification strategy corresponding to the metadata identifiers; extracting key key values from the record contents according to the verification strategy, wherein the key key values comprise key values of the verification objects; obtaining a first object and a second object by using the metadata identifiers and the key key values, wherein the second object is a verification object to be verified in a system to be verified, and the first object is a verification object in a reference state; and comparing the first object and the second object to obtain difference information, wherein the difference information is used for describing the difference between the first object and the second object. The technical problem of the accuracy and consistency of metadata in a distributed online system is solved, and the accuracy and consistency of the metadata in the distributed online system are ensured.

Description

Technical Field

[0001] This relates to the field of computer technology, and in particular to an object verification method, apparatus, device, medium, and program product. Background Technology

[0002] Distributed online systems typically employ an architecture that separates the control plane and the data plane. The control plane can be a data center responsible for maintaining and publishing metadata, while the data plane can be an execution engine that performs traffic routing and decision-making.

[0003] Distributed online systems are prone to problems with the accuracy and consistency of metadata. Summary of the Invention

[0004] This invention provides an object verification method, apparatus, device, medium, and program product that ensures the accuracy and consistency of metadata in a distributed online system.

[0005] In one scenario, this paper provides an object validation method, which includes: Obtain a dataset containing metadata identifiers and record content. The metadata identifiers are used to identify the verification object, and the record content is used to describe the verification object. Select the verification strategy corresponding to the metadata identifier; According to the verification strategy, key values ​​are extracted from the record content, and the key values ​​include the key values ​​of the verification object; Using the metadata identifier and the key value, obtain the first object and the second object, where the second object is the verification object being verified in the verification system, and the first object is the verification object in the baseline state. The first object and the second object are compared to obtain difference information, which is used to describe the differences between the first object and the second object.

[0006] In one instance, this document also provides an object verification apparatus, comprising: The acquisition module is used to acquire a dataset, which contains metadata identifiers and record content. The metadata identifiers are used to identify the verification object, and the record content is used to describe the verification object. The selection module is used to select the verification strategy corresponding to the metadata identifier; An extraction module is used to extract key values ​​from the record content according to the verification strategy, wherein the key values ​​include the key values ​​of the verification object; The acquisition module is used to acquire a first object and a second object using the metadata identifier and the key value, wherein the second object is the verification object being verified in the verification system, and the first object is the verification object in the baseline state. A comparison module is used to compare the first object and the second object to obtain difference information, which is used to describe the differences between the first object and the second object.

[0007] In one instance, this document also provides an electronic device comprising: One or more processing devices; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processing devices, the one or more processing devices perform any of the methods described herein.

[0008] In one instance, this document also provides a storage medium containing computer-executable instructions that, when executed by a computer processor, are used to perform any of the methods described herein.

[0009] In another scenario, this document also provides a computer program product comprising a computer program that, when executed by a processor, implements any of the methods described herein.

[0010] The above method obtains a dataset containing metadata identifiers and record content. Then, a verification strategy corresponding to the metadata identifier is selected, and key values ​​are extracted from the record content according to the verification strategy. Using the metadata identifier and the key values, a first object and a second object are obtained. The first object and the second object are compared to obtain difference information, thereby verifying the first object in the system being verified. This solves the technical problem of metadata accuracy and consistency that easily occurs in distributed online systems, ensuring the accuracy and consistency of metadata in distributed online systems. Attached Figure Description

[0011] The above and other features, advantages, and aspects of the various situations described herein will become more apparent when viewed in conjunction with the accompanying drawings and with reference to the following specific manner. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale.

[0012] Figure 1 This is a schematic diagram of the structure of an object verification system under one scenario. Figure 2 This is a flowchart illustrating an object verification method for one scenario. Figure 3 This is a flowchart illustrating an object verification method for another scenario. Figure 4 A flowchart illustrating an optional instance of the object validation method in another scenario; Figure 5 This is a schematic diagram of an object verification device under one specific scenario. Figure 6 This is a schematic diagram of the structure of an electronic device used to implement an object verification method in one scenario. Detailed Implementation

[0013] The present invention will now be described in more detail with reference to the accompanying drawings. While certain scenarios are shown in the drawings, it should be understood that the solutions can be implemented in various forms and should not be construed as limited to the scenarios described herein. Rather, these scenarios are provided to provide a more thorough and complete understanding of the solutions herein. It should be understood that the accompanying drawings and implementations are for illustrative purposes only and are not intended to limit the scope of this document.

[0014] It should be understood that the steps described in the method may be performed in different orders and / or in parallel. Furthermore, the method may include additional steps and / or omit the steps shown. The scope of this document is not limited in this respect.

[0015] The term "comprising" and its variations as used herein are open-ended inclusions, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one situation" means "at least one situation"; the term "another situation" means "at least one additional situation"; the term "some situations" means "at least some situations". Definitions of other terms will be given in the following description.

[0016] It should be noted that the concepts of "first" and "second" mentioned are only used to distinguish different devices, modules or units, and are not used to limit the order of the functions performed by these devices, modules or units or their interdependencies.

[0017] It should be noted that the terms "one" and "more" used in this document are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0018] The names of messages or information exchanged between multiple devices in this document are for illustrative purposes only and are not intended to limit the scope of these messages or information.

[0019] It is understandable that before using the technical solutions disclosed in each scenario in this document, users should be informed of the type, scope of use, and usage scenarios of the personal information involved in this document in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.

[0020] For example, upon receiving a user's active request, a prompt message is sent to the user to explicitly inform them that the requested operation will require the acquisition and use of the user's personal information. This allows the user to independently choose whether to provide personal information to the software or hardware, such as electronic devices, applications, servers, or storage media, that perform the operations described herein, based on the prompt message.

[0021] As an optional but non-limiting implementation, in response to a user's active request, sending a prompt message to the user can be done via a pop-up window, where the prompt message can be presented in text format. Furthermore, the pop-up window can also include a selection control allowing the user to choose "agree" or "disagree" to provide personal information to the electronic device.

[0022] It is understood that the above notification and user authorization process is merely illustrative and does not limit the implementation method described in this article. Other methods that comply with relevant laws and regulations may also be applied to the implementation method described in this article.

[0023] It is understood that the data involved in the technical solutions in this article (including but not limited to the data itself, the acquisition or use of the data) shall comply with the requirements of relevant laws, regulations and related provisions.

[0024] Figure 1 This is a schematic diagram of an object verification system in one scenario. In a distributed online system, the control plane and data plane are often separated. The control plane can be considered the configuration and rule center, such as the configuration and rule center responsible for maintaining and publishing configurations for traffic distribution, routing, and decision-making. The control plane maintains rules or configurations for traffic distribution, routing, and decision-making, and propagates changes to online nodes through methods such as publishing, pushing, pulling, or cache refreshing, similar to the online data plane.

[0025] The data plane can be considered an online traffic routing and decision execution engine. This engine executes traffic routing and decision-making logic on the online request chain. Under strict latency and availability constraints, the data plane performs real-time traffic routing and decision-making based on already effective rules; these rules and configurations also fall into a certain type of authoritative data source for backtracking and unified querying. An authoritative data source can refer to data storage considered ultimately trustworthy in the overall system, such as a database, metadata store, or read-only mirror repository.

[0026] like Figure 1 As shown, the object verification system includes the system being verified and the verification system.

[0027] The system being verified comprises three subsystems: the control plane, the data plane, and the authoritative data source. The control plane is responsible for creating, editing, and publishing rules or configurations; the data plane is responsible for executing traffic allocation decisions based on currently effective configurations on the online pipeline; and the authoritative data source is used to persistently store the final state of various rules or configurations, serving as a basis for backtracking and benchmark reconciliation. Reconciliation refers to comparing and verifying two or more sets of data to check for equality and matching, and to identify discrepancies.

[0028] The verification system includes a triggering and orchestration module, a bypass verification service, and a driver module.

[0029] The triggering and orchestration module generates verification tasks from change events and sends verification requests. The source of change events is not limited here; they can originate from the rule release pipeline, configuration center change logs, scheduled inspection tasks, or manually triggered work orders. The triggering and orchestration module encapsulates change events into unified verification requests, which can be referred to as the first request, and sends them to the bypass verification service according to a unified protocol. Bypass verification refers to the process of verifying the consistency of data or rule validity through an independent link without altering the core processing link of the system being verified.

[0030] The bypass verification service can provide a unified verification entry point externally, and internally complete steps such as rule routing, change convergence window identification, data retrieval, semantic normalization, field consistency determination, propagation timing determination, and result encapsulation. Semantic normalization refers to the process of converting the fields to be compared into a normalized representation to eliminate non-semantic differences, including but not limited to key sorting, time and numerical unit unification, null value normalization, and ignoring field removal.

[0031] Driver module: Includes sub-modules such as monitoring and alarms, verification dashboards, and manual review. The standardized response output by the bypass verification service will enter the driver module to drive automatic retry, tiered alarms, manual review, and subsequent rectification.

[0032] Distributed online systems are characterized by frequent rule changes, multi-level propagation chains, complex component dependencies, and extreme sensitivity of online links to performance and stability. Once a consistency anomaly occurs, it often manifests as "partial node activation, delayed activation, missing fields, and semantic drift of fields," leading to problems such as incorrect traffic distribution strategies. For example, if the control plane adjusts the activation time of a policy from 10:00 to 10:05, and the caches of some data plane nodes are not refreshed in time, the same request may receive different traffic distribution results on different nodes.

[0033] To address the aforementioned issues of data accuracy and consistency, this paper presents an object calibration method. Figure 2This is a flowchart illustrating an object verification method for one scenario. This method is suitable for scenarios involving metadata verification, particularly distributed systems where data and control are categorized, such as metadata verification in distributed online systems. The metadata can be rules and / or configurations. This object verification method can be executed by an object verification device, which can be implemented in software and / or hardware, optionally through an electronic device such as a mobile terminal, PC, or server. Figure 2 As shown, the object verification method may specifically include: S210, Obtain the dataset.

[0034] The dataset contains metadata identifiers and record content. The metadata identifiers are used to identify the verification object, and the record content is used to describe the verification object. The verification object, also known as the verification context object, can be metadata, such as rules and / or configurations.

[0035] Metadata identifiers, also known as rule identifiers, are used to uniquely identify a type of verification logic or verification object. For example, they can be defined by "..." The string is composed of concatenated characters, such as Metadata identifiers can be used in subsequent steps to select the corresponding verification strategy in the routing table, and the business meaning of the verification can be marked in the record.

[0036] The recorded content can be the content of the verification object, such as the original payload passed along with the change event or inspection request, generally in a structured format such as JSON. The recorded content typically includes at least the fields before and after the configuration change, the operation type (e.g., add, modify, delete), the operation time, and one or more pieces of information from the business primary key. The recorded content can be the direct source for subsequent extraction of key values, change times, and baseline query conditions for constructing the verification object.

[0037] The key values ​​include the key values ​​of the verification object; key values ​​can refer to a set of key values ​​used to uniquely locate the verification object in both the authoritative data source and the verified side. The keys in the key values ​​can be single-field primary keys or multi-field composite primary keys. For example, for a certain traffic splitting rule object, the keys in the key values ​​can be... The three components constitute a single entity. The key-value pair can be used as query conditions in subsequent steps of obtaining the baseline and target states. The baseline state can refer to an authoritative snapshot of the data source side, typically derived from rule tables or persistent storage in the configuration center, serving as a baseline for consistency comparison. The target state can refer to a snapshot of the state being verified, typically derived from the data plane or its tightly coupled read-only storage, representing the configuration state that truly takes effect on online requests.

[0038] The change time refers to the timestamp directly associated with the change to the object being verified (also known as the verification object). The change time typically comes from the "update_time," "publish_time," or "operate_time" fields in the record content or the log. When a record contains multiple time fields, a strategy can be configured to select a priority for each rule; for example, prioritizing the publication time of the publishing pipeline record and then reverting to the update time of the configuration record. The change time can be used as a time reference in subsequent change convergence window determination and propagation timing determination.

[0039] The convergence window, also known as the change convergence window, refers to the time interval during which the control plane, data plane, and authoritative data source become inconsistent for a short period due to the propagation of changes. Differences occurring within this interval can be suppressed using noise reduction strategies.

[0040] The dataset can be a collection formed after parsing the first request. The first request can be a request used to trigger the validation of the object being validated, and it can include multiple fields. Extracting the fields from the first request forms the dataset.

[0041] In one scenario, obtaining the dataset includes: Receive a first request, the first request being used to trigger the verification of the verification object; If the first request passes verification, the first request is parsed to obtain the dataset.

[0042] The first request, also known as a verification request, can be the input carrier required to trigger a bypass verification. A verification request must include at least the following information: rule identifier, record content, key value, change time, and caller.

[0043] Upon receiving the first request, authentication, rate limiting, and infrastructure validation can be performed on it. After successful validation, the fields included in the first request can be parsed to form a dataset.

[0044] If the first request fails to validate, the result can be returned directly without validating the object being validated.

[0045] In one scenario, parsing the first request to obtain the dataset after the first request passes verification includes: The structure of the first request is verified to obtain the verification result; If the verification result indicates that the verification passed, the fields included in the first request are extracted to form the dataset.

[0046] The validation result can be considered as the result obtained after verifying the structure of the first request. This article can validate the structure of the first request; the validation method is not limited here, as long as it is related to the structure of the first request. If the validation result indicates that the first request has passed validation, the fields included in the first request can be extracted from the first request, and the extracted fields can be used to form a dataset.

[0047] In one scenario, the structure of the first request is validated to obtain a validation result, including: The following one or more of the first request are validated to obtain the validation results: The fields included in the first request, and the size of the first request.

[0048] In this article, the validation of the first request structure includes the validation of the fields included in the first request, such as whether the first request contains the fields required for the validation object, and whether the types of the fields are correct.

[0049] In this paper, the verification of the first request structure includes verifying the size of the first request, such as verifying whether the size of the payload of the first request exceeds a preset limit. If so, the result can be returned directly without verifying the object being verified.

[0050] S220. Select the verification strategy corresponding to the metadata identifier.

[0051] After obtaining the dataset, a verification strategy (also known as a validation strategy) is selected based on the metadata identifiers within the dataset. The validation strategy is the method used to validate the object being validated. Different metadata can correspond to different validation strategies. After obtaining the metadata identifiers, a validation strategy for those metadata identifiers can be selected to verify the object being validated. A verification strategy can refer to a verification logic unit bound to a certain type of rule identifier, responsible for defining specific field comparisons, semantic normalization configurations, convergence window thresholds, and propagation timing rules.

[0052] In this paper, a verification strategy can be selected from those strategies that have already been compiled and tested. Alternatively, it can verify whether the metadata identifier in the dataset allows execution in a production environment (such as a production environment for the control plane and / or data plane) of the object verification system.

[0053] In one scenario, the verification strategy corresponding to the metadata identifier is selected, including: Select the policy type corresponding to the metadata identifier from the policy registry; If the authorization set contains the metadata identifier, the policy of the policy type shall be used as the verification policy; The policy registry is a mapping table generated during compilation, which stores the mapping relationship between the metadata identifier and the policy type.

[0054] The policy registry can include multiple policies that have been compiled and tested. The object verification method provided in this article can be a method executed in the bypass verification service. During the compilation of the object verification method, the compiled policy can be added to the policy registry. The policy registry can describe the policy types corresponding to different metadata. When selecting the verification policy corresponding to the metadata identifier, the policy type corresponding to the metadata identifier can be selected from the policy registry.

[0055] The authorization set contains metadata identifiers that allow validation to be performed. When the authorization set contains metadata identifiers, it can be assumed that the metadata identifiers in the dataset are permitted to be executed in the production environment of the object validation system. For example, validation of the validation object can be performed based on the metadata identifiers in the production environment.

[0056] During the verification process, if the authorization set contains the aforementioned metadata identifier, the policy of the policy type will be used as the verification policy. The policy of the policy type can be the policy corresponding to the metadata identifier, used to verify the verification object.

[0057] To achieve low-cost expansion and secure use of multiple rules, this paper adopts a policy interface, a policy registry, and a controlled-enabling framework. Each verification rule corresponds to a verification policy (which can refer to a logical unit bound to a certain type of rule identifier, implementing specific field comparison and timing determination logic) and exposes a unified verification entry interface. For example, it can be agreed that all policies implement a unified interface, which is called back by the bypass verification service after routing is completed.

[0058] Policies are registered through a constructor factory: during compilation, the system scans policy implementation classes or explicit registration lists, registering all policy types in the policy registry. During the build phase, automatic aggregation ensures that new policies are included in the artifacts, even if they are not yet enabled at runtime. At runtime, a dual-gate mechanism ensures safe enabling: The first gate (compile-time aggregation): controls whether the strategy is compiled into the artifacts. The strategy code will only be included in the release artifacts after passing code reviews, unit tests, and the build pipeline. The second gate (runtime authorization set): controls whether the policy is instantiated at runtime and receives actual traffic. The policy whitelist can be configured by rule identifier, caller, environment (test / pre-production / production), etc., and supports online hot updates.

[0059] Through this strategy framework and dual-gate mechanism, adding or modifying verification rules only requires adding or adjusting the corresponding strategy implementation, without altering the main bypass service process, significantly reducing expansion costs and rollback risks. The dual-gate mechanism refers to a control mechanism that separates the inclusion of strategies in artifacts from their actual runtime activation or release, including compile-time strategy aggregation as the first gate and runtime authorization set activation as the second gate.

[0060] S230. Extract key values ​​from the record content according to the verification strategy.

[0061] After obtaining the verification strategy, it can be added to the dataset. The verification strategy can contain strategy metadata, which can declare the list of key fields and the priority list of change time fields corresponding to the metadata.

[0062] The key field list can include keys from multiple key values ​​in the metadata. The change time field priority list can sort multiple fields describing change times according to their priority, used to describe the priority of different change times.

[0063] This article can extract the values ​​of each key in the list of key fields from the record content, and then form key values ​​according to the set type.

[0064] This article describes how to extract multiple change times from record content according to the priority of change times as described in the change time field priority list. For example, it can sequentially extract the change time fields included in the change time field priority list and their corresponding values ​​from the record content for use in validating the validation object.

[0065] S240. Use metadata identifiers and key values ​​to obtain the first and second objects.

[0066] The second object is the verification object being verified in the system being verified, and the first object is the verification object in the baseline state; the first object can be the verification object in the baseline state, and the second object can be the verification object in the target state. The first object can be used to verify the second object.

[0067] This paper describes how to obtain a second object from the system being tested and a first object from a trusted data source based on metadata identifiers and key values, so as to use the first object to verify the second object.

[0068] During the process of retrieving the first object and the second object, the first object and the second object can be retrieved in parallel. Alternatively, the first object can be retrieved first, and then the first object can be validated to determine whether the second object should be validated based on the first object.

[0069] For example, to determine whether the change to the first object is within the convergence window, if it is, differences between the second object and the first object are permissible. If it is outside the convergence window, all changes to the objects being verified in the system being verified should take effect; therefore, the second object can be obtained and used to verify the second object using the first object.

[0070] In one scenario, the first object includes one or more of the following: The first structured content of the metadata, and the second time of the metadata; The second object includes one or more of the following: The second structured content of the metadata, and the third time of the metadata; The second time includes the version time of the metadata at the data source, also known as the baseline version time. The third time includes the version time of the metadata in the system being verified, also known as the baseline version time. .

[0071] The first structured content can be considered as the structured content of the metadata used for calibration. The second structured content can be the structured content of the metadata being calibrated.

[0072] In one scenario, obtaining the first object and the second object using the metadata identifier and the key value includes: The first object is obtained from the data source using the metadata identifier and the key value; According to the verification strategy, a first time is extracted from the record content, the first time including the change time of the verification object; Based on the first time, the second time, and the current time, determine whether to acquire the second object; If so, the second object is obtained from the verified system using the metadata identifier and the key value.

[0073] The data source can be a trusted source that stores the first object. This article uses metadata identifiers and key-value pairs as query criteria to retrieve the corresponding first object from the data source.

[0074] This article does not impose any restrictions on the timing of extracting the first time frame, as long as it is obtained before its use. The first time frame can be a time related to the object being verified, such as the time required during the verification process.

[0075] This article uses the priority indicated in the verification strategy to extract the first time from the recorded content. This priority describes the priority of each time as the first time, and the corresponding time can be selected as the first time according to the priority.

[0076] This document can determine, based on the first time and the current time, whether a change to the first object is within a time window that allows for differences. This window can be called a convergence window or a change convergence window. Within this window, differences between the second object and the first object are allowed, and the second object can be returned directly without retrieving it, indicating that it is within the convergence window. Beyond this window, the second object can be retrieved for comparison with the first object.

[0077] This article compares the second time with the first time and the current time to verify whether the version time of the first object can be used, thus avoiding the first object being too old.

[0078] In one scenario, determining whether to acquire the second object based on the first time, the second time, and the current time includes: Determine a first time difference between the first time and the current time; The need to obtain the second object is determined if one or more of the following conditions are met: The first time difference is greater than or equal to the first threshold; The second time is less than or equal to the current time, and the second time is greater than or equal to the first time.

[0079] First time difference It can be the current time minus the first time. The current time can be the current time of the electronic device. For example, when determining the first time difference, the current time of the electronic device can be obtained as the current time.

[0080] First threshold This can be a threshold used to determine whether a change is within a convergence window. If the first time difference is less than the first threshold, the current change can be considered to be within the convergence window; otherwise, it can be considered to be outside the convergence window.

[0081] If the second time is less than or equal to the current time, and the second time is greater than or equal to the first time, the version time of the first object can be considered to meet the requirements, and the first object can be used to verify the second object.

[0082] S250. Compare the first object and the second object to obtain difference information.

[0083] The difference information is used to describe the differences between the first object and the second object. This could include differences in the content of the first and second objects, or differences in the timeframe between them.

[0084] The difference information can be a standardized response, also known as a standard response. A standard response can be the output of a bypass verification method, used to uniformly express the verification result upstream. A standard response includes at least: a system status code and status information, and a difference identifier. Difference type (i.e.) For example, differences only in fields, propagation delay only, or both, etc.), retry flags (i.e. ) and the reasons for the differences (or the cause of the error). The bypass verification method can be considered the object verification method of this paper. It achieves verification of the system being verified through a bypass that is independent of the system being verified.

[0085] The system status codes and status information are used to indicate whether the bypass verification service itself and external dependent calls were successful. For example, 0 can be defined as success, and non-zero values ​​can represent various error types (such as 1001 indicating a timeout of the authoritative data source, 1002 indicating an error in the verified interface, and 1003 indicating invalid request parameters). The status information can be a textual description of the status codes.

[0086] A difference flag can be a flag used to indicate whether a business or data difference exists. Difference flags can be represented by enumeration or Boolean values; for example, 0 indicates "no business difference," 1 indicates "business difference exists," and 2 indicates "cannot be determined (e.g., target state is missing)." Difference flags focus on inconsistencies in business content between the baseline state and the target state, but do not cover system malfunctions.

[0087] The retry flag can be a marker indicating a system recoverable error or dependency unavailability, guiding the upstream system on whether and when to retry or degrade. The retry flag can characterize situations such as system recoverable errors or suggest delays. The retry flag can be represented by an enumeration of values, for example, 0 means "no retry required," 1 means "retry immediately recommended," 2 means "retry after a certain time recommended," and 3 means "no retry, manual intervention required." The upstream system can use the retry flag to decide whether and when to trigger verification again.

[0088] The reason for the difference / error reason can be used to provide locatable explanatory information. For cases where there are business differences, the reason for the difference records a list of the difference fields (which may include fields in the second object that differ from the first object), a summary of the expected and actual values, and the policy identifier to which it belongs; for cases where the system fails or the dependency is unavailable, the error reason records the name of the failed dependency, the error code, the timeout duration, and other information.

[0089] In this article, the first and second objects can be compared from the perspective of fields. Before the comparison, the first and second objects can be normalized respectively, and then the fields included in the normalized first and second objects can be compared to determine whether there are any content differences between the first and second objects. During the field comparison, it can be determined whether the fields need to be consistent based on their types. The normalized first object can be considered as the normalized first object. The normalized second object can be considered as the normalized second object.

[0090] In this paper, the first object and the second object can be compared from the time dimension to determine whether the second object has a propagation lag problem.

[0091] In one scenario, the comparison of the aforementioned field dimensions can be considered a field consistency determination. The comparison of the aforementioned time dimension can be considered a propagation timing determination. Field consistency determination and propagation timing determination can be two complementary determination dimensions. Field consistency determination is used to determine whether the baseline state and the target state are consistent in business semantics. This paper performs field-level comparison after semantic normalization, comparing each field set declared by the strategy, or only comparing the set of key fields that affect the result, such as the result of the traffic splitting decision. When inconsistencies exist, the path of the differing field, the expected value and the actual value summary (e.g., only retaining the first few characters or hashing the pair), and the strategy identifier are recorded in the reason for the difference to facilitate manual review.

[0092] Propagation timing determination is used to identify problems such as delayed propagation of the target state. By jointly calculating the change time, the version time of the target state, and the current time, it is possible to distinguish between two situations: "just released and still propagating" and "exceeded the expected time but still not effective." Thus, it outputs two different semantic results: "in the convergence window, it is recommended to try again later" and "propagation is delayed and intervention is required."

[0093] By combining field consistency checks with propagation timing checks, this paper's bypass verification framework can simultaneously output conclusions regarding content discrepancies and time lags, clearly distinguishing the causes of each in the standard response. Thus, the upstream system can, based on... Determining whether there are business differences can also be based on the results of the propagation sequence determination. The `diff_type` parameter can be used to determine if there is a propagation lag, and the appropriate parameter can be selected accordingly. or Different processing strategies, etc.

[0094] The above method obtains a dataset containing metadata identifiers and record content. Then, a verification strategy corresponding to the metadata identifier is selected, and key values ​​are extracted from the record content according to the verification strategy. Using the metadata identifier and the key values, a first object and a second object are obtained. The first object and the second object are compared to obtain difference information, thereby verifying the first object in the system being verified. This solves the technical problem of metadata accuracy and consistency that easily occurs in distributed online systems, ensuring the accuracy and consistency of metadata in distributed online systems.

[0095] Figure 3 This is a flowchart illustrating an object verification method for another scenario. The solution in this scenario can be combined with solutions from other scenarios. For identical or related parts, descriptions from other scenarios can be used, and these will not be repeated here. Figure 3 As shown, the method in this case may specifically include: S310. Obtain the dataset.

[0096] The dataset contains metadata identifiers and record content. The metadata identifiers are used to identify the verification object, and the record content is used to describe the verification object.

[0097] S320. Select the verification strategy corresponding to the metadata identifier.

[0098] S330. Extract key values ​​from the record content according to the verification strategy.

[0099] The key values ​​include the key values ​​of the verification object.

[0100] S340. Use metadata identifiers and key values ​​to obtain the first and second objects.

[0101] The second object is the verification object being verified in the verification system, and the first object is the verification object in the baseline state.

[0102] S350. Compare the fields included in the first object and the fields included in the second object to obtain the first information.

[0103] First information (i.e.) This is used to indicate whether there are differences in the fields between the first object and the second object; the first information may be information obtained after comparing the contents of the first object and the second object.

[0104] In this paper, when comparing the fields included in the first object and the fields included in the second object, normalization processing can be performed first, followed by field comparison. During the field comparison, the comparison can be conducted according to the set of comparison fields indicated in the validation strategy. The set of comparison fields can include fields that need to be compared item by item. Fields in the first and second objects that fall within the set of comparison fields are compared to obtain the first piece of information. The fields to be compared within the set of comparison fields can be further divided, such as into fields that must be identical and fields that are allowed to be slightly different under certain conditions.

[0105] In one scenario, comparing fields included in the first object and fields included in the second object to obtain first information includes: Normalize the first object and the second object respectively to obtain the normalized first object and the normalized second object; The fields included in the normalized first object and the fields included in the normalized second object are compared to obtain the first information.

[0106] To reduce spurious differences caused by serialization discrepancies, the semantic normalization process defined in this paper includes at least the following steps: Structure parsing: Structured fields in both the baseline and target states are uniformly parsed into a common structure, such as tree nodes or nested map structures. For JSON strings, a unified parsing library is used; for... For strings, they are split into key-value pairs according to agreed rules; for array or list fields, they are parsed into ordered or unordered collection structures.

[0107] Key sorting and stable serialization: Fields of all Map / Dict type maps are sorted by key name to ensure that identical content yields completely consistent serialization results after normalization in any system. For nested structures, the same sorting rule is recursively applied.

[0108] Ignore Field Removal: Based on the set of ignored fields configured in the strategy (which includes fields that can be ignored), these fields are recursively removed during the normalization process. This avoids fields unrelated to business semantics from affecting consistency determination.

[0109] Numerical and time unification: Convert numerical fields such as amount, weight, and percentage into preset units and retain decimals with fixed precision; convert all time fields into millisecond-level timestamps and perform unified parsing for different representations.

[0110] Null values ​​and default values ​​are standardized: Null values, missing fields, empty strings, and explicit default values ​​(such as 0) are mapped to a unified, standardized representation according to policy rules. For example, in some policies, missing fields can be treated as equivalent to default values; in others, missing fields are treated as exceptions.

[0111] Through the semantic normalization described above, this paper unifies the representation of the same object in different systems to a stable and standardized representation, so that the field consistency determination result only reflects the real business differences and is not affected by non-semantic factors such as serialization order, time format, and null value representation.

[0112] This document describes a method to compare the fields included in a normalized object with the fields included in a normalized second object, according to a validation strategy. The validation strategy can specify the set of fields to be compared, as well as field tolerance rules. Field tolerance rules specify the conditions that must be met when fields are not completely consistent, and / or the degree of inconsistency.

[0113] S360. Using the first time, the second time, and the third time, obtain second information, which is used to describe the time difference between the first object and the second object.

[0114] The first time includes the change time of the object being verified. During the determination of the second information, the second time and the first time can be compared. If the second time is less than the first time, it can be assumed that the data source has not yet completed the write-in of this change, and is considered to be within the convergence window; therefore, no judgment on the propagation lag is made for the second object. For example, no judgment is made regarding whether there is a time difference between the first and second objects. The second information can be empty, meaning that the time difference between the first and second objects is not analyzed.

[0115] If the second time is greater than or equal to the first time, the difference between the third time and the first time can be determined, and the temporal differences between the first object and the second object can be analyzed based on this difference.

[0116] In one scenario, using the first time, the second time, and the third time, second information is obtained, including: If the second time is greater than or equal to the first time, a second time difference between the third time and the first time is determined; Based on the comparison result of the first time difference and the second threshold, and / or the second time difference, the second information is obtained. The first time difference is the difference between the first time and the current time, and the first time includes the change time of the verification object. The first time difference is the time difference determined in the above manner.

[0117] If the second time is greater than or equal to the first time, it can be considered that the convergence window has been exceeded, and a propagation lag can be determined for the second object. During this determination, the difference between the third time and the first time can be defined as the second time difference. This represents the difference between the version time and the change time of the second object. If the second time difference is less than zero, it indicates that the version of the second object is still earlier than the change time, meaning that the side being verified has not yet received the change.

[0118] The second threshold can also be called the propagation timing threshold. This article can determine the first time difference. Compare with the second threshold.

[0119] If the first time difference is less than the second threshold, it can be considered that the current propagation delay is still within the allowable range. The record shows the "propagating" status.

[0120] If the first time difference is greater than the second threshold and the second time difference is less than zero, propagation lag can be considered, and corresponding second information can be formed, such as in... Record data propagation delay The specific time difference and related fields are attached.

[0121] If the first time difference is greater than the second threshold and the second object does not exist, it can be considered as a propagation lag or an abnormal object missing, and corresponding second information can be formed.

[0122] S370, aggregate the first and second information to obtain the difference information.

[0123] The difference information can be the aggregated first and second information. The difference information can reflect the differences between the first and second objects in terms of time and content.

[0124] This paper uses a difference indicator to comprehensively reflect the results reflected by the first and second information respectively. Then, the corresponding content is set in the retry indicator.

[0125] This paper compares the first and second objects in terms of time sequence and content, and then summarizes the information through the difference information, thus ensuring the accuracy and consistency of the data.

[0126] Regarding the issues of data accuracy and consistency, the relevant technologies have the following problems: First, it is highly invasive, introducing additional logic into the core link, increasing performance overhead and stability risks, increasing access and maintenance costs, and potentially introducing new points of failure.

[0127] Second, there is a high rate of false alarms. During the propagation and convergence period after a rule is released, the control plane, data plane, and authoritative data source may naturally be inconsistent for a short period of time. If the differences during this period are directly regarded as anomalies, a large number of "transient difference" alarms will be generated, making it difficult for the upstream system to distinguish which problems need to be addressed immediately and which are simply due to incomplete propagation.

[0128] Third, expansion is difficult and deployment risks are high. As business evolves, validation rules need frequent iterations and expansions, resulting in long delivery cycles for traditional solutions. Furthermore, the validation logic for different rules is scattered across various locations, lacking a unified strategy framework and lifecycle management.

[0129] Fourth, closed-loop processing is difficult. The output results of related solutions lack unified semantics and do not clearly distinguish between business differences and system failures, dependency unavailability, etc. As a result, upstream systems cannot reliably perform automatic retries, degradation, or tiered alerts, and manual troubleshooting is costly.

[0130] To address the above problems, this paper solves at least the following technical issues: 1. Without intruding on the core online links of the traffic distribution decision system, how to achieve bypass verification of the data accuracy after rules or configurations have been propagated through multiple levels, and ensure its feasibility and sustainable scalability? Bypass verification refers to performing consistency verification of the effective status of data or rules through an independent link without changing the core processing links of the system being verified, thereby decoupling the verification capability from the main business link.

[0131] 2. How to identify and handle "unconverged change windows" (referred to as "change convergence windows", which refers to the time interval from when a rule is changed in the control plane until the change takes effect in all levels of cache, data plane nodes and authoritative data sources) during the propagation and cache refresh phase of rule changes, so as to reduce false alarms and alarm noise caused by transient differences.

[0132] 3. How to construct a pluggable validation strategy framework driven by "rule identifiers," so that adding new validation rules does not require changes to the main process, and supports secure and controllable enabling or disabling. Here, a rule identifier refers to an identifier used to uniquely identify a type of validation logic or validation object; it can be a string or a multi-field key combination.

[0133] 4. How to output standardized results with unified semantics (referred to as standardized response results) to clearly distinguish between business differences and system failures or dependency unavailability, so as to support upstream to achieve automatic retry, hierarchical alarms and manual review closed loop.

[0134] 5. How to achieve anomaly isolation when external dependency calls (including reading authoritative data sources, fetching remote status, etc.) experience timeouts, rate limiting, or abnormal returns, to prevent bypass checks from negatively impacting the stability of the online system, and to use appropriate "retry flags" to indicate upstream retry and degradation behaviors. A retry flag can be a flag indicating whether the result should be retried or deferred by the upstream.

[0135] To address the aforementioned technical challenges, this paper presents a data accuracy bypass verification method and system for traffic diversion decision systems. This solution decouples the verification capability from the system being verified, enabling it to operate via triggering and orchestration, combined with a bypass verification service. It achieves low-intrusion, low-noise, and scalable verification through change convergence window noise reduction (a mechanism that proactively suppresses unnecessary alarms before changes have fully propagated), semantic normalization (a process of parsing and standardizing structured fields into stable and comparable normalized representations to eliminate non-business semantic differences), joint determination of field consistency and propagation sequence, and standardized response semantics.

[0136] Figure 4 This is a flowchart illustrating an optional instance of the object validation method in another scenario. For example... Figure 4 As shown in this paper, the bypass verification service can execute bypass verification methods. The object verification method provided in this paper can be considered a data accuracy bypass verification method for a traffic diversion decision system. The bypass verification method can be triggered by change events, timed triggers, or manual triggers.

[0137] The bypass verification method includes: receiving verification requests (i.e., the first request) and completing basic verification; routing to the verification strategy (also known as the verification strategy) based on the rule identifier (i.e., the metadata identifier); verifying the activation status through a dual-gate mechanism during routing; parsing the record content and extracting key values ​​and change times (i.e., the first time); obtaining the baseline state (i.e., the first object) from an authoritative data source based on the key values; performing change convergence window identification and deciding whether to return with early noise reduction; obtaining the target state (i.e., the second object) from the verified side; performing semantic normalization on the baseline state and the target state; performing field consistency judgment; performing propagation timing judgment; aggregating the field consistency and propagation timing judgment results and encapsulating a standard response.

[0138] The bypass verification service may include the following modules to implement the above process: The verification entry module (also known as the acquisition module) is responsible for request authentication, rate limiting, basic parameter verification, and unified log tracking. This module ensures that the bypass verification service has the necessary protection capabilities and that high-frequency verification does not affect overall stability.

[0139] The rule routing module (also known as the selection module) routes the request to the corresponding verification policy instance based on the rule identifier in the verification request. Routing relationships are typically expressed in the format of "...". The information is maintained in the routing table in the form of "".

[0140] The policy registration and factory module is responsible for aggregating all policy implementations during compilation and constructing policy instances on demand based on configuration at runtime, thus implementing policy lifecycle management. This module is related to the dual-gate mechanism (a mechanism that decouples policy inclusion into artifacts from actual runtime activation or release into two independent control gates) discussed later.

[0141] The baseline state acquisition module (also known as the acquisition module) is responsible for accessing authoritative data sources and retrieving the baseline state (which can refer to a snapshot of the state of the object being verified from the authoritative data source) based on key values. The baseline state is usually returned in the form of structured records, such as database rows or structured JSON documents.

[0142] The change convergence window identification module (also known as the determination unit) is responsible for determining whether the change is within the change convergence window based on information such as the change time and the current time, thereby deciding whether to perform subsequent complete verification or directly output the noise reduction result.

[0143] The target state acquisition module (also known as the second object acquisition unit) is responsible for accessing the data plane of the verified side or its tightly coupled state query interface to obtain the target state (referring to the current effective state snapshot of the verified system). The target state usually comes from the query interface provided by the online service, the online cache, or its read-only mirror library.

[0144] The semantic normalization module (also known as the comparison module) is responsible for semantic normalization of the structured fields of the baseline and target states, converting different serialization formats that may be used by different systems (such as different JSON field order, different null value representations, and different time units) into a unified normalized representation.

[0145] The Difference and Propagation Timing Determination Module (also known as the Comparison Module) is responsible for performing field consistency determination and propagation timing determination based on the normalization results. Field consistency determination focuses on whether the baseline state and the target state are consistent in terms of business semantics, while propagation timing determination focuses on whether the effective time of the target state falls within the allowable propagation delay range relative to the change time.

[0146] The result encapsulation module is responsible for generating a standardized response structure and storing necessary information (including rule identifiers, key values, version information, difference summaries, and time consumption) in the log for subsequent traceability and visualization.

[0147] The specific steps for receiving verification requests and completing basic verifications are as follows: Input data: Receives verification requests from the triggering and orchestration module. These can be Hypertext Transfer Protocol (HTTP) requests or message bodies from a message queue. The structure of the request payload is not limited here, but can be a JSON structure, and should at least include fields such as rule identifier, record content, key values, change time, caller identifier, and link detection identifier.

[0148] Processing logic: The verification entry module first performs authentication on the request (e.g., verifying the caller's signature), rate limiting, and infrastructure verification (e.g., checking if required fields exist, if field types are correct, and if the payload size exceeds preset limits). When the request body is too large, an error can be returned directly, suggesting that the caller send the request in batches or by sampling, to protect the bypass verification service.

[0149] Output: If the basic verification passes, construct an internally unified verification context object, which includes rule identifier, key value, change time, record content, caller information, and link detection identifier. These are used for sharing in subsequent steps; if the basic verification fails, a standard response and system status code are generated. Marked as parameter error. Set to "Unable to determine" Set to "cannot be retried", and in The specific reasons are noted in the text.

[0150] The verification context object (also known as a dataset) is a standardized data structure used in distributed system rule consistency verification scenarios to uniformly encapsulate and transmit all key information during the verification process. It transforms verification request data from different sources and in different formats into an internally unified data model that can be shared among various modules.

[0151] Based on the rule identifier, the route is routed to the verification policy. During routing, the enabled status is verified using a dual-gate mechanism as follows: Input data: Verify the context object, such as the rule identifier within it.

[0152] Processing logic: The rule routing module first searches for the policy type corresponding to the rule identifier in the policy registry generated at compile time. For example, a static mapping table can be maintained. After finding the policy type, a second filtering is performed by combining it with the policy enablement set (also known as the authorization set) in the runtime configuration to control which rule identifiers are allowed to be actually executed in the current environment (such as the production environment) of the object verification system. The combination of compile-time policy aggregation and runtime set enablement can be considered as a double-gate mechanism. The first gatekeeper: During compilation, the policy implementation is compiled into the artifact to obtain the policy registry, ensuring that the policy code has passed compilation and basic testing; The second gate: At runtime, only rules in the authorization set are instantiated with policies and allowed to be executed. Rules not in the authorization set will not be actually triggered, even if they have been compiled into the artifacts.

[0153] Output: If routing and enable checks are successful, the corresponding policy instance is bound to the verification context object; if the rule identifier is not found or is not enabled, a fallback response indicating that it is not enabled is generated. Set to a specific error code (e.g., 2001). Set as undeterminable. It can be set to either no retry required or manual processing required, while in The rule indicates that it is not registered or enabled.

[0154] Parse the record content and extract key values ​​(i.e. ) and change time (i.e. The content is as follows: Input data: Record content and policy metadata in the verification context. The policy metadata predefines a list of key fields corresponding to the rule (this list contains keys for multiple key values) and a priority list of change time fields, used to describe the priority between times (e.g., ...). ).

[0155] Processing logic: Based on the list of fields declared according to the strategy, extract the values ​​of the keys of the key-value pairs from the record content, and store them in string or basic type format. Mapping; for missing fields, default values ​​can be used or the request can be directly deemed invalid. Subsequently, the change time field is read from the record content in order of priority and converted into a uniform time format (e.g., millisecond-level timestamp). If the record content does not contain any time field, the event time can be supplemented by the triggering and orchestration module when generating the request, or the bypass verification service can use the current time as a lower limit estimate of the change time when receiving the request.

[0156] Output: Complete and The extraction of two key attributes and their writing back to the verification context object provide input for subsequent acquisition of the baseline and target states and for determining changes to the convergence window.

[0157] The baseline state content is obtained from an authoritative data source based on key values ​​as follows: Input data: Key values ​​output from step 3 and rule identifiers.

[0158] Data source: Authoritative data source, typically the master database used to store rules or configurations, such as rule configuration tables in a relational database, JSON document collections in metadata storage, or persistent storage in a unified configuration center. To avoid putting additional pressure on the business master database, a read-only instance or mirror repository can be used to host the authoritative data source.

[0159] Processing logic: The baseline state acquisition module constructs query conditions based on the rule identifier and key values. For example, for routing rules, it can be done according to... The conditional query rule table can store rules, and the corresponding rule can be retrieved from the rule table as the validation object. It can be considered a rule identifier. It can be a business line identifier. It can be used to represent the environment.

[0160] The query results need to be mapped to a unified structured representation, for example: For relational database rows, each column is converted into a key-value pair, with the field name being the column name and the field value being a string or a basic type; For JSON documents, load them directly as structured objects; For objects consisting of multiple tables or multiple documents, assembly logic can be defined within the strategy to merge multiple query results into a single baseline object.

[0161] If the query result is empty (the object does not exist), the baseline state can be marked as "missing" and treated as a special case in subsequent difference determination (e.g., judged as "the target state is redundant" or "the baseline configuration has been deleted but the target state has not been deleted").

[0162] Output: The baseline state object is obtained, containing at least the following information: Business primary key (i.e.) Structured representation of ) The second time (i.e.) ): Version time or most recent update time, used to determine the propagation sequence; The first structured content (i.e., payload): the complete structured content of the metadata (which can be JSON or key-value mapping).

[0163] The following content is returned after performing change convergence window identification and deciding whether to perform noise reduction in advance: Input data: Change time ( The system's current time (now) and the version time in the baseline state. (If present). The change time can refer to the timestamp directly related to the change of the object being verified: usually derived from the "update time" in the record content. "Release Time" "or the "operation time" in the audit log ".

[0164] Convergence window definition and calculation formula: For each type of rule, the policy can be configured with a convergence window threshold. (That is, the first threshold, in seconds). In implementation, the following determination formula can be used: First, calculate the time difference from the time of the change to the current time, i.e., the first time difference: ; like If so, it is considered that the change is still within the change convergence window; Optionally, it can also be combined with the baseline version time. ,Require That is, the second time is less than or equal to the current time, and the second time is greater than or equal to the first time, so as to avoid using an older version of the time in the judgment.

[0165] When the data plane cache has not been fully refreshed and some nodes have not yet received the change push during the change convergence window, this is normal. If a complete reconciliation is forcibly performed at this time, it is easy to mistake the temporary inconsistency for an anomaly. To reduce noise, this paper uses noise reduction output when the convergence window is hit.

[0166] Processing logic: like Then write "" in the verification context object The "" tag directly generates a noise reduction response that suggests delaying or retrying. It can be a field indicating whether it is in a change convergence window.

[0167] For example, Set to "Unable to determine" Set to "Retry later" and in The text includes a message stating that the window is currently in the change convergence phase and it is recommended to... The message "Retry in seconds" will appear. like If the change has been propagated or should have been propagated, then the subsequent steps are performed to obtain the target state and determine consistency.

[0168] Output: If the change convergence window is hit, the current time series will end early and the denoised response will be returned; if not, the subsequent steps will continue.

[0169] The content of the target state obtained from the verified side is as follows: Input data: key-value pairs The rules, identifiers, and target access methods configured within the policy.

[0170] Data source: The data plane of the verified side or its tightly coupled state storage. Depending on the system, the target state can be obtained using one of the following methods: Call the read-only query interface (such as HTTP) provided by the service being verified, and query the currently effective configuration based on the key value; Access the read-only image library or state snapshot table of the data plane cache and read the corresponding configuration object from it; The configuration is read from the local cache via a bypass proxy.

[0171] Processing Logic: The target state acquisition module constructs a query request and executes the call according to the strategy configuration. To avoid impacting online business, a timeout (e.g., 300 milliseconds) and retry strategy (e.g., maximum retries of 2 times, with 50 millisecond and 100 millisecond backoffs) need to be set during the call. When the call fails or times out, the error information is written to the verification context object, subsequently presented as a system error in the standard response, and a retry flag is used to instruct the upstream to retry or degrade. When the call succeeds, the returned result is mapped to the same structured form as the baseline state, such as including version time. (If available) and payload (the complete structure of the rule or configuration). If the validated side returns "object does not exist", the target state is marked as missing for subsequent difference determination.

[0172] Output: The target state object is obtained, and its structure is consistent with the base state, which facilitates subsequent unified processing.

[0173] The semantic normalization performed on the baseline state and the target state is as follows: Input data: the baseline payload (i.e., the first structured content) and the target payload (i.e., the second structured content), as well as the "set of ignored fields" and "numerical / time format specifications" declared in the strategy.

[0174] Processing logic: The semantic normalization module performs the following processing flow for the base state and the target state respectively: Structured fields are parsed into stable structures: for example, for JSON fields, a unified parsing library is used to parse them into a nested key-value tree structure; for key-value lists stored as strings, they are first parsed into a mapping structure.

[0175] Perform key sorting, stabilization, and serialization on unordered mappings: For dictionary / mapping (Map / Dict) type fields, sort by key name in lexicographical order before serialization to ensure that the string representation of the same content is completely consistent across different systems.

[0176] Recursively remove the set of fields to ignore: The strategy can be configured with a set of "ignore fields", such as update time ( This includes metadata fields that do not affect traffic splitting decisions, such as operator, link detection identifier, and last modification time. During normalization, the structured object is recursively traversed, and keys located in the ignored field set are removed.

[0177] Perform unified unit and precision processing on numerical values ​​and time: for example, convert all amounts into integers in "cents", convert all times into millisecond-level timestamps in a set time zone, and retain a fixed number of decimal places for floating-point numbers and normalize them according to rounding rules.

[0178] Merge mappings for null values ​​and default values: For example, map null values, empty strings, missing fields, and explicit default values ​​(such as 0) to the same semantics according to policy rules to avoid pseudo-differences caused by different systems representing null values ​​differently.

[0179] Output result: For the baseline state and the target state, each obtains a "normalized representation", namely the first normalized object and the second normalized object, which can be a nested key-value tree or a deterministically serialized string (such as a JSON string). It also outputs a "normalized digest", such as calculating a hash value on the normalized representation, to quickly determine whether they are completely consistent.

[0180] The content of the field consistency check is as follows: Input data: semantically normalized baseline and target state normalized representations, and the "comparison field set" and "field tolerance rules" of the policy declaration.

[0181] The set of comparison fields can be a list of fields declared for each strategy class that need to be compared item by item, including: Fields that must be consistent include: rule identifier, rule type, matching condition expression, priority, on / off status, effective time, and expiration time. Tolerable fields: such as notes, descriptions, and non-critical log level configurations, can be slightly inconsistent under certain conditions; Structured fields: such as JSON-formatted routing expressions, lists of filtering conditions, etc.

[0182] Comparison method: For basic data types such as strings, integers, and booleans, strict equality comparison is used. For floating-point or percentage fields, a tolerance range can be configured, for example, requiring the difference between the two extreme values. Or the relative error does not exceed ; It can be a field in the normalized second object. It can be a field in the first object after normalization.

[0183] For list / collection fields, sort and remove duplicates during the semantic normalization stage, and then perform order-independent collection comparisons. For nested structured fields, use the normalized JSON string for overall comparison or compare differences layer by layer.

[0184] Processing logic: Based on the above rules, compare all comparison fields item by item, and record the following information for each difference: field path, summary of the baseline median, summary of the target median, and the policy identifier. For tolerable fields, when the difference falls within the tolerable range, you can choose to record it only as "ignorable difference" and not include it in the difference identifier.

[0185] Output: A list of field differences. and an aggregated difference flag .like If empty, then "No content difference"; if If not empty, it indicates "content difference exists", and the difference type can be specified (e.g., only the baseline state exists, only the target state exists, content mismatch, etc.). The difference type can be field-level, used to describe the type of difference between fields.

[0186] The content of the propagation timing determination is as follows: Input data: Change time Version time of the baseline state (If applicable) Target version time (If applicable) Propagation timing thresholds for strategy configuration That is, the second threshold.

[0187] Judgment Approach: Propagation timing determination is used to identify problems such as target state propagation lag. The implementation is as follows: First, calculate the relationship between the baseline state and the change time: If Existence and This indicates that the authoritative data source has not yet completed the storage of this change. At this time, a strict propagation lag judgment should not be made on the target state. It can be regarded as still being in the expansion convergence window. Secondly, calculate the time difference between the target state and the change time. That is, the second time difference. When If the target version is still earlier than the change time, it means that the side being verified has not yet pulled or applied this change. Next, calculate the time difference from the time of the change to the current time. ,when It has exceeded the propagation timing threshold. ,and If the value is still less than 0 or has not been updated to the expected version, it can be determined that there is a propagation lag difference.

[0188] Judgment result: like Even if Alternatively, it can be considered to be within the allowable propagation delay range and not regarded as abnormal, only within... The system records the "transmission in progress" status. like and If so, it is determined to be "propagation lag", and can be... The data propagation delay is marked in the middle and in Please include the specific time difference and related fields. like And the target state does not exist ( Missing items can also be seen as a propagation lag or an anomaly of missing objects.

[0189] Output: Results of propagation time-related determinations (e.g., timing is normal, timing is lagging, timing is unknown) and their detailed descriptions. .

[0190] The results of the aggregation field consistency and propagation timing determination, along with the encapsulated standard response content, are as follows: Input data: Field consistency determination results and Propagation timing determination results and And / or system error messages that may occur during the aforementioned steps (such as authoritative data source timeout, target state query failure, etc.).

[0191] Aggregation logic: First, determine if there are any system-level errors in this verification (e.g., the authoritative data source is completely unreachable, or the target query interface is faulty). If so, then... Set the corresponding error code, and set retry_flag to "retryable" or "non-retryable" according to the error type. diff_flag is generally set to "cannot be determined", and error details are attached in diff_reason. If there are no system-level errors, then `diff_flag` is generated based on a combination of `diff_flag_content` and `timing_flag`. When diff_flag_content and When there is no difference overall, diff_flag is set to "no business difference" and retry_flag is set to "no need to retry". Here, "not much" can be less than or equal to the set value. when Furthermore, when timing_flag is normal, diff_flag is set to "business differences exist", and retry_flag is usually set to "no retry", because retries cannot eliminate content differences; when Furthermore, when timing_flag is set to time lag, it can be assumed that there are both content differences and dissemination lags. Therefore, diff_flag is set to "there are business differences and timeliness differences", and diff_type is marked as inconsistent fields accompanied by lag. when but When this condition is met, it can be considered as "only a delay in propagation", diff_flag can be set to "there is a time difference", and retry_flag can be set to "it is recommended to postpone the retry".

[0192] Output: A complete standard response structure is constructed, writing fields such as system_code, system_message, diff_flag, retry_flag, diff_type, diff_reason, rule_id, and primary_key into the response and simultaneously writing them to the log for subsequent querying and display. This response will be returned to the triggering and orchestration module or the upstream caller for use in subsequent steps such as automatic retries, alerts, and manual review.

[0193] The object verification method presented in this paper can be considered a bypass verification. Bypass verification is a non-core capability, ensuring that its failure will not affect the stability of the verified system. This paper implements timeout control, retry backoff, rate limiting, and exception handling mechanisms at the entry layer, external dependency call layer, and data parsing layer to achieve exception isolation and degradation protection. Entry layer: Set rate limiting thresholds and queue length limits for verification requests to avoid overloading the bypass service itself due to concentrated triggering; set an upper limit on the size of a single request body (e.g., 256KB) to prevent abnormal requests from dragging down the parsing thread; set a timeout limit for the overall processing time, and requests exceeding the limit will return a timeout error and be logged.

[0194] External dependency call layer: Set single-timeouts (e.g., 200ms timeout for data source reads, 300ms timeout for target state retrieval) and maximum retry counts (e.g., 50ms and 100ms backoff for two retries). When continuous failures occur, classify errors as "retryable" or "non-retryable" using retry flags to avoid infinite retries amplifying the failure.

[0195] Data parsing layer: Sets defensive limits on structured data parsing, such as maximum depth (e.g., 10 layers) and maximum number of nodes, to prevent malicious or abnormal data from causing excessive parsing time or memory consumption; it captures parsing anomalies and presents them as system errors in the standard response, rather than directly interrupting the process. When identification is in a convergence window or dependencies are temporarily unavailable, it prioritizes returning semantics suggesting a delay or retry. When an unrecoverable error occurs (such as a severe configuration structure anomaly or a missing critical field preventing further progress), a non-retry semantic is returned along with an error classification to help the upstream system choose appropriate subsequent actions.

[0196] In one scenario, the following threshold can be used: First threshold If a difference between the control plane and the data plane is detected within 120 seconds after the change time, it is considered to be in the change convergence window by default, and the semantics of "suggest retrying later" are output instead of "deterministic anomaly"; Propagation timing threshold If, 300 seconds after the change time, the target state has not been updated to the new version, it can be determined as a propagation lag anomaly. The data source read timeout is set to 200 milliseconds, and the target state acquisition timeout is set to 300 milliseconds; the number of pull retries is set to 2, with backoff intervals of 50 milliseconds and 100 milliseconds; The set of fields to be ignored includes update time (update_time), operator, etc. The requested payload is limited to 256KB, and the structural resolution depth is limited to 10 layers.

[0197] Correspondingly, when in a convergence window, suggest deferring semantics; when fields are inconsistent and exceed the propagation timing threshold, output deterministic difference semantics; when a dependency times out, output retry semantics and record the timeout category. The above parameters are only examples and can be adjusted according to business sensitivity and system scale during actual deployment.

[0198] The text verification request carries a rule identifier. The system selects the corresponding strategy from the routing table based on the rule identifier, realizing customized verification logic at the rule granularity. By decoupling the inclusion of the strategy in the artifact from the actual activation, the strategy is included in the artifact but only instantiated or allowed to be executed for the authorized set, reducing the risk of erroneous deployment. Before accessing the verified side, an authoritative data source is read to form a reconciliation baseline, avoiding mistaking the current state of the data plane for the authoritative truth. By calculating the change time and the current time, the system identifies the non-convergence window of propagation and outputs noise reduction results such as skipping or suggesting postponement, significantly reducing transient alarm noise. Structured fields are parsed, stabilized, serialized, and have default values ​​processed and ignored fields removed, retaining only fields related to the routing decision for comparison, thereby reducing false differences. At the same time, the system outputs the conclusions of content differences and time delays and distinguishes the causes, enabling the upstream system to distinguish between "configuration errors" and "slow propagation" problems. Business differences are expressed through difference identifiers, and system recoverable errors or dependency unavailability are expressed through retry identifiers, avoiding confusion between the two and facilitating automated closed-loop. When a rule does not match or is not enabled, a preset response is output, which can include a reason code, avoiding ambiguous "empty responses" or unpredictable behavior. A chain of evidence is formed by recording the rule identifier, key values, version, path, execution time, and difference summary, supporting problem review. Layered timeouts, rate limiting, circuit breaking, and anomaly capture at the entry point, dependency, and parsing levels prevent fault propagation and limit risks to a single verification or policy scope. Differences are categorized and aggregated from multiple sources (such as field differences, time-series differences, and dependency errors) to reduce manual review costs. Event-driven, timed, and manual triggers are supported, all using the same verification entry point and protocol, facilitating unified access and expansion by upstream systems.

[0199] Regarding question 1 above: This paper adopts a non-intrusive bypass verification approach that is sustainably scalable. By separating the verification logic from the core link of the system being verified and implementing reconciliation as an independent bypass service, the workload for integration is reduced from modifying the core link to implementing verification policies and enabling configurations. For systems that already have rule change events or configuration centers, the integration cycle can be shortened, and the stability risk to the online main link can be significantly reduced.

[0200] Regarding issue 2 above: This paper addresses transient inconsistencies and false alarms through a convergence window mechanism. By introducing an authoritative baseline state and a change convergence window identification mechanism, this paper can suppress false alarms and noise caused by propagation non-convergence within a controllable range. For high-frequency release scenarios with large changes, this can reduce false alarms or noise, and the alarm signals can be more focused on the issues that truly require intervention.

[0201] Regarding issue 3 above: to address the difficulties in expanding verification rules and the high risk of deployment, this paper adopts a pluggable strategy framework. This framework allows new rules to be added without altering the main process; only the corresponding strategy implementation needs to be added or modified. A dual-gate mechanism ensures that the rules are not active by default. Developers can merge the strategy code in advance without affecting the production environment and gradually enable it for production traffic after thorough verification in the testing or pre-production environment. This significantly improves expansion efficiency and reduces the risk of accidental deployment.

[0202] Regarding issue 4 above: to address the difficulty in closing the loop due to the lack of unified response semantics, this paper standardizes the response structure to decouple business differences from system recoverable errors. Upstream systems can drive tiered alarms and manual review based on difference identifiers, and automatic retries and degradation based on retry identifiers. In typical scenarios, this can reduce the proportion requiring manual intervention and improve the overall level of automation.

[0203] Regarding issue 5 above: to address the potential amplified impact of dependency timeouts and anomalies, this paper employs a layered timeout, retries, rate limiting, and isolation strategy to confine failures to a single verification or policy scope, preventing bypass verification from dragging down core business services. When a dependency is temporarily unavailable, the system guides the upstream to delay or retry via a retry flag; in the event of a severe dependency anomaly, it fails quickly, improving the overall resilience of the system.

[0204] In this paper, strategy discovery can be implemented using explicit mapping tables, reflection scanning, configuration-driven loading, or plug-in dynamic loading; the dual-gate mechanism can be extended to multi-level control such as global switch, rule switch, and environment switch; the off-limits behavior can be replaced with fixed error codes, skip states, retry or asynchronous acceptance, etc., to achieve different degrees of loose coupling.

[0205] The baseline data source can be replaced by a cache, object storage snapshot, log-type storage, or read-only image library, as long as it logically represents the "authoritative truth"; target state acquisition can be replaced by push subscription, side-path snapshot pull, bypass proxy reading local cache, or asynchronous acquisition; consistency reference can be replaced by introducing a third-party arbitration source to determine the final standard in multi-source scenarios.

[0206] The window identification signal can be replaced by version difference (such as version number difference), timestamp difference, propagation link level, release batch or cache hit change; the threshold strategy can be replaced by fixed threshold, rule-based threshold, dynamic threshold and graded threshold; the noise reduction action can be replaced by skip, delayed retry, entering the queue to wait, sampling verification or only recording without alarm, etc.

[0207] Normalized representation can be replaced by deterministic serialization, hash digest comparison, or structured difference algorithms; the ignored field set can be replaced by the fields to be compared, field weights, or field tolerance ranges; semantic drift can be resolved through enumeration mapping, unit conversion, time zone unification, and string normalization.

[0208] Difference determination can be replaced by field-by-field comparison, structured differences, rule expression engine, or sample validation; propagation timeliness determination object can be replaced by end-to-end event completion time or multi-hop time decomposition; response semantics can be replaced by difference type enumeration, suggested actions, or a combination of synchronous and asynchronous write-back.

[0209] Deployment can be a standalone bypass service, function computing, or a hybrid deployment; triggering methods can be replaced by event-driven, scheduled inspection, work order triggering, or batch playback; isolation implementation can be replaced by thread pool isolation, process isolation, tenant isolation, or policy-level rate limiting, etc.

[0210] Figure 5 This is a schematic diagram of an object verification device in one scenario. This device can be integrated into an electronic device, such as... Figure 5 As shown, the device includes: The acquisition module 510 is used to acquire a dataset, which contains metadata identifiers and record content. The metadata identifiers are used to identify the verification object, and the record content is used to describe the verification object. The selection module 520 is used to select the verification strategy corresponding to the metadata identifier; Extraction module 530 is used to extract key values ​​from the record content according to the verification strategy, wherein the key values ​​include the key values ​​of the verification object; The acquisition module 540 is used to acquire a first object and a second object using the metadata identifier and the key value, wherein the second object is the verification object being verified in the verification system, and the first object is the verification object in the baseline state. The comparison module 550 is used to compare the first object and the second object to obtain difference information, which is used to describe the differences between the first object and the second object.

[0211] In one scenario, module 510 is obtained, including: A receiving unit is configured to receive a first request, wherein the first request is used to trigger the verification of the verification object; The parsing unit is used to parse the first request to obtain the dataset if the first request passes the verification.

[0212] In one scenario, the parsing unit is used for: The verification subunit is used to verify the structure of the first request and obtain the verification result; Extraction sub-units are used to extract the fields included in the first request to form the dataset when the verification result indicates that the verification has passed.

[0213] In one scenario, the verification subunit is specifically used for: The following one or more of the first request are validated to obtain the validation results: The fields included in the first request, and the size of the first request.

[0214] In one scenario, module 520 is selected, specifically for: Select the policy type corresponding to the metadata identifier from the policy registry; If the authorization set contains the metadata identifier, the policy of the policy type shall be used as the verification policy; The policy registry is a mapping table generated during compilation, which stores the mapping relationship between the metadata identifier and the policy type.

[0215] In one scenario, the first object includes one or more of the following: The first structured content of the metadata, and the second time of the metadata; The second object includes one or more of the following: The second structured content of the metadata, and the third time of the metadata; The second time includes the version time of the metadata at the data source, and the third time includes the version time of the metadata in the system being verified.

[0216] Module 540 is included: The first object acquisition unit is used to acquire the first object from the data source using the metadata identifier and the key value; An extraction unit is configured to extract a first time from the record content according to the verification strategy, wherein the first time includes the change time of the verification object; The determining unit is configured to determine whether to acquire the second object based on the first time, the second time, and the current time; The second object acquisition unit is used to acquire the second object from the verified system if the condition is met, using the metadata identifier and the key value.

[0217] In one scenario, a unit is defined, specifically for: Determine a first time difference between the first time and the current time; The need to obtain the second object is determined if one or more of the following conditions are met: The first time difference is greater than or equal to the first threshold; The second time is less than or equal to the current time, and the second time is greater than or equal to the first time.

[0218] In one scenario, comparison module 550 includes: A comparison unit is used to compare the fields included in the first object and the fields included in the second object to obtain first information, wherein the first information is used to indicate whether there are differences in the fields between the first object and the second object; The second information acquisition unit is used to acquire second information using the first time, the second time, and the third time. The second information is used to describe the time difference between the first object and the second object. The first time includes the change time of the verification object. An aggregation unit is used to aggregate the first information and the second information to obtain the difference information.

[0219] In one scenario, the comparison unit is specifically used for: Normalize the first object and the second object respectively to obtain the normalized first object and the normalized second object; The fields included in the normalized first object and the fields included in the normalized second object are compared to obtain the first information.

[0220] In one scenario, the second information acquisition unit is specifically used for: If the second time is greater than or equal to the first time, a second time difference between the third time and the first time is determined; Based on the comparison result of the first time difference and the second threshold, and / or the second time difference, the second information is obtained, wherein the first time difference is the difference between the first time and the current time, and the first time includes the change time of the verification object.

[0221] The above-described apparatus can execute the methods provided in any of the cases described herein, and has the corresponding functional modules and beneficial effects for executing the methods.

[0222] It is worth noting that the various units and modules included in the above-mentioned device are divided according to functional logic, but are not limited to the above division, as long as the corresponding functions can be realized; in addition, the specific names of each functional unit are only for easy differentiation and are not used to limit the scope of protection of this document.

[0223] Figure 6 This is a schematic diagram of the structure of an electronic device used to implement an object verification method in one scenario. (Refer to the following...) Figure 6This document illustrates a schematic diagram of an electronic device (e.g., a terminal device or server) 700 suitable for implementing the above-described methods. The terminal device referred to herein may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital radio receivers, personal digital assistants (PDAs), tablet computers (PADs), portable multimedia players (PMPs), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital televisions and desktop computers. Figure 6 The electronic device 700 shown is merely an example and should not impose any limitations on the functionality and scope of this document.

[0224] like Figure 6 As shown, the electronic device 700 may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 701, which can perform various appropriate actions and processes according to a program stored in a read-only memory 702 or a program loaded from a storage device 708 into a random access memory 703. The random access memory 703 also stores various programs and data required for the operation of the electronic device 700. The processing unit 701, the read-only memory 702, and the random access memory 703 are interconnected via a bus 704. An input / output interface 705 is also connected to the bus 704.

[0225] Typically, the following devices can be connected to the input / output interface 705: input devices 706 including, for example, a touchscreen, touchpad, keyboard, mouse, camera, microphone, accelerometer, gyroscope, etc.; output devices 707 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 708 including, for example, magnetic tape, hard disk, etc.; and communication devices 709. Communication device 709 allows electronic device 700 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 6 An electronic device 700 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

[0226] Specifically, the process described in the flowchart above can be implemented as a computer software program. For example, the technical solution of this document includes a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowchart. In such a case, the computer program can be downloaded and installed from a network via communication device 709, or installed from storage device 708, or installed from read-only memory 702. When the computer program is executed by processing device 701, it performs the functions defined in the method of this document.

[0227] The names of messages or information exchanged between multiple devices in this document are for illustrative purposes only and are not intended to limit the scope of these messages or information.

[0228] The electronic device provided in this document and the method provided in the above-described technical solution belong to the same concept. Technical details not described in detail in this document can be found in the above-described situation, and this situation has the same beneficial effects as the above-described situation.

[0229] This article provides a computer storage medium on which a computer program is stored, which, when executed by a processor, implements the methods provided above.

[0230] It should be noted that the computer-readable medium mentioned above can be a computer-readable signal medium, a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, a random access memory, a read-only memory, an erasable programmable read-only memory (EPROM, also known as flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In this document, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such transmitted data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, radio frequency, etc., or any suitable combination thereof.

[0231] Based on one or more scenarios described in this article, Example 1 provides an object validation method, including: Obtain a dataset containing metadata identifiers and record content. The metadata identifiers are used to identify the verification object, and the record content is used to describe the verification object. Select the verification strategy corresponding to the metadata identifier; According to the verification strategy, key values ​​are extracted from the record content, and the key values ​​include the key values ​​of the verification object; Using the metadata identifier and the key value, obtain the first object and the second object, where the second object is the verification object being verified in the verification system, and the first object is the verification object in the baseline state. The first object and the second object are compared to obtain difference information, which is used to describe the differences between the first object and the second object.

[0232] Based on one or more scenarios described herein, Example 2 provides the method described in Example 1, wherein obtaining the dataset includes: Receive a first request, the first request being used to trigger the verification of the verification object; If the first request passes verification, the first request is parsed to obtain the dataset.

[0233] Based on one or more scenarios described herein, Example 3 provides the method described in Example 2, wherein parsing the first request to obtain the dataset when the first request verification passes includes: The structure of the first request is verified to obtain the verification result; If the verification result indicates that the verification passed, the fields included in the first request are extracted to form the dataset.

[0234] Based on one or more scenarios described herein, Example 4 provides the method described in Example 3, wherein validating the structure of the first request and obtaining a validation result includes: The following one or more of the first request are validated to obtain the validation results: The fields included in the first request, and the size of the first request.

[0235] Based on one or more scenarios described herein, Example 5 provides the method described in Example 1, wherein selecting the verification strategy corresponding to the metadata identifier includes: Select the policy type corresponding to the metadata identifier from the policy registry; The authorization set includes the strategy used for authorization; The policy registry is a mapping table generated during compilation, which stores the mapping relationship between the metadata identifier and the policy type.

[0236] Based on one or more scenarios described herein, Example 6 provides the method described in Example 1, wherein the first object includes one or more of the following: The first structured content of the metadata, and the second time of the metadata; The second object includes one or more of the following: The second structured content of the metadata, and the third time of the metadata; The second time includes the version time of the metadata at the data source, and the third time includes the version time of the metadata in the system being verified.

[0237] Based on one or more scenarios described herein, Example 7 provides the method described in Example 6, wherein obtaining the first object and the second object using the metadata identifier and the key value includes: The first object is obtained from the data source using the metadata identifier and the key value; According to the verification strategy, a first time is extracted from the record content, the first time including the change time of the verification object; Based on the first time, the second time, and the current time, determine whether to acquire the second object; If so, the second object is obtained from the verified system using the metadata identifier and the key value.

[0238] Based on one or more scenarios described herein, Example 8 provides the method described in Example 7, wherein determining whether to acquire the second object based on the first time, the second time, and the current time includes: Determine a first time difference between the first time and the current time; The need to obtain the second object is determined if one or more of the following conditions are met: The first time difference is greater than or equal to the first threshold; The second time is less than or equal to the current time, and the second time is greater than or equal to the first time.

[0239] Based on one or more scenarios described herein, Example 9 provides the method described in Example 6, wherein comparing the first object and the second object to obtain difference information includes: The fields included in the first object and the fields included in the second object are compared to obtain first information, which is used to indicate whether there are differences in the fields between the first object and the second object; Using the first time, the second time, and the third time, second information is obtained. The second information is used to describe the time difference between the first object and the second object. The first time includes the change time of the verified object. The difference information is obtained by aggregating the first information and the second information.

[0240] Based on one or more scenarios described herein, Example 10 provides the method described in Example 9, wherein comparing the fields included in the first object and the fields included in the second object to obtain first information includes: Normalize the first object and the second object respectively to obtain the normalized first object and the normalized second object; The fields included in the normalized first object and the fields included in the normalized second object are compared to obtain the first information.

[0241] Based on one or more scenarios described herein, Example 11 provides the method described in Example 9, wherein obtaining second information using a first time, a second time, and a third time includes: If the second time is greater than or equal to the first time, a second time difference between the third time and the first time is determined; Based on the comparison result of the first time difference and the second threshold, and / or the second time difference, the second information is obtained, wherein the first time difference is the difference between the first time and the current time, and the first time includes the change time of the verification object.

[0242] According to one or more scenarios described herein, [Example 12] provides an object verification apparatus, comprising: The acquisition module is used to acquire a dataset, which contains metadata identifiers and record content. The metadata identifiers are used to identify the verification object, and the record content is used to describe the verification object. The selection module is used to select the verification strategy corresponding to the metadata identifier; An extraction module is used to extract key values ​​from the record content according to the verification strategy, wherein the key values ​​include the key values ​​of the verification object; The acquisition module is used to acquire a first object and a second object using the metadata identifier and the key value, wherein the second object is the verification object being verified in the verification system, and the first object is the verification object in the baseline state. A comparison module is used to compare the first object and the second object to obtain difference information, which is used to describe the differences between the first object and the second object.

[0243] According to one or more of the provisions herein, [Example 13] provides an electronic device comprising: One or more processing devices; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processing devices, the one or more processing devices implement the methods provided herein.

[0244] According to one or more of the embodiments described herein, [Example 14] a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform the methods provided herein.

[0245] According to one or more of the scenarios described herein, [Example 15] a computer program product includes a computer program that, when executed by a processor, implements the methods provided herein.

[0246] In some scenarios, clients and servers can communicate using any currently known or future-developed network protocol, such as HTTP (Hypertext Transfer Protocol), and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include Local Area Networks (LANs), Wide Area Networks (WANs), the Internet (e.g., the Internet), and peer-to-peer networks (e.g., end-to-end networks), as well as any currently known or future-developed networks.

[0247] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0248] The aforementioned computer-readable medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to: obtain a dataset containing metadata identifiers and record content, wherein the metadata identifiers are used to identify a verification object, and the record content is used to describe the verification object; Select the verification strategy corresponding to the metadata identifier; According to the verification strategy, key values ​​are extracted from the record content, and the key values ​​include the key values ​​of the verification object; Using the metadata identifier and the key value, obtain the first object and the second object, where the second object is the verification object being verified in the verification system, and the first object is the verification object in the baseline state. The first object and the second object are compared to obtain difference information, which is used to describe the differences between the first object and the second object.

[0249] Computer program code for performing the operations described herein can be written in one or more programming languages ​​or a combination thereof, including but not limited to object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" programming language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including local area networks (LANs) or wide area networks (WANs), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0250] The flowcharts and block diagrams in the accompanying figures illustrate the architecture, functionality, and operation of possible implementations of the systems, methods, and computer program products according to the various scenarios described herein. In this respect, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the figures. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0251] The modules or units described in this document can be implemented in software or hardware. The name of a module or unit does not necessarily limit the module or unit itself; for example, an acquisition module can also be described as a "dataset acquisition module".

[0252] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, without limitation, exemplary types of hardware logic components that can be used include at least one of the following: Field-Programmable Gate Array (FPGA), Application-Specific Integrated Circuit (ASIC), Application-Specific Standard Product (ASSP), System on Chip (SOC), Complex Programmable Logic Device (CPLD), etc.

[0253] In the context of this document, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory (flash memory), optical fibers, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0254] The above description is merely a preferred implementation of this document and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure herein is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described disclosed concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features disclosed herein that have similar functions.

[0255] Furthermore, while the operations are described in a specific order, this should not be construed as requiring these operations to be executed in the specific order shown or in a sequential order. Multitasking and parallel processing may be advantageous in certain contexts. Similarly, while some specific implementation details are included in the above discussion, these should not be interpreted as limiting the scope of this paper. Certain features described in the context of a single implementation can also be implemented in combination in a single implementation. Conversely, various features described in the context of a single implementation can also be implemented individually or in any suitable sub-combination in multiple implementations.

[0256] Although the subject matter has been described using a programming language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative forms of implementing the claims.

Claims

1. An object validation method, comprising: Obtain a dataset containing metadata identifiers and record content. The metadata identifiers are used to identify the verification object, and the record content is used to describe the verification object. Select the verification strategy corresponding to the metadata identifier; According to the verification strategy, key values ​​are extracted from the record content, and the key values ​​include the key values ​​of the verification object; Using the metadata identifier and the key value, obtain the first object and the second object, where the second object is the verification object being verified in the verification system, and the first object is the verification object in the baseline state. The first object and the second object are compared to obtain difference information, which is used to describe the differences between the first object and the second object.

2. The method according to claim 1, wherein obtaining the dataset comprises: Receive a first request, the first request being used to trigger the verification of the verification object; If the first request passes verification, the first request is parsed to obtain the dataset.

3. The method according to claim 2, wherein parsing the first request to obtain the dataset when the first request verification passes includes: The structure of the first request is verified to obtain the verification result; If the verification result indicates that the verification passed, the fields included in the first request are extracted to form the dataset.

4. The method according to claim 3, wherein verifying the structure of the first request and obtaining a verification result includes: The following one or more of the first request are validated to obtain the validation results: The fields included in the first request, and the size of the first request.

5. The method according to claim 1, wherein selecting the verification strategy corresponding to the metadata identifier includes: Select the policy type corresponding to the metadata identifier from the policy registry; If the authorization set contains the metadata identifier, the policy of the policy type shall be used as the verification policy; The policy registry is a mapping table generated during compilation, which stores the mapping relationship between the metadata identifier and the policy type.

6. The method according to claim 1, wherein the first object comprises one or more of the following: The first structured content of the metadata, and the second time of the metadata; The second object includes one or more of the following: The second structured content of the metadata, and the third time of the metadata; in, The second time includes the version time of the metadata at the data source, and the third time includes the version time of the metadata in the system being verified.

7. The method according to claim 6, wherein obtaining the first object and the second object using the metadata identifier and the key value comprises: The first object is obtained from the data source using the metadata identifier and the key value; According to the verification strategy, a first time is extracted from the record content, the first time including the change time of the verification object; Based on the first time, the second time, and the current time, determine whether to acquire the second object; If so, the second object is obtained from the verified system using the metadata identifier and the key value.

8. The method according to claim 7, wherein determining whether to acquire the second object based on the first time, the second time, and the current time includes: Determine a first time difference between the first time and the current time; The need to obtain the second object is determined if one or more of the following conditions are met: The first time difference is greater than or equal to the first threshold; The second time is less than or equal to the current time, and the second time is greater than or equal to the first time.

9. The method according to claim 6, wherein comparing the first object and the second object to obtain difference information includes: The fields included in the first object and the fields included in the second object are compared to obtain first information, which is used to indicate whether there are differences in the fields between the first object and the second object; Using the first time, the second time, and the third time, second information is obtained. The second information is used to describe the time difference between the first object and the second object. The first time includes the change time of the verified object. The difference information is obtained by aggregating the first information and the second information.

10. The method according to claim 9, wherein comparing the fields included in the first object and the fields included in the second object to obtain first information comprises: Normalize the first object and the second object respectively to obtain the normalized first object and the normalized second object; The fields included in the normalized first object and the fields included in the normalized second object are compared to obtain the first information.

11. The method according to claim 9, wherein obtaining the second information using the first time, the second time, and the third time comprises: If the second time is greater than or equal to the first time, a second time difference between the third time and the first time is determined; Based on the comparison result of the first time difference and the second threshold, and / or the second time difference, the second information is obtained, wherein the first time difference is the difference between the first time and the current time, and the first time includes the change time of the verification object.

12. An object verification device, comprising: The acquisition module is used to acquire a dataset, which contains metadata identifiers and record content. The metadata identifiers are used to identify the verification object, and the record content is used to describe the verification object. The selection module is used to select the verification strategy corresponding to the metadata identifier; An extraction module is used to extract key values ​​from the record content according to the verification strategy, wherein the key values ​​include the key values ​​of the verification object; The acquisition module is used to acquire a first object and a second object using the metadata identifier and the key value, wherein the second object is the verification object being verified in the verification system, and the first object is the verification object in the baseline state. A comparison module is used to compare the first object and the second object to obtain difference information, which is used to describe the differences between the first object and the second object.

13. An electronic device, the electronic device comprising: One or more processing devices; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processing devices, the one or more processing devices perform the method as described in any one of claims 1-11.

14. A storage medium comprising computer-executable instructions, which, when executed by a computer processor, are used to perform the method as described in any one of claims 1-11.

15. A computer program product comprising a computer program that, when executed by a processor, implements the method as described in any one of claims 1-11.

Images