A SaaS tenant customization service method

Abstract

The application provides a SaaS tenant customization service method, relates to the technical field of software as a service system architecture, and comprises the following steps: generating an independent database or a table space through a tenant identifier, converting configuration parameters into JSON metadata in combination with a graphical tool and storing the JSON metadata, and realizing lightweight customization; according to a deep customization request, allocating an independent server or a container instance to a tenant, deploying personalized code, and realizing separated operation from standard code through a dynamic loading mechanism; generating a unique second-level domain name based on a tenant identifier, routing a request to a corresponding service node through DNS resolution and reverse proxy, supporting migration of a standard tenant to a customized tenant, synchronizing configuration and business data to a target instance, updating domain name resolution and proxy configuration, and realizing seamless switching of a service path.

Description

Technical Field

[0001] This application belongs to the field of Software as a Service (SaaS) system architecture technology, specifically relating to a method for SaaS tenant customization services. Background Technology

[0002] With the development of cloud computing technology, the SaaS (Software as a Service) model has become an important way for enterprises to build their information systems. SaaS ERP systems are widely used due to their advantages such as convenient deployment, centralized operation and maintenance, and low cost. However, traditional SaaS ERP products usually adopt a standardized architecture design, supporting only limited zero-code configuration functions, which makes it difficult to meet the customized needs of enterprises for complex business processes, industry characteristics, or deep functional integration.

[0003] When customers raise functional requirements that exceed the scope of standard products, existing technologies typically employ two solutions: one is to provide customers with an independent system through private deployment, but this approach results in customers bearing high costs for server resources, maintenance teams, and security compliance; the other is to rely on vendors for secondary development and unified upgrades, but this has issues such as long development cycles, slow version iterations, and impact on the stability of other tenants.

[0004] Furthermore, existing SaaS systems rely heavily on database-level logical isolation for tenant isolation, lacking deep isolation mechanisms for service instances, runtime environments, and code layers. This can lead to highly customized tenants potentially interfering with overall system performance. Additionally, the lack of a smooth migration mechanism when customers switch from a standard SaaS environment to a highly customized one can easily result in data loss, service interruptions, or a degraded user experience.

[0005] Therefore, how to maintain the advantages of centralized operation and maintenance and resource sharing of SaaS systems, support lightweight form and process configuration, allow deep code-level extensions, and achieve seamless migration from standard tenants to customized tenants has become a pressing technical challenge. Summary of the Invention

[0006] This application provides a method for customizing services for SaaS tenants to address one of the aforementioned technical problems.

[0007] The technical solution adopted in this application is as follows:

[0008] This application provides a method for customizing services for SaaS tenants, including:

[0009] Receive a tenant’s lightweight customization request, generate an independent database instance or tablespace based on the tenant identifier, receive the tenant’s form, process and application configuration parameters through a graphical interface tool, convert the parameters into metadata in JSON format, and write the metadata into the tenant’s database instance or tablespace to generate a customized configuration data file.

[0010] Based on the tenant's deep customization request, an independent server node or container instance is allocated to the tenant, and the tenant's personalized code is deployed to the server node or container instance. The personalized code includes business logic extension code and dependency libraries. The personalized code is separated from the standard product code through a dynamic loading mechanism, and the personalized code is loaded at runtime based on the tenant identifier.

[0011] A unique second-level domain name is generated based on the tenant identifier, and the domain name is mapped to the IP address of the server node or container instance through DNS resolution service. The domain name request of the tenant is forwarded to the server node or container instance corresponding to the IP address using reverse proxy technology, wherein the forwarding rule is generated based on the mapping relationship between the tenant identifier and the IP address.

[0012] The system receives a migration request from a standard tenant to a customized tenant, extracts the customized configuration data file and business data from the database instance of the standard tenant, and synchronizes the customized configuration data file and business data to the database instance of the target server node or container instance; updates the domain name and IP address mapping relationship in the DNS resolution service, and modifies the reverse proxy configuration to route the tenant's domain name requests to the target server node or container instance.

[0013] According to one embodiment of this application, the process of receiving a tenant's lightweight customization request, generating an independent database instance or tablespace based on the tenant identifier, receiving the tenant's forms, processes, and application configuration parameters through a graphical interface tool, converting the parameters into metadata in JSON format, and writing the metadata into the tenant's database instance or tablespace to generate a customized configuration data file includes:

[0014] By using database sharding technology or tablespace partitioning in a shared database, the customized configuration data files of the tenant are physically isolated from the standard product data;

[0015] When the system starts, the metadata of the standard product is loaded first, and then the customized configuration data file is dynamically loaded according to the tenant identifier. The performance overhead of repeated loading is reduced through a caching mechanism.

[0016] According to one embodiment of this application, the step of allocating an independent server node or container instance to the tenant based on the tenant's deep customization request, deploying the tenant's personalized code to the server node or container instance, wherein the personalized code includes business logic extension code and dependency libraries, separating the personalized code from the standard product code through a dynamic loading mechanism, and loading the personalized code at runtime based on the tenant identifier, includes:

[0017] An extension directory is reserved in the standard product code project. The extension directory defines loading rules through an independent configuration file. The configuration file contains the mapping relationship between the tenant identifier and the extension code path.

[0018] Allocate independent CPU and memory resources to the server nodes or container instances, and limit the usage limit of the resources through container orchestration technology to avoid resource contention between tenants.

[0019] According to one embodiment of this application, the step of generating a unique second-level domain name based on the tenant identifier, mapping the domain name to the IP address of the server node or container instance through a DNS resolution service, and forwarding the tenant's domain name request to the server node or container instance corresponding to the IP address using reverse proxy technology, wherein the forwarding rule is generated based on the mapping relationship between the tenant identifier and the IP address, including:

[0020] The unique second-level domain name is generated based on the tenant identifier;

[0021] The A records in the DNS resolution service are updated in real time via the API interface to ensure that the mapping relationship between the domain name and the IP address takes effect immediately after the tenant migrates.

[0022] Based on the mapping relationship between the tenant identifier and the IP address, the Nginx reverse proxy configuration file is dynamically generated, and the configuration changes are made effective immediately through hot reload technology.

[0023] According to one embodiment of this application, the steps of receiving a migration request from a standard tenant to a customized tenant, extracting the customized configuration data file and business data from the database instance of the standard tenant, synchronizing the customized configuration data file and business data to the database instance of the target server node or container instance, updating the domain name and IP address mapping relationship in the DNS resolution service, and modifying the reverse proxy configuration to route the tenant's domain name requests to the target server node or container instance include:

[0024] The customized configuration data file and business data are packaged into a compressed file using a database backup tool, and the compressed file is synchronized to the target server node or container instance via a network transmission protocol.

[0025] After data synchronization is complete, the domain name requests of the tenant are gradually switched to the target server node or container instance by modifying the DNS resolution records and reverse proxy configuration. During the switching process, user requests are intercepted and migration progress prompts are displayed.

[0026] According to one embodiment of this application, it also includes:

[0027] The management backend displays the data synchronization progress, resource usage status of the target server node, and migration failure rate in real time.

[0028] If the migration fails, the customized configuration data file and business data will be automatically restored to the source server node before the migration, and the original DNS resolution records and reverse proxy configuration will be reactivated.

[0029] According to one embodiment of this application, it also includes:

[0030] The graphical interface tool supports drag-and-drop operations, parameter configuration, and flowchart design, and converts the operation results into metadata in the JSON format in real time.

[0031] Version management is implemented for the customized configuration data files, allowing tenants to roll back to historical versions via a version selector or apply the current version of the configuration file via the publish function.

