Intelligent service management system supporting multi-tenant data isolation and resource quota

Abstract

This invention relates to the field of intelligent service management technology, and more particularly to an intelligent service management system that supports multi-tenant data isolation and resource quotas. The intelligent service management system includes a tenant identification management module, a resource quota management module, a data isolation access module, and a monitoring and auditing module. The tenant identification management module is used to assign a unique tenant identifier to each tenant during the service access phase and to identify the tenant to which the request belongs when an external request enters the system, injecting the corresponding tenant identifier into the request context. The resource quota management module is used to deploy resource quota checking middleware at the service entry point. This invention improves the accuracy of resource control, data security, and operational observability of intelligent agent services in a multi-tenant environment through intelligent service management with tenant data isolation and resource quotas.

Description

Technical Field

[0001] This invention relates to the field of intelligent agent service management technology, and in particular to an intelligent service management system that supports multi-tenant data isolation and resource quotas. Background Technology

[0002] Multi-tenant architecture, as a mature cloud computing model, can significantly reduce unit service costs and improve overall resource utilization by allowing multiple tenants to share the same system infrastructure, application services, and data storage resources. However, directly applying the traditional multi-tenant model to the intelligent agent service domain faces a series of new challenges. In terms of resource management, intelligent agent services are characterized by high computing density, large contextual interactions, and long-running tasks. The workloads of intelligent agents from different tenants vary greatly; some may engage in high-frequency, lightweight dialogues, while others require complex multi-step inference and tool calls. Without a fine-grained resource quota and scheduling mechanism designed for intelligent agent scenarios, it is easy for a few tenants' complex tasks to excessively consume critical resources such as GPUs, memory, or concurrent threads, leading to response delays, task queue congestion, and even service interruptions for other tenants' intelligent agents, severely impacting service fairness and system stability in a multi-tenant environment. Therefore, there is an urgent need for a multi-tenant intelligent service management system designed for intelligent agent service scenarios, supporting strong resource quotas and fine-grained data isolation, to achieve efficient resource sharing and intelligent operation while ensuring performance isolation and data security. Summary of the Invention

[0003] Therefore, it is necessary to provide an intelligent service management system that supports multi-tenant data isolation and resource quotas to solve at least one of the above-mentioned technical problems.

[0004] To achieve the above objectives, an intelligent service management system supporting multi-tenant data isolation and resource quotas includes the following steps: The tenant identifier management module is used to assign a unique tenant identifier to each tenant during the service access phase, and to identify the tenant to which the request belongs when an external request enters the system, and inject the corresponding tenant identifier into the request context. The resource quota management module is used to deploy resource quota checking middleware at the service entry point. It obtains the corresponding resource quota policy and current resource usage based on the tenant identifier in the request context, performs verification before request processing, and executes rate limiting or rejection when the resource usage reaches the threshold set by the resource quota policy. The data isolation access module is used to add filtering conditions based on the tenant identifier in the request context to data query and data write operations in the shared storage structure when the request enters the data access stage after passing the resource quota verification. The monitoring and auditing module is used to record structured audit logs containing tenant identifiers and aggregate them by tenant dimension to generate system monitoring indicators and resource usage statistics.

[0005] This invention assigns a unique tenant identifier to each tenant during the system service access phase and injects this identifier into the request context when an external request enters the system. This enables the agent service to continuously identify the tenant's identity when processing requests from different tenants. Furthermore, a resource quota management module verifies the resource quota of agent service requests at the service entry point. This allows the system to monitor and limit API call frequency, concurrent sessions, and storage resource usage in real time based on the tenant, preventing excessive resource consumption by individual tenants' agent tasks from affecting the service quality of other tenants.

[0006] Meanwhile, the data isolation access module automatically applies tenant identifier filtering conditions to data operations of the agent service within the shared storage structure, achieving logical isolation of vector data, session history, and configuration information of different tenants in the shared storage. This prevents data confusion or unauthorized access between tenants during agent processing. Furthermore, the monitoring and auditing module records agent service operation logs containing tenant identifiers and aggregates them by tenant to generate statistics on call volume, response latency, and resource usage. This provides effective data support for multi-tenant resource management, operational quality monitoring, and security auditing of the agent service. Attached Figure Description

[0007] Fig. 1 A flowchart illustrating the steps of an intelligent service management system that supports multi-tenant data isolation and resource quotas; Fig. 2 This is a schematic diagram of the functional architecture of the intelligent service management system; Fig. 3 This is a schematic diagram of the intelligent service management system modules; The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0008] The technical method of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0009] Furthermore, the accompanying drawings are merely illustrative of the invention and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor methods and / or microcontroller methods.

