Service dependency relationship efficient management and query method based on dynamic bit mask

Abstract

The invention provides a service dependency relationship efficient management and query method based on a dynamic bit mask, which comprises the following steps of: distributing a unique service bit identifier for each service, recording a mapping relationship between the service and the service bit identifier to a service bit mapping table, and progressively increasing the service bit identifier according to a registration sequence of the service; calling a service bit identifier of a service on which the current service depends from the service bit mapping table, performing bit operation based on the service bit identifier of the depended service to obtain a dependency relationship variable, and storing the dependency relationship variable into a dependency relationship field of the current service, the method has the advantages of high storage space efficiency, convenience in complex query and low overall complexity.

Description

Technical Field

[0001] This application relates to the field of data, and in particular to an efficient method for managing and querying service dependencies based on dynamic bitmasks. Background Technology

[0002] With the large-scale application of services and cloud-native architectures, the number of services in distributed systems is exploding. Services form complex and dynamically changing dependency networks through synchronous calls, asynchronous messaging, data dependencies, and other methods. For example, the order placement process of an e-commerce platform may involve the coordinated calls of dozens of services, such as order services, payment services, inventory services, user services, and logistics services. Each service may also depend on basic support services such as caching services, database services, and configuration centers. This multi-dimensional and multi-level dependency network is core to ensuring the complete realization of system functions, but it also places extremely high demands on dependency management. Clear, accurate, and efficient management of these dependencies (e.g., knowing explicitly that "service A calls services B, C, and D") is crucial for system stability assurance, rapid fault location, change impact analysis, capacity planning, and other operational governance activities.

[0003] Currently, the mainstream methods for managing service dependencies in the industry and their shortcomings are as follows: Method 1: Relational Database-Based Association Table Method The implementation involves creating a "service dependency table" containing two fields: the main service ID and the dependent service ID. Each dependency pair is stored as one record. For example, if service A depends on services B and C, two records will be generated in the table: (A, B) and (A, C). Dependency queries are performed using SQL syntax such as JOIN, IN, and INTERSECT. This approach has drawbacks: 1. Low storage and I / O efficiency: A service that depends on N services will generate N records. For large systems (hundreds or thousands of services), the table's data volume is O(n^2). 2 1. Rapid growth, consuming large amounts of storage, and high I / O load during full or join queries. 2. Poor performance of complex queries: When performing multi-condition queries such as "querying all main services that depend on several specific services", complex SQL JOIN and INTERSECT operations are required, resulting in slow response under large data volumes and difficulty in meeting real-time operation and maintenance analysis needs. 3. High maintenance costs: Every change in dependency relationships (addition, deletion) corresponds to an INSERT or DELETE operation in the database, putting continuous pressure on the database in high-frequency release scenarios.

[0004] Method 2. Graph Database-Based Method: The implementation treats services as nodes and dependencies as edges, using a graph database for storage and traversal queries. Node attributes include service ID, service name, and status, while edge attributes include dependency type, creation time, and interaction frequency. Dependency queries are implemented using graph traversal algorithms. This approach has drawbacks: it introduces an additional technology stack through graph traversal, leading to higher operational complexity, learning costs, and migration costs. Furthermore, graph databases may not perform as well as mature relational database solutions in handling high-concurrency queries of large-scale edge relationships (such as fast filtering based on service identifiers).

[0005] In summary, existing technologies struggle to achieve a good balance between storage efficiency, performance of complex queries (especially multi-condition combined queries), and overall system complexity and operation and maintenance costs when managing massive service dependencies, thus hindering the operation and maintenance efficiency and intelligent governance level of large-scale distributed systems. Summary of the Invention

[0006] This application provides a method for efficient management and querying of service dependencies based on dynamic bitmasks, which combines the advantages of high storage space efficiency, ease of complex queries, and low overall complexity.

[0007] In a first aspect, embodiments of this application provide a service dependency management method based on dynamic bitmasks, comprising the following steps: Each service is assigned a unique service bit identifier, and the mapping relationship between services and service bit identifiers is recorded in the service bit mapping table, wherein the service bit identifier is incremented according to the registration order of services; Retrieve the service bit identifier of the service that the current service depends on from the service bit mapping table, perform bit operations based on the service bit identifier of the dependent service to obtain the dependency variable, and store the dependency variable in the dependency field of the current service.

