Multi-tenant implementation method based on multi-subsystem integration platform and related equipment

Abstract

The invention provides a multi-tenant implementation method based on a multi-subsystem integration platform and related equipment, and relates to the technical field of network security. According to the method, tenants are created according to tenant information, function modules corresponding to the tenants and access permissions input by managers on an operation platform, Nacos is called to allocate tenant resources and perform application isolation, and butt joint with subsystems is performed through an agreed interface calling mode and synchronous frequency; receiving a target subsystem access operation of a user on the platform, and sending an access request to a target subsystem; verifying the authority verification information sent by the target subsystem; and if the permission verification information passes verification, synchronizing the tenant resource to a corresponding target subsystem according to a preset field table, so that the target subsystem obtains the tenant resource through the operation platform. By implementing the method, efficient integration of the multi-tenant operation platform and a plurality of subsystems is realized, and the resource utilization efficiency is improved.

Description

Technical Field

[0001] The present application relates to the field of network security technology, and in particular to a multi-tenant implementation method and related equipment based on a multi-subsystem integration platform. Background Art

[0002] With the rapid development of information technology, enterprise operation platforms are facing increasingly complex business needs and huge amounts of data, and need to integrate multiple subsystems to achieve efficient operation management.

[0003] At present, the traditional subsystem tenant implementation adopts a physical isolation method, and each subsystem operates independently. When it is necessary to provide services to tenants, each subsystem will create tenants within itself. Specifically, the subsystem will allocate corresponding resources to tenants according to its own business needs and rules. For example, subsystem A may create a specific set of menus for tenant A, so that it can access and use the functions provided by subsystem A; subsystem B will create another set of menus for tenant B to meet tenant B's needs for subsystem B's functions. In this process, each subsystem manages its own tenant information independently, and there is no information sharing and interaction between each other.

[0004] However, this model has obvious flaws. First, the information isolation between subsystems leads to data inconsistency and redundancy, which increases the difficulty and cost of data management. At the same time, the tenant implementation methods of each subsystem are different. The same user needs to create tenants in different subsystems. For example, a financial user needs to create a tenant in the financial management subsystem to use the financial report function, and check the salary of employees in the personnel management subsystem. In this case, different subsystems need to create separate tenants for him, which will face the problem of more resource usage. Therefore, the existing technology lacks a method that is efficient and fully utilizes resource efficiency. Summary of the invention

[0005] The present application provides a multi-tenant implementation method and related equipment based on a multi-subsystem integration platform, which are used to improve the accuracy and efficiency of subsystem integration, reduce the probability of errors, make the transfer of tenant resources between different subsystems smoother, and provide tenants with a better service experience.

[0006] In combination with some embodiments of the first aspect, in some embodiments, after receiving the user's operation of accessing the target subsystem on the platform and sending an access request to the target subsystem, it also includes: obtaining a random key sent by the target subsystem, the random key refers to a key randomly refreshed in the target subsystem key library for verifying the tenant's access rights; judging whether there is a key for the random key based on the random key and the tenant resources corresponding to the platform; if there is a key in the tenant resources, unlocking the random key and synchronizing the tenant resources to the target subsystem.

[0007] By adopting the above technical solution, the operating platform can strictly control user permissions and prevent illegal operations.

[0008] In a second aspect, the present application provides an operation platform, which includes: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code includes computer instructions, and the one or more processors call the computer instructions to enable the operation platform to execute the method described in the first aspect and any possible implementation method of the first aspect.

[0009] In a third aspect, the present application provides a computer-readable storage medium comprising instructions, which, when executed on an operation platform, causes the operation platform to execute the method described in the first aspect and any possible implementation of the first aspect.

[0010] In a fourth aspect, the present application provides a computer program product, which, when executed on an operation platform, enables the operation platform to execute the method described in the first aspect and any possible implementation manner of the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 It is a schematic diagram of a framework of a multi-tenant implementation method based on a multi-subsystem integration platform in an embodiment of the present application; Figure 2 It is a flowchart of a multi-tenant implementation method based on a multi-subsystem integration platform in an embodiment of the present application; Figure 3 This is a scenario diagram of a multi-tenant implementation method based on a multi-subsystem integration platform in an embodiment of the present application; Figure 4 is another flowchart of a multi-tenant implementation method based on a multi-subsystem integration platform in an embodiment of the present application; Figure 5 It is a schematic diagram of the structure of a physical device of the operating platform in an embodiment of the present application. DETAILED DESCRIPTION

[0012] For ease of understanding, the following is a structural description of the method provided by this implementation. Figure 1 , which is a framework diagram of a multi-tenant implementation method based on a multi-subsystem integration platform in an embodiment of the present application.

