Multi-load compatible system version verification method and device

Abstract

The invention belongs to the field of system version verification, and provides a multi-load compatible system version verification method and device. The method comprises the following steps: taking each micro-service as a topological node, acquiring topological information of the multi-micro-service system, querying a patch installation record of each topological node, and extracting (Major, Minor, SetDepth) three-dimensional features of a corresponding topological node patch; according to a combined patch equivalent transformation mechanism, combining the installation records of the sub-patches with the dependency relationship to obtain the installation record of the combined patch of each topological node; and on the basis of the (Major, Minor, SetDepth) three-dimensional features of the patches of each topological node, in combination with the installation record of the combined patch of each topological node and the current patch installation state, determining whether the sub-patches are not installed in each topological node. According to the method, the difference of patches between topological nodes in a multi-load architecture environment is considered, and the root cause of system version inconsistency is accurately positioned.

Description

Technical Field

[0001] The present invention belongs to the field of system version verification, and particularly relates to a system version verification method and device compatible with multiple loads. Background Art

[0002] The statements in this part only provide background technical information related to the present invention and do not necessarily constitute prior art.

[0003] The ERP (Enterprise Resource Planning) system is the core tool for enterprise management. During the product update and iteration process, the ERP system is usually maintained by means of patch updates to ensure its stability and usability. In a multi-microservice or multi-load architecture environment, the patch installations among multiple microservices or topology nodes may be inconsistent, which may lead to problems such as program errors, system process interruptions, or function failures caused by version differences.

[0004] Most of the existing system version verifications adopt manual verification methods, such as manually identifying patch record differences. However, in scenarios where the patch record base is large and the dependency relationships are complex, it is impossible to quickly and accurately identify the differences. To solve the deficiencies of the manual verification method, the prior art also provides a version number definition method based on function drive, which adds a software development version format based on functions, and associates the changes and upgrades of each version with specific functions to facilitate users and developers to more clearly understand the differences and changes between versions. However, this method does not consider the differences in patches among topology nodes in a multi-microservice or multi-load architecture environment and cannot accurately locate the root cause of system version inconsistency. Summary of the Invention

[0005] To solve the above technical problems, the present invention provides a system version verification method and device compatible with multiple loads, which consider the differences in patches among topology nodes in a multi-microservice or multi-load architecture environment and can accurately locate the root cause of system version inconsistency.

[0006] To achieve the above object, the present invention adopts the following technical solutions: The first aspect of the present invention provides a system version verification method compatible with multiple loads.

[0007] In one or more embodiments, a system version verification method compatible with multiple loads is provided, including: Taking each microservice as a topology node, obtaining the topology information of the multi-microservice system; Querying the patch installation records of each topology node according to the topology information; Extract the three-dimensional features (Major, Minor, SetDepth) of the patches corresponding to each topology node according to the patch installation records of each topology node; where Major is the major version number, Minor is the patch serial number, and SetDepth is the merged patch level; According to the merged patch equivalent conversion mechanism, merge the installation records of sub-patches with dependency relationships to obtain the installation records of the merged patches of each topology node; Based on the three-dimensional features (Major, Minor, SetDepth) of the patches of each topology node, combined with the installation records of the merged patches of each topology node and the current patch installation status, determine whether there are un-installed sub-patches in each topology node.

[0008] As an implementation, the patch installation status is represented by a three-dimensional vector, and the three-dimensional vector is [installed, not installed, implicitly installed]; where implicitly installed means that the sub-patch has been installed.

[0009] As an implementation, the patch installation status is sorted according to the release time series and visually displayed.

[0010] As an implementation, the topology information includes the service identifiers and dependency relationships of each topology node.

[0011] As an implementation, the merged patch equivalent conversion mechanism is: the merged patch is logically equivalent to the installation records of all sub-patches in the merged patch.

[0012] As an implementation, use a hash table to determine whether sub-patches have dependency relationships.

[0013] As an implementation, when there are un-installed sub-patches in a certain topology node, it is determined that the system versions of each topology node are inconsistent; when there are no installed sub-patches in all topology nodes, it is determined that the system versions of each topology node are consistent.

[0014] The second aspect of the present invention provides a system version verification device compatible with multiple loads.