[0010] It should be understood that although the terms "first," "second," etc., may be used herein to describe various units, these units should not be limited by these terms. These terms are used merely to distinguish one unit from another. For example, without departing from the scope of the exemplary embodiments, a first unit may be referred to as a second unit, and similarly, a second unit may be referred to as a first unit. The term "and / or" as used herein includes any and all combinations of one or more of the associated listed items.

[0011] To achieve the above objectives, please refer to Figs. 1 to 3 This invention provides an intelligent service management system that supports multi-tenant data isolation and resource quotas. The intelligent service management system includes a tenant identification management module, a resource quota management module, a data isolation access module, and a monitoring and auditing module. The intelligent service management system performs the following steps: All specific values ​​involved in this embodiment are exemplary parameters used to clearly illustrate the technical operation process and are not the only limitation of the present invention.

[0012] S1: During the service access phase, assign a unique tenant identifier to each tenant and identify the tenant to which the request belongs when an external request enters the system, and inject the corresponding tenant identifier into the request context; S2: Deploy a resource quota check middleware at the service entry point. Obtain the corresponding resource quota policy and current resource usage based on the tenant identifier in the request context. Perform verification before request processing. When the resource usage reaches the threshold set by the resource quota policy, perform rate limiting or rejection. S3: When a request enters the data access phase after passing the resource quota verification, based on the tenant identifier in the request context, filter conditions with the tenant identifier as the dimension are added to the data query and data write operations in the shared storage structure. S4: Records structured audit logs containing tenant identifiers and aggregates them by tenant dimension to generate system monitoring metrics and resource usage statistics.

[0013] In one embodiment, an intelligent service management system supporting multi-tenant data isolation and resource quotas is applied to a SaaS service environment based on shared service instances. The system receives access requests from different tenants at a unified service entry point and executes them according to the following processing flow: In step S1, a unique tenant identifier is assigned to each tenant during the service access phase. When an external request enters the system, the system identifies the tenant to which the request belongs and injects the corresponding tenant identifier into the request context. During system initialization or tenant registration, a globally unique tenant_id is generated for each tenant and bound and stored with the tenant account and permission information. When a user initiates an access request, the request carries authentication information. The system parses this authentication information at the service entry point, identifies the tenant, and extracts the corresponding tenant_id. The system completes the tenant identifier injection at the service gateway or unified access layer, writing the tenant_id into the request context object so that all subsequent processing steps can access this identifier.

[0014] In a synchronous processing environment, the tenant_id is bound to the current request processing thread through a thread-local storage mechanism, and all service calls executed within that thread share the tenant identifier.

[0015] In asynchronous or coroutine execution environments, the tenant_id is bound to a coroutine context variable, enabling asynchronous processing logic within the same request chain to continuously obtain the tenant identifier.

[0016] In a distributed microservice architecture, when a request is made across multiple service nodes, the tenant_id is passed via HTTP request headers or RPC call metadata. This allows downstream services to rebind the tenant identifier to their local context upon receiving the request. In asynchronous processing scenarios involving message queues, the tenant_id is passed along with the message body or message header. Consumers extract the tenant_id and inject it into the processing context when processing messages, thus ensuring the consistency of the tenant identifier across components.

[0017] In step S2, a resource quota check middleware is deployed at the service entry point. Based on the tenant identifier in the request context, the corresponding resource quota policy and current resource usage are obtained and verified before request processing. When resource usage reaches the threshold set by the resource quota policy, rate limiting or rejection is executed. Specifically, the system pre-configures resource quota policies for different tenants or different service levels. These resource quota policies include multiple dimensions such as API call count, concurrent request count, data storage capacity, and computing resource usage.

[0018] Deploy quota check middleware at the service gateway or core service entry point. When a request arrives, first query the corresponding quota policy based on the tenant_id in the request context, and obtain the current resource usage of the tenant.

[0019] The system maintains a resource usage counter for each tenant in the distributed caching system, and updates the resource usage in real time through atomic counting operations to ensure the accuracy of the count under high concurrency access.

[0020] The system controls the request rate using a sliding time window or token bucket mechanism, determining whether the quota limit has been exceeded by counting the number of requests per unit time. When resource usage approaches a preset threshold, the system triggers an early warning mechanism; when resource usage reaches or exceeds a hard quota threshold, the system directly performs rate limiting or rejection before processing the request and returns a resource over-limit message.

[0021] It should be added that the resource quota policy supports dual threshold control of soft quotas and hard quotas, which will trigger tiered alarms and forced restriction operations when different thresholds are reached.

[0022] In step S3, when the request enters the data access stage after passing the resource quota verification, the data query and data write operations in the shared storage structure are subject to filtering conditions based on the tenant identifier in the request context, with the tenant identifier as the dimension.

[0023] Specifically, all data operations are intercepted and processed uniformly at the data access layer, and the tenant_id filter condition is automatically attached when generating data access instructions, so that each tenant can only access its own data.

