Method and apparatus for dynamic configuration and instantiation of software products based on version snapshots

Abstract

The present application relates to a kind of based on version snapshot software product dynamic configuration and instantiation method and device.The method includes: integrating configuration source and solidification version, establishing subject inheritance chain, resource tree, environment snapshot and the original hit strategy set of operation set dynamic quadruple, by along inheritance chain collection, conflict processing and filtering strategy, effective authority set is encapsulated as configuration list, then parse configuration list, to complete container layout and rendering.The device includes: configuration source integration module, original hit strategy set generation module, strategy collection module, conflict processing module, filtering module, configuration list analysis module, container layout and rendering module.The present application realizes "one development, unlimited configuration " in architecture level, configuration keeps in a core system code library, and independently generated system instance on function, UI, authority and brand etc., meet the life cycle of control software in the market variable environment of current cost saving.

Description

Technical Field

[0001] This invention belongs to the field of information security and relates to a method, apparatus, computer equipment, computer storage medium, and computer program product for dynamic configuration and instantiation of software products based on version snapshots. Background Technology

[0002] As enterprise software delivery shifts from project-based delivery to large-scale operation, "a single codebase supporting multiple product instances" has become an industry necessity. Software providers need to simultaneously generate different product forms such as "standard," "enterprise," and "SaaS" versions on the same kernel, and each product must support multiple versions running concurrently and multi-tenant isolation. While this "one core, multiple uses" model can reduce development costs, it also leads to an explosion in configuration complexity: the policy rules, UI interfaces, and permission models of different products need to be dynamically switched without interference.

[0003] In current industry practice, multi-tenant architecture, through resource sharing and standardized delivery, has become the technological cornerstone of the SaaS model. For example, renting 10 server resources to 5 customers can reduce the marginal cost for software providers. However, even systems that have adopted multi-tenant architecture still have significant limitations in configuration management because their core still relies on static configuration.

[0004] (1) Static configuration-driven systems often involve hard-coded policy and resource tree mappings. Changes in requirements require manual modification and service restart, resulting in prolonged business interruptions.

[0005] (2) When there are overlapping and conflicting policies, the system cannot clearly perform "conflict elimination". The policy decision delay increases linearly with the number of rules. When the policy scale is large, the time consumed becomes longer and the response speed becomes slower.

[0006] (3) There is a lack of a strategy-driven UI dynamic rendering mechanism. Strategy changes cannot be automatically applied to the front end and require manual code adjustments, making it impossible to achieve end-to-end automated closed loop.

[0007] Especially after the introduction of the "super administrator" role, high-privilege operations across tenants / products lack a linkage mechanism with the dynamic configuration architecture. The permission boundaries rely on a static rule set configured manually, which poses risks of unauthorized access and configuration drift.

[0008] Therefore, the aforementioned shortcomings limit the reusability potential of multi-tenant architecture in large-scale and agile delivery scenarios. This invention aims to provide a dynamic configuration method for the entire chain from product requirements to interface presentation to fill this gap. Summary of the Invention

[0009] In order to solve the technical problems in the background art, the present invention provides a method, apparatus, computer device, computer storage medium and computer program product for dynamic configuration and instantiation of software products based on version snapshots.

[0010] The technical solution of the present invention to solve the above-mentioned technical problems is as follows:

[0011] The first aspect provides a method for dynamic configuration and instantiation of software products based on version snapshots, the method comprising the following steps:

[0012] It receives parameterized configuration instructions for the same set of source code, integrates the configuration source, generates and stores a version snapshot with a unique ID and its encrypted license file;

[0013] When permission determination is triggered, the entity inheritance chain vector, resource tree vector, environment snapshot vector and operation set vector are collected in real time to form a dynamic quadruple. After adaptive encoding based on its data characteristics, the original hit strategy set is output.

[0014] Tracing back along the inheritance chain of the current subject, collect associated strategies from the original hit strategy set;

[0015] When multiple policies associated with a subject conflict, a bit vector algorithm combining explicit rejection priority and proximity processing is used to determine the conflict. In this algorithm, the rejection policy is encoded in the high bit area of ​​the bit vector, and the allow policy is encoded in the low bit area of ​​the bit vector according to priority. The priority includes at least user level, user group level and tenant level. The encoding value of the high priority policy is greater than the encoding value of the low priority policy. The effective policy is determined by comparing the size of the encoding values.

[0016] Irrelevant policies are filtered out using the version snapshot ID, and the generated valid permission set is then encapsulated into a configuration manifest.

[0017] Parse the abstract strategies in the configuration manifest and map them to UI build instructions;

[0018] The UI component library is queried according to the UI build instructions, an instantiated UI container is output, and then sent to the front end for rendering and display.

[0019] Secondly, a software product dynamic configuration and instantiation device based on version snapshots is provided, including:

[0020] The configuration source integration module is used to receive parameterized configuration instructions for the same set of source code, integrate the configuration sources, generate and store version snapshots with unique IDs and their encrypted license files;

[0021] The original hit strategy set generation module is used to collect the subject inheritance chain vector, resource tree vector, environment snapshot vector and operation set vector in real time when the permission judgment is triggered, form a dynamic quadruple, and output the original hit strategy set after adaptive encoding based on its data characteristics.

[0022] The strategy collection module is used to collect associated strategies from the original hit strategy set by traversing back along the inheritance chain of the current subject.

[0023] The conflict handling module is used to determine the conflict when multiple policies associated with a subject conflict. It employs a bit vector algorithm that combines explicit rejection priority with proximity processing. The rejection policy is encoded in the high bit area of ​​the bit vector, while the allow policy is encoded in the low bit area of ​​the bit vector according to priority. The priority includes at least user level, user group level, and tenant level. The encoding value of the higher priority policy is greater than that of the lower priority policy. The effective policy is determined by comparing the size of the encoding values.

[0024] The filtering module is used to filter irrelevant policies by version snapshot ID and then encapsulate the generated valid permission set into a configuration list.

[0025] The configuration manifest parsing module is used to parse the abstract strategies in the configuration manifest and map them into UI build instructions;

[0026] The container layout and rendering module is used to query the UI component library according to the UI build instructions, output instantiated UI containers, and then send them to the front end for rendering and display.

[0027] Thirdly, a computer device is provided, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, it implements the steps of the software product dynamic configuration and instantiation method based on version snapshots as described in any of the preceding claims.