[0008] Secondly, embodiments of this application provide a service dependency query method based on dynamic bitmasks, including the following steps; Each service is assigned a unique service bit identifier, and the mapping relationship between services and service bit identifiers is recorded in the service bit mapping table, wherein the service bit identifier is incremented according to the registration order of services; Retrieve the service bit identifier of the service that the current service depends on from the service bit mapping table, perform bit operations based on the service bit identifier of the dependent service to obtain the dependency variable, and store the dependency variable in the dependency field of the current service. Dependency query statements are constructed based on the query content, where the query content records the target service and the query method; The dependency query statement retrieves the dependency fields of all services to obtain the query results.

[0009] The main contributions and innovations of this invention are as follows: 1. By encoding all the dependencies of a single service into a compact dependency variable, an extremely high data compression rate is achieved. Relationships that might otherwise require dozens of database records are compressed into a single field, significantly reducing storage space usage and I / O overhead.

[0010] 2. Leveraging the atomicity and extremely high speed of bitwise operations, it enables millisecond-level dependency queries. Especially for multi-condition combined queries such as "finding all services that depend on several other services", no table joins or intersection calculations are required. It can be completed with just one bitwise AND operation, which improves performance by several orders of magnitude compared to traditional relational methods and can perfectly support real-time operation and maintenance analysis.

[0011] 3. Simply adding a dependency field to the service metadata table is enough to record all its dependencies, eliminating the need to maintain additional association tables and reducing the complexity and maintenance cost of the system data model.

[0012] 4. Through dynamic service identifier allocation and optional "bitmask grouping" mechanism, it can theoretically support dependency management of thousands or even tens of thousands of services and flexibly adapt to the continuous growth of service scale.

[0013] 5. It can work with existing service registries (such as Nacos, Eureka, Consul) and relational databases without overhauling the existing architecture, resulting in low implementation costs.

[0014] Details of one or more embodiments of this application are set forth in the following drawings and description to make other features, objects and advantages of this application more readily apparent. Attached Figure Description

[0015] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a flowchart illustrating a service dependency management method based on dynamic bitmasks according to an embodiment of this application.

[0016] Figure 2 This is a flowchart illustrating the service dependency query method based on dynamic bitmask according to an embodiment of this application.

[0017] Figure 3 This is a logical schematic diagram of a service dependency query method based on dynamic bitmasks according to an embodiment of this application.

[0018] Figure 4This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0019] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of one or more embodiments of this specification as detailed in the appended claims.

[0020] It should be noted that the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification in other embodiments. In some other embodiments, the methods may include more or fewer steps than described in this specification. Furthermore, a single step described in this specification may be broken down into multiple steps in other embodiments; and multiple steps described in this specification may be combined into a single step in other embodiments.

[0021] Example 1 like Figure 1 As shown, this solution provides a service dependency management method based on dynamic bitmasks, including the following steps: Each service is assigned a unique service bit identifier, and the mapping relationship between services and service bit identifiers is recorded in the service bit mapping table, wherein the service bit identifier is incremented according to the registration order of services; Retrieve the service bit identifier of the service that the current service depends on from the service bit mapping table, perform bit operations based on the service bit identifier of the dependent service to obtain the dependency variable, and store the dependency variable in the dependency field of the current service.

[0022] In other words, this solution encodes the dependencies between services into dependency variables using bitwise operations, thereby significantly reducing storage space and resulting in an exponential optimization of storage efficiency. Specifically, a service that depends on N services does not need to store N related records; only one integer field is needed to fully represent all dependencies, resulting in extremely high data compression. For large systems containing thousands of services, the original O(n) data compression efficiency can be reduced significantly. 2 The storage data volume, which had been growing at the O(n) level, has been reduced to the O(n) level, significantly reducing the database disk usage. In addition, subsequent queries or updates of dependencies also only require reading and writing individual fields, which improves the response speed of data access.

[0023] In this scheme, the service bit identifier adopts a design that is "unique and continuous, and increments in the order of registration". Its core advantages are: first, it can make full use of every binary bit of the bitmask, avoid the waste of idle bits caused by skipping numbers, and maximize the carrying capacity of a single dependency variable; second, when calculating the dependency relationship in the future, the identifier can be directly converted through standard bit operations without additional mapping conversion or offset calculation, which simplifies the operation logic and reduces the probability of error.