[0024] In one embodiment, in a relational database, a `tenant_id` field is set in the data table structure, and the query condition "tenant_id = current tenant identifier" is automatically concatenated when executing SQL statements. An index is also created for `tenant_id` to improve query efficiency. In vector databases or search engine systems, a `tenant_id` dimension is introduced into the data index or vector set. When performing retrieval operations, `tenant_id` is used as a necessary filtering condition, thereby achieving data isolation between different tenants. In object storage systems, data is organized according to the path structure "tenant_id / data type / object identifier," creating logical isolation between the data of different tenants in the storage structure. In caching systems, by adding a `tenant_id` prefix to the cache key, data from different tenants is distinguished, preventing the mixing of cached data. For high-level tenants or scenarios with high security requirements, independent data storage instances or independent service instance groups can be allocated to different tenants to achieve a higher level of isolation.

[0025] In step S4, structured audit logs containing tenant identifiers are recorded, and system monitoring metrics and resource usage statistics are aggregated by tenant dimension. Specifically, during request processing, the system logs key operational behaviors, including at least tenant identifier, request time, user identifier, operation type, resource object, request result, and resource usage information. The system writes the log data uniformly into a centralized log system and stores the logs in a structured manner to support subsequent retrieval and analysis. The system performs aggregated analysis based on the log data by tenant dimension to generate resource usage statistics and operational behavior analysis results. A monitoring indicator system based on the tenant dimension is constructed to monitor indicators such as request volume, response time, error rate, and resource consumption in real time.

[0026] When abnormal access behavior or abnormal resource usage is detected, the system triggers an alarm mechanism and sends alarm information to the management platform for timely handling.

[0027] Please refer to [link / reference needed] for further information. Fig. 2 The process begins in the tenant identification management module at the top left. Verifying identity and injecting a tenant identification lays the foundation for the workflow. Next, requests carrying the identification enter the resource quota management module for usage verification. Once verification is successful, the request reaches the data isolation access module. This module automatically adds tenant identification filtering conditions to query and write operations to achieve data isolation. The monitoring and auditing module is present throughout the entire process, recording audit logs and generating tenant-level monitoring and statistical information.

[0028] Please refer to [link / reference needed] for further information. Fig. 3 This is a closed-loop collaborative workflow formed by connecting four modules in a multi-tenant system: tenant identification, resource quota verification, data access isolation, and monitoring and audit feedback, with tenant identification as the link.

[0029] Preferably, during the service access phase, a unique tenant identifier is assigned to each tenant, and when an external request enters the system, the tenant to which the request belongs is identified, and the corresponding tenant identifier is injected into the request context, including: Receive access requests carrying tenant identity credentials; Verify the tenant's identity based on their credentials; After successful identity verification, a unique tenant identifier is extracted or generated from the tenant identity information database. Bind the tenant identifier to the current request session and inject it into the request context.

[0030] In one embodiment, the system receives an access request carrying tenant identity credentials. Specifically, when an external client accesses system services, it sends an access request to the system through a unified service gateway. The request message carries identity credential information used to identify the tenant, such as a tenant access token, API key, digital signature, or encrypted authentication string. Upon receiving the request, the service gateway parses the request message, extracts the tenant identity credential from the request header or authentication field, and passes the parsed credential to the authentication component for processing. The tenant's identity is verified based on the tenant identity credential. Specifically, the authentication component performs format and validity checks on the extracted tenant identity credential, such as verifying whether the access token is valid and whether the digital signature matches a pre-stored key in the system. If the verification passes, the system determines the tenant subject corresponding to the current request based on the identity credential and returns the verification result to the service gateway; if the verification fails, the request processing flow is terminated directly, and an authentication failure response is returned to the client.

[0031] After successful authentication, the system extracts or generates a unique tenant identifier from the tenant identity information database. Specifically, the system uses the verified tenant identity credential as the search condition to perform a query operation in the pre-established tenant identity information database to check if a tenant identifier record bound to that identity credential exists. When a corresponding record is found, the system directly extracts the tenant identifier stored in that record as the tenant identifier corresponding to the current request; when no corresponding record is found, the system generates a globally unique identifier according to preset rules, such as a unique number or unified identifier generated based on a combination of random numbers and timestamps, and uses the generated identifier as the new tenant identifier. At the same time, the system establishes a binding relationship between this tenant identifier and the current tenant identity credential, and writes this binding relationship into the tenant identity information database so that subsequent requests can directly retrieve the corresponding tenant identifier.

[0032] The system binds the tenant identifier to the current request session and injects it into the request context. Specifically, before the current request enters the business processing flow, the system creates a request context object and reserves a data field within this object to store tenant information. Subsequently, the system writes the acquired tenant identifier into this field and establishes an association between the tenant identifier and the current request session, ensuring that the tenant identifier can be continuously accessed throughout the request processing. Afterward, when the request flows between various processing modules within the system, it carries the tenant identifier through the request context object, enabling subsequent resource quota management, data isolation access, and monitoring and auditing modules to directly read the tenant identifier and execute corresponding control and processing operations. Through this process, tenant identification and tenant identifier injection are completed at the initial stage of the request entering the system, providing a unified identifier foundation for subsequent multi-tenant resource management and data isolation.