[0028] Fourthly, a computer-readable storage medium is provided on which a computer program is stored, which, when executed by a processor, implements the above-described method for dynamic configuration and instantiation of software products based on version snapshots.

[0029] Fifthly, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the version snapshot-based dynamic configuration and instantiation method for software products described in any of the preceding claims.

[0030] The beneficial effects of this invention are:

[0031] (1) This invention decouples the mapping logic from the code to the runtime by constructing a quadruple decision context in real time, adopts an adaptive coding algorithm to automatically select the bitmask strategy, eliminates manual intervention, and achieves hot loading of the strategy through version snapshot license, so that it can take effect without redeployment;

[0032] (2) The present invention uses a bit vector algorithm that combines explicit rejection priority with proximity processing to clearly and quickly determine conflicts, effectively avoid permission confusion, and shorten the time consumed in the case of large-scale strategies.

[0033] (3) This invention solidifies the configuration list through version snapshots, and uses dynamic quadruples to parse the snapshot strategy in real time and drive the UI dynamic rendering, forming a linkage relationship of version binding, precise and fast policy processing, and interface rendering display. This not only realizes the end-to-end automated closed loop of configuration taking effect and decision being presented, but also realizes the upgrade from "manual operation and maintenance" to "configuration autonomy".

[0034] (4) This invention can achieve a "develop once, configure infinitely" solution at the architecture level, so that the configuration is kept in a core system code library. The core can efficiently and flexibly generate system instances that are independent in terms of functional interface, UI interface, permissions and brand, thereby meeting the needs of cost-saving control software life cycle in the current volatile market environment. Attached Figure Description

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

[0036] Figure 1 This is a schematic diagram of the dynamic configuration and instantiation method for software products based on version snapshots provided in Embodiment 1 of the present invention.

[0037] Figure 2 This is a schematic diagram of the hierarchical structure of the main inheritance chain in Embodiment 1 of the present invention.

[0038] Figure 3 This is a schematic diagram of the generated dynamic quadruple structure in Embodiment 1 of the present invention.

[0039] Figure 4 This is a schematic diagram of the dynamic configuration and instantiation method for software products based on version snapshots provided in Embodiment 2 of the present invention.

[0040] Figure 5 This is a schematic diagram of the structure of a software product dynamic configuration and instantiation device based on version snapshots provided in Embodiment 3 of the present invention.

[0041] Figure 6 This is a schematic diagram of the structure of the electronic device provided in Embodiment 4 of the present invention.

[0042] The attached diagram lists the components represented by each number as follows:

[0043] 3001. Configuration source integration module; 3002. Original hit strategy set generation module; 3003. Strategy collection module; 3004. Conflict handling module; 3005. Filtering module; 3006. Configuration list parsing module; 3007. Container layout and rendering module; 410. Processor; 420. Communication interface; 430. Memory; 440. Communication bus. Detailed Implementation

[0044] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0045] Example 1

[0046] In current industry practice, multi-tenant architecture, through resource sharing and standardized delivery, has become the technological cornerstone of the SaaS model. For example, renting 10 server resources to 5 customers can reduce the marginal cost for software providers. However, even systems that have adopted multi-tenant architecture still have significant limitations in configuration management because their core still relies on static configuration.

[0047] (1) Static configuration-driven systems often involve hard-coded policy and resource tree mappings. Changes in requirements require manual modification and service restart, resulting in prolonged business interruptions.

[0048] (2) When there are overlapping and conflicting policies, the system cannot clearly perform "conflict elimination". The policy decision delay increases linearly with the number of rules. When the policy scale is large, the time consumed becomes longer and the response speed becomes slower.

[0049] (3) There is a lack of a strategy-driven UI dynamic rendering mechanism. Strategy changes cannot be automatically applied to the front end and require manual code adjustments, making it impossible to achieve end-to-end automated closed loop.

[0050] Especially after the introduction of the "super administrator" role, high-privilege operations across tenants / products lack a linkage mechanism with the dynamic configuration architecture. The permission boundaries rely on a static rule set configured manually, which poses risks of unauthorized access and configuration drift.

[0051] To address the aforementioned issues, embodiments of the present invention provide a method for dynamic configuration and instantiation of software products based on version snapshots. Figure 1This is a schematic diagram of the dynamic configuration and instantiation method for software products based on version snapshots provided in an embodiment of the present invention, such as... Figure 1 As shown, this method includes:

[0052] Step S101: Receive parameterized configuration instructions for the same set of source code, integrate the configuration source, generate and store a version snapshot with a unique ID and its encrypted license file.

[0053] It is understood that the parameterized configuration instructions referred to in this implementation are the initial configuration instructions issued by the user when selecting a version or copying and modifying an existing template. The parameters to be configured according to the instructions include, but are not limited to: authorization information, personalized page information, and brand information.

[0054] It is also understandable that in this implementation, the configuration source is a container carrier that carries configuration parameters, such as YAML files, database tables and API interfaces. The configuration parameters are differentiated instruction sets that determine the system behavior. By loading different configuration contents from different configuration sources into the same set of source code, multiple customized system products can be realized.

[0055] It is also understandable that this embodiment avoids redundant code development and version fragmentation by using a model of "using the same set of source code for general capabilities and configuration parameters to support customized needs," thereby reducing the explosive reduction in maintenance costs. When a user accesses the system, the request first retrieves the parameters from the corresponding configuration source, and then integrates the configuration source using these parameters to initialize the page. Those skilled in the art should understand the relationship between configuration commands, configuration parameters, configuration sources, and source code, which will not be elaborated upon here.

[0056] It is worth noting that after the system integrates all configuration sources, it will generate a version snapshot with a unique ID and an encrypted license file for that version snapshot. The version snapshot is a certificate that solidifies the subsequent configuration list into a tamper-proof, version-traceable, and tenant-isolated certificate. Specifically, the version snapshot can play multiple roles in this scenario: (1) The version number, timestamp, and hash verification are embedded in the snapshot. When the system runs, it can instantly identify the current software version, authorization policy version, and scope of effectiveness by decrypting the snapshot; (2) When the version is abnormal, the policy configuration of any historical version can be quickly located by the timestamp and version chain in the snapshot, and the system can be atomically rolled back to the historical snapshot; (3) The policy adjudication engine loads a policy set that strictly matches the requested version number from the version snapshot, automatically filters the residual policies of the historical version, and avoids unauthorized access or denial-of-service incidents caused by version inconsistency.