[0024] Specifically, in the service registry or a separate metadata management service, whenever a new service is registered, the system automatically assigns it a unique, consecutive integer as its service identifier. This service identifier starts from 0 and increments, and the system maintains a service identifier mapping table to record the mapping relationship between services and service identifiers. An example of the mapping is as follows: User Service -> SBI=0 OrderService -> SBI=1 ProductService -> SBI=2.

[0025] In some embodiments, the value of the service bit identifier is a continuous integer ranging from 0 to 2047, so that a single 64-bit long integer dependency variable can be used to fully cover all dependency encoding requirements.

[0026] In some embodiments, the service registry or independent metadata management service acts as the sole allocation entity, allocating service bit identifiers through atomic auto-increment operations to avoid identifier conflicts caused by parallel allocation across multiple nodes in a distributed environment.

[0027] In some embodiments, the dependency variable is a long integer variable. Essentially, this involves converting all dependent services into binary identifiers using bitwise operations and then converting those binary identifiers into integers, using these integers as the dependency variable. It should be noted that the dependency variable in this scheme is essentially an instance of a bitmask. The binary identifier indicates that the current service depends on the service to which the corresponding bit identifier belongs; a value of 0 indicates no dependency.

[0028] Correspondingly, the dependency variable of the current service is initialized so that the initial value of the dependency variable is 0. For the service bit identifier of each dependent service, a left shift operation is performed to convert the service bit identifier of the dependent service into a binary identifier with the corresponding service bit identifier position 1 and the rest positions 0. If there is only one dependent service, the converted binary identifier is converted into an integer dependency variable. If there are multiple dependent services, the multiple binary identifiers are combined into an integer by bitwise OR operation as a dependency variable, and this dependency variable is assigned to the dependency field of the current service.

[0029] It should be noted that the left shift bits in the binary identifier represent the service bit identifier of the service being relied upon.

[0030] In some embodiments, the dependency variable is assigned to the dependency field of the metadata table of the current service.

[0031] It should be noted that when performing a bitwise OR operation on multiple binary identifiers, the operation rule is: if any one of the multiple binary identifiers is 1, the result bit will be 1.

[0032] In some embodiments, when performing bitwise operations on the service bit identifier, the output result is specified as a long integer variable.

[0033] For example, when it is necessary to record or update the dependencies of a main service (such as OrderService, whose SBI=1) (assuming it depends on UserService (SBI=0) and ProductService (SBI=2)), the system performs the following operations: Initialize a dependency variable `dependencyMask` with a value of 0; For each dependent service SBI, perform a bitwise operation: dependencyMask = dependencyMask |(1L< <SBI): (1L<<0) yields the binary identifier ...0001; (1L<<2) yields the binary identifier ...0100; Performing a bitwise OR operation on the two results in ...0101, which is the decimal number 5. The decimal number 5 is used as the dependency variable. The calculated dependencyMask (5 in this example) is stored in the dependency field DEPENDENCY_MASK of the metadata table of the main service.

[0034] In some embodiments, when the value of the Service Bit Identifier (SBI) exceeds the single-word length coverage range (e.g., exceeding 2047), multiple dependency variables are designed for the current service group, such as DEPENDENCY_MASK_1 and DEPENDENCY_MASK_2. SBI=0~2047 corresponds to DEPENDENCY_MASK_1, and SBI=2048~4095 corresponds to DEPENDENCY_MASK_2. The grouping of the dependency variables is calculated by dividing SBI by 2048.

[0035] Furthermore, when it is necessary to update the current service dependencies, this service dependency management method based on dynamic bitmasks includes the following steps: If the current service's dependencies require the addition of a new service, the service bit identifier of the new service is retrieved from the service bit mapping table, the dependency variable of the current service is retrieved, and bitwise operations are performed on the service bit identifier of the new service to obtain the new mask. A bitwise OR operation is performed on the dependency variable and the new mask to obtain a new dependency variable, and the new dependency variable is updated in the dependency field of the current service. If the current service's dependencies require the deletion of a service, the dependency variable of the current service is retrieved, and a bitwise operation is performed on the service identifier of the deleted service to obtain the deletion mask. A bitwise AND operation is then performed on the dependency variable and the deletion mask to obtain a new dependency variable, and the new dependency variable is updated in the dependency field of the current service.

[0036] In some embodiments, executing an SQL update statement updates the new dependency variable to the dependency field of the current service metadata table, completing the update of deleted or added dependencies.