[0032] According to one embodiment of this application, it also includes:

[0033] Deploying a hot code update module in the server node or container instance allows the personalized code to be dynamically loaded or updated without restarting the service;

[0034] The dependency libraries of the personalized code are version controlled by a package management tool, and missing dependency libraries are automatically downloaded during deployment.

[0035] A second aspect of this application provides a computer-readable storage medium having a program stored thereon that, when executed by a processor, implements the steps described in the method.

[0036] A third aspect of this application provides an electronic device including a memory, a processor, and a program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the method as described.

[0037] Due to the adoption of the above technical solution, the beneficial effects achieved by this application are as follows:

[0038] This application transforms tenant form and process configuration parameters into structured JSON metadata and persists it in an independent database instance, enabling standard products to dynamically load tenant-specific configurations at runtime. This technique achieves zero-code-level personalization adaptation, avoiding modifications to core code and improving system flexibility and maintainability. Simultaneously, it provides a "personalized code deployment" mechanism for tenants requiring deeper customization, running extended code on independent server nodes or container instances and dynamically loading it at runtime based on tenant identifiers. This ensures that complex business logic can be executed independently without affecting other tenants, thus balancing standardization and deep customization capabilities within the same platform architecture.

[0039] This application achieves service-level resource isolation by allocating independent server nodes or container instances to deeply customized tenants and separating personalized code from standard product code at the deployment and loading levels. Combined with containerization technology's limitation of CPU, memory, and other resources, it effectively prevents individual high-load tenants from impacting overall system performance, thus improving system stability and security in multi-tenant environments.

[0040] This application utilizes the technical means of "generating a unique second-level domain name based on the tenant identifier" and "mapping it to the corresponding IP address through DNS resolution service" to construct a direct mapping relationship between tenant identity and service nodes. Then, a reverse proxy forwards requests based on this mapping relationship, enabling access from different tenants to be accurately directed to their dedicated service instances. This tenant identifier-driven routing mechanism not only improves access efficiency but also provides foundational support for subsequent advanced features such as load balancing and canary releases.

[0041] During the migration process, this application "extracts customized configuration data files and business data from the standard tenant database" and migrates them to the target customized node through a synchronization mechanism, ensuring the integrity of the configuration and data. Furthermore, "updating DNS resolution records and reverse proxy configuration" allows tenant access paths to smoothly switch to the new service node. The entire migration process is completed automatically in the background, with user requests temporarily intercepted and migration status displayed, minimizing business interruption time. This technical solution significantly reduces the technical barriers and operational risks for customers upgrading to customized tiers, improving service continuity and customer satisfaction.

[0042] This application establishes a clear data flow loop: tenant configuration parameters generate customized configuration files → configuration files are bound to tenant identifiers → identifiers are used for service deployment and domain name generation → domain name mapping guides request routing → existing configuration files are reused during migration to complete environment reconstruction. This end-to-end linkage mechanism, with tenant identifiers at its core and data as the link, ensures that all components of the system are coordinated and consistent, improving the overall level of automation and manageability. Attached Figure Description

[0043] 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:

[0044] Figure 1 A flowchart illustrating a SaaS tenant customization service method provided in this application embodiment;

[0045] Figure 2 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0046] Figure label:

[0047] 810, Processor; 820, Communication interface; 830, Memory; 840, Communication bus. Detailed Implementation

[0048] To more clearly illustrate the overall concept of this application, a detailed explanation is provided below with reference to the accompanying drawings.

[0049] Many specific details are set forth in the following description to provide a thorough understanding of this application. However, this application may also be implemented in other ways different from those described herein. Therefore, the scope of protection of this application is not limited to the specific embodiments disclosed below. It should be noted that, unless otherwise specified, the embodiments of this application and the features thereof can be combined with each other.

[0050] In this application, unless otherwise expressly specified and limited, the "above" or "below" of the second feature can mean that the first and second features are in direct contact, or that the first and second features are in indirect contact through an intermediate medium. In the description of this specification, references to terms such as "an embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples.

[0051] Example 1

[0052] like Figure 1 As shown, a method for customizing services for SaaS tenants includes:

[0053] The system receives lightweight customization requests from tenants, generates independent database instances or tablespaces based on tenant identifiers, receives tenant forms, processes, and application configuration parameters through a graphical interface tool, converts the parameters into metadata in JSON format, and writes the metadata into the tenant's database instance or tablespace to generate customized configuration data files.

[0054] As mentioned above, non-code-level personalized configuration information of tenants is received and persisted in a structured manner, while ensuring data isolation and independent management between different tenants.

[0055] First, the system receives a lightweight customization request from a specific tenant. This request is typically initiated by the tenant administrator through the web front-end interface and involves adjustments to the interface layout, field display, approval rules, and business process sequence of standard ERP functional modules (such as purchase orders, expense reimbursement processes, customer files, etc.).

[0056] Upon receiving a request, the system creates an independent data storage environment for the tenant based on their unique tenant ID within the platform. This environment can be a physically isolated independent database instance, or a dedicated tablespace or set of dedicated tables within a shared database. This design ensures that a tenant's customized data is not shared with other tenants, avoiding data contamination and access violation issues, while also facilitating subsequent data migration, backup, and recovery operations.

[0057] Subsequently, the system provides users with a visual interface through a graphical configuration tool. Users can complete configurations by dragging and dropping fields, setting conditional branches, and adjusting form styles. The system parses these user actions into structured descriptive information and serializes it in JSON format. JSON, as a lightweight, highly readable, and cross-platform compatible data exchange format, can flexibly express various data forms such as nested structures, arrays, and key-value pairs, making it suitable for describing complex configurations such as form structures, process nodes, and permission rules.

[0058] Finally, the system writes the generated JSON-formatted metadata into the tenant's dedicated database instance or tablespace, forming a "customized configuration data file." Logically, this file can be viewed as a "differential description" of the tenant's standard product functionality, recording all modifications made relative to the standard version. During system runtime, this configuration file is dynamically loaded and merged with the standard product metadata, resulting in a customized user interface and business behavior.

[0059] For example, a manufacturing company using a SaaS ERP system wants to add an "environmental compliance approval" step to the standard "purchase requisition form" and add a "supplier carbon emission level" field to the form.

[0060] After logging into the system, the tenant administrator enters the "Form Designer" module and selects "Purchase Request Form" for editing. Through the graphical interface, the administrator drags and drops to add a new "Text Input Box" field, names it "Supplier Carbon Emission Level," sets it as a required field, and limits the selectable values ​​to "Level A," "Level B," and "Level C." Subsequently, in the approval process design area, the administrator adds a new approval node "Environmental Specialist Review," and sets its trigger condition to "when the purchase amount exceeds 500,000 yuan and the material category is chemical."

[0061] The system parses the above operations into a set of structured configuration information, including the name, type, constraints, and display location of newly added fields; the name, execution role, and triggering conditions of process nodes. This information is organized into a JSON structure, such as a data block containing key-value items like "fields", "rules", and "workflow_nodes".

[0062] The system writes the JSON data into the tenant's dedicated database table `tenant_config` based on the tenant's tenant identifier (e.g., "tenant_2025_mfg"), marking the record type as "form_customization". This record is the "customized configuration data file" generated for this lightweight customization. When users subsequently access purchase requisition forms, the system automatically loads this configuration, dynamically rendering an interface containing the new fields and approval processes, while other tenants continue to use the original standard version, without affecting each other.

[0063] It should be noted that, in specific implementation scenarios, in addition to the above solutions, a version chain can be established in the database for each customized configuration data file, recording the timestamp, operator, and change summary for each modification. Tenants can roll back to any historical version at any time, or preview the effect of the new configuration in a test environment, improving the security and flexibility of configuration management.