[0057] Preferably, step S101 further includes:

[0058] Step S1011: Receive parameterized configuration instructions for the same set of source code. The configured parameters include, but are not limited to: authorization information, personalized page information, and brand information.

[0059] Step S1012: According to the parameterized configuration instructions, the scattered configuration sources are integrated into a unified in-memory configuration tree through the configuration merging engine. The configuration sources include, but are not limited to: YAML files, database tables and API interfaces.

[0060] Step S1013: Perform deterministic hash calculation on the merged memory configuration tree to generate a unique version snapshot ID, and serialize the configuration tree into a compact binary format;

[0061] Step S1014: Encrypt the version snapshot content using a temporary key to generate a license file that cannot be directly modified. Once the license file is generated, its content cannot be edited or deleted. It can only be updated by regenerating the version snapshot and performing a new round of encrypted authorization.

[0062] Step S1015: Create a version snapshot index table containing tenant ID, version snapshot ID, and license path.

[0063] It is understood that the above-mentioned authorization information includes, but is not limited to: authorization type, authorization version, authorized functions, authorization capacity, and authorization quantity; the above-mentioned personalized page information includes, but is not limited to: version type, applicable scenarios, applicable themes, and applicable page layout; the above-mentioned brand information includes, but is not limited to: company name, logo, and product name. Of course, this example only lists typical configuration parameters, and those skilled in the art can adjust key configuration parameters according to business needs.

[0064] It's also understandable that the in-memory configuration tree naturally maps the hierarchical relationship of configurations to a tree structure, such as tenant-level permission policies → functional module-level switches → page element-level styles. This transforms the configuration loading process from "multi-source fragmented queries" to "single-tree structured traversal." When the business needs to adjust parameters such as authorized capacity or brand logo, the configuration engine can fetch the new configuration in real time and incrementally update the in-memory tree without restarting the service, ensuring continuous response to user requests in high-concurrency scenarios. Simultaneously, the merging engine, through conflict detection and version locking mechanisms, ensures strong data consistency among multiple sources such as databases, files, and APIs during merging, avoiding the risk of "some tenants loading old configurations while others load new configurations." This effectively improves the efficiency of configuration changes taking effect and eliminates disk I / O latency through in-memory configuration, improving the performance of operations such as permission verification and page rendering, helping to support the differentiated configuration needs of "personalized experiences" in multi-tenant scenarios. Furthermore, serializing the configuration tree into a compact binary format effectively compresses its size.

[0065] The index table is a composite index built with tenant ID as the first dimension and version snapshot ID as the second dimension. This allows the system to quickly locate snapshot files in scenarios with "millions of snapshots and tens of thousands of tenants" by using a chained search of tenant ID → snapshot ID → license path. For example, when tenant C needs to roll back to version V3.2.1 snapshot, the index table directly points to the corresponding storage path. At the same time, the index table fully records metadata such as "snapshot creation time, tenant, and associated license," forming an audit evidence chain for version iteration. When the compliance department reviews whether "a tenant has illegally modified historical snapshots," it can trace the entire lifecycle of snapshot creation, use, and disposal through the index table, meeting compliance standards such as GDPR / HIPAA. More importantly, the index table implements permission sandbox isolation through tenant ID: the index records of different tenants are strictly isolated at the physical / logical level. Tenant A cannot tamper with tenant B's snapshot path through the index, improving the security of multi-tenant systems from the data layer.

[0066] It's worth noting that version snapshots and license file storage are not limited to databases or file systems. If the number of tenants is small and snapshot capacity is controllable, using a single database or a single distributed file system can simplify the architecture and reduce operational costs. However, for enterprise-level multi-tenant SaaS, a hybrid storage approach combining databases, file systems, and distributed storage can better meet the needs for fast data retrieval, stable large file storage, and disaster recovery against massive data volumes. This example does not impose specific limitations on this.

[0067] It is also worth noting that this embodiment encrypts the entire content of the version snapshot (including metadata checksum and data body). Specifically, it derives a memory key using a hash algorithm with the tenant ID as the salt and the timestamp as the dynamic factor. The encrypted ciphertext is then fixed as a license file in a database, object storage, or distributed ledger and marked as read-only. At the same time, WORM technology or database triggers can be used to block any UPDATE / DELETE operations, ensuring that any bit change in the version snapshot will cause the license to expire. The only legal way to change the license is to regenerate the snapshot and a new license.

[0068] Thus, this embodiment can effectively handle scenarios with dynamically loaded policies. Specifically, any bit change in a version snapshot can lead to unauthorized access or denial of service. Therefore, the entire content must be encrypted as a whole, rather than in segments, to ensure that attackers cannot bypass specific policies through partial tampering. A memory key is derived from the tenant ID and timestamp, achieving one key per version. The key's lifecycle is bound to the snapshot and is automatically destroyed after the request ends. A data anti-tampering mechanism is introduced to block any UPDATE / DELETE operations, ensuring the non-repudiation of configuration change history and preventing maintenance personnel from accidentally or maliciously deleting historical versions.

[0069] Step S102: When the permission determination is triggered, the main inheritance chain vector, resource tree vector, environment snapshot vector and operation set vector are collected in real time to form a dynamic quadruple. After adaptive encoding based on its data characteristics, the original hit strategy set is output.

[0070] Preferably, step S102 further includes:

[0071] Step S1021: When the permission determination is triggered, the subject inheritance chain vector, resource tree vector, environment snapshot vector, and operation set vector are collected in real time to form a dynamic four-tuple decision context. Among them, the subject inheritance chain vector is a multi-level inheritance chain vector containing at least user ID, user group, and tenant ID; the resource tree vector is a resource tree vector containing at least menu, page, button, API, and data fields; the environment snapshot vector is a snapshot environment snapshot vector containing at least version snapshot ID, release time, and effective status; and the operation set vector is an operation set vector containing at least explicit, implicit, available, denied, and prompt operations.

[0072] Step S1022: Based on the data characteristics of the constituent vectors in the dynamic quadruple, adaptively select bitmask encoding, hash encoding, or hybrid encoding mode to form an intermediate representation for decision;