[0013] exist Figure 1 In the example, the integrated platform can be an operation platform, which includes menu integration, role authorization, information distribution and system management. The subsystem group includes subsystem A, subsystem B, subsystem C and other subsystems. The subsystem group provides a menu set to the operation platform. The subsystem group and the operation platform can connect information through the set calling method and interface. The operation platform sends the relationship between roles and menus, organizational structure, user personnel, main and part-time jobs of personnel and functional roles of personnel to the subsystem group. It can also send other pre-set configuration information, which is not limited here. In this way, the information of all tenants is centrally stored on the operation platform, and the subsystem only needs to implement the functions of providing menus and verifying permissions. When a user accesses a subsystem, the subsystem will call the interface of the operation platform to verify user permissions and obtain menu information. The operation platform returns the corresponding menu set based on the user's tenant, role, permissions and other information, thus realizing role-based fine-grained menu isolation and control.

[0014] The following describes the process of the method provided by this implementation in combination with the above structure. Figure 2 , which is a flow chart of a multi-tenant implementation method based on a multi-subsystem integration platform in an embodiment of the present application.

[0015] S201. Create a tenant based on the tenant information entered by the administrator on the operation platform, the functional modules and access rights corresponding to the tenant, where the access rights refer to the set operation scope that the tenant is allowed to perform when using the operation platform and its various subsystems; Specifically, the operation platform provides tenant management functions, allowing managers to enter tenant information on the interface of the operation platform to create tenants. The operation platform will receive and verify the operation permissions of the managers to confirm that they have the permission to create tenants. After the verification is passed, the operation platform will obtain and parse the tenant information entered by the managers, including basic information such as tenant name, contact information, and purpose of use. The operation platform also needs to obtain the functional module information specified by the managers for the tenant. The functional module refers to the specific functional components of the operation platform and subsystems that the tenant is allowed to use, such as order management, product management, etc. The operation platform also needs to obtain the access permission information configured by the managers for the tenant. The access permission defines the scope of operations that the tenant is allowed to perform when using the functional module, and is fine-grained to the access control of the interface elements and data fields. After the above information is verified, the operation platform will create a corresponding tenant resource instance, which contains tenant information, associated functional module information, access permission information, and persists it. For example, suppose the administrator needs to create a new tenant named A on the operation platform to provide e-commerce business services. A enters basic information in the tenant management interface, specifies that the tenant A needs to use two functional modules, such as order management and product management, and configures the tenant to have access rights to query and export orders for order management, and to query products and modify inventory for product management. This information will be submitted to the server, and the server will verify that A has the authority to create a tenant and check the correctness of the corresponding information, functional modules and access rights. After verification, the server will call the tenant management module of the operation platform to create a tenant instance of A and save the corresponding information, associated functional modules, access rights and other data.

[0016] S202, calling Nacos to allocate tenant resources and isolate applications, where the tenant resources include the tenant information, the functional module, and the access rights, and Nacos refers to a dynamic service discovery, configuration management, and service management platform for building cloud-native applications; After creating the tenant, you need to call Nacos to allocate tenant resources and isolate applications. Nacos is a cloud-native application management platform that provides service discovery, configuration management, service management and other functions. The operation platform needs to be integrated with Nacos. When creating a tenant, call the configuration management interface of Nacos to create a resource instance for the tenant in Nacos. The resource instance contains the tenant information, function module information, access permission information, etc. created previously. Nacos will allocate actual CPU, memory, network and other resources to the tenant resource instance according to the resource situation, and isolate it from other tenant resource instances. This ensures the isolation between data and services of different tenants. In addition to resource allocation, the operation platform also needs to create configuration information for the tenant in Nacos, such as database connection configuration, cache configuration, service authentication configuration, etc., for access to the function modules corresponding to the tenant. Configuration also achieves isolation. The advantage of calling Nacos is that resources are dynamically allocated and recycled, and it supports management and control by tenant to improve resource utilization.

[0017] S203, connecting with each subsystem through the agreed interface calling method and synchronization frequency; To ensure the quality of docking, the operation platform needs to agree with each subsystem on a unified interface calling method and data synchronization frequency. The operation platform and multiple subsystems choose to use RESTful-based interface technology. Both parties agree to use POST to send JSON format data for interface interaction. The data interaction format uses JSON, which is simpler and faster to parse than XML. It is the current mainstream lightweight data exchange format. The encoding method is unified as UTF-8 to ensure support for globally common characters and avoid multi-language encoding problems. The data interaction method uses POST submission. POST requests can transmit larger data and have higher security. This can improve the versatility and interoperability of the interface and facilitate interface development and calling in different languages.

[0018] In addition, as the active pusher, the operation platform needs to determine the frequency of synchronizing data to the subsystem. First, perform a full data initialization synchronization to push all valid data in the operation platform to the target system as the basis for subsequent incremental synchronization. The frequency of incremental synchronization is set to push once every 8 seconds. Incremental data refers to resource information that has been added or modified since the last synchronization.