[0015] In one or more embodiments, a system version verification device compatible with multiple loads includes: A topology information acquisition module, which is used to obtain the topology information of a multi-microservice system with each microservice as a topology node; A patch installation record query module, which is used to query the patch installation records of each topology node according to the topology information; A three-dimensional feature extraction module, which is used to extract the (Major, Minor, SetDepth) three-dimensional features of the patches corresponding to the topological nodes according to the patch installation records of each topological node; where Major is the major version number, Minor is the patch serial number, and SetDepth is the merged patch level; A patch merging module, which is used to merge the installation records of sub-patches with dependency relationships according to the merged patch equivalent conversion mechanism to obtain the installation records of the merged patches of each topological node; A patch comparison module, which is used to judge whether there are un-installed sub-patches in each topological node based on the (Major, Minor, SetDepth) three-dimensional features of the patches of each topological node, combined with the installation records of the merged patches of each topological node and the current patch installation status.

[0016] The third aspect of the present invention provides a computer-readable storage medium.

[0017] A computer-readable storage medium, on which a computer program is stored, and when the program is executed by a processor, it implements the steps in the multi-load compatible system version verification method as described above.

[0018] The fourth aspect of the present invention provides a computer program product.

[0019] A computer program product, including computer programs / instructions, and when the computer programs / instructions are executed by a processor, it implements the steps in the multi-load compatible system version verification method as described above.

[0020] The fifth aspect of the present invention provides an electronic device.

[0021] An electronic device, including a memory, a processor, and a computer program stored on the memory and executable on the processor, and when the processor executes the program, it implements the steps in the multi-load compatible system version verification method as described above.

[0022] Compared with the prior art, the beneficial effects of the present invention are: (1) By constructing the (Major, Minor, SetDepth) three-dimensional features as the unique features of the patch installation records of each topological node in the multi-load architecture environment, and according to the merged patch equivalent conversion mechanism, merging the installation records of sub-patches with dependency relationships, the present invention improves the patch comparison accuracy in complex environments, considers the differences between patches of topological nodes in the multi-microservice or multi-load architecture environment, and achieves the effect of accurately locating the root cause of system version inconsistency.

[0023] (2) The present invention represents the patch installation status by a three-dimensional vector of [installed, not installed, implicitly installed]. The dynamic difference matrix engine can accurately identify the version differences of complex environments and complex patches between different nodes, and reduces the time-consuming for patch troubleshooting by judging whether sub-patches have dependencies through a hash table, improving the efficiency of patch comparison and processing.

[0024] (3) The visualization of the patch installation status of the topological nodes of the present invention can reduce the troubleshooting cost of maintenance personnel, and its automated comparison and deployment reduce the need for manual operations, reducing the possibility of human errors. Maintenance personnel can quickly understand which systems need to be updated through automated tools, so as to arrange maintenance plans more efficiently. Brief Description of the Drawings

[0025] The attached drawings forming a part of the present invention are used to provide a further understanding of the present invention. The schematic embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation of the present invention.

[0026] Figure 1 It is a flowchart of a method for verifying system versions compatible with multiple loads according to an embodiment of the present invention; Figure 2 It is a schematic diagram of a scenario for verifying system versions compatible with multiple loads according to an embodiment of the present invention; Figure 3 It is a schematic structural diagram of a device for verifying system versions compatible with multiple loads according to an embodiment of the present invention; Figure 4 It is a schematic diagram of an electronic device according to an embodiment of the present invention; Figure 5 It is a display of comparison results according to an embodiment of the present invention. Detailed Embodiments

[0027] The present invention will be further described below in conjunction with the drawings and embodiments.

[0028] It should be noted that the following detailed description is illustrative and is intended to provide further explanation of the present invention. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by those of ordinary skill in the technical field to which the present invention belongs.

[0029] It should be noted that the terms used herein are only for describing specific embodiments and are not intended to limit the exemplary embodiments according to the present invention. As used herein, unless the context clearly indicates otherwise, the singular form is also intended to include the plural form. In addition, it should be understood that when the terms "comprising" and / or "including" are used in this specification, they indicate the presence of features, steps, operations, devices, components, and / or combinations thereof.

[0030] Term Explanation: ERP: Enterprise Resource Planning, an enterprise resource planning system.

[0031] Microservices: A style of architecture that advocates developing a single application as a set of small services, each running in its own process and communicating with each other using lightweight mechanisms.

[0032] Topological Node: Refers to the specific applications (program files, jar packages, html, etc.) and database instances that make up a microservice, which is the smallest unit for program operation. A single application node and a single database node can form the simplest microservice.