[0073] Step S1023: The intermediate decision representation is sent to the policy adjudication engine, and the original hit policy set is output through vector Boolean operation.

[0074] It is understandable that, such as Figure 2 As shown, taking a multi-tenant scenario as an example, the subject inheritance chain is the hierarchical carrier of permission attribution, consisting of nodes such as "single user inheritance chain: super administrator → user C", "user group carrier chain: super administrator → user group → user A → auditor; super administrator → user group → user B → operator", and "tenant carrier chain: super administrator → tenant → user D; super administrator → tenant → user group → user E → auditor; super administrator → tenant → user group → user H → operator". Permission inheritance and aggregation can be achieved through backtracking of the subject chain. For example, after Company A, acting as the super administrator, purchases "basic product A", it can create tenants and assign them to subsidiaries (tenant subjects). Subsidiaries then refine permissions through user groups / users / departments—when an employee initiates a resource request, the system will backtrack layer by layer from "subsidiary (tenant)" to "employee (user)," collecting direct / indirect permission policies at each level to form the final permission set. This chain structure enables the permission management of complex organizations to have the capability of "top-down permission flow," while also supporting flexible control of "resource sharing + private resource isolation" in this scenario.

[0075] The resource tree is a tree-structured representation of the objects affected by permissions. These are the objects controlled by permissions, and it is also an aggregateable hierarchical structure. The hierarchical chain is: System → Functional Module Group → Functional Module → Page → UI Component → Data Interface → Data Field. This refines resource control from coarse-grained "modules" to a single button or table column on the front end, and an API interface or data field on the back end. It also implicitly controls child nodes based on the permission policies of parent nodes. For example, if the parent node "Basic Product A" of "Virtual Machine Protection" is explicitly denied, even if the "Virtual Machine Protection" node itself allows access, employees cannot access this function. Therefore, it implements a top-down decision-making logic of "Subject > Resource," allowing permission control to support both macro-level product-level management and granular button / field-level operations.

[0076] An environment snapshot is a collection of dynamic contexts for decision-making, encompassing real-time information such as time, system load, and user status, like "Is user A's task B performed during off-peak hours?" or "Is cluster CPU utilization exceeding the threshold?" It binds static permission policies to the dynamic environment through "environment filters": when a user requests resources, the system collects the current environment state and matches it against predefined environment policies. For example, when an auditor views task logs during a "high system load" period, the environment snapshot triggers a "visible only, inoperable" policy to avoid increasing system load. This allows permissions to have "contextual adaptive" capabilities, balancing security and resource utilization.

[0077] An action set is a collection of executable actions performed by an entity on a resource. It equally covers the entire interactive hierarchy from "navigation bar → page → button → data field" and defines the interface state through "visibility and availability". For example, an auditor's action set may include "view task logs" but not "modify task parameters," which would be displayed on the front end as "log table visible but edit button disabled." If an action set completely lacks a certain function, the front end would directly hide that button. This allows for a strong binding between permission decisions and interface rendering, achieving end-to-end control from "permission definition to interface interaction."

[0078] This embodiment introduces the four dimensions of permission decision-making—the subject chain, resource tree, environment, and operation—into a vector space, encoding them as orthogonal components of a high-dimensional vector. For example, the subject chain dimension corresponds to the hierarchical feature vector of "product → tenant → user group → user → department," and the resource tree dimension corresponds to the tree structure vector of resource paths. This allows the permission engine to handle complex hierarchical relationships such as "subject chain backtracking and resource tree mapping," and also lays the foundation for efficiently resolving conflicts through vector operations in the future.

[0079] It is worth noting that, such as Figure 3As shown, dynamic quadruples are runtime-aggregated decision contexts, rather than static storage structures. Specifically, quadruples are not pre-generated; instead, they are generated in real-time by aggregating the main inheritance chain, resource tree, environment snapshot, and operation set upon each access request. This is achieved by calling the main inheritance chain resolver, resource path generator, environment context collector, and operation set expander. The processing path is then selected based on the feature labels of the quadruple data. For example, when the main inheritance chain contains a high-privilege identifier, extended bit-width encoding (48 / 64 / 128 bits) is used to accommodate more context; when the environment snapshot indicates a sensitive area, a geofence encoding mode is triggered, adding environment constraint bits; and in normal scenarios, standard 64-bit quadruples are used for equal-segment encoding. Therefore, dynamic quadruples enable the construction of a multi-dimensional real-time evaluation framework. Adaptive encoding algorithms automatically select bitmask strategies, eliminating manual intervention and supporting the goal of dynamic configuration and generation.

[0080] It is important to note that the quadruple aggregation point can be a temporary object in the stack memory, which is automatically recycled when the request ends. There is no global storage or database write here, which realizes request-level dynamic aggregation and leaves no global state residue.

[0081] Step S103: Backtrack along the inheritance chain of the current subject to collect associated strategies from the original hit strategy set.

[0082] Step S104: When multiple policies associated with a subject conflict, a bit vector algorithm combining explicit rejection priority and proximity processing is used to complete the conflict determination. The rejection policy is encoded in the high bit area of ​​the bit vector; the allow policy is encoded in the low bit area of ​​the bit vector according to priority. The priority includes at least user level, user group level and tenant level. The encoding value of the high priority policy is greater than the encoding value of the low priority policy. The effective policy is determined by comparing the size of the encoding values.

[0083] Preferably, step S104 further includes:

[0084] Step S1041: Compress all access policies into a 64-bit register to achieve single-instruction parallel processing. The rejection policy is encoded as the high 32 bits of a 64-bit integer, and the allow policy is encoded as the low 32 bits of a 64-bit integer.

[0085] Step S1042: When multiple policies associated with a subject conflict, check whether there is a valid bit in the high 32-bit area by performing a bitwise OR operation. If there is, output a rejection decision; if not, extract the code with the largest value among the user-level, user group-level, and tenant-level priority codes in the low 32-bit area by comparison operation, and execute the corresponding priority allow policy.

[0086] It's worth noting that explicit denial priority is a key concept in conflict resolution: when an entity has an explicit denial policy in any dimension, regardless of whether there are allow policies in other dimensions, the final decision is denial. For example, a super administrator configures a subsidiary tenant to "allow access to all virtual machine resources," but a user within that tenant is explicitly denied the "delete virtual machine" operation—even if the user's group allows "delete virtual machine," the explicit denial will still override all allow policies and prohibit the operation. This rule ensures the rigid enforcement of the "principle of least privilege," preventing high-risk operations from being accidentally allowed due to multi-dimensional policy conflicts.