[0019] S204, receiving the user's operation of accessing the target subsystem on the platform, and sending an access request to the target subsystem; when the user clicks to access a target subsystem on the interface of the operation platform, the operation platform needs to receive this access operation and send an access request to the target subsystem. Specifically, the access portals of multiple subsystems will be displayed on the interface of the operation platform. When the user clicks on the portal of a subsystem, the operation platform will capture this click operation, obtain the subsystem information clicked, and then send an access request to the target subsystem. The request contains: user identification, indicating the user who initiated the access request, which can be the user's account or ID, etc. The operation platform has obtained and verified the user identification when the user logs in; target subsystem identification, indicating the subsystem that the user requests to access, in this example, it is the identification information of the subsystem that the user clicked; request timestamp, indicating the exact time when the request was initiated. Other request information may also be included, which is not limited here. The operation platform will perform necessary verifications, such as confirming the correctness of the user identification and the target subsystem identification to avoid illegal requests. After the verification is passed, the address information of the target subsystem will be found, and then an access request data packet will be sent to the service address of the subsystem through the network connection. This data packet follows the predefined protocol specification and contains information such as user identification and access time. After receiving the access request from the operation platform, the target subsystem will start its own authentication process.

[0020] S205, verifying the authority verification information sent by the target subsystem; The process of processing access requests by the target subsystem includes: performing security verification on the request data packet and confirming the integrity of the data packet; querying the user's permission information according to the user identifier to determine whether the user has the permission to access the subsystem; generating a permission verification information data packet. The data packet contains the permission identifier of the query result, indicating whether the verification is passed. It also contains information such as user identifier, subsystem identifier, timestamp, etc.; encrypting the data packet using a predefined security algorithm (such as a digital signature) to prevent the content from being tampered with; and sending the encrypted permission verification information to the operation platform. After receiving the permission verification information returned by the target subsystem, the operation platform needs to verify its content to ensure its authenticity, integrity and accuracy. The specific process of verification is: using a pre-shared key or the public key of the subsystem to decrypt the digital signature and authenticate the integrity of the information; comparing the user identifier, subsystem identifier and other contents in the data packet, and associating the corresponding request for permission verification; proving that it has not been intercepted and tampered with; reading the content of the permission identifier to determine whether the verification result is passed; extracting other important contents in the data packet according to the verification needs. In some embodiments, each target subsystem can maintain a key library respectively, which stores random keys for verifying tenant access rights. The target subsystem will periodically update and refresh these random keys in the keystore to prevent the keys from being cracked.

[0021] When the operation platform sends an access request to the target subsystem, the target subsystem will randomly take out a secret key from the key library and send it to the operation platform, which receives the random secret key. The operation platform then determines whether the user information corresponding to the access request holds the corresponding key and can unlock the random secret key. The operation platform will search for the tenant resource information corresponding to the target subsystem in the platform. These resource information contain the access permission data of each tenant. The operation platform will search for the corresponding key in these access permission data to determine whether the random secret key sent by the target subsystem can be unlocked. If a matching key is found in the tenant resource, it is determined that the key exists, otherwise it is determined that the key does not exist. If the operation platform determines that the corresponding key exists in the tenant resource, it can use this key to unlock the random secret key sent by the target subsystem and decrypt it to pass the access permission verification of the target subsystem.

[0022] S206: If the permission verification information is verified, the tenant resources are synchronized to the corresponding target subsystem according to the preset field table, so that the target subsystem obtains the tenant resources through the operation platform.

[0023] When the operation platform verifies the permission information returned by the target subsystem and determines that the user has the permission to access the subsystem, it can continue to execute the process of issuing tenant resources. Here, the tenant resources can be synchronized to the corresponding target subsystem according to the preset user synchronization interface and the preset field table, wherein the preset field table includes but is not limited to the user service interface general table, the user account field table, the organization information field table and the role interface field table, and may also include other preset field tables, which can be set according to the actual needs of the user and are not limited here. Specifically, the operation platform can determine the interface type according to the preset user service interface general table, which at least includes adding users, modifying users, disabling users and enabling users. The content of the user service interface general table is as follows: The operation platform can also save the synchronized user information according to the preset user account field table. The content of the user account field table is as follows: The operation platform synchronizes the organization of the target subsystem according to the preset organization information field table. The content of the organization information field table is as follows: The parameter is IT_DATA, and the array element type corresponds to the organization information field table of ZORGTREE_ZA, as follows: Below is the organizational information field table of type ZACO_LIST: The operation platform synchronizes roles for the target subsystem according to the pre-set role interface field table. The content of the role table is as follows: The operation platform defines a general table of role service interfaces, which is used to identify whether the push role is newly added, modified, disabled, or enabled. The content of the general table of role service interfaces is as follows: In the embodiment of the present application, due to the technical means of determining the target subsystem to be integrated, integrating with the target subsystem through the agreed interface calling method and synchronization frequency, configuring tenant information and permissions, and calling Nacos for tenant resource allocation and application isolation, efficient integration and collaborative work of the operation platform and subsystems are achieved, and the problems of data inconsistency, redundancy and low resource utilization efficiency caused by independent operation of each subsystem and information isolation in the prior art are effectively solved, thereby achieving the technical effect of improving the integration efficiency of the operation platform and subsystems, ensuring data consistency and security, and improving resource utilization efficiency.