[0037] In some embodiments, if the current service's dependency requires the addition of a new service, it is first determined whether the new service has a service bit identifier. If the new service does not have a service bit identifier, a unique service bit identifier is assigned to each service, and the mapping relationship between the service and the service bit identifier is updated to the service bit mapping table. Then, the service bit identifier of the new service is retrieved from the service bit mapping table.

[0038] In some embodiments, if the dependency of the current service needs to be deleted, the dependency variable of the current service is retrieved to determine whether the current service has a service that needs to be deleted. If it does not exist, an error is triggered.

[0039] For example, when you need to add a dependency on the Inventory Service (SBI=3) to the OrderService (original mask is 5, binary 0101), perform the following steps: Calculate the new mask for the inventory service: addMask = (1L<<3), the result is ...1000, which is 8; Retrieve the dependency variable of the current service as oldMask, and perform a bitwise OR operation with the new mask: newMask = oldMask | addMask -> 5 | 8 = 13 (binary 1101); Execute the SQL update: UPDATE service_table SET DEPENDENCY_MASK = 13 WHERE service_name = 'OrderService'.

[0040] To remove the dependency of OrderService (original mask 5, binary 0101) on ProductService (SBI=2), perform the following steps: Calculate the removal mask for the service to be deleted: removeMask = ~(1L<<2), where ~(1L<<2) results in ...1111111011 (64-bit). Retrieve the dependency variable of the current service as oldMask, and perform a bitwise AND operation with the deletion mask: newMask = oldMask&removeMask ->13&...11111011 = 9 (binary 1001); Execute the SQL update: UPDATE service_table SET DEPENDENCY_MASK = 9 WHERE service_name = 'OrderService'.

[0041] As described above, this solution assigns a unique Service Bit Identifier (SBI) to each service, incrementing sequentially by registration order. All dependencies of a single service are encoded into a compact integer bitmask (dependency variable) using bitwise operations and stored in a single field of the service metadata table. Leveraging bitwise operations, it achieves millisecond-level responses for single dependencies, multi-dependency joins, and any query, as well as lightweight addition and deletion of dependencies. No additional association tables or new technology stacks are required, significantly optimizing storage efficiency, query performance, and maintenance costs. Furthermore, the bitmask grouping mechanism adapts to service growth and can seamlessly integrate with existing service registries and relational databases, effectively addressing the pain points of traditional association table and graph database methods in managing massive service dependencies.

[0042] Example 2 like Figure 2 As shown, this solution, based on Embodiment 1, provides a service dependency query method based on dynamic bitmasks, including the following steps; Each service is assigned a unique service bit identifier, and the mapping relationship between services and service bit identifiers is recorded in the service bit mapping table, wherein the service bit identifier is incremented according to the registration order of services; Retrieve the service bit identifier of the service that the current service depends on from the service bit mapping table, perform bit operations based on the service bit identifier of the dependent service to obtain the dependency variable, and store the dependency variable in the dependency field of the current service. Dependency query statements are constructed based on the query content, where the query content records the target service and the query method; The dependency query statement retrieves the dependency fields of all services to obtain the query results.

[0043] Since all dependencies in this solution have been converted into dependency variables and written into the dependency fields of the corresponding services, queries only need to query the dependency fields to quickly find the corresponding dependencies, which greatly improves the retrieval effect.

[0044] In some embodiments, the query methods are single dependency query, multi-dependency joint query, and multi-dependency any query, wherein a single dependency query queries services that depend on a single target service, a multi-dependency joint query queries services that depend on at least two target services, and a multi-dependency any query queries services that depend on at least one target service.

[0045] When the query method is a single dependency query, the service bit identifier of the target service is converted into a query bit identifier, and a dependency query statement is constructed based on the query bit identifier and the dependency relationship field. Correspondingly, the dependency query statement performs a bitwise AND operation on the query bit identifier and the dependency relationship field of all services, and takes the service whose bitwise AND operation result is 1 as the query result.

[0046] Specifically, a left shift operation is used to convert the service bit identifier of the target service into a query bit identifier, where the query bit identifier contains only binary numbers whose corresponding positions are 1.

[0047] Furthermore, the dependency query statement performs a bitwise AND operation based on the query bit identifier and the dependency fields of all services. That is, it checks whether the corresponding position of the dependency field of all services is 1 according to the position of the service bit identifier marked in the query bit identifier. If it is 1, it means that the service depends on the target service.