[0033] Patch: Refers to a small software package or update file used to repair or improve the functions of a microservice, usually containing code changes or configuration updates.

[0034] Patch Module: Corresponding to a functional module, it is an attribute of a patch used to mark the specific functional module it maintains. A patch module can include application components (such as JAR packages, web scripts, etc.) and database changes (such as table structures, table data). Multiple Loads: An architectural description characterized by replicating a certain microservice or a certain topological node to ensure system reliability.

[0035] Figure 1 It is a schematic flowchart of a system version verification method compatible with multiple loads in an embodiment of the present invention. As Figure 1 shown, the system version verification method compatible with multiple loads in this embodiment may include the following steps S101 to S105.

[0036] S101: Taking each microservice as a topological node, obtain the topological information of the multi-microservice system.

[0037] Step S101 is a topology awareness step. Specifically, each microservice in the ERP system will automatically register its topological information with the central registration center when starting up. The topological information includes the service identifiers and dependencies of each topological node. As Figure 2 the system in [description] includes Microservice 1 and Microservice 2. Instance 1 is configured in Microservice 1, and Instances 2 and 3 are configured in Microservice 2. Among them, the patch records of Instances 1, 2, and 3 are Patch Installation Record 1, Patch Installation Record 2, and Patch Installation Record 3 respectively.

[0038] S102: According to the topological information, query the patch installation records of each topological node.

[0039] The patch installation records here include, but are not limited to, basic information, status tracking, system information, operation records, etc.; among them, the basic information includes Name / Number: such as the KB number of Microsoft or the unique identifier provided by the manufacturer, used to accurately match the patch; Description: briefly describe the vulnerabilities fixed by the patch, new functions or optimization items; Release Date: the date when the manufacturer officially releases the patch, used to judge the timeliness of the patch; Installation Information includes Installation Date: records the time when the patch is actually deployed to the system, facilitating the tracking of the update cycle; Installer: the person responsible for performing the operation, used for auditing and problem tracing; Applicable System: marks the operating system, software version or hardware environment supported by the patch.

[0040] The status tracking includes the installation status and dependency relationships; Among them, the installation status includes results marked as "Installed", "Failed", "Rolled Back", etc., and the final status needs to be clarified; and the Reason for Failure: records the error log (such as missing dependencies, insufficient space, etc.), facilitating subsequent troubleshooting; The dependency relationships include Pre - requisite Patches: a list of dependent patches that must be deployed before installation, to avoid failure caused by omission; and Conflict Records: conflict information with the standard classes of second - development code or private packages, used for problem tracing.

[0041] The system information includes the server / device identifier, which is used to record the server name, IP address or unique device number, to clarify the patch deployment target.

[0042] The operation records are used to save the key operation steps and command - line records (such as wmic qfe list or yum list installed) during the installation process.

[0043] S103: Extract the three - dimensional features (Major, Minor, SetDepth) of the patches corresponding to each topology node according to the patch installation records of each topology node; among them, Major is the major version number, Minor is the patch serial number, and SetDepth is the merged patch level.

[0044] The major version number here is the patch module version, used to identify the modular classification to which the patch function belongs. For example, security patches, performance optimization patches, etc. can be assigned different Major values; different Major values are used to distinguish the patch function types, avoiding cross - module patch conflicts; combined with the module version iteration strategy, ensuring the compatibility of the patch with the target system; The patch serial number is the patch ID, usually generated by the manufacturer or development team according to rules (such as hash value, serial number); through the Minor value, the release time, content and dependency relationships of the patch can be quickly located; combined with the database query mechanism, duplicate or conflicting patches can be identified (such as multiple deployments of patches with the same Minor value).

[0045] Merge patch level: The level value calculated recursively based on sub-patch information, reflecting the depth of the patch in the dependency chain.

[0046] The functions of the merge patch level are as follows: Dependency relationship optimization: Determine the patch installation order through level calculation to avoid installation failures caused by missing pre-dependencies; Priority control: Patches with high SetDepth values (such as base library patches) are deployed first to ensure the stability of underlying functions.

[0047] Implement a globally unique identifier for patches through a three-dimensional feature combination (such as Major = 2, Minor = 015, SetDepth = 3) to reduce management complexity; The SetDepth level supports dynamic updates (such as recalculating when new sub-patches are added) to adapt to complex patch dependency scenarios; The three-dimensional feature system (Major, Minor, SetDepth) can be adapted to system patch management tools such as Windows and Linux, as well as enterprise-level patch distribution platforms.