[0024] The following is a scenario description of the method in this application in combination with the above embodiments. Figure 3 , which is another scenario diagram of the multi-tenant implementation method based on the multi-subsystem integration platform in an embodiment of the present application.

[0025] exist Figure 3In the example, the operation platform generates a role for tenant 0001 that includes menu permissions for subsystems A and B. Menu permissions for subsystem A: role id is R001; menu permissions for subsystem B: role id is R002. The operation platform generates a role for tenant 0002 that includes menu permissions for subsystems B and C: menu permissions for subsystem B: role id is R003, menu permissions for subsystem C: role id is C001. User A logs in to the operation platform and accesses tenant 0001: the operation platform only displays menus for subsystems A and B to user A based on the menu permissions of tenant 0001. User A has menu permissions for role R001 in subsystem A, and user A has menu permissions for role R002 in subsystem B. User A switches to access tenant 0002. The operation platform only displays menus for subsystems B and C to user A based on the menu permissions of tenant 0002. User A has menu permissions for role R003 in subsystem B, and user A has menu permissions for role C001 in subsystem C. In this way, when user A accesses different tenants, he sees the menu permissions specific to the tenant, thus achieving menu isolation. Although subsystem B does not perceive the tenant ID, by issuing different role permissions through the operation platform, user A will see different menus when accessing subsystem B in tenants 0002 and 0001, thus achieving the effect of menu isolation.

[0026] In some embodiments, the operation platform needs to collect the interaction data between the target subsystem in real time, including but not limited to the user's operation records, the system's response time, the use of resources, etc. For example, when a user performs an operation on the operation platform, the platform will record the user's operation behavior, operation time, subsystems involved, and other information. At the same time, the platform will also monitor the operating status of each subsystem, such as the load of the operation platform, the delay of the network, etc. Taking an e-commerce platform as an example, the operation platform will collect the operation data of the commodity management subsystem, the order processing subsystem, the payment subsystem, etc. After collecting the interaction data, the operation platform needs to pre-process these data to remove noise and irrelevant information and improve the quality and availability of the data. Pre-processing may include operations such as data cleaning, data conversion, and data normalization. For example, for the user's operation records, some repeated or invalid operations may be removed, the time format may be uniformly converted, and the numerical data may be normalized. After the pre-processing is completed, the operation platform will extract the set key features according to the preset rules and algorithms. These key features are usually important indicators related to system abnormalities, such as the frequency of user operations, changes in response time, and abnormal fluctuations in resource usage. Taking response time as an example, if the response time of a subsystem suddenly increases significantly and exceeds the normal threshold range, this may be a key feature, indicating that there may be an abnormality in the system.

[0027] The operation platform uses an anomaly detection model to identify anomalies in the interaction process. This anomaly detection model is trained based on the normal data, fault type, and impact level labels corresponding to the key features in the historical interaction data. When the extracted key features are input into the anomaly detection model, the model determines whether the current interaction situation is abnormal based on the learned knowledge and patterns. If the model detects an anomaly, it determines the type of anomaly and the impact level. For example, if the model detects that the response time of a subsystem continues to be too long, it may be judged as an abnormal situation of system performance degradation and determine that its impact level is moderate, which may result in a poor user experience. Abnormal situations include fault type and impact level. Fault types may include system crashes, network failures, data errors, etc., and the impact level can be divided into mild, moderate, severe, etc. Once the abnormal situation is determined, the operation platform will immediately send relevant information to the management end. This information includes the type of anomaly, the impact level, the time of occurrence, and the subsystems involved.

