A machine room main version detection method, system, device and storage medium

Abstract

This application provides a method, system, device, and storage medium for detecting the main version of a data center, relating to the field of cloud computing. The method includes: obtaining service version information reported by a server; determining the target data center identifier based on the service version reporting string, extracting the service identifier and version number to generate a version reporting record; constructing a view of the current version of the data center, matching it with the main version configuration set to identify the current main version configuration; detecting version consistency of the same service on multiple servers and outputting the exception type; and writing the current main version configuration and exception type into a data center main version status object. This application can automatically determine the overall version status of the data center, realize the detection and classification of version inconsistency issues, improve the automation level of data center version management, and reduce system compatibility risks and operational complexity.

Description

Technical Field

[0001] This application relates to the field of cloud computing, and in particular to a method, system, device and storage medium for detecting the main version of a data center. Background Technology

[0002] In existing technologies, data center software version management mainly relies on manual ledger recording, node-level version query result aggregation, or simply displaying a single service report record. While these methods can reflect the version information of a service on a specific server node at a specific moment, they struggle to automatically converge to a data center-level master version view. They also fail to automatically determine the current master version configuration based on a preset master version configuration set, and cannot effectively identify the common anomaly of version inconsistencies for the same service on different servers within the same data center. Furthermore, multiple services within the data center often report versions intensively within a short period during upgrades or restarts. Triggering a full match for each report immediately not only incurs redundant calculations but also causes fluctuating results due to incomplete reporting by some services. Simultaneously, the version reporting string formats of different services may differ (e.g., compatibility issues between hyphens and underscores), and the lack of a unified normalization mechanism makes subsequent matching processes unstable.

[0003] Therefore, how to automatically identify the main version of the data center and accurately determine the anomalies of multiple node versions based on distributed service version reporting is a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0004] The purpose of this application is to provide a method, system, computer-readable storage medium, and electronic device for detecting the main version of a data center, which can identify the main version of the data center and accurately determine the anomalies of multiple node versions.

[0005] To address the aforementioned technical problems, this application provides a method for detecting the main version of a data center, the specific technical solution of which is as follows: Obtain the service version information reported by the server; the service version information includes at least the service version reporting string. Based on the service version reporting string, determine the target data center identifier to which the server belongs, and extract the service identifier and version number from the service version reporting string to generate a version reporting record associated with the target data center, the server, and the service corresponding to the service identifier; Extract the most recently reported version of each service in the target data center and construct a view of the current version of the data center. When the current version view of the data center matches any of the main version configuration sets, the matching main version configuration set is identified as the current main version configuration of the target data center; Extract the most recently reported version of the same service on multiple servers in the target data center, and output the anomaly type based on the consistency of the most recently reported version of the same service on multiple servers; Write the current main version configuration and the exception type into the data center main version status object.

[0006] Optionally, after generating the version reporting record associated with the target data center, the server, and the service corresponding to the service identifier, the method further includes: A delay matching task is generated for the target data center, and the delay matching task is deduplicated so that only one delay matching task is retained for execution within a set time window for the same target data center. Accordingly, when the delay matching task is triggered, the step of extracting the most recently reported version of each service in the target data center and constructing a view of the current version of the data center is executed.

[0007] Optionally, determining the target data center identifier to which the server belongs based on the service version reporting string includes: Read the license field from the service version information; When the license field is in a compatible format, extract the data center identifier from the license field; When the license field is in a normal format, the online data center object is queried based on the license field to obtain the corresponding data center identifier.

[0008] Optionally, extracting the service identifier and version number from the service version reporting string includes: Identify the format type of the service version reporting string; When the service version reporting string meets the first format, the service identifier and version number are extracted according to the first parsing strategy; When the service version reporting string meets the second format, the service identifier and version number are extracted according to the second parsing strategy; The corresponding service object is found based on the extracted service identifier, and the corresponding service version object is found or created based on the extracted version number.

[0009] Optionally, a delay matching task is generated for the target data center, and task deduplication of the delay matching task includes: The task name for the delay matching task is generated based on the data center identifier of the target data center; Submit the delayed matching task to the delay queue; Determine whether there is a matching task with the same task name to be executed in the delay queue; If there is an existing pending matching task with the same task name, reject the current delayed matching task from being added to the queue. If there is no matching task with the same task name to be executed, the delayed matching task is added to the delayed queue.

[0010] Optionally, the matching process between the current version view of the data center and any of the major version configuration sets includes: Read at least one major version configuration set, each of which contains multiple mapping relationships between services and target version numbers; For each of the main version configuration sets, verify whether the most recently reported version of each service in the current version view of the data center is consistent with the target version number of the corresponding service in the main version configuration set; When the current version view of the data center is missing the most recently reported version corresponding to any service in the main version configuration set, it is determined that the corresponding main version configuration set does not match. When the most recently reported version of any service in the current version view of the data center is inconsistent with the target version number of the corresponding service in the main version configuration set, it is determined that the corresponding main version configuration set does not match. When the most recently reported version of each service in the current version view of the data center is consistent with the target version number of the corresponding service in the main version configuration set, it is determined that the corresponding main version configuration set is matched.