[0033] Preferably, after successful authentication, retrieving or generating a unique tenant identifier from the tenant identity information database includes: Query the tenant identity information database based on the verified tenant identity credentials; If the bound tenant identifier is found, extract it directly; If no match is found, a globally unique identifier is generated according to preset rules as the tenant identifier, and a binding relationship is established with the tenant identity credentials.

[0034] In one embodiment, the system queries the tenant identity information database based on the verified tenant identity credentials. Specifically, after the authentication component confirms the validity of the tenant identity credentials in the current request, the system passes the credentials as a search condition to the tenant identification management module. The tenant identification management module calls the data access interface to perform a query operation on the pre-established tenant identity information database. This database stores tenant identity credentials, tenant identifiers, and records of the binding relationship between the two. The system uses the tenant identity credentials as the query key to retrieve the record corresponding to the credentials from the database and returns the query result to the tenant identification management module for further processing.

[0035] If a bound tenant identifier is found, it is extracted directly. Specifically, when the database query results contain a record corresponding to the current tenant's identity credentials, the system reads the tenant identifier field from that record and extracts it as the unique identifier for the tenant corresponding to the current request. Simultaneously, the system performs basic validation on the tenant identifier, such as confirming whether the identifier format conforms to the system's encoding rules and whether it is valid. After validation, the tenant identifier is temporarily stored in the current request processing flow, ready to be written into the request context in subsequent steps for identification and use by subsequent system modules.

[0036] If no bound tenant identifier is found, a globally unique identifier is generated as the tenant identifier according to preset rules, and a binding relationship is established with the tenant's identity credentials. Specifically, when the system does not find a record corresponding to the current identity credentials in the tenant identity information database, the system considers the tenant to be a first-time user, and a new tenant identifier needs to be generated. The system generates a globally unique identifier according to preset identifier generation rules, such as generating a unique number based on a combination of timestamp and random number, or generating a standard format identifier string according to a unified identifier generation algorithm. After generation, the system creates a new record in the tenant identity information database, establishes a correspondence between the generated tenant identifier and the current tenant's identity credentials, and persists this binding relationship in the database. Subsequently, the system returns the generated tenant identifier to the request processing flow, allowing it to continue participating in subsequent processing as the unique identifier of the tenant corresponding to the current request. Through the above process, a tenant identifier is automatically established when the tenant first connects, and the corresponding tenant identifier can be quickly obtained directly through identity credentials in subsequent requests, thereby ensuring that each tenant in the system has unique and stable identifier information.

[0037] Preferably, binding the tenant identifier to the current request session and injecting it into the request context includes: Establish a binding relationship between the tenant identifier and the current request session; Write the binding data, which includes the tenant identifier, to the request context object.

[0038] In one embodiment, a binding relationship is established between the tenant identifier and the current request session. Specifically, after the system completes tenant authentication and obtains the corresponding tenant identifier, the request enters the system's unified request processing flow. The system creates a corresponding request session object for each request entering the system at the service gateway or application service entry point. This session object is used to record runtime information related to the request throughout the entire request processing process. Subsequently, the tenant identifier management module writes the tenant identifier obtained in the previous stage into this session object and establishes a tenant identifier field in the session object, associating this field with the unique session identifier of the current request. In this way, a one-to-one correspondence of "request session - tenant identifier" is formed internally, enabling the system to quickly locate the corresponding tenant identifier based on the current request session during subsequent processing. Simultaneously, to ensure consistency in subsequent module access, the system also sets a tenant identifier reading interface in the session object, allowing internal system components to obtain the tenant identifier through a unified interface.

[0039] Subsequently, the binding data containing the tenant identifier is written to the request context object. Specifically, the system creates a request context object before the request enters the business processing chain. This object is used to transfer request-related data between multiple processing modules. The system pre-sets a tenant information field in this context object and writes the tenant identifier, established in the previous binding step, into this field, thus forming an information structure containing the tenant identifier within the request context. Later, when the request is passed between various processing modules within the system, the request context object is transmitted along with the request, enabling the resource quota management module, data isolation access module, and monitoring and auditing module to obtain the tenant information to which the current request belongs by reading the tenant identifier field in the request context. Through this method, the binding between the tenant identifier and the request session is completed at the initial stage of the request entering the system, and the tenant identifier is continuously transmitted throughout the request processing flow via the request context, thereby providing a unified data basis for subsequent tenant-based resource control, data isolation, and audit statistics.