[0028] The operation platform will search for matching repair solutions from the preset repair solution library based on the detected abnormal situation. The repair solution library stores various possible abnormal situations and their corresponding solutions. For example, if the abnormal situation is a network failure, the repair solution may include checking the network connection, restarting the network equipment, etc.; if the system performance is degraded, possible repair solutions include optimizing the system configuration, increasing resource allocation, etc. Taking the abnormal situation of the order processing subsystem responding too long as an example, the operation platform may select repair solutions such as optimizing database queries and increasing operation platform resources from the repair solution library. Finally, the operation platform will repair the abnormal situation according to the determined repair solution. This may involve adjusting the system configuration, restarting related services, updating software versions, etc. For example, if the repair solution is to optimize database queries, the operation platform will execute the corresponding database optimization script to adjust the performance of the query statement; if it is to increase the operation platform resources, the platform will allocate more computing resources to the relevant subsystems. During the repair process, the operation platform will closely monitor the operating status of the system to ensure the effectiveness of the repair work. If the abnormal situation still exists after the repair, the platform will re-evaluate and adjust the repair solution until the problem is solved. The operation platform can promptly detect and resolve anomalies in the system by collecting interaction data, extracting key features, performing anomaly detection, sending anomalies, determining repair plans and implementing repairs, thereby ensuring the normal operation of the system and user experience.

[0029] The following is a more detailed description of the process of the method provided by this implementation. Figure 4 , which is another flow chart of the multi-tenant implementation method based on the multi-subsystem integration platform in an embodiment of the present application.

[0030] S401, after receiving the operation information of the user clicking the menu function at the interactive end, sending a use application to the corresponding target subsystem, the use application includes the user identification and the requested function information; When a user clicks on a menu on the interactive end of the operation platform (which can be a web page or mobile app), a usage application will be triggered, and the operation platform needs to receive and process this usage application. Specifically, when a user clicks on a function menu, the interactive end will capture this click operation and send a usage application request to the operation platform. The request contains: 1) User identification. This can be information such as the user's account or ID, which is used to uniquely identify a user. This information is obtained and recorded by the interactive end when the user logs in, and will be included in subsequent operations so that the operation platform can identify the identity of the requesting user. 2) Requested function information. This indicates which specific menu function the user clicked, such as "add user", "apply for report", etc. This information is also obtained by the interactive end and filled in the request.

[0031] The operation platform can be pre-set with a front-end API gateway to receive various requests from the interactive end. When the gateway receives the application request, it will first perform some pre-processing: 1) Verify the legitimacy of the user ID. 2) Record the request log. 3) Request forwarding. After preliminary verification and recording, the request will be forwarded to the controller of the core service module of the operation platform for processing.

[0032] In the operation platform, a module similar to "application processing" can be set up to specifically handle such requests. This module needs to complete the following tasks: 1) Parse the request parameters and check whether the user ID and function information are correctly filled in. 2) Query the user's permissions and query the user's role and permission information in the platform database according to the user ID. Determine whether the user has the access right to request the function. 3) Record the use request. Regardless of whether the permission verification is passed, the use request needs to be recorded in the audit log to track all request information. 4) Send the use application. If the permission verification is passed, the use application needs to be sent to the docking target subsystem. The application contains the user ID and the requested function information. The sending can be completed by calling the interface opened by the target subsystem. 5) Return the response result and return the permission verification result to the interactive end. If the permission verification fails, a prompt message can be returned to inform the user. In this way, the operation platform can receive and verify the user's use application, query the user's permissions, record the audit log, and send the real use application to the target subsystem according to the permission conditions.

[0033] S402, receiving the permission verification information returned by the target subsystem, the permission verification information including the user identifier, function identifier and permission tag; Specifically, after receiving the use application request, the target subsystem will perform permission verification on the request according to its own business logic. The permission verification process may include: 1) verifying the legitimacy of the user ID to avoid illegal access. 2) querying the user's permission to the function based on the function ID, such as checking the role table, etc. 3) generating a permission tag to indicate the verification result. 4) recording the permission audit log, including user ID, function ID, permission tag and other information. 5) using a security algorithm to sign the returned information to prevent the result from being tampered with. The security algorithm can use symmetric or asymmetric encryption. 6) returning the signed permission verification result information to the operation platform.

[0034] S403, judging whether the authority verification information is successfully verified based on a preset encryption verification algorithm; After receiving the permission verification information returned by the target subsystem, the operation platform needs to verify its authenticity to prevent the information from being tampered with.

[0035] Here, a preset encryption verification algorithm can be used to verify the permission verification information. A typical technical solution includes that the target subsystem can use an asymmetric encryption algorithm (such as RSA) to generate a digital signature for the returned permission information. The operation platform holds the public key of the subsystem. After receiving the result, the signature is decrypted using the public key to verify the correctness of the signature and confirm the integrity of the information. At the same time, when the subsystem issues permission information, a timestamp is generated. After receiving the timestamp, the operation platform compares the time difference. If it is within the allowable error range, it proves that the information has not been intercepted or tampered with.

[0036] The operation platform can select an appropriate verification algorithm based on business needs and security requirements, which is not limited here. Verification is performed immediately after receiving the verification information. If the verification fails, step S405 is executed; if the verification succeeds, step S404 is executed.