[0048] S104: According to the merge patch equivalent conversion mechanism, merge the installation records of sub-patches with dependency relationships to obtain the installation records of merge patches for each topological node.

[0049] Among them, the merge patch equivalent conversion mechanism is: The merge patch is logically equivalent to the installation records of all sub-patches in the merge patch. It can be understood that the installation of all sub-patches in this merge patch is equivalent to only installing the merge patch.

[0050] In this embodiment, a hash table is used to determine whether sub-patches have dependency relationships.

[0051] Use a hash table to establish a logically equivalent relationship model between the merge patch and the sub-patch set, greatly reducing the search time-consuming and achieving a logically equivalent determination of the installation status of the merge patch and the sub-patch.

[0052] In the specific implementation process, the hash table key-value mapping design includes: Key: The unique identifier of the merge patch (based on the three-dimensional feature system Major, Minor, SetDepth); Value: The hash digest of the sub-patch set (such as the unique signature generated by the consistent hashing algorithm); In some alternative embodiments, open addressing or chaining hash structures are used to ensure the uniqueness of the key values of the merge patch.

[0053] When the hash digest of the merged patch is consistent with that of the sub-patch set, it is determined that the two are logically equivalent; when the installation status of the sub-patch changes, the hash digest of the parent merged patch is recursively updated.

[0054] In some alternative embodiments, the MurmurHash or SHA-256 algorithm is used to generate the hash values of the merged patch identifier and the sub-patch set, reducing the collision probability. The installation status of the sub-patch (installed / not installed / failed) is stored in the hash table value and quickly read through bitwise operations.

[0055] In some other embodiments, the hash values of the sub-patch set can be pre-generated before patch deployment, reducing the runtime computational overhead. The batch query feature of the hash table can also be utilized to simultaneously determine the equivalence relationship between multiple merged patches and the sub-patch set.

[0056] This embodiment realizes the rapid logical equivalence determination of the merged patch and the sub-patch set through the efficient addressing of the hash table and the logical digest technology, combined with the dynamic update and conflict handling mechanisms, significantly optimizing the performance and reliability of the patch management system.

[0057] S105: Based on the (Major, Minor, SetDepth) three-dimensional features of the patches of each topology node, combined with the installation records of the merged patches of each topology node and the current patch installation status, determine whether there are un-installed sub-patches in each topology node.

[0058] Among them, the patch installation status is represented by a three-dimensional vector, and the three-dimensional vector is [installed, not installed, implicitly installed]; among them, implicit installation means that the sub-patch is installed.

[0059] The patch installation status is sorted according to the release time sequence and visually displayed, as Figure 5 shown.

[0060] Specifically, when there are un-installed sub-patches in a certain topology node, it is determined that the system versions of each topology node are inconsistent; when there are no installed sub-patches in all topology nodes, it is determined that the system versions of each topology node are consistent.

[0061] This embodiment constructs the (Major, Minor, SetDepth) three-dimensional feature as the unique feature of the patch installation records of each topology node in the multi-load architecture environment, and according to the merged patch equivalence conversion mechanism, merges the installation records of the sub-patches with dependency relationships, improving the patch comparison accuracy in complex environments, considering the differences in patches between topology nodes in the multi-microservice or multi-load architecture environment, and achieving the effect of accurately locating the root cause of inconsistent system versions.

[0062] In this embodiment, the patch installation status is represented by a three-dimensional vector of [installed, not installed, implicitly installed]. The dynamic difference matrix engine can accurately identify the version differences of complex environments and complex patches between different nodes, and reduce the time-consuming of patch troubleshooting by judging whether sub-patches have dependencies through a hash table, improving the efficiency of patch comparison and processing.

[0063] As Figure 3 shown, the multi-load compatible system version verification device provided by the embodiment of the present invention can be implemented in software. The multi-load compatible system version verification device 300 includes the following software modules: a topology information acquisition module 301, a patch installation record query module 302, a three-dimensional feature extraction module 303, a patch merging module 304, and a patch comparison module 305.

[0064] The functions of each software module in the multi-load compatible system version verification device 300 are introduced below: The topology information acquisition module 301 is used to acquire the topology information of the multi-microservice system with each microservice as a topology node.