[0040] Preferably, in the resource quota management module, obtaining the corresponding resource quota policy and current resource usage based on the tenant identifier in the request context includes: Parse the request context to extract the tenant identifier; The resource quota policy is obtained by querying the resource configuration database based on the tenant identifier. The current resource usage can be obtained by querying the resource usage record database based on the tenant identifier.

[0041] In one embodiment, the tenant identifier is extracted by parsing the request context. Specifically, when an external request passes through the tenant identifier management module and enters the system service entry point, the request carries the request context object in the internal processing chain and continues to be passed forward. The resource quota management module, as a request processing middleware deployed at the service entry point, intercepts the request before it enters business processing. The module reads the request context object associated with the request and parses the context information fields stored therein to extract the tenant identifier bound to the current request. To ensure consistency in subsequent processing, the system also performs basic checks on the extracted tenant identifier, such as checking whether the identifier format conforms to the system's set rules and whether the identifier is empty. After passing the checks, the tenant identifier is used as the index condition for subsequent query operations.

[0042] The resource quota policy is retrieved from the resource configuration database based on the tenant identifier. Specifically, the resource quota management module calls the system's resource configuration database interface, using the extracted tenant identifier as the query condition to retrieve the resource quota policy record corresponding to that tenant from the database. The resource configuration database pre-stores resource control parameters for each tenant, such as the maximum allowed interface call frequency, the maximum number of concurrent sessions, the maximum usable storage capacity, and resource restriction indicators for different types. Once the system finds the corresponding record, it loads the resource quota policy configured for that tenant into the current request processing flow and temporarily stores it in the resource quota management module's runtime environment for subsequent resource verification processes.

[0043] The system queries the resource usage record database based on the tenant identifier to obtain the current resource usage. Specifically, the resource quota management module continues to use the same tenant identifier as the query condition to access the resource usage record database, which records the resource information already occupied by each tenant during system operation in real time. The system extracts the tenant's current resource usage data from the resource usage record database, such as the number of interface calls within the current time window, the number of concurrent sessions currently in use, and the amount of storage space already used. After obtaining this real-time resource usage, the resource quota management module saves it along with the resource quota policy obtained in the previous step to the current request processing environment. Through the above steps, the system can obtain the tenant's resource restriction rules and current resource usage status before request processing, thus providing the necessary data foundation for subsequent execution of resource quota verification and rate limiting control.

[0044] Preferably, in the resource quota management module, the verification before request processing includes: Compare the current resource usage with the resource thresholds set in the resource quota policy; The comparison results will determine whether the resource usage has reached or exceeded the threshold.

[0045] In one embodiment, the current resource usage is compared with the resource thresholds set in the resource quota policy. Specifically, after the resource quota management module has obtained the resource quota policy and current resource usage corresponding to the tenant based on the tenant identifier, the system loads both types of data into the resource verification processing unit for processing. The resource quota policy typically includes multiple resource control parameters, such as the upper limit of the number of interface calls, the upper limit of the number of concurrent sessions, the upper limit of storage capacity, and configurable system resource limit indicators. At the same time, the resource usage record database stores the amount of resources actually occupied by the current tenant during system operation, such as the number of interface calls that have occurred within the current time window, the number of currently running sessions, and the storage space capacity already occupied. The resource quota management module matches the current resource usage item by item with the corresponding resource thresholds in the resource quota policy and performs an item-by-item comparison operation in the verification processing unit. For example, when the system detects interface call resources, it compares the number of interface calls within the current time window with the maximum number of calls set in the policy; when detecting concurrent session resources, it compares the number of currently running sessions with the maximum number of allowed concurrent sessions; and when detecting storage resources, it compares the storage space capacity currently used by the tenant with the upper limit of allocable storage space.

[0046] The system determines whether resource usage has reached or exceeded the threshold based on the comparison results. Specifically, after comparing various resource indicators, the resource quota management module makes a unified judgment on all comparison results. When none of the resource usages have reached the corresponding resource threshold, the system considers the current request not to cause resource usage to exceed the quota limit. In this case, the resource quota management module allows the request to continue into the subsequent business processing flow and passes the request to the data access module or business processing module for further execution. When it detects that a certain resource usage has reached or exceeded the resource threshold, the resource quota management module considers the current tenant's resource usage to have reached the limit, and the module triggers the resource control mechanism. For example, the system performs rate limiting on the current request according to a pre-set control policy, causing the request to enter a queuing or delayed execution state; or it directly rejects the request and returns a resource over-limit response. Simultaneously, the system records the resource verification result in the log system for subsequent system monitoring and resource statistical analysis. Through the above process, resource quota verification is completed before the request officially enters the business processing, effectively preventing a single tenant from excessively consuming system resources and ensuring the stability and fairness of the system operation in a multi-tenant environment.