[0037] S404, returning verification pass information to the target subsystem; When the operation platform successfully verifies the permission verification information using an encryption verification algorithm and proves its authenticity, it needs to return a positive verification response to the target subsystem, indicating that the next business operation interaction can continue. Specifically, the verification information can include important identification information of the original permission verification information, such as user identification and function identification, to associate the context of permission verification; verification result mark, indicating that the verification has been successfully passed; timestamp, indicating the verification time; platform signature to prevent the verification information from being forged; serial number, to ensure the request response order; and other necessary content related to the business.

[0038] S405, returning verification failure information to the target subsystem; If in step S403, the operation platform verifies the permission verification information returned by the target subsystem using a preset encryption verification algorithm and determines that the verification information does not exist or has been tampered with, it indicates that the verification fails. At this time, it is necessary to send a verification failure response message to the target subsystem, which may specifically include a verification result mark indicating that the verification fails. Different mark values ​​may be set to indicate different reasons for failure. Other included contents are similar to those in step S404 and will not be repeated here.

[0039] S406: Establish a tenant feedback mechanism, which is used to provide a channel to collect suggestions from tenants using the operation platform on their usage experience of each target subsystem; In order to continuously improve the functions of the platform and subsystems and meet the needs of tenants, the operating platform needs to establish a tenant feedback mechanism, the main function of which is to collect feedback and suggestions from tenants using platform services on the subsystem usage experience. Specifically, the feedback mechanism can include: adding a feedback form to the user interaction interface of the platform, where tenants can select subsystems, enter problem descriptions, upload screenshots, etc. Required items can also be set, such as contact information; in addition to the form, other feedback channels such as email and customer service phone can be added to facilitate tenant feedback; feedback is classified into categories such as function suggestions, optimization opinions, and fault reports, and different countermeasures can be taken according to categories during subsequent processing; feedback is statistically analyzed to determine hot issues, including which subsystems have more problems and which functions need to be optimized, as a basis for improvement. Feedback after hot spot analysis is shared with relevant subsystems for their improvement, while ensuring that tenant sensitive information is deleted and data compliance requirements are followed.

[0040] In this way, through the establishment of a feedback mechanism, the operation platform can keep in touch with tenants continuously, understand the usage of each subsystem, and promote its continuous optimization and updating to better meet tenant needs and improve the platform service quality.

[0041] S407: Determine tenant demand information for which the number of occurrences of the feedback content is greater than a set number threshold according to the collected tenant feedback information, where the tenant demand information includes suggestions for improving each target subsystem proposed by the tenant; After establishing the tenant feedback mechanism, the operation platform can collect a large amount of feedback on the use of the target subsystem. In order to determine which feedback content truly represents the general needs of tenants, you can set an occurrence threshold to filter: regularly count the number of feedback from feedback forms and other channels, aggregate by molecular system, category, etc., and judge the popularity. According to the actual tenant scale of the operation platform and the total amount of feedback, set a reasonable number threshold. For example, if there are more than 100 tenants and more than 2,000 feedbacks, you can set the threshold to 20, count the number of occurrences of various types of feedback by subsystem and category, and extract the content that exceeds the threshold. These represent the common needs or hot pain points of tenants. Feedback that exceeds the threshold is confirmed as tenant demand information, which can be directly used as suggestions for subsystem optimization without the need to be drafted again. The operation platform needs to send these suggestions to the relevant subsystems and regularly track their implementation to close the feedback optimization process. In this way, through statistical analysis of tenant feedback and setting thresholds to extract hot suggestions, subsystem optimization can be more targeted, directly focusing on the pain points that tenants urgently need to solve, thereby effectively improving the platform service level.

[0042] S408: Call the configuration interface provided by each target subsystem according to the tenant demand information to optimize the function of the target subsystem.

[0043] The operation platform needs to query the configuration interface information opened by the subsystem to determine which interfaces can meet the current optimization requirements. Based on the tenant demand information, the operation platform determines the parameter adjustment plan for the interface. If the demand requires improving the response time, the latency parameters need to be adjusted. The operation platform converts the demand into the parameter content of the interface, assembles it into a standard call request, includes the configuration information to be adjusted, calls the subsystem interface, passes in the optimized configuration parameters, completes the configuration delivery, obtains the result returned by the subsystem, confirms whether the configuration is successful, and needs to retry or alarm if it fails.

[0044] The operation platform should regularly collect tenant feedback to confirm whether the problem has been resolved. If improvement is still needed, the solution should be adjusted and the interface should be re-invoked for optimization until the problem is resolved.

[0045] In the embodiment of the present application, due to the adoption of a series of processing steps after receiving the user operation information, including sending a use application, receiving permission verification information, verifying permission information, establishing a tenant feedback mechanism, determining tenant demand information, and optimizing subsystem functions according to demand, strict control of user permissions and accurate response to tenant needs are achieved, effectively solving the problems of lax user permission management and difficulty in meeting tenant needs in the prior art, thereby achieving the technical effect of improving system security and user satisfaction.