[0087] Therefore, in this embodiment, explicit rejection policies are uniformly mapped to the high 32 bits of a 64-bit vector, 0xFFFF0000_00000000, while allow policies are mapped to the low 32 bits. When the policy set consisting of the subject, resource, environment, and operation quadruples undergoes conflict resolution, the hardware-level bitwise OR instruction merges all policy vectors in parallel within a single CPU cycle. If any bit in the high 32 bits of the result is set arbitrarily, the hardware circuit automatically triggers a short-circuit return, directly outputting the rejection decision without traversing the remaining allow policies.

[0088] It's also worth noting that "proximity-based processing" is a "nearest policy priority" logic for resolving permission conflicts. In the subject inheritance chain or resource tree, the policy "closest to" the requesting subject / resource has higher priority. For example, employee A's direct supervisor (user group level) is configured to "allow modification of virtual machine configuration," while the company super administrator (product level) is configured to "prohibit modification of virtual machine configuration"—because the user group is employee A's "most recent supervisor," proximity-based processing allows "allow modification" to take effect. This concept aligns with organizational management logic, ensuring that lower-level managers' permission decisions are closer to actual business needs while reducing conflicts arising from "higher-level policies excessively restricting lower-level operations."

[0089] Therefore, for permitted policy conflicts, the system hierarchically encodes weight values ​​down to the lowest 32 bits of a vector based on the distance between the policy and the subject / resource. For example, user-level policies are directly assigned 0x00000000_FFFFFFFF, user group-level policies inherit 0x00000000_FFFF0000, and tenant-level policies inherit 0x00000000_0000FFFF. During conflict resolution, the VPMAXSD instruction compares all permitted vectors in parallel within a single instruction cycle and automatically selects the one with the largest value to take effect. The encoded weights are strictly negatively correlated with the distance, ensuring that the hardware calculation result is equivalent to the "closest processing".

[0090] Therefore, this embodiment implements vector Boolean operations through bitmask design, SIMD instruction set and hardware short-circuit mechanism. Explicit rejection is preferentially converted into irreversible operations in the high 32-bit field, and nearest processing is converted into maximum value extraction in the low 32-bit field. This enables clear and fast conflict determination, effectively avoids permission confusion, and shortens the time consumed in large-scale policy scenarios.

[0091] Step S105: Filter irrelevant policies by version snapshot ID, and then encapsulate the generated valid permission set into a configuration list.

[0092] Step S106: Parse the abstract strategy in the configuration manifest and map it to UI build instructions;

[0093] Step S107: Query the UI component library according to the UI build instructions, output the instantiated UI container, and then send it to the front end for rendering and display.

[0094] It's worth noting that this embodiment primarily focuses on building a multi-product dynamic configuration capability on a single codebase. The multi-tenant example provided is merely a specific implementation scenario under a particular business model. Other potential application scenarios include: multi-version canary release scenarios, where the same product can run both v1.0 and v2.0 simultaneously, using version snapshot isolation strategies and UIs, and automatically routing requests based on version numbers in dynamic four-tuples to achieve gradual upgrades by user / user group without downtime; based on the same kernel, configuration manifests can be quickly generated: Standard Edition: basic backup + default UI; Enterprise Edition: advanced strategy + customized UI; SaaS Edition: multi-tenant isolation + lightweight UI. Strategies and interfaces for each product line are fixed through independent version snapshots, ensuring they do not affect each other and evolve in parallel; the same product deployed in different geographical regions can automatically load policy configurations compliant with local regulations through environment snapshot vectors, and dynamically render privacy policy interfaces through containers, achieving global compliance with a single codebase. Therefore, this embodiment is intended for scenarios where "same kernel + differentiated configuration manifest = multiple product instances," and is not limited to more specific scenarios.

[0095] In this embodiment, the configuration list is solidified through version snapshots, and the snapshot strategy is parsed in real time through dynamic four-tuples to drive the dynamic rendering of the UI, forming a linkage relationship of version binding, precise strategy and interface rendering display. This not only realizes the end-to-end automated closed loop of configuration taking effect and decision being presented immediately, but also realizes the upgrade from "manual operation and maintenance" to "configuration autonomy".

[0096] Example 2

[0097] like Figure 4 As shown, in one embodiment, a method for dynamic configuration and instantiation of software products based on version snapshots is provided. This method includes:

[0098] Step S201: Receive parameterized configuration instructions for the same set of source code, integrate the configuration source, generate and store a version snapshot with a unique ID and its encrypted license file;

[0099] Step S202: When the permission determination is triggered, the main inheritance chain vector, resource tree vector, environment snapshot vector and operation set vector are collected in real time to form a dynamic quadruple. After adaptive encoding based on its data characteristics, the original hit strategy set is calculated and output.

[0100] Step S203: Backtrack along the inheritance chain of the current subject to collect associated strategies from the original hit strategy set;

[0101] Step S204: When multiple policies associated with a subject conflict, a bit vector algorithm combining explicit rejection priority and proximity processing is used to complete the conflict determination. The rejection policy is encoded in the high bit area of ​​the bit vector; the allow policy is encoded in the low bit area of ​​the bit vector according to priority. The priority includes at least user level, user group level and tenant level. The encoding value of the high priority policy is greater than the encoding value of the low priority policy. The effective policy is determined by comparing the size of the encoding values.

[0102] Step S205: Filter irrelevant policies by version snapshot ID, and then encapsulate the generated valid permission set into a configuration list;

[0103] Step S206: Parse the abstract strategy in the configuration manifest and map it to UI build instructions;

[0104] Step S207: Query the UI component library according to the UI build instructions and output the instantiated UI container. Each function in the UI component library corresponds to multiple visual containers with unique identifiers.

[0105] Step S208: Standardize the layout properties of each instantiated UI container, defining the base width, base height, name, and priority of the instantiated container;

[0106] Step S209: Perform multi-level sorting on the instantiated UI containers after standardization definition to form a container queue. The sorting weight factors include: pre-configured module priority, user historical layout preference and default business rules.