[0047] Preferably, in the data isolation access module, the filtering conditions for data query and data write operations in the shared storage structure, based on the tenant identifier in the request context, include: Intercept data query requests sent to the shared storage structure; Extract the tenant identifier from the request context associated with the query request; When constructing a query command, the tenant identifier is embedded as a filter field in the query conditions.

[0048] In one embodiment, data query requests sent to the shared storage structure are intercepted. Specifically, in the system architecture, a data access interception component is set up between the application service and the underlying shared storage structure. This component is deployed in the data access link as the core part of the data isolation access module. When the upper-layer business module needs to perform data query or data write operations on the database or shared storage structure, the request is sent to the data access interface layer. The data isolation access module intercepts all data access requests uniformly at this interface layer, ensuring that any data operation accessing the shared storage structure must be processed by this module, thereby ensuring that the system can uniformly control access conditions before executing data access.

[0049] The tenant identifier is extracted from the request context associated with the query request. Specifically, when the data isolation access module intercepts a data query request, it reads the request context object associated with that request. Since the tenant identifier was already written into the request context object during the system integration phase, the module directly retrieves the tenant identifier information corresponding to the current request from the context object. To ensure the accuracy of data access, the system also performs validity checks on the extracted tenant identifier, such as confirming the existence of the tenant identifier field, whether the identifier value is empty, and whether the identifier format conforms to the system's set rules. Once the verification passes, the tenant identifier will serve as a key condition for data access control and will participate in generating access constraints when constructing subsequent data access commands.

[0050] When constructing the query command, the tenant identifier is embedded as a filter field matching condition into the query conditions. Specifically, before generating the final data access command, the data isolation access module parses the original data query request, extracting the query statements or data operation instructions contained therein. Subsequently, the module generates matching conditions corresponding to the tenant identifier field in the data records based on the extracted tenant identifier, such as generating a filter condition "tenant identifier equals current tenant identifier," and merges this condition with the query conditions in the original query statement to form the final query command containing the tenant identifier restriction. When the system executes this query command, the database will only return data records whose tenant identifier field matches the currently requested tenant identifier, thus ensuring that data between different tenants cannot be accessed by each other.

[0051] During data write operations, the system employs a similar approach. After intercepting a write request, the data isolation access module extracts the tenant identifier from the request context and appends this identifier as a data attribute field to the data record to be written when constructing the write command. This ensures that the written data automatically carries the corresponding tenant identifier during storage. Through this process, even if multiple tenants' data resides in the same shared storage structure, the system can differentiate and control the data using the tenant identifier when performing data queries or write operations, thereby achieving data isolation access in a multi-tenant environment.

[0052] Preferably, embedding the tenant identifier as a filter field matching condition into the query condition when constructing the query command includes: Parse the original query command corresponding to the data query request; Generate an equality clause for the tenant identifier field in the matching data record based on the tenant identifier; The equality clause is combined with the original query conditions to form the final query command.

[0053] In one embodiment, the original query command corresponding to the data query request is parsed. Specifically, when the data isolation access module intercepts a data query request from an upper-layer business module, the module reads the original query command carried in the request, such as a database query statement or a query expression generated by the data access interface. Subsequently, the module performs structured parsing of the original query command through a query statement parsing component, breaking the query command down into different statement components, such as the data table name, the list of query fields, and the original query conditions. Through the parsing operation, the system can obtain the filtering conditions and logical relationships already contained in the original query statement, providing a basis for subsequently inserting tenant filtering conditions.

[0054] The system generates an equality clause based on the tenant identifier, matching the tenant identifier field in the data records. Specifically, the data isolation access module extracts the tenant identifier corresponding to the current request from the request context object and uses this identifier as a parameter for query restrictions. The system generates an equality matching clause corresponding to the pre-defined tenant identifier field name in the database table structure, for example, generating a conditional expression that "the tenant identifier field equals the current tenant identifier." This clause restricts the database query results to include only data records matching the current tenant identifier, thus preventing the query from finding the tenant's data.

[0055] The system merges the equivalent condition clause with the original query conditions to form the final query command. Specifically, after parsing the original query command and generating the tenant condition clause, the system merges the generated tenant identifier matching conditions with the query conditions in the original query command. When the original query command already contains filtering conditions, the system combines the tenant condition clause with the original conditions using logical joins, such as concatenating the two types of conditions using a logical AND relation, to form a new, complete query condition. When the original query command does not contain any filtering conditions, the system directly inserts the tenant identifier equivalent condition as a query condition into the query statement. The final generated query command adds tenant identifier restrictions while maintaining the original query logic, and is then sent to the shared storage structure for execution. Through this process, the system automatically adds tenant identifier filtering conditions to all query operations without changing the original business query logic, thereby achieving data isolation and access control in a multi-tenant environment.