[0064] In specific implementation scenarios, based on the above solutions, the system can export a tenant's customized configuration data file as a reusable "configuration template" for other tenants with similar business needs to directly import and use, reducing the workload of repetitive configuration and improving implementation efficiency.

[0065] In specific implementation scenarios, the above solutions can be further customized beyond single functional modules, defining cross-module business rules. For example, rules such as "automatically generate pre-production scheduling tasks in the production plan when a sales order contains a specific product" can also be configured through graphical tools and stored in JSON format, enabling lightweight integration between modules.

[0066] In specific implementation scenarios, based on the above solution, JSON metadata can be encrypted before being written to the database to ensure the security of sensitive configuration information (such as approval rules and field permissions) at the storage layer. Simultaneously, read and write permissions for configuration data can be defined based on roles to prevent unauthorized personnel from modifying critical business logic.

[0067] In specific implementation scenarios, based on the above solution, when the customized configuration data file is updated, the system can automatically trigger a set of preset test cases to verify whether the new configuration causes functional abnormalities or performance degradation, thus forming a closed-loop quality assurance mechanism.

[0068] In specific implementation scenarios, based on the above solution, in the subsequent "one-click migration" step, this customized configuration data file will be extracted and synchronized to the target customized service node as one of the core inputs. This will be used to rebuild the tenant's personalized functions in the new environment and ensure the consistency of user experience before and after the migration.

[0069] Based on the tenant's deep customization request, an independent server node or container instance is allocated to the tenant, and the tenant's personalized code is deployed to the server node or container instance. The personalized code includes business logic extension code and dependency libraries. The personalized code is separated from the standard product code through a dynamic loading mechanism, and the personalized code is loaded at runtime based on the tenant identifier.

[0070] As mentioned above, by using resource isolation and code decoupling mechanisms, the advantages of centralized SaaS operation and maintenance are retained while giving specific tenants an independent operating environment and code extension capabilities.

[0071] When the system receives a deep customization request from a tenant (such as requiring the implementation of special production scheduling algorithms, complex cost accounting logic, or deep integration with third-party systems), it indicates that the tenant's needs exceed the capabilities of the graphical configuration tool and must be implemented through written program code. At this point, the system initiates the service isolation process.

[0072] First, based on the tenant's tenant identifier, a dedicated server node or container instance is allocated to them. This node can be a physical server, a virtual machine, or a lightweight runtime environment built using container technologies such as Docker. This resource is independent of the standard SaaS shared service cluster, ensuring that the tenant's workload, security policies, and deployment schedule are not affected by other tenants, while also preventing abnormal behavior from interfering with the overall stability of the platform.

[0073] Subsequently, the system deploys the customized code package developed by the tenant or provided by the service provider to this independent node. This code package not only contains business logic extension code that implements specific business functions, but also all external dependency libraries required for operation (such as encryption components, reporting engines, communication middleware, etc.). These code and library files are placed in a preset extension directory, maintaining physical separation from the standard product code at the file system level.

[0074] Crucially, the system employs a dynamic loading mechanism. At runtime, it determines whether to load the tenant's customized code based on the tenant identifier in the current access request. If the request belongs to that customized tenant, the system prioritizes loading the standard product code as the basic runtime environment, and then dynamically injects its customized code modules to achieve feature overlay. If the request belongs to another standard tenant, only the standard code is loaded, without triggering extended logic. This on-demand loading mechanism ensures efficient resource utilization and system stability.

[0075] This step enables a flexible combination model of "one standard product architecture + multiple personalized extension capabilities", which ensures that most tenants use unified and stable standard services, while providing tenants with special needs with near-private deployment flexibility, without requiring customers to assume the responsibility for infrastructure operation and maintenance.

[0076] For example, take a car parts manufacturing company as an example. The company needs to implement a "dynamic capacity prediction and production scheduling optimization" function based on AI algorithms in its ERP system. This function involves complex mathematical models and external AI service calls, which cannot be implemented with zero-code tools.

[0077] When a tenant submits a deep customization request, the system allocates an independent container instance to it based on its tenant identifier "tenant_auto_007". This instance runs in a dedicated customized resource pool and is configured with high CPU and memory resources to support compute-intensive tasks.

[0078] The development team packages the "scheduling optimization service" code (including algorithm logic, data interfaces, scheduler, etc.) and its dependent machine learning libraries and message queue clients into a deployment package and uploads it to the system. The system automatically unzips and deploys it to the extended directory of the container instance (e.g., / opt / ext / scheduling).

[0079] During system operation, when a tenant initiates a "Generate Production Plan" operation, the request includes a tenant identifier. The service gateway recognizes this identifier and routes the request to the tenant's dedicated container instance. Once the instance starts, it first loads standard ERP core modules (such as material management and order processing), then dynamically loads the "Production Scheduling Optimization" code module located in the extension directory and registers it as a callable service. Ultimately, the user receives intelligent production scheduling results driven by AI algorithms.

[0080] For other tenants who have not customized this feature, their similar requests will still be handled by the standard service cluster, which will only execute basic scheduling logic, and the overall system operation will not be affected.

[0081] It should be noted that, in specific implementation scenarios, based on the above solutions, a tenant's personalized functional module, after undergoing security review and standardized encapsulation, can be used as an "industry plugin" for other tenants with similar needs to subscribe to, thereby realizing the reuse and commercialization of customization capabilities and enhancing the platform's ecosystem value.

[0082] In specific implementation scenarios, based on the above solutions, after deploying the new version of personalized code on independent nodes, access can be initially made available to a limited number of users. By comparing and analyzing their behavioral data with system performance, the stability of the function can be verified, and then the coverage can be gradually expanded to reduce the risk of going live.

[0083] In specific implementation scenarios, based on the above solutions, the system can dynamically replace or update personalized code modules without interrupting services, achieving "hot deployment." For example, when an algorithm defect is discovered, operations and maintenance personnel can upload a new version of the code package, and the system will automatically uninstall the old module and load the new module, ensuring business continuity.

[0084] In specific implementation scenarios, based on the above solutions, the system can automatically adjust the resource configuration of the container instance or start multiple instances to achieve horizontal scaling, thereby improving the response capability under high load scenarios, according to the load conditions of the tenant's personalized services (such as CPU utilization and the number of concurrent requests).

[0085] In specific implementation scenarios, based on the above solutions, independent log collection channels and performance monitoring metrics can be established for each customized tenant to facilitate quick problem location, analysis of call chains, and provide data support for subsequent billing and optimization.

[0086] In specific implementation scenarios, based on the above solution, in the subsequent "one-click migration" process, the independent server node or container instance can serve as the target runtime environment, receiving configuration data and business data migrated from the standard tenant, thus achieving a smooth evolution from "lightweight customization" to "deep customization".

[0087] In specific implementation scenarios, based on the above solutions, runtime security detection mechanisms can be introduced into container instances to restrict system call permissions for personalized code (such as prohibiting access to sensitive files and restricting network connections), preventing malicious code or vulnerabilities from harming the system and improving overall security.

[0088] A unique second-level domain name is generated based on the tenant identifier, and the domain name is mapped to the IP address of the server node or container instance through DNS resolution service. The domain name request of the tenant is forwarded to the server node or container instance corresponding to the IP address using reverse proxy technology, wherein the forwarding rule is generated based on the mapping relationship between the tenant identifier and the IP address.