[0065] Specifically, each microservice of the ERP system will automatically register its topology information with the central registration center when starting up. The topology information includes the service identifier and dependency relationship of each topology node. As Figure 2 shown in the figure, the system includes microservice 1 and microservice 2. Instance 1 is configured in microservice 1, and instances 2 and 3 are configured in microservice 2; among them, the patch records of instances 1, 2, and 3 are patch installation records 1, patch installation record 2, and patch installation record 3 respectively.

[0066] The patch installation record query module 302 is used to query the patch installation records of each topology node according to the topology information.

[0067] The patch installation records here include but are not limited to basic information, status tracking, system information, operation records, etc.; among them, the basic information includes name / number: such as the KB number of Microsoft or the unique identifier provided by the manufacturer, which is used to accurately match the patch; description: briefly describe the vulnerabilities fixed by the patch, new functions or optimization items; release date: the date when the manufacturer officially releases the patch, which is used to judge the timeliness of the patch; the installation information includes installation date: records the time when the patch is actually deployed to the system, which is convenient for tracking the update cycle; installer: the person responsible for performing the operation, which is used for auditing and problem tracing; applicable system: indicates the operating system, software version or hardware environment supported by the patch.

[0068] The status tracking includes installation status and dependency relationship; Among them, the installation status includes results such as marked "installed", "failed", "rolled back", etc., and the final status needs to be clarified; and the reason for failure: record error logs (such as missing dependencies, insufficient space, etc.) for subsequent troubleshooting. Dependency relationships include pre-patch: a list of dependency patches that must be deployed before installation to avoid failure due to omission; and conflict records: conflict information with standard classes of second development code or private packages for problem tracing.

[0069] System information includes server / device identification, which is used to record the server name, IP address, or unique device number to clarify the patch deployment target.

[0070] Operation records are used to save key operation steps and command-line records during the installation process (such as wmic qfe list or yum list installed).

[0071] The three-dimensional feature extraction module 303 is used to extract the (Major, Minor, SetDepth) three-dimensional features of the patches corresponding to each topological node according to the patch installation records of each topological node; among them, Major is the major version number, Minor is the patch serial number, and SetDepth is the merged patch level.

[0072] The major version number here is the patch module version, which is used to identify the modular classification to which the patch function belongs. For example, security patches, performance optimization patches, etc. can be assigned different Major values; different patch function types are distinguished by Major to avoid cross-module patch conflicts; combined with the module version iteration strategy, ensure the compatibility of the patch with the target system; The patch serial number is the patch ID, usually generated by the manufacturer or development team according to rules (such as hash value, serial number); the release time, content, and dependency relationships of the patch can be quickly located through the Minor value; combined with the database query mechanism, identify duplicate or conflicting patches (such as multiple deployments of patches with the same Minor value).

[0073] Merged patch level: a hierarchical value calculated recursively based on sub-patch information, reflecting the depth of the patch in the dependency chain.

[0074] The role of the merged patch level is: Dependency relationship optimization: Determine the patch installation order through hierarchical calculation to avoid installation failure due to missing pre-dependencies; Priority control: Patches with high SetDepth values (such as basic library patches) are deployed first to ensure the stability of underlying functions.

[0075] The global unique identifier of the patch is achieved through a three-dimensional feature combination (e.g., Major = 2, Minor = 015, SetDepth = 3), reducing the management complexity; the SetDepth level supports dynamic updates (e.g., recalculating when adding sub-patches) to adapt to complex patch dependency scenarios; the three-dimensional feature system (Major, Minor, SetDepth) can be adapted to system patch management tools such as Windows and Linux, as well as enterprise-level patch distribution platforms.

[0076] The patch merging module 304 is used to merge the installation records of sub-patches with dependency relationships according to the merging patch equivalent conversion mechanism to obtain the installation records of the merged patches for each topology node.

[0077] Among them, the merging patch equivalent conversion mechanism is: the merging patch is logically equivalent to the installation records of all sub-patches in the merging patch. It can be understood that the installation of all sub-patches in this merging patch is equivalent to only installing the merging patch.

[0078] In this embodiment, a hash table is used to determine whether sub-patches have dependency relationships.

[0079] A logical equivalence relationship model between the merged patch and the sub-patch set is established using a hash table, greatly reducing the search time-consuming and realizing the logical equivalence determination of the installation status of the merged patch and the sub-patch.