[0056] Preferably, in the monitoring and auditing module, the structured audit logs containing tenant identifiers include: Audit points are set at system processing nodes. Processing nodes include at least request access, resource verification, data access, and business processing completion. Collect tenant identifier, operation time, operation type, operation result, and resource change amount from the request context at each audit point; Audit logs are encapsulated in a preset structured format and stored in the log system.

[0057] In one embodiment, audit points are set at system processing nodes. Specifically, in the overall system processing flow, key processing stages are designated as audit nodes, and log collection components are deployed at the corresponding locations. The set processing nodes include at least request access nodes, resource verification nodes, data access nodes, and business processing completion nodes. When an external request enters the system service gateway, the request passes through the request access node; subsequently, it passes through the resource verification node when the resource quota management module performs resource verification; it passes through the data access node when the system performs database queries or data write operations; and it passes through the business processing completion node when the business logic processing is completed and ready to return a response result. The monitoring and auditing module embeds audit logging logic at the above node locations, so that log collection operations are triggered when a request passes through each node.

[0058] At each audit point, the system collects tenant identifier, operation time, operation type, operation result, and resource change amount from the request context. Specifically, when a request arrives at an audit node, the monitoring and auditing module reads the request context object associated with that request and extracts the tenant identifier corresponding to the current request. Simultaneously, the system records the current node's system time as the operation time and determines the corresponding operation type based on the current node's processing stage; for example, it records "request access operation" at the request access node, "resource verification operation" at the resource verification node, and "data access operation" at the data access node. Furthermore, the system generates operation result information based on the current node's processing result, such as whether resource verification passed, whether data access was successful, and whether business processing was completed. For operation nodes involving resource changes, the system also synchronously calculates and records resource change amounts, such as the increase in the number of API calls, changes in the number of sessions, or changes in storage space.

[0059] Audit logs are encapsulated into a pre-defined structured format and stored in the log system. Specifically, after completing the above information collection, the monitoring and auditing module encapsulates the collected information according to a predefined log data structure. For example, it combines fields such as tenant identifier, operation time, operation type, operation result, and resource change amount to form a complete audit log record. After encapsulation, the system sends the audit log to the log storage system for persistent storage through the log writing interface. The log storage system is a centralized log database or a dedicated log management platform used to uniformly store audit logs generated during system operation. Through the above processing, the system can continuously record structured audit logs containing tenant identifiers at key nodes in request processing, thereby providing a complete data foundation for subsequent system monitoring, operation analysis, and resource statistics.

[0060] Preferably, in the monitoring and auditing module, the aggregation and generation of system monitoring indicators and resource usage statistics by tenant dimension includes: Extract audit logs containing the specified tenant identifier from the log system according to the set time window; The extracted data is grouped and aggregated to count the number of API calls, peak concurrent sessions, and storage space growth for the tenant within a time window. A tenant resource usage report is generated based on the statistical results.

[0061] In one embodiment, audit logs containing a specified tenant identifier are extracted from the log system according to a set time window. Specifically, the system continuously records structured audit logs from each processing node in the log storage system, and the log records include fields such as tenant identifier, operation time, operation type, operation result, and resource change amount. The monitoring and auditing module performs statistics according to a preset time window during system operation, such as by minute, hour, or day. When the statistical period is reached, the module initiates a log query request to the log storage system and sets query conditions, which include at least time range conditions and tenant identifier conditions. The system retrieves log records generated within the corresponding time period according to the set time window range, and further filters out audit logs whose tenant identifier matches that of the specified tenant, thereby obtaining all operation log data generated by that tenant within the current statistical period.

[0062] The extracted data is grouped, aggregated, and relevant resource usage metrics are statistically analyzed. Specifically, the monitoring and auditing module categorizes the extracted log records according to log type or operation type. For example, logs recording interface calls are categorized as API call data, logs involving session establishment or release are categorized as session operation data, and logs involving data writing or storage changes are categorized as storage operation data. After data classification, the system performs aggregation calculations on each type of log data. For instance, by counting the number of records in the interface call logs, the total number of API calls for the tenant within the current time window is obtained; by analyzing the session creation and termination information recorded in the session logs, the maximum number of concurrent sessions recorded by the system within the same time period is calculated, thus obtaining the peak concurrent sessions for the tenant; and by accumulating the storage capacity change values ​​recorded in the storage operation logs, the data storage space growth for the tenant within the current time window is calculated.

[0063] Based on the statistical results, a tenant resource usage report is generated. Specifically, after completing the statistical analysis of the above indicators, the system organizes the obtained statistical results, such as API call volume, peak concurrent sessions, and storage space growth, according to a preset data structure and generates corresponding resource usage statistics. Subsequently, the monitoring and auditing module encapsulates this statistical information into a tenant resource usage report. This report is stored in the system monitoring database in structured data form and is also provided to the system management platform for display in the form of visualized monitoring indicators. Through the above process, the system can continuously statistically analyze the system usage of each tenant within a set time window, thereby forming tenant-based system monitoring indicators and resource usage statistics, providing data support for system resource management and operation monitoring.