[0089] As mentioned above, after the system completes the lightweight or deeply customized configuration of a tenant, it is necessary to ensure that users can access their dedicated runtime environment through an independent and identifiable access point. To this end, the system automatically generates a bound subdomain based on the tenant's unique tenant identifier (TenantID). For example, if the tenant identifier is "comp_tech_2025", the system generates a corresponding subdomain such as "comp-tech-2025.platform.com". This domain name is globally unique, ensuring that access conflicts do not occur between different tenants.

[0090] After generating a domain name, the system uses an integrated DNS resolution service (such as PowerDNS or a self-developed domain name management system) to establish a mapping relationship between the second-level domain name and the IP address of the service node corresponding to the tenant. This service node may be a virtual host in a standard shared cluster, or it may be a dedicated server or container instance allocated for a deeply customized tenant. This mapping relationship is persistently stored in the domain name management database and supports dynamic updates.

[0091] When a user accesses the subdomain through a browser, the DNS system returns the corresponding service node IP address, completing the domain name resolution. Subsequently, the request reaches the reverse proxy server (such as Nginx or HAProxy) deployed at the front end. This proxy server, based on pre-generated forwarding rules, further forwards the request to the target server node or container instance. These forwarding rules are not statically configured but dynamically generated routing strategies based on the "tenant identifier—IP address" mapping relationship. This ensures that even if the service node migrates or its IP address changes, the access path is automatically adjusted as long as the mapping relationship is updated.

[0092] This mechanism decouples the access point from the backend service instance, allowing the system to flexibly adjust the tenant's deployment location, achieve load balancing, or perform migration operations without affecting user access. It is an important foundation for supporting the operability and scalability of the entire customized service system.

[0093] For example, consider a large retail enterprise tenant. This enterprise has completed a deep customization of its ERP system, and its business logic runs in an independent container instance, which is assigned the IP address "192.168.10.55".

[0094] The system generates a unique second-level domain name "retail-group-cn.platform.com" based on the tenant's tenant identifier "retail_group_cn", and registers the domain name to the internal DNS resolution service through the DNS management interface, creating an A record "retail-group-cn.platform.com→192.168.10.55".

[0095] When an employee of the company enters "https: / / retail-group-cn.platform.com" in their browser, the local DNS lookup first resolves the domain name to "192.168.10.55," and the request is sent to the reverse proxy cluster deployed at the data center's entry point. Upon receiving the request, the reverse proxy server checks its internal routing table to confirm that the IP address corresponds to a container instance running a customized ERP service, and then forwards the HTTP request to the host where that instance resides.

[0096] Throughout the process, users do not need to be aware of the specific deployment location of the backend service. Even if the container instance is subsequently migrated to a new node due to resource expansion (e.g., the IP changes to "192.168.12.33"), the system only needs to update the mapping relationship in the DNS service and refresh the forwarding rules of the reverse proxy simultaneously. Users can still seamlessly access the system through the original domain name, and access continuity is not affected.

[0097] It should be noted that, in specific implementation scenarios, based on the above solution, a regionalized second-level domain name (such as "cn.retail-group.platform.com") can be generated according to the tenant's geographical location, and requests can be directed to the nearest data center node through DNS intelligent resolution, thereby reducing network latency and improving the access experience.

[0098] In specific implementation scenarios, based on the above solution, multiple subdomains or subpaths (such as "beta.retail-group-cn.platform.com") can be configured for the same tenant during system upgrades to redirect some user traffic to the new version service node, enabling gray-scale verification, and then switching to the full version after stabilization.

[0099] In specific implementation scenarios, based on the above solutions, tenants can also be allowed to use their own enterprise domain name (such as "erp.retailgroup.com") to point to the platform-generated subdomain through CNAME records. The system will automatically identify and match the corresponding tenant identifier and backend service instance to improve brand consistency.

[0100] In specific implementation scenarios, based on the above solutions, the system can automatically apply for and deploy SSL / TLS certificates for each subdomain, support HTTPS encrypted transmission, and automatically trigger the renewal process when the certificate is about to expire, ensuring communication security.

[0101] In specific implementation scenarios, based on the above solution, forwarding rules can be generated in real time based on the "tenant identifier-IP address" mapping in the database. The proxy server can detect configuration changes through a listening mechanism and dynamically update the routing table without restarting the service, achieving zero-interruption configuration updates.

[0102] In specific implementation scenarios, based on the above solutions, when tenants migrate from a standard environment to a customized environment, the system can seamlessly switch the original access path to the new service node by updating DNS mapping and reverse proxy rules after data synchronization is completed, so that users can complete the upgrade without being aware of it.

[0103] In specific implementation scenarios, based on the above solutions, domain name access for specific tenants can be associated with security policies such as IP whitelists, access frequency limits, and identity authentication methods to achieve fine-grained access control.

[0104] In specific implementation scenarios, in addition to HTTP / HTTPS, this mechanism can also be extended to protocols such as WebSocket and gRPC to ensure that functions such as real-time communication and remote calls in customized services can also be correctly routed through a unified domain name entry point.

[0105] The system receives a migration request from a standard tenant to a customized tenant, extracts the customized configuration data file and business data from the database instance of the standard tenant, and synchronizes the customized configuration data file and business data to the database instance of the target server node or container instance; updates the domain name and IP address mapping relationship in the DNS resolution service, and modifies the reverse proxy configuration to route the tenant's domain name requests to the target server node or container instance.

[0106] As mentioned above, when a standard tenant requests to upgrade to a customized tenant due to business development needs (e.g., to introduce independent code extensions, dedicated resource isolation, or a higher security level), the system receives the migration request and initiates an automated migration process. This request is typically initiated by the platform administrator or tenant administrator in the unified management backend. The system identifies the source environment (standard tenant) and the target environment (customized service node) based on the tenant identifier included in the request.

[0107] First, the system accesses the database instance currently used by the standard tenant and extracts two types of key data: one is the "customized configuration data file" (such as metadata like JSON-formatted forms, processes, and permissions) previously generated and stored through graphical tools; the other is the tenant's long-term accumulated business operation data (such as order records, customer profiles, and financial vouchers). These two types of data together constitute the core assets of the tenant's personalization capabilities and historical business.

[0108] Subsequently, the system synchronizes the extracted data to the target environment—namely, the database instance within the newly allocated independent server node or container instance for the tenant—via a secure transmission channel. The synchronization process supports breakpoint resumption and data verification mechanisms to ensure data integrity and consistency. After the data is written to the target database, the system verifies data availability and establishes a connection with the target runtime environment.

[0109] Next, the system performs an access path switching operation. By calling the management interface of the DNS resolution service, the mapping relationship between the tenant's subdomain and IP address is updated, so that it points from the original shared cluster IP address to the newly assigned independent service node IP address. At the same time, the configuration of the reverse proxy server is also dynamically modified, so that when it receives a domain name request from this tenant, it can accurately forward the traffic to the new target node.

[0110] During the migration process, the system can temporarily block user access and return messages such as "System upgrade in progress, please access later" to prevent users from operating under inconsistent data conditions. Once the migration is complete and the service is verified to be working properly, the system will automatically restore access, and users can seamlessly enter the upgraded customized environment through their original domain name, with all original functions, data, and usage habits remaining unchanged.

[0111] This step enables a non-disruptive evolution from "shared resources + configuration-level customization" to "independent resources + code-level extension," significantly reducing the technical barriers to customer upgrades and the risk of business interruption.

[0112] For example, a medium-sized manufacturing enterprise initially used the SaaS ERP system as a standard tenant. Its customization needs were limited to modifying purchase order fields and approval processes, with related configurations stored in its dedicated database in JSON format. As its business expanded, the enterprise needed to integrate an MES system and customize its production scheduling algorithm, so it decided to upgrade to a deeply customized tenant.