[0046] In some embodiments, the operation platform needs to regularly collect resource usage data reported by the target subsystem to understand the resource usage of each tenant. This includes but is not limited to data on CPU usage, memory usage, storage space usage, network bandwidth usage, etc. For example, the operation platform can set a daily, weekly, or monthly cycle to obtain this data from the target subsystem.

[0047] After collecting resource usage data, the operation platform will determine the resource usage prediction model for each tenant based on this data. This model can help the operation platform predict the future resource demand trend of tenants. For example, the operation platform can use time series analysis, machine learning algorithms and other methods to establish a prediction model. Taking time series analysis as an example, by analyzing the resource usage data of tenants over the past period of time, the rules and trends can be found, thereby predicting future resource usage. Assuming that the memory usage of tenant C has shown a gradual increase in the past few months, the operation platform can establish a prediction model based on this trend to predict that the memory usage of tenant C may continue to grow in the future. The operation platform will continuously optimize and adjust this prediction model to improve the accuracy of the prediction. Based on the resource usage prediction model, the operation platform will determine the tenants with growing resource demand whose growth rate of resource usage data exceeds the set threshold. This threshold is set based on the experience and actual situation of the operation platform, and is intended to distinguish tenants with normal and abnormal growth in resource demand. For example, if the set threshold is that the growth rate of resource usage data exceeds 20%, then when the operation platform finds that the predicted growth rate of tenant D's resource usage data in the future exceeds 20%, tenant D will be judged as a tenant with growing resource demand.

[0048] The operation platform will pay special attention to these tenants with growing resource demand, because they may need more resources to support business development. At the same time, it will also identify tenants with negative resource demand growth whose resource usage data growth rate is lower than a certain threshold, so as to adjust their resource quotas. After identifying tenants with growing resource demand and tenants with negative resource demand growth, the operation platform will call the configuration management interface of Nacos to adjust their resource quotas. For tenants with growing resource demand, the operation platform will increase their resource quota limits to meet the needs of their business growth. For example, increase their CPU core number, memory capacity, storage space, etc. For tenants with negative resource demand growth, the operation platform will reduce their resource quota limits to avoid resource waste. For example, reduce their CPU core number, memory capacity, storage space, etc. By calling the configuration management interface of Nacos, the operation platform can flexibly adjust tenant resource quotas and improve resource utilization efficiency.

[0049] The operation platform will send the adjusted resource quotas to the target subsystem to update the tenant's resource limit policy. The target subsystem will manage and control the tenant's resource usage according to these new resource quota limits. For example, when the operation platform adjusts the resource quota of tenant E to a higher limit, the target subsystem will ensure that tenant E can enjoy these increased quotas when using resources. At the same time, the tenant's resource usage will be monitored to ensure that they do not exceed the quota limit. Finally, the operation platform will schedule and allocate tenants' resource usage rights in real time according to the updated resource limit policy. This means that the operation platform will dynamically adjust the tenants' resource usage rights according to their resource quota limits. For example, if the resource quota limit of tenant F is adjusted to only use a certain number of CPU cores and memory in a certain time period, the operation platform will ensure that tenant F can only use the specified amount of resources during this time period.

[0050] The operation platform will ensure that tenants' resource usage rights are accurately executed through real-time monitoring and scheduling, and will also make dynamic adjustments based on actual conditions to meet tenants' needs.

[0051] The following describes the operating platform in the embodiment of the present invention from the perspective of hardware processing. Figure 5 , which is a schematic diagram of a physical device structure of an operating platform in an embodiment of the present application.

[0052] It should be noted that Figure 5 The structure of the operation platform shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present invention.

[0053] like Figure 5 As shown, the operation platform includes a central processing unit (CPU) 501, which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 502 or the program loaded from the storage part 508 to the random access memory (RAM) 503, such as executing the method described in the above embodiment. In RAM503, various programs and data required for system operation are also stored. CPU501, ROM502 and RAM503 are connected to each other through bus 504. Input / output (I / O) interface 505 is also connected to bus 504.

[0054] The following components are connected to the I / O interface 505: an input section 506 including an audio input device, a button switch, etc.; an output section 507 including a liquid crystal display (LCD) and an audio output device, an indicator light, etc.; a storage section 508 including a hard disk, etc.; and a communication section 509 including a network interface card such as a LAN (Local Area Network) card, a modem, etc. The communication section 509 performs communication processing via a network such as the Internet. A drive 510 is also connected to the I / O interface 505 as needed. A removable medium 511, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 510 as needed so that a computer program read therefrom is installed into the storage section 508 as needed.

[0055] In particular, according to an embodiment of the present invention, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present invention includes a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a computer program for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication section 509, and / or installed from a removable medium 511. When the computer program is executed by a central processing unit (CPU) 501, various functions defined in the present invention are performed.