[0011] Optionally, the step of extracting the most recently reported version of each service within the target data center and constructing a view of the current version of the data center includes: Based on the data center identifier of the target data center, obtain the version reporting records of all services on all servers within the target data center; For each service in the target data center, extract the most recently reported version from all version reporting records of that service in the target data center; Each service and its corresponding most recently reported version are combined into key-value pairs, and a current version view of the data center is generated by summarizing them.

[0012] This application also provides a data center master version detection system, including: The information acquisition module is used to acquire service version information reported by the server; the service version information includes at least the service version reporting string. The record generation module is used to determine the target data center identifier to which the server belongs based on the service version reporting string, and extract the service identifier and version number from the service version reporting string to generate a version reporting record associated with the target data center, the server and the service corresponding to the service identifier; The view building module is used to extract the most recently reported version of each service in the target data center and build a view of the current version of the data center. The matching module is used to identify the matched main version configuration set as the current main version configuration of the target data center when the current version view of the data center matches any of the main version configuration sets. The exception output module is used to extract the most recently reported version of the same service on multiple servers in the target data center, and output the exception type based on the consistency of the most recently reported version of the same service on multiple servers. The object writing module is used to write the current master version configuration and the exception type into the data center master version status object.

[0013] This application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described above.

[0014] This application also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor implements the steps of the method described above when it invokes the computer program in the memory.

[0015] This application also provides a computer program product, including a computer program that, when executed, implements the steps of the method described above.

[0016] This application provides a method for detecting the primary version of a data center, comprising: obtaining service version information reported by a server; the service version information including at least a service version reporting string; determining the target data center identifier to which the server belongs based on the service version reporting string, and extracting the service identifier and version number from the service version reporting string to generate a version reporting record associated with the target data center, the server, and the service corresponding to the service identifier; extracting the most recently reported version of each service in the target data center to construct a current version view of the data center; when the current version view of the data center matches any of the primary version configuration sets, identifying the matching primary version configuration set as the current primary version configuration of the target data center; extracting the most recently reported version of the same service on multiple servers in the target data center, and outputting an exception type based on the consistency of the most recently reported version of the same service on multiple servers; and writing the current primary version configuration and the exception type into a data center primary version status object.

[0017] This application constructs a view of the current version of each service within the target data center by extracting the most recently reported version of each service. This view is then matched with the master version configuration set to identify the current master version configuration of the target data center, automatically determining the overall version status of the data center. Simultaneously, by extracting the most recently reported versions of the same service across multiple servers within the target data center and outputting anomaly types based on the consistency of the reported versions across servers, it achieves the detection and classification of service version inconsistencies within the data center. By writing the identified current master version configuration and anomaly types into the data center master version status object, effective management of the data center version status is achieved, improving the automation level of data center version management, facilitating timely anomaly detection, and reducing system compatibility risks and operational complexity caused by version inconsistencies.

[0018] This application also provides a data center master version detection system, a computer-readable storage medium, an electronic device, and a computer program product, which have the above-mentioned beneficial effects, and will not be elaborated here. Attached Figure Description

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

[0020] Figure 1 This is a flowchart of the data center main version detection method provided in the embodiments of this application; Figure 2 A flowchart illustrating the service version reporting normalization and delayed deduplication processing provided in the embodiments of this application; Figure 3 This is a schematic diagram of the structure of the data center main version detection system provided in the embodiments of this application; Figure 4 This is a structural diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

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

[0022] See Figure 1 , Figure 1This is a flowchart of a data center master version detection method provided in an embodiment of this application. The method includes: Step S101: Obtain the service version information reported by the server; In this embodiment, the platform can receive service version reporting requests from server nodes via a network interface to obtain service version information. The service version information may include at least a service version reporting string, and may also include at least one of a server identifier and a data center ownership identifier. The service version reporting string is a version information string assembled by the server according to a predefined format, typically composed of a service identifier field and a version number field. The server identifier may be information that uniquely identifies a server, such as its IP address, hostname, or globally unique identifier. The data center ownership identifier may be a data center code directly carried by the server, or data center location information indirectly derived from other related fields. After receiving the service version report, the platform can temporarily store the original reported data in a message middleware or memory buffer for subsequent parsing and processing. The technical effect of this step is to establish a data acquisition channel from the server side to the platform side, providing a basic data source for subsequent data center ownership determination and version parsing.