[0113] The administrator selects the tenant in the management backend and clicks the "Upgrade to Customized Tenant" button. The system automatically generates a migration task. The system locates the current database instance based on the tenant identifier "mfg_2025_zj" and extracts the customized configuration file (such as "purchase_form_config.json") and business data such as procurement, inventory, and production from the past five years.

[0114] The system encrypts and transmits this data, then writes it to the database mounted on the newly created container instance (IP: 192.168.15.88). After data synchronization is complete, the system calls the DNS service interface to update the record for the domain name "mfg-2025-zj.platform.com" that originally pointed to the shared cluster IP "192.168.10.20" to "192.168.15.88". Simultaneously, the reverse proxy server updates its routing table to ensure that subsequent requests for this domain name are forwarded to the new node.

[0115] During the migration, users accessing the original domain saw a "System is upgrading" message. Approximately 15 minutes later, the migration was complete, and the system was unblocked. When users accessed the system again, it was running on an independent node, with all original form configurations and business data fully preserved. The newly added production scheduling service was also available, achieving a seamless upgrade.

[0116] It should be noted that, in specific implementation scenarios, the system can also support customized tenants to migrate back to the standard shared environment under specific conditions (such as business simplification and cost optimization) based on the above solutions. The migration process is reversible, ensuring architectural flexibility.

[0117] In specific implementation scenarios, based on the above solutions, the system can perform a full synchronization before the formal migration, continuously capturing change logs from the source database to achieve incremental data synchronization. Administrators can activate "pre-migration mode" to verify functional integrity in the target environment, reducing the risk of formal switchover.

[0118] In specific implementation scenarios, based on the above solutions, if the target environment's database structure changes (such as field type adjustments or index optimizations), the system can automatically perform data format conversion during the synchronization process to ensure compatibility.

[0119] In specific implementation scenarios, based on the above solutions, for tenants with large amounts of data, the migration can be carried out in modules (such as migrating master data first and then transaction data) to reduce the pressure of a single operation and improve the success rate.

[0120] In specific implementation scenarios, based on the above solutions, the management backend can also display indicators such as migration progress, data synchronization rate, target node resource usage, and number of failure retries in real time, making it easier for operations and maintenance personnel to grasp the overall status.

[0121] In specific implementation scenarios, based on the above solutions, if service anomalies or data inconsistencies are detected after migration, the system can automatically trigger a rollback process to restore DNS records and reverse proxy configurations to their pre-migration state and prompt the administrator to intervene, ensuring business continuity.

[0122] In specific implementation scenarios, based on the above solutions, the platform can proactively initiate migration tasks based on indicators such as tenant resource utilization and service load, to migrate high-load tenants from the shared cluster to independent nodes, or to reclaim resources from low-activity tenants, thereby achieving dynamic resource scheduling.

[0123] In specific implementation scenarios, based on the above solutions, combined with geographic DNS resolution capabilities, the system can migrate tenants from one data center to another data center in another region to meet data localization compliance requirements or disaster recovery needs.

[0124] In specific implementation scenarios, based on the above solutions, after the migration is completed, the system can automatically update the tenant's service level identifier and trigger a change in billing policy (such as switching from a standard subscription fee to a customized service fee), thereby achieving the coordinated evolution of business and technology.

[0125] According to one embodiment of this application, the process of receiving a tenant's lightweight customization request, generating an independent database instance or tablespace based on the tenant identifier, receiving the tenant's forms, processes, and application configuration parameters through a graphical interface tool, converting the parameters into metadata in JSON format, and writing the metadata into the tenant's database instance or tablespace to generate a customized configuration data file includes:

[0126] By using database sharding technology or tablespace partitioning in a shared database, the customized configuration data files of the tenant are physically isolated from the standard product data;

[0127] When the system starts, the metadata of the standard product is loaded first, and then the customized configuration data file is dynamically loaded according to the tenant identifier. The performance overhead of repeated loading is reduced through a caching mechanism.

[0128] As described above, upon receiving a tenant's lightweight customization request, the system creates an independent data storage environment for that tenant based on their unique tenant identifier. This storage environment can be implemented using database sharding technology, where each tenant is allocated an independent database instance, ensuring complete physical isolation between tenants' data. Alternatively, within a shared database architecture, tenant data isolation can be achieved by dividing the database into independent tablespaces or using dedicated sets of data tables. Regardless of the method used, it ensures that the tenant's customized configuration data files are separated from the standard product's metadata at the storage level, preventing data contamination between different tenants or between a tenant and the standard system, thereby improving data security and management independence.

[0129] After establishing the data storage environment, the system provides tenants with visual configuration capabilities through a graphical interface tool. Tenants can use this tool to adjust form structures, field attributes, approval processes, and application interface layouts. The system parses the configuration parameters entered by the tenant in the graphical interface and converts them into structured JSON metadata. JSON format offers good readability and extensibility, clearly expressing the hierarchical relationships, data types, and constraints of configuration items. After conversion, the system writes this JSON metadata to the tenant's corresponding database instance or tablespace, forming a complete customized configuration data file as a persistent record of the tenant's personalized settings.

[0130] When the system starts or processes tenant-related requests, it first loads the standard product's default generic metadata to build the basic functional framework. Then, based on the tenant identifier carried in the current access request, the system locates the tenant's dedicated database instance or tablespace and reads its customized configuration data file. The configuration content described in this file is merged with the standard metadata to generate the final user interface and execution logic. To improve loading efficiency and reduce performance overhead from frequent database reads, the system introduces a caching mechanism. After the tenant's customized configuration data file is loaded for the first time, it is stored in an in-memory cache with a reasonable cache expiration period or update strategy. Subsequent requests from the same tenant can directly read the configuration information from the cache, avoiding repeated database access operations, thereby reducing system response latency and improving overall performance.

[0131] According to one embodiment of this application, the step of allocating an independent server node or container instance to the tenant based on the tenant's deep customization request, deploying the tenant's personalized code to the server node or container instance, wherein the personalized code includes business logic extension code and dependency libraries, separating the personalized code from the standard product code through a dynamic loading mechanism, and loading the personalized code at runtime based on the tenant identifier, includes:

[0132] An extension directory is reserved in the standard product code project. The extension directory defines loading rules through an independent configuration file. The configuration file contains the mapping relationship between the tenant identifier and the extension code path.

[0133] Allocate independent CPU and memory resources to the server nodes or container instances, and limit the usage limit of the resources through container orchestration technology to avoid resource contention between tenants.

[0134] As described above, based on a tenant's deep customization request, the system allocates a dedicated server node or container instance to provide a dedicated runtime environment. This node can be a physical server, a virtual machine, or a runtime instance built using container technology, used to host the tenant's personalized business logic code. After allocation, the system deploys the personalized code developed by the tenant or provided by the service provider to this dedicated node. This personalized code includes extended logic for standard product functions, such as custom business processing flows, data calculation rules, and external system interfaces, as well as third-party library files or components that the code depends on.

[0135] To decouple customized code from standard product code, the system pre-defines an extension directory within the standard product code project structure, specifically for storing customized code modules from each tenant. This extension directory is not involved in the compilation and release process of the standard product's main code, ensuring that customized content does not affect the stability of the standard system. The system manages the loading behavior of extension code through a separate configuration file, which records the mapping relationship between each tenant's tenant identifier and its corresponding extension code storage path. When the system runs, it looks up the configuration file based on the tenant identifier in the current request, determines the code path to be loaded, and loads the corresponding extension module according to the rules.