[0048] In other words, the dependency field DEPENDENCY_MASK can be viewed as the binary encoding of the dependent service list. Each target service SBI corresponds to a "position" in the list. The purpose of the dependency query statement constructed in this solution is to find the corresponding "position" through the SBI and quickly check whether the position is marked (i.e., whether it is dependent) using bitwise operations. There is no need to traverse other data throughout the process, which is extremely efficient.

[0049] For example, if the query is "Which services depend on UserService (SBI=0)?", and the target service UserService has SBI=0, then the query bit representation is: 1<<0 = 1 (binary...0001), which means "match the dependency corresponding to SBI=0". The corresponding SQL query statement is: SELECT * FROM service_table WHEREDEPENDENCY_MASK&(1<<0) != 0; Check if the 0th bit of DEPENDENCY_MASK (corresponding to SBI=0) is 1. If it is 1, it means that the service depends on the target service.

[0050] When the query method is a multi-dependency joint query, the service bit identifier of each target service is converted into a query bit identifier, and then the target bit mask is obtained by bitwise OR operation. Based on the target bit mask and the dependency relationship field, a dependency relationship query statement is constructed. Correspondingly, the dependency relationship query statement performs a bitwise AND operation on the target bit mask and the dependency relationship field of all services, and the service whose bitwise AND operation result is the same as the target bit mask is taken as the query result.

[0051] It should be noted that, at this point, a left shift operation needs to be performed on the service bit identifier of each target service to obtain the query bit identifier. Then, a bitwise OR operation is used to aggregate all query bit identifiers into a target bitmask, where the target bitmask is an integer (targetMask). The target bitmask of this scheme essentially contains the decimal values ​​of the service bit identifiers of all target services.

[0052] As mentioned earlier, a left shift operation is used to convert the service bit identifier of the target service into a query bit identifier, where the query bit identifier contains only binary numbers whose positions correspond to the service bit identifier of the target service are 1. Furthermore, when multiple dependency queries are required, all query bit identifiers are combined using a bitwise OR operation to obtain the target bitmask, where the position corresponding to the service bit identifier of each target service in the target bitmask is 1.

[0053] Similarly, the dependency query statement performs a bitwise AND operation on the target bitmask and the dependency fields of all services. When the result of the bitwise AND operation equals the target bitmask, that service is used as the query result. Specifically, only when the result of the bitwise AND operation equals the target bitmask does it mean that the service identifier bits corresponding to all target services in the dependency fields are all 1.

[0054] For example, if the query is "Which services depend on both UserService (SBI=0) and ProductService (SBI=2)?", and the target service UserService has an SBI=0 and the target service ProductService has an SBI=2, then the result is converted to a target bitmask: targetMask = (1L<<0) | (1L<<2), which is ...0101, or 5. The corresponding SQL query is: SELECT * FROM service_table WHERE (DEPENDENCY_MASK&5) = 5; Check if the 0th and 2nd bits of DEPENDENCY_MASK (corresponding to SBI=0) are both 1. If they are both 1, it means that the service depends on multiple target services.

[0055] When the query method is a multi-dependency query, the service bit identifier of each target service is converted into a query bit identifier, and then the target bit mask is obtained by bitwise OR operation. Based on the target bit mask and the dependency relationship field, a dependency relationship query statement is constructed. Correspondingly, the dependency relationship query statement performs a bitwise AND operation on the target bit mask and the dependency relationship field of all services, and takes the service whose bitwise AND operation result is not 0 as the query result.

[0056] The difference between a query involving multiple dependencies and a query involving multiple dependencies in a union lies only in the query logic of the constructed dependency query statement. For example, the corresponding query content is "Which services depend on UserService (SBI=0) or ProductService (SBI=2)?". The target service UserService has an SBI=0, and the target service ProductService has an SBI=2. This is converted to a target bitmask targetMask = (1L<<0) | (1L<<2), resulting in ...0101, or 5. The corresponding SQL query statement is: SELECT * FROM service_table WHERE (DEPENDENCY_MASK&5) != 0; Checking that at least one of the 0th or 2nd bits (corresponding to SBI=0) of DEPENDENCY_MASK is 1 indicates that the service depends on any of the target services.

[0057] like Figure 3 As shown, Figure 3 This is a schematic diagram of the query logic of the service dependency query method based on dynamic bitmasks in this scheme. This scheme constructs different dependency query statements according to different query methods, and quickly queries dependencies based on the dependency query statements.