[0023] Step S102: Determine the target data center identifier based on the service version reporting string, extract the service identifier and version number, and generate a version reporting record; In this step, the platform can parse the obtained service version reporting string to determine three key pieces of information: target data center identifier, service identifier, and version number. First, to determine the target data center identifier, the platform can read the license field in the service version information and adopt the corresponding data center identifier retrieval strategy based on the format type of this field. When the license field is in a compatible format, the data center identifier can be directly extracted from the license field; when the license field is in a normal format, the online data center object can be queried based on the license field, and the corresponding data center identifier can be obtained through reverse mapping. Second, to extract the service identifier and version number, the platform can first identify the format type used in the service version reporting string, and then use corresponding parsing strategies to split it for different formats. When the service version reporting string meets the first format, the service identifier and version number can be extracted from it according to the first parsing strategy; when the service version reporting string meets the second format, the corresponding service identifier and version number can be extracted according to the second parsing strategy. For example, the first format can be a service identifier followed by a hyphen and then a version number (e.g., ServiceA-v1.2.3), and the second format can be a service identifier followed by an underscore and then a version number (e.g., ServiceA_v1.2.3). After successfully extracting the service identifier and version number, the platform can find the corresponding service object based on the extracted service identifier, and find or create the corresponding service version object based on the extracted version number. Finally, the platform can generate a version reporting record associated with the target data center, target server, and target service based on the determined target data center identifier, server identifier, service object, and service version object, and persist this record to the version reporting record database. The technical effect of this step is to complete the normalization processing of heterogeneous format reporting data, uniformly converting version information from different services and different formats into structured version reporting records, laying the data foundation for subsequent data center-level view construction.

[0024] Step S103: Extract the most recently reported version of each service in the target data center and construct a view of the current version of the data center.

[0025] In this step, the platform can extract the most recently reported version information of each service within the target data center from the version reporting record library to construct a data center-level current version view. Specifically, the platform can obtain the version reporting records of all services on all servers within the target data center based on the data center identifier. For each service within the target data center, the platform can filter out the record with the latest timestamp from all version reporting records for that service within the target data center and extract the most recently reported version number. Subsequently, the platform can combine each service and its corresponding most recently reported version into key-value pairs, and aggregate all key-value pairs to generate a data center current version view. The data center current version view is essentially a mapping set with the service identifier as the key and the most recently reported version number as the value, reflecting the overall version status of each service in the target data center at the current moment. The technical effect of this step is that it aggregates and consolidates the service version information scattered across multiple version reporting records according to the data center dimension, forming a unified version snapshot that can be used for master version comparison.

[0026] Step S104: Compare the current version view of the data center with the main version configuration set one by one to identify the current main version configuration of the target data center; In this step, the platform can use a pre-configured primary version configuration set library to compare the current version view of the data center built in step S103 one by one to identify which primary version configuration is currently running in the target data center. Each primary version configuration set can contain the mapping relationship between multiple services and their target version numbers, representing a complete and verified software version combination scheme. The platform can read each primary version configuration set sequentially and perform a complete matching and verification process for each primary version configuration set. During the matching and verification process, the platform needs to verify whether two conditions are met simultaneously: First, the current version view of the data center should include the most recently reported version for each service in the main version configuration set, and there should be no missing versions. Secondly, the most recently reported version of each service in the current version view of the data center should be completely consistent with the target version number of the corresponding service in the main version configuration set. If the current version view of the data center lacks the most recently reported version of any service in a main version configuration set, the main version configuration set can be determined to be mismatched; similarly, if the most recently reported version of any service in the current version view of the data center is inconsistent with the target version number of the corresponding service in the main version configuration set, the main version configuration set can also be determined to be mismatched; only when the most recently reported versions of all services in the current version view of the data center are consistent with the target version number of the corresponding service in a main version configuration set can the main version configuration set be determined to be matched, and the main version configuration set can be identified as the current main version configuration of the target data center. If no set is found to be matched after traversing all main version configuration sets, the main version of the target data center can be marked as unidentified. The technical effect of this step is that through strict item-by-item comparison rules, the automatic and deterministic determination of the main version of the data center is achieved, avoiding subjective bias caused by manual specification.

[0027] Step S105: Extract the most recently reported version of the same service on multiple servers, and output the anomaly type based on consistency. In this step, based on step S104, the platform can further perform multi-node version consistency checks on the same service that may be deployed in parallel on multiple servers within the target data center, and output the corresponding exception type based on the check results. Specifically, when the target data center does not match any major version configuration set, an unidentified exception type can be directly output, indicating that the current data center version status is not within the range of any known major version configuration. When the target data center has matched a certain major version configuration set, the platform can extract the most recently reported version of the same service on multiple servers in the target data center and construct a mapping relationship between server identifiers and the most recently reported version number. Subsequently, the platform can determine whether there are multiple different version numbers for the most recently reported version of the same service on multiple servers. When multiple different version numbers are detected, it indicates that the service is running inconsistent versions on different servers in the same data center, and a multi-version exception type can be output; when there are no multiple different version numbers, that is, the most recently reported version of the service is consistent across all servers, and a single-version type can be output. Ultimately, regardless of the anomaly type, the platform can write the identified primary version configuration identifier (if any) and the anomaly type into the data center primary version status object, forming the final classification result. The technical advantage of this step is that it not only identifies the primary version but also automatically detects and classifies version drift issues in multi-node deployment scenarios, providing operations and maintenance personnel with a clear basis for anomaly classification.