[0136] During operation, the system employs a dynamic loading mechanism, enabling personalized code to be identified and executed without modifying the standard product's main program. Specifically, when a service starts or processes a request, the system first loads the standard product code to build the basic runtime environment; then, it determines whether extension code needs to be loaded based on the tenant identifier. If a corresponding configuration exists, the personalized code module for that tenant is dynamically loaded and integrated into the current execution context, allowing for on-demand feature overlay.

[0137] To ensure overall system stability and fairness, and to prevent individual tenants from impacting other tenants or platform services due to excessive resource consumption, the system assigns independent CPU and memory resource quotas to each allocated server node or container instance. In containerized deployment scenarios, container orchestration technologies (such as Kubernetes or Docker Swarm) are used to precisely control resource usage, for example, by setting limits on the number of CPU cores and memory caps. When a tenant's code exceeds the set resource thresholds during execution, the system will automatically isolate resources or perform rate limiting to prevent interference with other services. This mechanism effectively achieves reasonable resource allocation and isolation in a multi-tenant environment, improving system reliability and maintainability.

[0138] According to one embodiment of this application, the step of generating a unique second-level domain name based on the tenant identifier, mapping the domain name to the IP address of the server node or container instance through a DNS resolution service, and forwarding the tenant's domain name request to the server node or container instance corresponding to the IP address using reverse proxy technology, wherein the forwarding rule is generated based on the mapping relationship between the tenant identifier and the IP address, including:

[0139] The unique second-level domain name is generated based on the tenant identifier;

[0140] The A records in the DNS resolution service are updated in real time via the API interface to ensure that the mapping relationship between the domain name and the IP address takes effect immediately after the tenant migrates.

[0141] Based on the mapping relationship between the tenant identifier and the IP address, the Nginx reverse proxy configuration file is dynamically generated, and the configuration changes are made effective immediately through hot reload technology.

[0142] As described above, a unique second-level domain name is generated based on the tenant's tenant identifier. The naming rules for this domain name are based on the tenant identifier, using a preset format conversion method to form a resolvable domain name string. For example, special characters in the tenant identifier are replaced with hyphens or underscores and appended to the platform's main domain name, forming a second-level domain name like "tenant-id.platform.com". This generation method ensures that each tenant's access point is unique globally, avoiding domain name conflicts.

[0143] After generating a second-level domain name, the system establishes a mapping between the domain name and its corresponding service node IP address by calling the API interface provided by the DNS resolution service. This mapping is stored in the DNS server as an A record, enabling external networks to obtain the correct IP address when resolving the domain name. When a tenant migrates, a service node changes, or an IP address is adjusted, the system again updates the A record in the DNS in real time through the same API interface, deleting the old mapping and writing the new IP address. Due to the immediacy of API calls, this update process can be completed within seconds, ensuring that the domain name resolution results take effect quickly after changes, reducing user access interruption time.

[0144] After a request reaches the network entry point, the reverse proxy server is responsible for further request forwarding. The reverse proxy's forwarding rules rely on the mapping between tenant identifiers and IP addresses. Based on this mapping, the system automatically generates configuration files suitable for reverse proxy software (such as Nginx), containing rules for each tenant domain name and its corresponding target IP address and port. This configuration file generation process is dynamic and requires no manual intervention.

[0145] After the configuration file is generated, the system applies it to the running proxy service using the hot reload technology supported by the reverse proxy software. Hot reload enables new forwarding rules to take effect immediately without interrupting existing connections or restarting service processes. User requests can then be correctly routed to the updated service node on the next access, achieving seamless switching of access paths. This mechanism ensures service continuity and high availability, while also supporting frequent deployment changes and migration operations.

[0146] According to one embodiment of this application, the steps of receiving a migration request from a standard tenant to a customized tenant, extracting the customized configuration data file and business data from the database instance of the standard tenant, synchronizing the customized configuration data file and business data to the database instance of the target server node or container instance, updating the domain name and IP address mapping relationship in the DNS resolution service, and modifying the reverse proxy configuration to route the tenant's domain name requests to the target server node or container instance include:

[0147] The customized configuration data file and business data are packaged into a compressed file using a database backup tool, and the compressed file is synchronized to the target server node or container instance via a network transmission protocol.

[0148] After data synchronization is complete, the domain name requests of the tenant are gradually switched to the target server node or container instance by modifying the DNS resolution records and reverse proxy configuration. During the switching process, user requests are intercepted and migration progress prompts are displayed.

[0149] As described above, when the system receives a migration request to upgrade from a standard tenant to a customized tenant, it first identifies the source tenant environment and the target deployment environment based on the tenant identifier in the request. The source environment is the shared database instance where the tenant currently resides, and the target environment is the database instance within an allocated standalone server node or container instance.

[0150] The system initiates the data migration process, first extracting the tenant's customized configuration data file and historical business data from the source database instance. The customized configuration data file includes JSON-formatted metadata previously generated and stored using graphical tools, such as form configurations, process rules, and permission settings; the business data includes actual operational data generated by the tenant during use, such as orders, customers, inventory, and financial data. The system uses a database backup tool to package the above data, generating a compressed file containing all necessary data to improve transmission efficiency and ensure data integrity.

[0151] The compressed file is transferred from the source environment to the data area of ​​the target server node or container instance via a secure network transmission protocol (such as SFTP or HTTPS). Upon arrival at the target location, the system automatically decompresses the file and imports it into the target database instance, completing the initial data writing. Throughout the synchronization process, the system records the transmission progress, verifies data consistency, and supports resuming interrupted transmissions to handle network interruptions or transmission anomalies.

[0152] After data synchronization is complete, the system enters the service switching phase. First, by calling the management interface of the DNS resolution service, the A record corresponding to the tenant's second-level domain name is updated, pointing it from the original shared cluster's IP address to the new IP address of the target independent node. Simultaneously, based on the updated tenant identifier-IP address mapping, the system regenerates the reverse proxy server's configuration rules and loads them into the reverse proxy component.

[0153] Before the configuration update takes effect, the system temporarily intercepts user requests from that tenant. When a user accesses its dedicated domain, the request is no longer forwarded to the backend service. Instead, a preset prompt page is returned, displaying migration status information such as "System is migrating, current progress: Completed". This prevents users from performing operations when the data is not fully ready or the service is not stable, thus preventing data inconsistency or operation failure.

[0154] Once DNS record propagation is complete, the reverse proxy configuration is successfully hot-reloaded, and the target service confirms normal responsiveness, the system removes request blocking and officially switches user traffic to the new target server node or container instance. Afterward, all requests from this tenant are routed to its dedicated, independent runtime environment, preserving the original configuration and business data. Users can continue to use the system normally, achieving a smooth transition from a standard tenant to a customized tenant.

[0155] According to one embodiment of this application, it also includes:

[0156] The management backend displays the data synchronization progress, resource usage status of the target server node, and migration failure rate in real time.

[0157] If the migration fails, the customized configuration data file and business data will be automatically restored to the source server node before the migration, and the original DNS resolution records and reverse proxy configuration will be reactivated.

[0158] As mentioned above, the system also includes a centralized management backend for monitoring the execution status of the tenant migration process. During the data synchronization phase, the management backend displays the real-time progress information of the migration task, including the amount of data transferred, the total amount of data, the percentage of synchronization completed, and the estimated remaining time. Simultaneously, the system continuously collects and displays the resource usage of the target server nodes or container instances, such as CPU utilization, memory usage, disk I / O, and network bandwidth, to allow administrators to assess the carrying capacity of the target environment.

[0159] In addition, the management backend records and displays abnormal events and failure rates during the migration process, such as the number of data packet transmission failures, the number of database import errors, and service startup anomalies. These metrics are presented visually to help operations and maintenance personnel promptly identify potential problems and determine whether manual intervention is required.