[0107] Step S210: Create a layout canvas. In the order of the container queue, place the instantiated UI containers that have completed the standardization definition into the canvas in a pipeline manner.

[0108] Step S211: If the runtime two-dimensional size of the current UI container exceeds the remaining threshold of the target layout space, prioritize scanning the queue of interchangeable matching containers. If a better size exists, swap the execution order; if no interchangeable container exists, perform minimum ratio dynamic scaling on the current container.

[0109] Step S212: Send the final layout scheme to the front end for rendering and display.

[0110] In this example, the system maintains a UI component library, where each function corresponds to one or more visual containers with unique identifiers. By parsing the configuration manifest and then querying the UI component library, the system determines which visual containers to include in the current rendering process.

[0111] It is worth noting that each visual container is assigned a basic set of layout attributes during the specification definition, which includes:

[0112] Base width: Based on a grid system of 12 equal parts, it is defined as the number of parts occupied, such as: 4 parts, 6 parts, 12 parts;

[0113] Base height: Defined by a fixed pixel unit as the basic module, representing the number of modules occupied, e.g., 2=>200px height;

[0114] Container name and priority: used for identification and sorting.

[0115] It's important to note that names also need to be standardized to support adaptive matching. Taking storage as an example, fuzzy matching can easily confuse instances like storage_1 (with dimensions in GB) and storage_2 (with dimensions in MB) that belong to the same module but have different attributes. Therefore, a structured approach can be used, combining a common module prefix with a unique instance suffix. For instance, naming storage instances storage_GB and storage_MB respectively allows the matching logic to accurately identify instance attributes, enabling flexible management.

[0116] This example further provides a layout process of "weighted sorting of containers → filling of 2D layout space → adaptive space optimization → serialization of layout configuration" to achieve a compact and aesthetically pleasing flow layout: First, the visual containers are weighted and sorted to form a queue to be laid out, taking into account the priority of module configuration, the order of users' historical layout preferences, and default business logic; then, using the 2D layout space as a grid reference, containers are placed according to the queue order, and adaptive adjustment is triggered when the width or height does not match, maximizing space utilization and reducing blank gaps; finally, the container coordinates, size, and state are serialized into a layout configuration object to support front-end rendering or differential updates.

[0117] To facilitate understanding of the layout process described above, we provide an example of an adaptively adjusted layout canvas with a width of 12 columns:

[0118] Assuming the widths of the containers to be laid out, sorted by priority, are [6, 4, 6, 3, 3] (unit: columns), the simulated layout process is as follows:

[0119] Step 1: Before triggering the adjustment

[0120] Take out the first container, width 6: place it in the first row, columns 1-6 → the remaining space in the current row is 12-6=6 columns;

[0121] Take out the second container, with a width of 4: place it in the first row, columns 7-10 → the remaining space in the current row is 6-4=2 columns;

[0122] Take out the 3rd container, width 6: There are 2 columns remaining in the current row, which cannot accommodate a container with a width of 6 → trigger the adaptive adjustment subroutine;

[0123] Step 2: Adaptive Adjustment Process

[0124] The third to fifth containers in the queue are examined, with widths of 6, 3, and 3 respectively. Space is optimized through "position swapping + dynamic scaling":

[0125] Try swapping the order: Swap the 3rd container (width 6) with the 4th container (width 3), the new queue becomes [6,4,3,6,3];

[0126] The queue after rearrangement and adjustment:

[0127] The third container (width 3): scaled to 2 columns (to fit the remaining 2 columns in the current row), placed in the 1st row, columns 11-12 → the remaining space in the 1st row is exhausted;

[0128] The 4th container (width 6): wrap to the 2nd row and place it in columns 1-6 of the 2nd row;

[0129] The 5th container (3 widths): placed in the 2nd row, columns 7-9 (the remaining space in the 2nd row is 12-6=6 columns, which will be 3 columns remaining after accommodating 3 columns).

[0130] Step 3: Final layout result

[0131] Adjusted layout coordinates and space utilization:

[0132] Row 1: Container 1 (6 columns, 1-6), Container 2 (4 columns, 7-10), Container 3 (3 columns reduced to 2, 11-12) → Space utilization rate increased from the initial (6+4) / 12=83.3% to (6+4+2) / 12≈100%;

[0133] Row 2: Container 4 (6 columns, 1-6), Container 5 (3 columns, 7-9) → 3 columns of space remaining, which can be filled by adding new containers later.

[0134] It's important to note that during execution, when the current container's width vector W_current exceeds the remaining space vector S_remain, a width vector scanning subroutine is triggered. This subroutine performs a single-instruction multiple-data comparison operation on the width vector sequence [W_next1, W_next2, ..., W_nextN] of the subsequent container queue, simultaneously checking if W_nextti ≤ S_remain. If it does, the vector element swap instruction SWAP(W_current, W_nextti) is executed, placing the subsequent container that meets the condition in advance. This process is completed quickly at the register level, and because it directly replaces containers with preset size specifications (such as 4 / 6 / 8 columns), it does not change the original container's aspect ratio and style definition, preserving the visual integrity of the UI design.

[0135] The algorithm triggers the dynamic scaling vector generator only when no specification vector satisfying W ≤ S_remain exists in the subsequent queue. It generates a candidate vector sequence from W_current using a preset scaling factor array [0.9, 0.8, 0.7], calculates the scaled pixel size using vector dot product, and selects the scheme with the smallest scaling ratio for execution. After scaling, the container style class name is automatically appended with the -scaled tag. The front-end can optimize spacing separately for the scaled state using CSS media queries to ensure that layout balance is not disrupted even during scaling.

[0136] Unlike the above embodiments, this embodiment provides a container-based adaptive adjustment flow layout scheme during container layout and rendering. When the container size exceeds the limit and needs to be re-layouted, the subsequent queue is first scanned to find target containers with matching width or height for execution order swapping. Only when no suitable container is available is minimum scaling triggered as a backup solution. In most scenarios, a compact layout can be achieved through sequential adjustment, fully preserving the visual proportions and design aesthetics of the original UI. In the remaining extreme scenarios, the minimum scaling factor is calculated to maximize space utilization with minimal visual compromise, improving the overall layout compactness and compressing blank gaps to pixel-level errors, thus balancing aesthetic restoration and engineering practicality.

[0137] Example 3