[0028] Step S106: Write the current master version configuration and exception type into the data center master version status object.

[0029] In this step, the platform can persistently store the identification and classification results generated in the preceding steps into a unified data center master version status object. This data center master version status object should at least include the following information: target data center identifier, identified master version configuration identifier (if a match is successful), exception type (unidentified, single version, or multiple versions), exception description text, and a timestamp of the result generation. The platform can write this status object into the data center master version status table via a database update interface, or push the status change event to downstream consumers via a message queue for use by monitoring dashboards, alarm engines, or operation and maintenance management pages. Once the writing is complete, the entire processing flow triggered by this service version report ends. The technical effect of this step is to converge the intermediate conclusions scattered across various processing stages into a structured data center version status snapshot, providing a unified version governance data entry point for upper-layer businesses.

[0030] Based on the above embodiments, in one feasible implementation, the compatible format and the ordinary format of the license field can be distinguished. Specifically, in step S102, for the determination process of the target data center identifier, after reading the license field in the service version information on the platform side, the value characteristics of the field can be analyzed to determine whether it belongs to the compatible format or the ordinary format.

[0031] The compatible format refers to a format where the data center identification information is directly embedded in the license field. The platform can directly parse the data center identification from the license field using regular expression matching or fixed-position truncation. The standard format refers to a license field that only contains the license number or other non-data center identification information. In this case, the platform can use the license field as a query condition to call the query interface of the online data center object and retrieve the corresponding data center identification through the association between the license and the data center. The processing paths for the two formats can be designed in parallel. During actual operation, the platform can automatically route to the correct processing branch based on the real-time content of the license field. This refined approach enables the system to be compatible with the differentiated license reporting formats used by services launched at different historical stages, without requiring a unified format transformation for all existing services, thus significantly reducing the cost of access and transformation. In addition, the rules for distinguishing between the compatible and standard formats can be predefined by those skilled in the art based on the types of license formats existing in the actual business scenario, or new format types can be dynamically extended through a configurable format rule table.

[0032] Based on the above embodiments, in one feasible implementation, compatible parsing of multiple versions of reporting string formats can be performed.

[0033] In step S102, the process of extracting the service identifier and version number from the service version reporting string can be further executed as follows: After receiving the service version report string, the platform can first identify the format type of the string. The format type identification can be based on the characteristics of the delimiters: when a hyphen (such as "-") is detected in the string as a delimiter between the service identifier and the version number, it can be classified as the first format (hyphen format); when an underscore (such as "_") is detected in the string as a delimiter, it can be classified as the second format (underscore format).

[0034] For the first format, the first parsing strategy can split the string according to the position of the hyphen, taking the part before the hyphen as the service identifier and the part after the hyphen as the version number.

[0035] For the second format, the second parsing strategy can perform similar segmentation based on the position of the underscore. In some cases, the version number itself may also contain hyphens or underscores (such as the semantic version number v1.2.3-beta). In this case, the parsing strategy can limit segmentation to only the first occurrence of the separator, or use the longest match from right to left to ensure the integrity of the version number. After extracting the service identifier and version number, the platform can match the service identifier with a preset service registry to determine the corresponding service object. If the service registry does not yet contain a record corresponding to the service identifier, it can choose to create a new service object or mark the report as pending confirmation. Similarly, for the version number, the platform can search in the existing list of service version objects. If an object with the same version number is found, the reference is reused; otherwise, a new service version object is created. This refined approach allows the system to smoothly integrate with historical services and newly added services using different coding standards, achieving unified version parsing and archiving without changing the service-side reporting logic.

[0036] Based on the above embodiments, in one feasible implementation, in step S103, the platform can use the target data center's data center identifier as a filter condition to batch retrieve all version reporting records within the data center's scope from the version reporting record database. Each version reporting record can include fields such as data center identifier, server identifier, service identifier, version number, and reporting timestamp. The platform can group the retrieved record set according to the service identifier, sort each service group in descending order according to the reporting timestamp, select the record at the top as the most recently reported version record for that service, and extract the version number from it as the most recently reported version. Subsequently, the platform can organize each group of service identifiers and their corresponding most recently reported version numbers into key-value pairs, and summarize all entries into a dictionary or mapping table structure, which is the current version view of the data center. During the construction of this view, the platform can also handle missing cases specially: if a service has no version reporting records in the target data center, the most recently reported version of that service can be marked as null or a placeholder in the view, so that the subsequent main version matching step can determine that the main version configuration set is not matched due to the lack of necessary services. This refinement method ensures the completeness and accuracy of the current version view of the data center, enabling it to faithfully reflect the actual version distribution of the target data center at the current moment.