[0160] If the system detects a critical error during the migration process that prevents data synchronization or service switching from continuing, a rollback mechanism will be automatically triggered. The system will first stop the current migration process, and then restore the backed-up customized configuration data files and business data from the target environment or temporary storage to the source server node database instance before the migration, ensuring that the original data state is complete and available.

[0161] Subsequently, the system calls the DNS management interface to restore the tenant's domain name resolution records to the IP address before the migration, and regenerates the original reverse proxy configuration rules, applying hot reload technology to make them effective. In this way, user requests will be rerouted back to the original standard tenant runtime environment.

[0162] The entire rollback process is executed automatically, requiring no manual intervention, minimizing service interruption time and ensuring business continuity and data security for tenants. After the rollback is complete, the system records the cause of failure and the processing results in the management backend for subsequent analysis and optimization.

[0163] According to one embodiment of this application, it also includes:

[0164] The graphical interface tool supports drag-and-drop operations, parameter configuration, and flowchart design, and converts the operation results into metadata in the JSON format in real time.

[0165] Version management is implemented for the customized configuration data files, allowing tenants to roll back to historical versions via a version selector or apply the current version of the configuration file via the publish function.

[0166] As mentioned above, the system also includes a fully functional graphical user interface tool to support lightweight customization by tenants. This tool provides an intuitive user interface that supports drag-and-drop operations. Tenants can drag fields, controls, or process nodes from the component library to the form or process design area using the mouse to customize the interface layout. Simultaneously, the tool provides a parameter configuration panel, allowing tenants to set the properties of selected components, such as field names, data types, validation rules, and display conditions. For defining business processes, the tool supports a flowchart design pattern. Tenants can build approval chains or workflows by connecting nodes and set the execution role, processing time limit, and flow conditions for each node.

[0167] During the user's operations, the system monitors interface changes in real time and instantly converts the configuration intent expressed by each operation into structured JSON metadata. This conversion process is based on preset mapping rules, ensuring that user operations are accurately reflected in storable and parsable data structures. Intermediate states can be saved without waiting for the operation to complete, improving configuration efficiency and response speed.

[0168] The system also implements a version management mechanism for the generated customized configuration data files. Each time the configuration content is modified and saved, the system automatically generates a new version record, including information such as version number, creation time, operator, and change summary, and persistently stores the JSON data of that version. All historical versions are retained, forming a traceable version chain.

[0169] Tenants can view current and historical configuration versions through the built-in version selector and select any historical version to perform a rollback operation. After rollback, the system reloads the JSON metadata of the historical version and sets it as the current effective configuration, restoring the system interface and business behavior to the corresponding state.

[0170] In addition, the system provides a publishing function, allowing tenants to make official changes to the current version by clicking the "Publish" button. The publishing process can include an approval process and supports a multi-level confirmation mechanism to ensure that critical configuration changes are approved before going live. This mechanism ensures both the flexibility of configuration changes and enhances the system's controllability and security.

[0171] According to one embodiment of this application, it also includes:

[0172] Deploying a hot code update module in the server node or container instance allows the personalized code to be dynamically loaded or updated without restarting the service;

[0173] The dependency libraries of the personalized code are version controlled by a package management tool, and missing dependency libraries are automatically downloaded during deployment.

[0174] As described above, the system also includes a code hot-update module deployed on the target server node or container instance to support dynamic updates of personalized code. This module continuously monitors for changes to personalized code files in the extension directory during service operation. When a code file is detected to have been modified, added, or deleted, the hot-update module automatically triggers a reload mechanism, re-injecting the changed code module into the current runtime environment, replacing the original version, and achieving instant functionality updates. The entire process does not interrupt the service process, nor does it affect other tenant requests being processed or other functional modules of the current tenant, ensuring system continuity and high business availability.

[0175] Meanwhile, to ensure the correct and complete operation of external libraries that the personalized code depends on, the system introduces a package management tool for unified management of dependency libraries. When deploying personalized code, the system parses its dependency declaration file (such as the library names and version numbers listed in the description file) and uses the package management tool to check whether the target environment already contains the required dependency libraries and whether their versions match. For missing or mismatched dependency libraries, the system automatically downloads and installs them from preset private or public repositories into the specified dependency directory, ensuring the integrity of the runtime environment.

[0176] This dependency management mechanism supports version locking and compatibility checks to prevent runtime anomalies caused by dependency conflicts. Simultaneously, the installation of all dependency libraries is performed in an isolated environment to prevent contamination of the system's underlying infrastructure. Through these technical means, the system achieves efficient, secure, and automated deployment and updates of customized code and its dependencies, improving the operational efficiency and stability of customized services.

[0177] A second aspect of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method described in any of the embodiments of the first aspect above.

[0178] Figure 2 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 2As shown, the electronic device may include: a processor 810, a communication interface 820, a memory 830, and a communication bus 840, wherein the processor 810, the communication interface 820, and the memory 830 communicate with each other via the communication bus 840. The processor 810 may call logical instructions in the memory 830 to execute the method in any of the embodiments of the first aspect described above, the method including:

[0179] Receive a tenant’s lightweight customization request, generate an independent database instance or tablespace based on the tenant identifier, receive the tenant’s form, process and application configuration parameters through a graphical interface tool, convert the parameters into metadata in JSON format, and write the metadata into the tenant’s database instance or tablespace to generate a customized configuration data file.

[0180] Based on the tenant's deep customization request, an independent server node or container instance is allocated to the tenant, and the tenant's personalized code is deployed to the server node or container instance. The personalized code includes business logic extension code and dependency libraries. The personalized code is separated from the standard product code through a dynamic loading mechanism, and the personalized code is loaded at runtime based on the tenant identifier.

[0181] A unique second-level domain name is generated based on the tenant identifier, and the domain name is mapped to the IP address of the server node or container instance through DNS resolution service. The domain name request of the tenant is forwarded to the server node or container instance corresponding to the IP address using reverse proxy technology, wherein the forwarding rule is generated based on the mapping relationship between the tenant identifier and the IP address.

[0182] The system receives a migration request from a standard tenant to a customized tenant, extracts the customized configuration data file and business data from the database instance of the standard tenant, and synchronizes the customized configuration data file and business data to the database instance of the target server node or container instance; updates the domain name and IP address mapping relationship in the DNS resolution service, and modifies the reverse proxy configuration to route the tenant's domain name requests to the target server node or container instance.

[0183] Furthermore, the logical instructions in the aforementioned memory 830 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, 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, random access memory, magnetic disks, or optical disks.

[0184] On the other hand, the present invention also provides a computer program product, the computer program product comprising a computer program, the computer program being able to be stored on a non-transitory computer-readable storage medium, and when the computer program is executed by a processor, the computer being able to perform the methods provided by the above methods, the method comprising:

[0185] Receive a tenant’s lightweight customization request, generate an independent database instance or tablespace based on the tenant identifier, receive the tenant’s form, process and application configuration parameters through a graphical interface tool, convert the parameters into metadata in JSON format, and write the metadata into the tenant’s database instance or tablespace to generate a customized configuration data file.

[0186] Based on the tenant's deep customization request, an independent server node or container instance is allocated to the tenant, and the tenant's personalized code is deployed to the server node or container instance. The personalized code includes business logic extension code and dependency libraries. The personalized code is separated from the standard product code through a dynamic loading mechanism, and the personalized code is loaded at runtime based on the tenant identifier.