[0064] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features of the invention herein.

Claims

1. An intelligent service management system supporting multi-tenant data isolation and resource quotas, characterized in that, Includes the following steps: The tenant identifier management module is used to assign a unique tenant identifier to each tenant during the service access phase, and to identify the tenant to which the request belongs when an external request enters the system, and inject the corresponding tenant identifier into the request context. The resource quota management module is used to deploy resource quota checking middleware at the service entry point. It obtains the corresponding resource quota policy and current resource usage based on the tenant identifier in the request context, performs verification before request processing, and executes rate limiting or rejection when the resource usage reaches the threshold set by the resource quota policy. The data isolation access module is used to add filtering conditions based on the tenant identifier in the request context to data query and data write operations in the shared storage structure when the request enters the data access stage after passing the resource quota verification. The monitoring and auditing module is used to record structured audit logs containing tenant identifiers and aggregate them by tenant dimension to generate system monitoring indicators and resource usage statistics.

2. The intelligent service management system supporting multi-tenant data isolation and resource quotas according to claim 1, characterized in that, During the service access phase, a unique tenant identifier is assigned to each tenant, and when an external request enters the system, the tenant to which the request belongs is identified, and the corresponding tenant identifier is injected into the request context, including: Receive access requests carrying tenant identity credentials; Verify the tenant's identity based on their credentials; After successful identity verification, a unique tenant identifier is extracted or generated from the tenant identity information database. Bind the tenant identifier to the current request session and inject it into the request context.

3. The intelligent service management system supporting multi-tenant data isolation and resource quotas according to claim 2, characterized in that, After successful authentication, a unique tenant identifier is extracted or generated from the tenant identity information database, including: Query the tenant identity information database based on the verified tenant identity credentials; If the bound tenant identifier is found, extract it directly; If no match is found, a globally unique identifier is generated according to preset rules as the tenant identifier, and a binding relationship is established with the tenant identity credentials.

4. The intelligent service management system supporting multi-tenant data isolation and resource quotas according to claim 3, characterized in that, Binding the tenant identifier to the current request session and injecting it into the request context includes: Establish a binding relationship between the tenant identifier and the current request session; Write the binding data, which includes the tenant identifier, to the request context object.

5. The intelligent service management system supporting multi-tenant data isolation and resource quotas according to claim 1, characterized in that, In the resource quota management module, obtaining the corresponding resource quota policy and current resource usage based on the tenant identifier in the request context includes: Parse the request context to extract the tenant identifier; The resource quota policy is obtained by querying the resource configuration database based on the tenant identifier. The current resource usage can be obtained by querying the resource usage record database based on the tenant identifier.

6. The intelligent service management system supporting multi-tenant data isolation and resource quotas according to claim 1, characterized in that, The resource quota management module performs verification before request processing, including: Compare the current resource usage with the resource thresholds set in the resource quota policy; The comparison results will determine whether the resource usage has reached or exceeded the threshold.

7. The intelligent service management system supporting multi-tenant data isolation and resource quotas according to claim 6, characterized in that, In the data isolation access module, based on the tenant identifier in the request context, the following filtering conditions are added to data query and data write operations in the shared storage structure, with the tenant identifier as the dimension: Intercept data query requests sent to the shared storage structure; Extract the tenant identifier from the request context associated with the query request; When constructing the query command, the tenant identifier is embedded as a filter field in the query conditions.

8. The intelligent service management system supporting multi-tenant data isolation and resource quotas according to claim 7, characterized in that, When constructing a query command, embedding the tenant identifier as a filter field into the query conditions includes: Parse the original query command corresponding to the data query request; Generate an equality clause for the tenant identifier field in the matching data record based on the tenant identifier; The equality clause is combined with the original query conditions to form the final query command.

9. The intelligent service management system supporting multi-tenant data isolation and resource quotas according to claim 1, characterized in that, The monitoring and auditing module records structured audit logs containing tenant identifiers, including: Audit points are set at system processing nodes. Processing nodes include at least request access, resource verification, data access, and business processing completion. Collect tenant identifier, operation time, operation type, operation result, and resource change amount from the request context at each audit point; Audit logs are encapsulated in a preset structured format and stored in the log system.

10. The intelligent service management system supporting multi-tenant data isolation and resource quotas according to claim 1, characterized in that, The monitoring and auditing module aggregates and generates system monitoring metrics and resource usage statistics by tenant dimension, including: Extract audit logs containing the specified tenant identifier from the log system according to the set time window; The extracted data is grouped and aggregated to count the number of API calls, peak concurrent sessions, and storage space growth for the tenant within a time window. A tenant resource usage report is generated based on the statistical results.

Images