[0037] Based on the above embodiments, in one feasible implementation, when the current version view of the data center in step S104 matches any of the main version configuration sets, the platform can pre-maintain a main version configuration set library. This library stores several main version configuration sets, each representing a verified, stable combination of software versions that can run in the data center. Each main version configuration set can contain several entries, each entry recording a service identifier and its target version number that should be present under that main version. During matching, the platform can retrieve each configuration set from the main version configuration set library one by one and perform the following verification logic: First, iterate through all service entries in the main version configuration set and check whether the current version view of the data center contains the most recently reported version of the service corresponding to each entry. If any service is found to be missing in the view (i.e., the service has no reported record in the current data center), it can be directly determined that the main version configuration set does not match, and jump to the next configuration set to continue the comparison.

[0038] Secondly, for each service that does exist in the current version view of the data center, its most recently reported version number is compared with the target version number of the corresponding service in the main version configuration set to ensure complete consistency. If any service's most recently reported version number is found to be inconsistent with the target version number, the main version configuration set can also be determined to be mismatched. Only when all services in a main version configuration set have corresponding entries in the current version view of the data center, and the most recently reported version number of each service is strictly consistent with the target version number, can the main version configuration set be considered to match the current version view of the data center, and the identifier of the configuration set is recorded as the current main version configuration of the target data center. If no matching item is found after traversing all configuration sets, the unidentified state can be retained. The matching rules of this refined method are complete and strict, requiring both the completeness of the service set and the precise consistency of each service version number, thereby ensuring the reliability of the data center main version identification results. In addition, the number and content of the main version configuration set are configured and maintained by those skilled in the art based on the officially released version scheme in actual business, and new configuration sets can be dynamically added with the release of new versions.

[0039] Based on the above embodiments, in one feasible implementation, step S105, the process of outputting the consistency exception type based on the most recently reported version of the same service on multiple servers, may include the following steps: When the target data center does not match any major version configuration set, an unidentified exception type is output. When the target data center matches any major version configuration set, extract the most recently reported version of the same service on multiple servers in the target data center; Determine whether there are multiple different version numbers for the most recently reported version of the same service on multiple servers; if there are multiple different version numbers, output a multi-version exception type; if there are no multiple different version numbers, output a single version type.

[0040] After completing the primary version configuration matching, the platform can proceed to the anomaly detection stage. If the target data center fails to match any primary version configuration set, it can directly output an unidentified anomaly type and record the reason as the version combination of services currently running in the target data center not being within the known primary version configuration range. If the target data center has successfully matched a primary version configuration set, it can continue to perform multi-node consistency verification. The platform can extract a list of all services with deployment records on multiple servers within the target data center from the version reporting record database. For each service in the list, it extracts the most recent reported version number on each server, constructing a mapping set with the server identifier as the key and the version number as the value.

[0041] Subsequently, the platform can count the number of deduplicated version numbers in the mapping set: if the number of deduplicated version numbers is greater than 1, it indicates that the service is running different versions on different servers. In this case, a multi-version exception type can be output, and the exception description can list the specific service names and involved version numbers where inconsistencies occur. If the number of deduplicated version numbers is equal to 1, it indicates that the service maintains consistency across all servers in the most recent version. In this case, a single-version type can be output. Finally, the platform can write the above classification results, along with the identified primary version configuration identifier, into the data center primary version status object. This refined approach achieves complete exception classification coverage from unidentified to single-version to multi-version, enabling operations and maintenance personnel to quickly locate the nature of the problem and take appropriate measures based on the exception type.

[0042] In this embodiment, a separate implementation method is described for the delayed matching task and the deduplication control mechanism. This embodiment is a supplementary implementation method added based on the above embodiments, and its purpose is to solve the problem of frequent duplicate matching caused by multiple services in the data center reporting in a short period of time.

[0043] In this embodiment, after the platform completes the generation and storage of version reporting records, it does not immediately trigger the data center main version identification process in steps S103 to S106. Instead, it first executes the generation and scheduling of a delayed matching task. Specifically, the platform can generate a delayed matching task for the target data center. The core attributes of this task can include: task name, target data center identifier, planned trigger time, and task status. The task name can be generated based on the target data center identifier. For example, the data center identifier can be used directly as the task name or a fixed prefix (such as match-) can be added before it to ensure the uniqueness and identifiability of the task name. The planned trigger time can be set to the current time plus a preset delay duration. The delay duration is a configurable parameter, for example, it can be set to 30 seconds. This value can be set by those skilled in the art based on the average service restart time window within the data center, or it can be dynamically adjusted based on actual operation and maintenance experience. The initial value of the task status can be set to pending execution.

[0044] After generating a delayed matching task, the platform can submit it to a delayed queue for unified management and scheduling. This delayed queue can be a queue middleware implementation that supports timed triggering and deduplication control, such as a Redis-based delayed task queue, a database polling-based timed task table, or a message middleware-based delayed delivery mechanism. Before enqueuing a task, the platform needs to perform a deduplication check on the delayed matching task. The deduplication check can be based on the task name, as delayed matching tasks within the same data center should use the same task name. The platform can scan the list of currently pending tasks in the delayed queue to determine if there is a task with the same name as the newly generated delayed matching task. If a pending matching task with the same name already exists in the delayed queue, it means that a delayed matching task with the same name was previously generated in a report for this data center and has not yet been executed. In this case, the platform can refuse to enqueue the current delayed matching task to avoid duplicate tasks consuming computing resources. If no pending matching task with the same name exists in the delayed queue, the platform can add the newly generated delayed matching task to the delayed queue and wait for the scheduled trigger time to be scheduled for execution.