[0058] Example 3 This embodiment also provides an electronic device, see reference. Figure 4 It includes a memory 404 and a processor 402, the memory 404 storing a computer program, and the processor 402 being configured to run the computer program to perform the steps in any of the embodiments of the dynamic bitmask-based service dependency management method or the dynamic bitmask-based service dependency query method described above.

[0059] Specifically, the processor 402 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application. The memory 404 may include a large-capacity memory 404 for data or instructions. The memory 404 can be used to store or cache various data files to be processed and / or used for communication, as well as possible computer program instructions executed by the processor 402. The processor 402 implements any of the dynamic bitmask-based service dependency management methods or dynamic bitmask-based service dependency query methods described in the above embodiments by reading and executing the computer program instructions stored in the memory 404.

[0060] Optionally, the electronic device may further include a transmission device 406 and an input / output device 408, wherein the transmission device 406 is connected to the processor 402, and the input / output device 408 is connected to the processor 402. The transmission device 406 can be used to receive or send data via a network.

[0061] Input / output device 408 is used to input or output information. In this embodiment, the input information may be a target service, etc., and the output information may be query results, etc.

[0062] Optionally, in this embodiment, the processor 402 can be configured to perform the following steps via a computer program: Each service is assigned a unique service bit identifier, and the mapping relationship between services and service bit identifiers is recorded in the service bit mapping table, wherein the service bit identifier is incremented according to the registration order of services; Retrieve the service bit identifier of the service that the current service depends on from the service bit mapping table, perform bit operations based on the service bit identifier of the dependent service to obtain the dependency variable, and store the dependency variable in the dependency field of the current service.

[0063] or: Each service is assigned a unique service bit identifier, and the mapping relationship between services and service bit identifiers is recorded in the service bit mapping table, wherein the service bit identifier is incremented according to the registration order of services; Retrieve the service bit identifier of the service that the current service depends on from the service bit mapping table, perform bit operations based on the service bit identifier of the dependent service to obtain the dependency variable, and store the dependency variable in the dependency field of the current service. Dependency query statements are constructed based on the query content, where the query content records the target service and the query method; The dependency query statement retrieves the dependency fields of all services to obtain the query results.

[0064] It should be noted that the specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementations, and will not be repeated here.

[0065] Generally, various embodiments can be implemented in hardware or dedicated circuitry, software, logic, or any combination thereof. Some aspects of the invention can be implemented in hardware, while others can be implemented by firmware or software executed by a controller, microprocessor, or other computing device, but the invention is not limited thereto. Although various aspects of the invention may be shown and described as block diagrams, flowcharts, or using some other graphical representation, it should be understood that, by way of non-limiting example, these blocks, apparatuses, systems, techniques, or methods described herein can be implemented in hardware, software, firmware, dedicated circuitry or logic, general-purpose hardware or controllers or other computing devices, or some combination thereof.

[0066] Embodiments of the present invention can be implemented by computer software, which may be executable by a data processor of a mobile device, such as a processor entity, or by hardware, or by a combination of software and hardware. Computer software or programs (also referred to as program products), including software routines, applets, and / or macros, can be stored in any device-readable data storage medium, and they include program instructions for performing specific tasks. A computer program product may include one or more computer-executable components configured to perform embodiments when the program is run. One or more computer-executable components may be at least one piece of software code or a portion thereof. Additionally, it should be noted that any block in the logical flow of the figures may represent a program step, or interconnected logical circuitry, blocks and functions, or a combination of program steps and logical circuitry, blocks and functions. The software may be stored on physical media such as memory chips or blocks of storage implemented within a processor, magnetic media such as hard disks or floppy disks, and optical media such as, for example, DVDs and their data variants, CDs, etc. The physical medium is a non-transient medium.

[0067] Those skilled in the art should understand that the technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments have been described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0068] The above embodiments are merely illustrative of several implementation methods of this application, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A service dependency management method based on dynamic bitmasks, characterized in that, Includes the following steps: Each service is assigned a unique service bit identifier, and the mapping relationship between services and service bit identifiers is recorded in the service bit mapping table, wherein the service bit identifier is incremented according to the registration order of the services; Retrieve the service bit identifier of the service that the current service depends on from the service bit mapping table, perform bit operations based on the service bit identifier of the dependent service to obtain the dependency variable, and store the dependency variable in the dependency field of the current service.