[0138] like Figure 5 As shown, in one embodiment, a software product dynamic configuration and instantiation apparatus based on version snapshots is provided. This apparatus includes:

[0139] The configuration source integration module 3001 is used to receive parameterized configuration instructions for the same set of source code, integrate the configuration source, generate and store a version snapshot with a unique ID and its encrypted license file.

[0140] The original hit strategy set generation module 3002 is used to collect the main inheritance chain vector, resource tree vector, environment snapshot vector and operation set vector in real time when the permission judgment is triggered, form a dynamic quadruple, and output the original hit strategy set after adaptive encoding based on its data characteristics.

[0141] The strategy collection module 3003 is used to collect associated strategies from the original hit strategy set by tracing back along the inheritance chain of the current subject.

[0142] The conflict handling module 3004 is used to determine the conflict when multiple policies associated with a subject conflict. It employs a bit vector algorithm that combines explicit rejection priority with proximity processing. The rejection policy is encoded in the high bit area of ​​the bit vector, and the allow policy is encoded in the low bit area of ​​the bit vector according to priority. The priority includes at least user level, user group level and tenant level. The encoding value of the high priority policy is greater than that of the low priority policy. The effective policy is determined by comparing the size of the encoding values.

[0143] The filtering module 3005 is used to filter irrelevant policies by version snapshot ID and then encapsulate the generated valid permission set into a configuration list.

[0144] Configuration manifest parsing module 3006 is used to parse the abstract strategies in the configuration manifest and map them into UI build instructions;

[0145] The container layout and rendering module 3007 is used to query the UI component library according to the UI build instructions, output instantiated UI containers, and then send them to the front end for rendering and display.

[0146] The device in this embodiment can achieve a "develop once, configure infinitely" solution at the architecture level, keeping the configuration in a core system code library. The core efficiently and flexibly generates system instances that are independent in terms of functional interface, UI interface, permissions, and brand, thereby meeting the life cycle requirements of cost-saving control software in today's volatile market environment.

[0147] Example 4

[0148] exist Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention, such as... Figure 6 As shown, the electronic device may include a processor 410, a communication interface 420, a memory 430, and a communication bus 440, wherein the processor 410, the communication interface 420, and the memory 430 communicate with each other through the communication bus 440. The processor 410 may call logical instructions in the memory 430 to execute the software product dynamic configuration and instantiation method based on version snapshots as described in either Embodiment 1 or 2.

[0149] Furthermore, the logical instructions in the aforementioned memory 430 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, essentially, or the part that contributes to the prior art, or a 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 includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. 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.

[0150] Example 5

[0151] In this embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the program is executed by a processor, it implements the software product dynamic configuration and instantiation method based on version snapshot as described in either Embodiment 1 or 2.

[0152] Example 6

[0153] In this embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the method for dynamic configuration and instantiation of a software product based on version snapshots as described in Embodiment 1 or 2.

[0154] The computer storage medium of this invention can be any combination of one or more computer-readable media. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0155] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0156] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

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

[0158] The embodiments described above are merely illustrative of several implementations of the present invention, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these modifications and improvements all fall within the scope of protection of the present invention. Therefore, the scope of protection of this patent should be determined by the appended claims.

Claims

1. A method for dynamic configuration and instantiation of software products based on version snapshots, characterized in that, The method is executed by a backend, and steps include: Receiving parameterized configuration instructions for the same set of source code, integrating configuration sources, generating and storing version snapshots with unique IDs and their encrypted license files; When the permission determination trigger is triggered, real-time collection of a subject inheritance chain vector, a resource tree vector, an environment snapshot vector, and an operation set vector to form a dynamic four-tuple decision context, wherein the subject inheritance chain vector at least contains a multi-level inheritance relationship of user ID, user group, and tenant ID, the resource tree vector at least contains menus, pages, buttons, APIs, and data fields, the environment snapshot vector at least contains a version snapshot ID, a release time, and an effective state, and the operation set vector at least contains explicit, implicit, available, rejected, and prompt operation types; according to the data characteristics of each vector in the dynamic four-tuple, adaptive selection of bit mask coding, hash coding, or hybrid coding mode to form a decision intermediate representation, and output of an original hit strategy set through vector Boolean operation; According to the current subject along its inheritance chain, collecting associated strategies from the original hit strategy set; When multiple strategies associated with the subject conflict, using a bit vector algorithm combining explicit rejection priority and nearest processing to complete conflict determination, and compressing all access strategies into a 64-bit register to realize single-instruction parallel processing, wherein the rejection strategy is coded as the high 32 bits of a 64-bit integer, the allowed strategy is hierarchically coded in the low 32 bits according to the priority of the user level, user group level, and tenant level, and the high priority coding value is greater than the low priority; through bitwise or operation, it is detected whether there is a valid bit in the high 32-bit area, if there is, the rejection decision is output, if there is not, the priority code with the largest value in the low 32-bit area is extracted through comparison operation and the corresponding allowed strategy is executed; Filtering irrelevant strategies through version snapshot ID, and then encapsulating the generated effective permission set as a configuration manifest; Parsing the abstract strategy in the configuration manifest and mapping it to the UI construction instruction; According to the UI construction instruction, querying the UI component library, outputting the instantiated UI container, and then sending it to the front end for rendering and display.

2. The version snapshot based software product dynamic configuration and instantiation method of claim 1, wherein, The step of receiving parameterized configuration instructions for the same set of source code, integrating configuration sources, generating and storing version snapshots with unique IDs and their encrypted license files, further includes: Receiving parameterized configuration instructions for the same set of source code, and the configuration parameters include but are not limited to: authorization information, personalized page information, and brand information; According to the parameterized configuration instructions, integrating the scattered configuration sources into a unified memory configuration tree through a configuration merging engine, and the configuration sources include but are not limited to: YAML files, database tables, and API interfaces; Performing deterministic hash calculation on the merged memory configuration tree to generate a unique version snapshot ID, and serializing the configuration tree into a compact binary format; Encrypting the version snapshot content using a temporary key to generate a license file that cannot be directly modified, and once the license file is generated, its content cannot be edited or deleted, and only updating through regenerating the version snapshot and performing a new round of encryption authorization is allowed; Establishing a version snapshot index table containing tenant ID, version snapshot ID, and license path.