[0045] When the scheduled trigger time for the delayed matching task arrives, the scheduler of the delayed queue can retrieve the task and trigger its execution. After the task is triggered, the platform can begin executing the data center main version identification process as described in steps S103 to S106 of the above embodiment, namely, extracting the most recently reported version of each service in the target data center, constructing a view of the current version of the data center, comparing it one by one with the main version configuration set, performing multi-node consistency verification and anomaly detection, and writing the results into the data center main version status object. Since the delayed matching task is triggered later than the last reported entry time, each service in the target data center has likely completed its version reporting by this time. Therefore, the constructed view of the current version of the data center has high completeness and stability, and the matching results will not fluctuate in the short term due to some services not yet reporting. The technical advantage of this embodiment lies in the fact that by introducing a delay mechanism and a task deduplication mechanism, multiple reporting events that occur intensively within a short time window are aggregated into a unified data center-level matching operation. This not only significantly reduces redundant computational overhead but also effectively suppresses the jitter of matching results in the time dimension, thereby improving the overall stability and resource utilization efficiency of the data center main version identification process.

[0046] The generation and deduplication control process of delayed matching tasks can be further implemented using the following methods: After each version report is entered into the database, the platform can construct a standardized task name based on the target data center's identifier. The task name generation rule can adopt a fixed pattern, such as room-version-match-{roomId}, where roomId is the actual value of the data center identifier.

[0047] Subsequently, the platform can call the deduplication query interface of the delayed queue, using the task name as the query condition, to check if a task with the same name and a pending status already exists in the queue. The implementation of the deduplication query depends on the underlying delayed queue technology: if implemented using a Redis sorted set, the task name can be used as a member element and the scheduled trigger time as a score for range queries; if implemented using a database scheduled task table, a unique index can be created on the task name field and an existence check can be performed using a SELECT statement; if implemented using a message middleware, the idempotency of message IDs or external caching can be used to record the set of task names that have been enqueued.

[0048] When the deduplication query returns a result indicating that a task with the same name already exists, the platform can discard the generated delayed matching task and return a successful deduplication response to the caller. When the result indicates that no task with the same name exists, the platform can formally write the delayed matching task into the delayed queue and optionally record the task name synchronously in the application layer cache to accelerate subsequent deduplication judgments.

[0049] Furthermore, the duration of the preset delay window can be managed as a globally adjustable parameter, with a default value of 30 seconds and a range between 10 and 120 seconds. The specific setting of this value can be determined by those skilled in the art based on measured data or industry experience, referring to the maximum reasonable time required for a full service to complete a version report within the data center. Alternatively, a tiered setting can be adopted based on the size of the data center (e.g., the number of services), with data centers serving more services using longer delay windows and those serving fewer services using shorter delay windows. This refined approach ensures the robustness and flexibility of the delay deduplication mechanism under various load scenarios.

[0050] Based on the above embodiments, in one feasible implementation, the generation of version reporting records may also include a function to record the previous version number. Specifically, before the platform prepares to write a new version reporting record for a target service on a target server, it can first query the version reporting record database to see if there are historical version records corresponding to the target server and the target service. If historical version records exist, the version number to be written this time can be compared with the version number recorded in the most recent historical version record. If they are different, the version number in the most recent historical version record can be extracted, recorded as the previous version number, and written together with the new version number into a new version reporting record or an existing record can be updated. If they are the same, it means that the service has not undergone version changes since the last report, and the update operation of the previous version number can be skipped to avoid meaningless write operations. In this way, each version reporting record can not only reflect the currently effective version number, but also trace the previous version number that the service ran before, thus forming a continuous version evolution trajectory. When reviewing version reporting records, operations and maintenance personnel can intuitively understand the relationship between versions before and after each version switch, which helps to quickly locate issues such as version rollback and error upgrades. This previous version number recording function can run independently of the main version matching process, or it can be retained as a standard field in the version reporting records.

[0051] Based on the above embodiments and detailed implementation methods, the automatic identification and anomaly determination method for main versions of data centers provided by the present invention can achieve the following complete technical effects: At the data access level, by being compatible with heterogeneous version reporting formats (hyphen and underscore formats) and multiple formats of license fields (compatible and normal formats), the system achieves unified acceptance and normalized parsing of service version reporting data from different historical periods and with different development specifications. This reduces the workload of modifying the management link for existing services to access the new data center version, enabling the data center version governance system to gradually cover all data centers and services across the network.