[0080] In the specific implementation process, the hash table key-value mapping design includes: Key: The unique identifier of the merged patch (based on the three-dimensional feature system Major, Minor, SetDepth); Value: The hash digest of the sub-patch set (e.g., the unique signature generated by the consistent hashing algorithm); In some alternative embodiments, open addressing or chaining hash structure is adopted to ensure the uniqueness of the key-value of the merged patch.

[0081] When the hash digest of the merged patch is consistent with that of the sub-patch set, it is determined that the two are logically equivalent; when the installation status of the sub-patch changes, the hash digest of the parent merged patch is recursively updated.

[0082] In some alternative embodiments, algorithms such as MurmurHash or SHA-256 are used to generate the hash values of the merged patch identifier and the sub-patch set, reducing the collision probability. The installation status (installed / uninstalled / failed) of the sub-patch is stored in the hash table value and read quickly through bit operations.

[0083] In some other embodiments, the hash values of the sub-patch sets can be pre-generated before patch deployment to reduce the runtime computational overhead. The batch query feature of the hash table can also be utilized to simultaneously determine the equivalence relationships between multiple merged patches and the sub-patch sets.

[0084] In this embodiment, through the efficient addressing of the hash table and the logical digest technology, combined with the dynamic update and conflict handling mechanisms, a fast logical equivalence determination between the merged patches and the sub-patch sets is achieved, significantly optimizing the performance and reliability of the patch management system.

[0085] The patch comparison module 305 uses the three-dimensional features (Major, Minor, SetDepth) based on the patches of each topology node, combined with the installation records of the merged patches of each topology node and the current patch installation status, to determine whether there are un-installed sub-patches in each topology node.

[0086] Among them, the patch installation status is represented by a three-dimensional vector, and the three-dimensional vector is [installed, not installed, implicitly installed]; where implicitly installed means the sub-patch has been installed.

[0087] The patch installation status is sorted according to the release time sequence and visually displayed, as Figure 5 shown.

[0088] Specifically, when there are un-installed sub-patches in a certain topology node, it is determined that the system versions of each topology node are inconsistent; when there are no installed sub-patches in all topology nodes, it is determined that the system versions of each topology node are consistent.

[0089] It should be noted here that, Figure 3 each module in the multi-load compatible system version verification device in Figure 1 corresponds one by one to each step in the multi-load compatible system version verification method in

[0090] and their specific implementation processes are the same, so they will not be repeated here. Figure 4 is the schematic composition structure diagram of the electronic device provided by the embodiment of the present invention. It can be understood that, Figure 4 only the exemplary structure of the electronic device is shown, rather than all the structures. According to needs, some or all of the shown structures can be implemented.

[0091] The electronic device provided by an embodiment of the present invention includes: at least one processor 401, a memory 402, a user interface 403, and at least one network interface 404. Each component in the multi-load compatible system version verification device is coupled together through a bus system 405. It can be understood that the bus system 405 is used to implement the connection and communication between these components. In addition to the data bus, the bus system 405 also includes a power bus, a control bus, and a status signal bus. However, for the sake of clear illustration, in Figure 4 all kinds of buses are labeled as the bus system 405.

[0092] Among them, the user interface 403 may include a display, a keyboard, a mouse, a trackball, a click wheel, a button, a touchpad, or a touch screen, etc.

[0093] It can be understood that the memory 402 may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. The memory 402 in the embodiment of the present invention can store data to support the operation of the terminal. Examples of these data include: any computer program for operating on the terminal, such as an operating system and application programs. Among them, the operating system contains various system programs, such as a framework layer, a core library layer, a driver layer, etc., for implementing various basic services and processing hardware-based tasks. The application programs may include various application programs.

[0094] In some embodiments, the multi-load compatible system version verification device 300 provided by the embodiment of the present invention can be implemented in a combination of software and hardware. As an example, the multi-load compatible system version verification device 300 provided by the embodiment of the present invention may be a processor in the form of a hardware decoding processor, which is programmed to execute the multi-load compatible system version verification method provided by the embodiment of the present invention. For example, a processor in the form of a hardware decoding processor may employ one or more application specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field programmable gate arrays (FPGAs), or other electronic components.

[0095] As an example, the processor 401 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among them, the general-purpose processor can be a microprocessor or any conventional processor, etc.