3. The version snapshot based software product dynamic configuration and instantiation method according to claim 1 or 2, c h a r a c t e r i z e d by, The step of collecting the subject inheritance chain vector, the resource tree vector, the environment snapshot vector and the operation set vector in real time when the permission judgment trigger occurs, forming a dynamic quadruple, and adaptively encoding and operating according to the data characteristics of the quadruple to output the original hit policy set further comprises: When the permission judgment trigger occurs, the subject inheritance chain vector, the resource tree vector, the environment snapshot vector and the operation set vector are collected in real time to form a dynamic quadruple decision context, wherein the subject inheritance chain vector is a multi-level inheritance chain vector containing at least a user ID, a user group to which the user belongs and a tenant ID; the resource tree vector is a resource tree vector containing at least a menu, a page, a button, an API and a data field; the environment snapshot vector is a snapshot environment snapshot vector containing at least a version snapshot ID, a release time and an effective state; and the operation set vector is an operation set vector containing at least an explicit, implicit, available, rejected and prompted operation set vector; According to the data characteristics of the vectors in the dynamic quadruple, a bit mask coding, a hash coding or a mixed coding mode is adaptively selected to form a decision intermediate representation; The decision intermediate representation is sent to a policy decision engine to output the original hit policy set through vector Boolean operation.

4. The version snapshot based software product dynamic configuration and instantiation method according to claim 1 or 2, characterized in that, The step of using an explicit rejection priority combined with a nearest processing bit vector algorithm to complete conflict judgment when multiple policies associated with the subject conflict further comprises: All access policies are compressed into a 64-bit register to realize single-instruction parallel processing, wherein the rejection policy is encoded as the high 32 bits of a 64-bit integer, and the allowed policy is encoded as the low 32 bits of the 64-bit integer; When multiple policies associated with the subject conflict, whether there is an effective bit in the high 32-bit area is detected by performing a bitwise OR operation, if there is, a rejection decision is output; if there is not, the value of the largest number in the priority encoding of the user level, the user group level and the tenant level is extracted by performing a comparison operation, and the allowed policy of the corresponding priority is executed.

5. The version snapshot based software product dynamic configuration and instantiation method according to claim 1 or 2, characterized in that, The step of querying a UI component library according to the UI construction instruction, outputting an instantiated UI container, and then sending the UI container to the front end for rendering and display further comprises: The UI component library is queried according to the UI construction instruction, and an instantiated UI container is output, wherein each function in the UI component library corresponds to multiple visual containers with unique identifiers; The layout properties of each instantiated UI container are normalized and defined, and the basic width, basic height, name and priority of the instantiated container are defined; The instantiated UI container after normalization is sorted in multiple levels to form a container queue, and the sorting weight factors include: pre-configured module priority, user historical layout preference and default business rules; A layout canvas is created, and the instantiated UI container after normalization is placed in the canvas in a pipeline manner according to the order of the container queue; If the runtime two-dimensional size of the current UI container exceeds the remaining threshold of the target layout space, a matching container that can be exchanged is scanned in the subsequent container queue in priority, and if there is a better size, the execution order is exchanged; if there is no exchangeable container, the current container is dynamically scaled by the minimum ratio; The final layout scheme is sent to the front end for rendering and display.

6. The version snapshot based software product dynamic configuration and instantiation method of claim 5, wherein, The scanning specifically comprises: In a single layout calculation cycle, a prospective width and / or height scan is performed on an un-laid-out container, and the order of UI containers in the to-be-laid-out queue is adjusted according to the scan result.

7. A version snapshot based software product dynamic configuration and instantiation apparatus, characterized by, The method comprises the following steps: The configuration source integration module is configured to receive parameterized configuration instructions for the same set of source code, integrate configuration sources, and generate and store a version snapshot with a unique ID and an encrypted license file; The original hit strategy set generation module is configured to, when a permission judgment is triggered, collect a dynamic four-tuple decision context composed of a subject inheritance chain vector, a resource tree vector, an environment snapshot vector, and an operation set vector in real time, wherein the subject inheritance chain vector at least contains a multi-level inheritance relationship of a user ID, a user group to which the user belongs, and a tenant ID, the resource tree vector at least contains a menu, a page, a button, an API, and a data field, the environment snapshot vector at least contains a version snapshot ID, a release time, and an effective state, and the operation set vector at least contains an explicit, implicit, available, denied, and prompted operation type; according to the data characteristics of each vector in the dynamic four-tuple, adaptively select a bit mask encoding, a hash encoding, or a hybrid encoding mode to form a decision intermediate representation, and output an original hit strategy set through vector Boolean operation; The strategy collection module is configured to collect associated strategies from the original hit strategy set by backtracking from the current subject along its inheritance chain; The conflict processing module is configured to, when multiple strategies associated with the subject conflict, complete conflict judgment by using a bit vector algorithm combining explicit denial priority and nearest processing, compress all access strategies into a 64-bit register to realize single-instruction parallel processing, wherein the denial strategy is encoded as the high 32 bits of a 64-bit integer, the permission strategy is hierarchically encoded in the low 32 bits according to the priority of the user level, the user group level, and the tenant level, and the high-priority encoding value is greater than the low-priority encoding value; whether there is a valid bit in the high 32-bit area is detected by performing a bitwise OR operation, if there is, a denial decision is output, and if there is not, the priority encoding with the largest value in the low 32 bits is extracted by comparison operation and the corresponding permission strategy is executed; The filtering module is configured to filter irrelevant strategies by version snapshot ID, and encapsulate the generated valid permission set as a configuration manifest; The configuration manifest analysis module is configured to analyze the abstract strategies in the configuration manifest and map them to UI construction instructions; The container layout and rendering module is configured to query a UI component library according to the UI construction instructions, output instantiated UI containers, and send them to the front end for rendering and display.

8. A computer device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, The processor executes the program to implement the steps of the version snapshot-based software product dynamic configuration and instantiation method of any one of claims 1 to 6.

9. A computer readable storage medium having stored thereon a computer program, characterized in that, The program is executed by the processor to implement the version snapshot-based software product dynamic configuration and instantiation method of any one of claims 1 to 6.

10. A computer program product comprising a computer program, characterized in that, The computer program is executed by the processor to implement the steps of the version snapshot-based software product dynamic configuration and instantiation method of any one of claims 1 to 6.

Images