[0052] At the data processing level, a complete version information storage system was formed by establishing a three-dimensional version reporting record model encompassing the data center, servers, and services, combined with the ability to record the previous version number. Based on this, by aggregating the most recently reported versions by service dimension and constructing a data center-level current version view, a data dimensionality upgrade was achieved from discrete, point-like version records to continuous, area-like version snapshots, providing a standardized input data structure for master version comparison.

[0053] At the matching and scheduling level, by introducing a delayed matching task generation mechanism based on a delayed queue and a deduplication control mechanism based on task name, multiple reporting events triggered intensively within a short time window are intelligently merged into a unified matching execution, effectively avoiding the waste of redundant calculations and result jitter in scenarios of concentrated service restarts. The configurable feature of the delayed window parameter enables the system to adapt to data center environments of different sizes.

[0054] At the major version identification level, the system achieves automated and objective determination of the data center's major version by performing item-by-item integrity checks and precise consistency comparisons with a preset major version configuration set. The strictness of the matching rules (requiring both complete service coverage and matching version numbers one by one) ensures the accuracy of the identification results, while the scalability of the configuration set allows the system to continuously incorporate new official version solutions as business evolves.

[0055] At the anomaly identification level, by further overlaying multi-node recent version consistency verification after major version identification, full coverage output of three anomaly types—unidentified, single-version, and multi-version—is achieved. In particular, the automatic detection of multi-version anomalies fills the blind spot of traditional node-level version display methods in detecting cross-node version drift, enabling operations teams to promptly discover and address the hidden problem of the same service running inconsistent versions on different servers.

[0056] At the output level, by uniformly writing the main version configuration identifier and exception type into the data center main version status object and persistently storing and pushing events, a closed-loop version governance data link is formed. Downstream consumer devices (such as monitoring dashboards, alarm engines, and operation and maintenance management platforms) can use this status object to achieve value-added capabilities such as real-time visualization of data center versions, out-of-bounds alarms, and trend analysis.

[0057] For a better understanding of this application, see [link to application]. Figure 2 , Figure 2 This illustrates the complete process of service version reporting normalization and delayed deduplication in an embodiment of the present invention. For example... Figure 2 As shown, the process proceeds from top to bottom, sequentially including receiving service version reports, reading license fields and version report strings, license format judgment (the compatible format branch and the normal format branch respectively execute the extraction of data center identifier or query of online data center objects), version string format verification (distinguishing between hyphen and underscore formats), and the four parallel processing actions at the bottom (extracting service identifier and version number, writing version report record, recording the previous version number, and deduplicating and queuing data center task names), fully presenting the entire process from raw reported data to normalized records and then to delayed task scheduling.

[0058] See Figure 3 , Figure 3This is a schematic diagram of the structure of the data center master version detection system provided in this application embodiment. The system includes: The information acquisition module is used to acquire service version information reported by the server; the service version information includes at least the service version reporting string. The record generation module is used to determine the target data center identifier to which the server belongs based on the service version reporting string, and extract the service identifier and version number from the service version reporting string to generate a version reporting record associated with the target data center, the server and the service corresponding to the service identifier; The view building module is used to extract the most recently reported version of each service in the target data center and build a view of the current version of the data center. The matching module is used to identify the matched main version configuration set as the current main version configuration of the target data center when the current version view of the data center matches any of the main version configuration sets. The exception output module is used to extract the most recently reported version of the same service on multiple servers in the target data center, and output the exception type based on the consistency of the most recently reported version of the same service on multiple servers. The object writing module is used to write the current master version configuration and the exception type into the data center master version status object.

[0059] This application also provides an embodiment of a computer-readable storage medium and a computer program product. Both the computer-readable storage medium and the computer program product may store a computer program that, when executed by a processor, implements the steps of the method described in the above method embodiments.

[0060] It is understood that if the methods in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and executes all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0061] The computer-readable storage medium provided in this embodiment includes computer programs that implement the corresponding embodiments of the above methods, and the effects are the same as above.

[0062] This application also provides an electronic device, see [link to document]. Figure 4 The present application provides a structural diagram of an electronic device, as shown in the embodiment. Figure 4 As shown, it may include a processor 1410 and a memory 1420.

[0063] The processor 1410 may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor 1410 may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). The processor 1410 may also include a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 1410 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, the processor 1410 may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0064] The memory 1420 may include one or more computer-readable storage media, which may be non-transitory. The memory 1420 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In this embodiment, the memory 1420 is used to store at least the following computer program 1421, which, after being loaded and executed by the processor 1410, is capable of implementing the relevant steps in the methods executed by the electronic device side as disclosed in any of the foregoing embodiments. In addition, the resources stored in the memory 1420 may also include an operating system 1422 and data 1423, etc., and the storage method may be temporary storage or permanent storage. The operating system 1422 may include Windows, Linux, Android, etc.

[0065] In some embodiments, the electronic device may further include a display screen 1430, an input / output interface 1440, a communication interface 1450, a sensor 1460, a power supply 1470, and a communication bus 1480.