2. The service dependency management method based on dynamic bitmask according to claim 1, characterized in that, If the current service's dependencies require the addition of a new service, the service bit identifier of the new service is retrieved from the service bit mapping table, the dependency variable of the current service is retrieved, and bitwise operations are performed on the service bit identifier of the new service to obtain the new mask. A bitwise OR operation is performed on the dependency variable and the new mask to obtain a new dependency variable, and the new dependency variable is updated in the dependency field of the current service. If the current service's dependencies require the deletion of a service, the dependency variable of the current service is retrieved, and a bitwise operation is performed on the service identifier of the deleted service to obtain the deletion mask. A bitwise AND operation is then performed on the dependency variable and the deletion mask to obtain a new dependency variable, and the new dependency variable is updated in the dependency field of the current service.

3. The service dependency management method based on dynamic bitmask according to claim 2, characterized in that, If a new service needs to be added as a dependency of the current service, first check if the new service has a service identifier. If the new service does not have a service identifier, assign a unique service identifier to each service and update the mapping relationship between the service and the service identifier to the service identifier mapping table. Then, retrieve the service identifier of the new service from the service identifier mapping table. If a service needs to be deleted as a dependency of the current service, check the dependency variable of the current service to see if the service to be deleted exists in the current service. If it does not exist, issue an error.

4. The service dependency management method based on dynamic bitmask according to claim 1, characterized in that, The value of the service bit identifier is a continuous integer from 0 to 2047. When the value of the service bit identifier exceeds the coverage range of a single word, multiple dependency variables are designed for the current service group.

5. The service dependency management method based on dynamic bitmask according to claim 1, characterized in that, For each service bit identifier of a dependent service, perform a left shift operation to convert the service bit identifier of the dependent service into a binary identifier where the corresponding service bit identifier is 1 and the rest are 0. If there is only one dependent service, convert the binary identifier into an integer dependency variable. If there are multiple dependent services, perform a bitwise OR operation on the multiple binary identifiers and combine them into an integer as the dependency variable.

6. A service dependency query method based on dynamic bitmasks, characterized in that, include: Each service is assigned a unique service bit identifier, and the mapping relationship between services and service bit identifiers is recorded in the service bit mapping table, wherein the service bit identifier is incremented according to the registration order of the services; Retrieve the service bit identifier of the service that the current service depends on from the service bit mapping table, perform bit operations based on the service bit identifier of the dependent service to obtain the dependency variable, and store the dependency variable in the dependency field of the current service. Dependency query statements are constructed based on the query content, where the query content records the target service and the query method; The dependency query statement retrieves the dependency fields of all services to obtain the query results.

7. The service dependency query method based on dynamic bitmask according to claim 6, characterized in that, When the query method is a single dependency query, the service bit identifier of the target service is converted into a query bit identifier, and a dependency query statement is constructed based on the query bit identifier and the dependency relationship field. Correspondingly, the dependency query statement performs a bitwise AND operation on the query bit identifier and the dependency relationship field of all services, and takes the service whose bitwise AND operation result is 1 as the query result.

8. The service dependency query method based on dynamic bitmask according to claim 6, characterized in that, When the query method is a multi-dependency joint query, the service bit identifier of each target service is converted into a query bit identifier, and then the target bit mask is obtained by bitwise OR operation. Based on the target bit mask and the dependency relationship field, a dependency relationship query statement is constructed. Correspondingly, the dependency relationship query statement performs a bitwise AND operation on the target bit mask and the dependency relationship field of all services, and the service whose bitwise AND operation result is the same as the target bit mask is taken as the query result.

9. The service dependency query method based on dynamic bitmask according to claim 6, characterized in that, When the query method is a multi-dependency query, the service bit identifier of each target service is converted into a query bit identifier, and then the target bit mask is obtained by bitwise OR operation. Based on the target bit mask and the dependency relationship field, a dependency relationship query statement is constructed. Correspondingly, the dependency relationship query statement performs a bitwise AND operation on the target bit mask and the dependency relationship field of all services, and takes the service whose bitwise AND operation result is not 0 as the query result.

10. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to run the computer program to execute the service dependency management method based on dynamic bitmask as described in any one of claims 1 to 5 or the service dependency query method based on dynamic bitmask as described in any one of claims 6 to 9.

Images