[0096] As an example of the multi-load compatible system version verification device 300 provided by the embodiments of the present invention implemented in hardware, the device provided by the embodiments of the present invention can be directly implemented by a processor 401 in the form of a hardware decoding processor. For example, it can be implemented by one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components to execute the multi-load compatible system version verification method provided by the embodiments of the present invention.

[0097] The memory 402 in the embodiments of the present invention is used to store various types of data to support the operation of the multi-load compatible system version verification device 300, or store the program code for executing Figure 1 the method shown. Examples of these data include: any executable instructions for operating on the multi-load compatible system version verification device, such as executable instructions. The program implementing the multi-load compatible system version verification method of the embodiments of the present invention can be included in the executable instructions.

[0098] In particular, according to the embodiments of the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments of the present application include a computer program product that includes a computer program carried on a computer-readable medium, and the computer program contains the program code for executing Figure 1 the method shown. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part, and / or installed from a removable medium. When the computer program is executed by the central processing unit, it executes various functions defined in the device of the present application.

[0099] Among them, Figure 1The computer program instructions corresponding to the methods shown can also be stored in a computer-readable memory capable of guiding a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory produce a manufactured article including instruction means, and the instruction means implements the processes Figure 1 one process or multiple processes and / or blocks Figure 1 the functions specified in one block or multiple blocks.

[0100] The foregoing is only a preferred embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, the present invention may have various changes and modifications. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included within the protection scope of the present invention.

Claims

1. A system version verification method compatible with multiple loads, characterized in that Including: Taking each microservice as a topology node to obtain the topology information of the multi-microservice system; Querying the patch installation records of each topology node according to the topology information; Extracting the three-dimensional features (Major, Minor, SetDepth) of the patches corresponding to the topology nodes according to the patch installation records of each topology node; where Major is the major version number, Minor is the patch serial number, and SetDepth is the merged patch level; According to the merged patch equivalence conversion mechanism, merging the installation records of sub-patches with dependencies to obtain the installation records of the merged patches of each topology node; Based on the three-dimensional features (Major, Minor, SetDepth) of the patches of each topology node, combined with the installation records of the merged patches of each topology node and the current patch installation status, determining whether there are un-installed sub-patches in each topology node.

2. The method for verifying system versions compatible with multiple loads according to claim 1, wherein, The patch installation status is represented by a three-dimensional vector, and the three-dimensional vector is [installed, not installed, implicitly installed]; where implicitly installed means that the sub-patch has been installed; Or / and the patch installation status is sorted according to the release time series and visually displayed.

3. The method for verifying system versions compatible with multiple loads according to claim 1, wherein, The topology information includes the service identifiers and dependencies of each topology node.

4. The method for verifying system versions compatible with multiple loads according to claim 1, wherein The merged patch equivalence conversion mechanism is: the merged patch is logically equivalent to the installation records of all sub-patches in the merged patch.

5. The method for verifying system versions compatible with multiple loads according to claim 1, characterized in that Judging whether sub-patches have dependencies through a hash table.

6. The method for verifying system versions compatible with multiple loads according to claim 1, wherein, When there are un-installed sub-patches in a certain topology node, it is judged that the system versions of each topology node are inconsistent; when there are no installed sub-patches in all topology nodes, it is judged that the system versions of each topology node are consistent.

7. A system version verification device compatible with multiple loads, characterized in that, Including: A topology information acquisition module, which is used to take each microservice as a topology node to obtain the topology information of the multi-microservice system; A patch installation record query module, which is used to query the patch installation records of each topology node according to the topology information; A three-dimensional feature extraction module, which is used to extract the three-dimensional features (Major, Minor, SetDepth) of the patches corresponding to the topology nodes according to the patch installation records of each topology node; where Major is the major version number, Minor is the patch serial number, and SetDepth is the merged patch level; A patch merging module, which is used to merge the installation records of sub-patches with dependencies according to the merged patch equivalence conversion mechanism to obtain the installation records of the merged patches of each topology node; A patch comparison module, which is used to judge whether there are un-installed sub-patches in each topology node based on the three-dimensional features (Major, Minor, SetDepth) of the patches of each topology node, combined with the installation records of the merged patches of each topology node and the current patch installation status.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by a processor, it implements the steps in the multi-load compatible system version verification method described in any one of claims 1-6.

9. A computer program product, comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by a processor, it implements the steps in the multi-load compatible system version verification method described in any one of claims 1-6.

10. An electronic device, comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps in the multi-load compatible system version verification method described in any one of claims 1-6.

Images