[0066] certainly, Figure 4The structure of the electronic device shown does not constitute a limitation on the electronic device in the embodiments of this application. In practical applications, the electronic device may include more than [other components]. Figure 4 More or fewer components as shown, or combinations of certain components.

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

[0068] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. It should be noted that those skilled in the art can make several improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of this application.

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

Claims

1. A method for detecting the main version of a computer room, characterized in that, include: Retrieve the service version information reported by the server; The service version information includes at least the service version reporting string; Based on the service version reporting string, determine the target data center identifier to which the server belongs, and extract the service identifier and version number from the service version reporting string to generate a version reporting record associated with the target data center, the server, and the service corresponding to the service identifier; Extract the most recently reported version of each service in the target data center and construct a view of the current version of the data center. When the current version view of the data center matches any of the main version configuration sets, the matching main version configuration set is identified as the current main version configuration of the target data center; Extract the most recently reported version of the same service on multiple servers in the target data center, and output the anomaly type based on the consistency of the most recently reported version of the same service on multiple servers; Write the current main version configuration and the exception type into the data center main version status object.

2. The method according to claim 1, characterized in that, After generating the version reporting record associated with the target data center, the server, and the service corresponding to the service identifier, the process also includes: A delay matching task is generated for the target data center, and the delay matching task is deduplicated so that only one delay matching task is retained for execution within a set time window for the same target data center. Accordingly, when the delay matching task is triggered, the step of extracting the most recently reported version of each service in the target data center and constructing a view of the current version of the data center is executed.

3. The method according to claim 1, characterized in that, Based on the service version reporting string, the target data center identifier to which the server belongs is determined, including: Read the license field from the service version information; When the license field is in a compatible format, extract the data center identifier from the license field; When the license field is in a normal format, the online data center object is queried based on the license field to obtain the corresponding data center identifier.

4. The method according to claim 1, characterized in that, Extracting the service identifier and version number from the service version reporting string includes: Identify the format type of the service version reporting string; When the service version reporting string meets the first format, the service identifier and version number are extracted according to the first parsing strategy; When the service version reporting string meets the second format, the service identifier and version number are extracted according to the second parsing strategy; The corresponding service object is found based on the extracted service identifier, and the corresponding service version object is found or created based on the extracted version number.

5. The method according to claim 2, characterized in that, Generate a delay matching task for the target data center, and perform task deduplication on the delay matching task, including: The task name for the delay matching task is generated based on the data center identifier of the target data center; Submit the delayed matching task to the delay queue; Determine whether there is a matching task with the same task name to be executed in the delay queue; If there is an existing pending matching task with the same task name, reject the current delayed matching task from being added to the queue. If there is no matching task with the same task name to be executed, the delayed matching task is added to the delayed queue.

6. The method according to claim 1, characterized in that, The matching process between the current version view of the data center and any of the major version configuration sets includes: Read at least one major version configuration set, each of which contains multiple mapping relationships between services and target version numbers; For each of the main version configuration sets, verify whether the most recently reported version of each service in the current version view of the data center is consistent with the target version number of the corresponding service in the main version configuration set; When the current version view of the data center is missing the most recently reported version corresponding to any service in the main version configuration set, it is determined that the corresponding main version configuration set does not match. When the most recently reported version of any service in the current version view of the data center is inconsistent with the target version number of the corresponding service in the main version configuration set, it is determined that the corresponding main version configuration set does not match. When the most recently reported version of each service in the current version view of the data center is consistent with the target version number of the corresponding service in the main version configuration set, it is determined that the corresponding main version configuration set is matched.

7. The method according to claim 1, characterized in that, The step of extracting the most recently reported version of each service within the target data center and constructing a view of the current version of the data center includes: Based on the data center identifier of the target data center, obtain the version reporting records of all services on all servers within the target data center; For each service in the target data center, extract the most recently reported version from all version reporting records of that service in the target data center; Each service and its corresponding most recently reported version are combined into key-value pairs, and a current version view of the data center is generated by summarizing them.

8. A main version detection system for a data center, characterized in that, include: The information acquisition module is used to acquire service version information reported by the server; The service version information includes at least the service version reporting string; The record generation module is used to determine the target data center identifier to which the server belongs based on the service version reporting string, and extract the service identifier and version number from the service version reporting string to generate a version reporting record associated with the target data center, the server and the service corresponding to the service identifier; The view building module is used to extract the most recently reported version of each service in the target data center and build a view of the current version of the data center. The matching module is used to identify the matched main version configuration set as the current main version configuration of the target data center when the current version view of the data center matches any of the main version configuration sets. The exception output module is used to extract the most recently reported version of the same service on multiple servers in the target data center, and output the exception type based on the consistency of the most recently reported version of the same service on multiple servers. The object writing module is used to write the current master version configuration and the exception type into the data center master version status object.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the method as claimed in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed, implements the steps of the method as described in any one of claims 1 to 7.

Images