Claims

1. A multi-tenant implementation method based on a multi-subsystem integration platform, applied to an operation platform, characterized in that: The method comprises: Create tenants based on the tenant information entered by the administrator on the operation platform, the tenant's corresponding functional modules and access rights. The access rights refer to the set range of operations that the tenant is allowed to perform when using the operation platform and its various subsystems. Call Nacos to allocate tenant resources and isolate applications. The tenant resources include tenant information, function modules, and access rights. Nacos is a dynamic service discovery, configuration management, and service management platform for building cloud-native applications. Connect with each subsystem through the agreed interface calling method and synchronization frequency; Receiving the user's operation of accessing the target subsystem on the platform, sending an access request to the target subsystem; Verify the permission verification information sent by the target subsystem; If the permission verification information is verified, the tenant resources are synchronized to the corresponding target subsystem according to the preset field table, so that the target subsystem obtains the tenant resources through the operation platform.

2. The method according to claim 1, characterized in that If the permission verification information is verified, the steps of synchronizing the tenant resources to the corresponding target subsystem according to the preset field table so that the target subsystem obtains the tenant resources through the operation platform specifically include: If the permission verification information is verified, the user information is synchronized to the corresponding target subsystem according to the preset user synchronization interface; Determine the interface type according to a preset user service interface general table, where the interface type at least includes adding a new user, modifying a user, disabling a user, and enabling a user; Save the synchronized user information according to the preset user account field table; Synchronize the target subsystem with the organization according to the preset organization information field table; The target subsystem is synchronized with roles according to a preset role interface field table.

3. The method according to claim 1, characterized in that After receiving the user's operation of accessing the target subsystem on the platform and sending an access request to the target subsystem, the method further includes: Obtaining a random key sent by the target subsystem, where the random key refers to a key randomly refreshed in the target subsystem key library for verifying tenant access rights; Determine whether the random key has a key based on the random key combined with the tenant resources corresponding to the platform; If there is a key in the tenant resource, the random key is unlocked and the tenant resource is synchronized to the target subsystem.

4. The method according to claim 3, characterized in that If there is a key in the tenant resource, the random key is unlocked, and after the step of synchronizing the tenant resource to the target subsystem, the method further includes: Establishing a tenant feedback mechanism, the tenant feedback mechanism is used to provide a channel to collect suggestions from tenants using the operation platform on the usage experience of each of the target subsystems; Determine tenant demand information whose feedback content appears more than a set threshold number of times according to the collected tenant feedback information, wherein the tenant demand information includes suggestions for improving each of the target subsystems proposed by the tenant; The configuration interface provided by each of the target subsystems is called according to the tenant demand information to optimize the function of the target subsystem.

5. The method according to claim 1, characterized in that After calling Nacos to allocate tenant resources for application isolation, it also includes: Collect interaction data with the target subsystem, After processing the interaction data, extracting set key features; Inputting the key features into an anomaly detection model to determine abnormal situations in the interaction process, wherein the anomaly detection model is trained based on normal data, fault type and impact degree labels corresponding to the key features in historical interaction data, and the abnormal situations include fault type and impact degree; The abnormal situation is sent to the management end.

6. The method according to claim 5, characterized in that After the step of inputting the key features into the anomaly detection model to determine the abnormal situation in the interaction process, the method further includes: Determine a matching repair solution from a preset repair solution library according to the abnormal situation; The abnormal situation is repaired according to the repair plan.

7. The method according to claim 1, characterized in that After the step of sending the tenant resource to the target subsystem according to the integration relationship with the target subsystem, the method further includes: Regularly collect resource usage data reported by the target subsystem; Determining a resource usage prediction model for each tenant based on the resource usage data; Determining, according to the resource usage prediction model, a tenant with a resource demand growth whose growth rate of the resource usage data exceeds a set threshold; Call the configuration management interface of Nacos to increase the resource quota limit of the tenant with increasing resource demand and reduce the resource quota limit of the tenant with negative resource demand growth. The tenant with negative resource demand growth refers to the tenant with negative resource usage demand growth; Send the adjusted resource quota to the target subsystem to update the tenant's resource restriction policy; The resource usage rights of tenants are scheduled and allocated in real time according to the updated resource restriction policy.

8. An operation platform, characterized in that: The operation platform includes: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code includes computer instructions, and the one or more processors call the computer instructions to enable the operation platform to execute the method described in any one of claims 1-7.

9. A computer-readable storage medium comprising instructions, characterized in that: When the instruction is executed on the operation platform, the operation platform is caused to execute the method according to any one of claims 1 to 7.

10. A computer program product, characterized in that When the computer program product runs on an operation platform, the operation platform is enabled to execute the method according to any one of claims 1 to 7.

Images