[0187] A unique second-level domain name is generated based on the tenant identifier, and the domain name is mapped to the IP address of the server node or container instance through DNS resolution service. The domain name request of the tenant is forwarded to the server node or container instance corresponding to the IP address using reverse proxy technology, wherein the forwarding rule is generated based on the mapping relationship between the tenant identifier and the IP address.

[0188] The system receives a migration request from a standard tenant to a customized tenant, extracts the customized configuration data file and business data from the database instance of the standard tenant, and synchronizes the customized configuration data file and business data to the database instance of the target server node or container instance; updates the domain name and IP address mapping relationship in the DNS resolution service, and modifies the reverse proxy configuration to route the tenant's domain name requests to the target server node or container instance.

[0189] In another aspect, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to perform the cigarette box image recognition method provided by the methods described above, the method comprising:

[0190] Receive a tenant’s lightweight customization request, generate an independent database instance or tablespace based on the tenant identifier, receive the tenant’s form, process and application configuration parameters through a graphical interface tool, convert the parameters into metadata in JSON format, and write the metadata into the tenant’s database instance or tablespace to generate a customized configuration data file.

[0191] Based on the tenant's deep customization request, an independent server node or container instance is allocated to the tenant, and the tenant's personalized code is deployed to the server node or container instance. The personalized code includes business logic extension code and dependency libraries. The personalized code is separated from the standard product code through a dynamic loading mechanism, and the personalized code is loaded at runtime based on the tenant identifier.

[0192] A unique second-level domain name is generated based on the tenant identifier, and the domain name is mapped to the IP address of the server node or container instance through DNS resolution service. The domain name request of the tenant is forwarded to the server node or container instance corresponding to the IP address using reverse proxy technology, wherein the forwarding rule is generated based on the mapping relationship between the tenant identifier and the IP address.

[0193] The system receives a migration request from a standard tenant to a customized tenant, extracts the customized configuration data file and business data from the database instance of the standard tenant, and synchronizes the customized configuration data file and business data to the database instance of the target server node or container instance; updates the domain name and IP address mapping relationship in the DNS resolution service, and modifies the reverse proxy configuration to route the tenant's domain name requests to the target server node or container instance.

[0194] For any parts not mentioned in this application, existing technologies may be used or referenced.

[0195] The various embodiments in this specification are described in a progressive manner. The same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on describing the differences from other embodiments.

[0196] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for customizing services for SaaS tenants, characterized in that, include: Receive a tenant’s lightweight customization request, generate an independent database instance or tablespace based on the tenant identifier, receive the tenant’s form, process and application configuration parameters through a graphical interface tool, convert the parameters into metadata in JSON format, and write the metadata into the tenant’s database instance or tablespace to generate a customized configuration data file. Based on the tenant's deep customization request, an independent server node or container instance is allocated to the tenant, and the tenant's personalized code is deployed to the server node or container instance. The personalized code includes business logic extension code and dependency libraries. The personalized code is separated from the standard product code through a dynamic loading mechanism, and the personalized code is loaded at runtime based on the tenant identifier. A unique second-level domain name is generated based on the tenant identifier, and the domain name is mapped to the IP address of the server node or container instance through DNS resolution service. The domain name request of the tenant is forwarded to the server node or container instance corresponding to the IP address using reverse proxy technology, wherein the forwarding rules are generated based on the mapping relationship between the tenant identifier and the IP address. Receive a migration request from a standard tenant to a customized tenant, extract the customized configuration data file and business data from the database instance of the standard tenant, and synchronize the customized configuration data file and business data to the database instance of the target server node or container instance; Update the domain name and IP address mapping relationship in the DNS resolution service and modify the reverse proxy configuration to route the tenant's domain name requests to the target server node or container instance; After data synchronization is complete, the domain name requests of the tenant are gradually switched to the target server node or container instance by modifying the DNS resolution records and reverse proxy configuration. During the switching process, user requests are intercepted and migration progress prompts are displayed.

2. The method according to claim 1, characterized in that, The process involves receiving a lightweight customization request from a tenant, generating an independent database instance or tablespace based on the tenant identifier, receiving the tenant's forms, processes, and application configuration parameters through a graphical interface tool, converting the parameters into JSON-formatted metadata, and writing the metadata into the tenant's database instance or tablespace to generate a customized configuration data file, including: By using database sharding technology or tablespace partitioning in a shared database, the customized configuration data files of the tenant are physically isolated from the standard product data; When the system starts, the metadata of the standard product is loaded first, and then the customized configuration data file is dynamically loaded according to the tenant identifier. The performance overhead of repeated loading is reduced through a caching mechanism.

3. The method according to claim 1, characterized in that, Based on the tenant's deep customization request, an independent server node or container instance is allocated to the tenant. The tenant's personalized code is deployed to the server node or container instance. The personalized code includes business logic extension code and dependency libraries. The personalized code is separated from the standard product code through a dynamic loading mechanism, and the personalized code is loaded at runtime based on the tenant identifier. An extension directory is reserved in the standard product code project. The extension directory defines loading rules through an independent configuration file. The configuration file contains the mapping relationship between the tenant identifier and the extension code path. Allocate independent CPU and memory resources to the server nodes or container instances, and limit the usage limit of the resources through container orchestration technology to avoid resource contention between tenants.

4. The method according to claim 1, characterized in that, The process involves generating a unique second-level domain name based on the tenant identifier, mapping the domain name to the IP address of the server node or container instance via DNS resolution, and forwarding the tenant's domain name requests to the server node or container instance corresponding to the IP address using reverse proxy technology. The forwarding rules are generated based on the mapping relationship between the tenant identifier and the IP address, and include: The unique second-level domain name is generated based on the tenant identifier; The A records in the DNS resolution service are updated in real time via the API interface to ensure that the mapping relationship between the domain name and the IP address takes effect immediately after the tenant migrates. Based on the mapping relationship between the tenant identifier and the IP address, the Nginx reverse proxy configuration file is dynamically generated, and the configuration changes are made effective immediately through hot reload technology.

5. The method according to claim 1, characterized in that, The process involves receiving a migration request from a standard tenant to a customized tenant, extracting the customized configuration data file and business data from the database instance of the standard tenant, and synchronizing the customized configuration data file and business data to the database instance of the target server node or container instance. Update the domain name and IP address mapping in the DNS resolution service and modify the reverse proxy configuration to route the tenant's domain name requests to the target server node or container instance, including: The customized configuration data file and business data are packaged into a compressed file using a database backup tool, and the compressed file is synchronized to the target server node or container instance via a network transmission protocol.

6. The method according to claim 5, characterized in that, Also includes: The management backend displays the data synchronization progress, resource usage status of the target server node, and migration failure rate in real time. If the migration fails, the customized configuration data file and business data will be automatically restored to the source server node before the migration, and the original DNS resolution records and reverse proxy configuration will be reactivated.

7. The method according to claim 2, characterized in that, Also includes: The graphical interface tool supports drag-and-drop operations, parameter configuration, and flowchart design, and converts the operation results into metadata in the JSON format in real time. Version management is implemented for the customized configuration data files, allowing tenants to roll back to historical versions via a version selector or apply the current version of the configuration file via the publish function.

8. The method according to claim 3, characterized in that, Also includes: Deploying a hot code update module in the server node or container instance allows the personalized code to be dynamically loaded or updated without restarting the service; The dependency libraries of the personalized code are version controlled by a package management tool, and missing dependency libraries are automatically downloaded during deployment.

9. A computer-readable storage medium having a program stored thereon, characterized in that, When the program is executed by the processor, it implements the steps of the method as described in any one of claims 1-8.

10. An electronic device comprising a memory, a processor, and a program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the method as described in any one of claims 1-8.

Images