Human resource management method based on distributed SaaS

Abstract

The invention relates to the technical field of resource management, in particular to a human resource management method based on distributed SaaS. The method comprises the following steps: constructing a multi-tenant isolation architecture, separating data and behaviors of different tenants, and establishing a tenant configuration table containing tenant basic information, a data storage path and permission configuration at the same time; providing a user-defined interface and a business rule configuration function for each tenant based on the tenant configuration table, and setting a corresponding business module flow and a display style; the method comprises the following steps: splitting into a plurality of micro-service modules by adopting a distributed system architecture, and realizing event-driven decoupling among the micro-service modules by utilizing a message queue; and monitoring the resource use condition of each tenant based on the user-defined interface in real time, dynamically allocating system resources, carrying out system upgrading and vulnerability repairing operation on all tenants, and realizing data interaction with an external system by utilizing an open API interface. According to the invention, high availability, expandability and safe operation of human resource management can be realized.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of resource management, and in particular to a distributed SaaS-based human resource management method. BACKGROUND

[0002] With the rapid development of information technology, enterprise human resource management (HRM) has transformed from traditional manual management mode to more efficient and flexible digital management mode. Especially under the tide of globalization and digitization, enterprises are facing challenges such as wide distribution of personnel, complex management, real-time and accuracy requirements of data, etc. In order to improve the efficiency, accuracy and flexibility of human resource management, SaaS (Software as a Service) human resource management solution based on cloud computing has gradually become the mainstream.

[0003] In addition, similar patents such as CN115564369A disclose an intelligent information screening system for human resource management platform, which includes the present application. The intelligent information screening system for human resource management platform based on cloud computing developed by human resource cloud, so that the enterprise human resource management system is an important application and attempt of multidisciplinary technology in human resource management. The implementation of this system breaks through the defects of traditional human resource management and the barrier that data cannot be shared between different departments. It can realize extensive cooperation of data resources, and realize reasonable mining of data by using the advantages of resource integration, distributed computing and collaborative management of cloud computing. Although it can realize the sharing and management of data between different departments, it still tends to be a single server or data center, lacks high distributed deployment capability, and fails to fully realize flexible management between multiple tenants, especially in personnel management, performance evaluation, salary management, etc. It lacks sufficient intelligent analysis and decision support, which affects the optimization and efficiency of the human resource management process. SUMMARY

[0004] In order to solve the above technical problems existing in the current human resource management system, the present application provides a distributed SaaS-based human resource management method which can efficiently and flexibly manage the data and behavior of multiple tenants through a multi-tenant isolation architecture, guarantee data security and isolation, and improve the data permission management efficiency of the human resource management process by providing personalized custom interface and business process configuration functions for each tenant, comprising the following steps: A multi-tenant isolation architecture is constructed, and the data and behavior of different tenants are separated through the multi-tenant isolation architecture to generate an independent tenant identifier for each tenant and establish a tenant configuration table containing tenant basic information, data storage path and permission configuration; providing a customized interface, a business rule configuration function and a tenant for each tenant based on the tenant identifier and the tenant configuration table, and enabling the tenant to set up a business module process and a display style of a corresponding human resource management function including core personnel, performance management, democratic evaluation, democratic recommendation, evaluation, title review, talent map, online examination, online learning, salary, talent inventory and integration without modifying underlying codes, and storing the business module process and the display style in association with the tenant identifier; adopting a distributed system architecture, splitting the human resource management function into a plurality of micro-service modules, assigning data access permissions of corresponding tenants to each micro-service module according to a data storage path in the tenant configuration table, and realizing event-driven decoupling between the micro-service modules by using a message queue; monitoring resource usage of each tenant based on the customized interface in real time, and dynamically allocating system resources according to the resource usage, so as to automatically expand corresponding micro-service nodes to complete elastic allocation of computing power and bandwidth when a business peak period including a year-end performance evaluation is detected; reading tenant basic information in the tenant configuration table through a cloud platform, performing system upgrade and vulnerability repair operations on all tenants, and realizing data interaction with external systems by using an open API interface, and performing data authority verification management according to permission configuration in the tenant configuration table during the interaction process.

[0005] The application can effectively separate the data and behavior of different tenants by constructing a multi-tenant isolation architecture, thereby ensuring the security and privacy of the data of each tenant. Each tenant has an independent identification and personalized configuration table, allowing customization of business processes and display styles according to different needs without modifying the underlying code, greatly improving the flexibility and scalability of human resource management. Based on a distributed system architecture, the functional modules are split into multiple microservices, allowing decoupling between modules through message queues, further improving the maintainability and stability of the human resource management process. Dynamic resource allocation and elastic expansion ensure high availability and high response capability of human resource management during peak periods (such as performance evaluation season), avoiding resource bottlenecks that affect user experience. Real-time monitoring of resource usage of tenant-defined interfaces allows automatic expansion of microservice nodes based on load, enabling elastic allocation of computing power and bandwidth, effectively improving the processing capacity and efficiency of human resource management. At the same time, centralized management using a cloud platform allows unified system upgrades and vulnerability fixes for all tenants, ensuring that the system always remains in the latest secure state. The use of open API interfaces enables seamless integration with external systems and data access control based on permissions in the tenant configuration table, ensuring data security and compliance. These features enable the human resource management system to support multiple tenants while maintaining high efficiency, security, and flexibility.

[0006] Preferably, the multi-tenant isolation architecture is constructed, and the data and behavior of different tenants are separated through the multi-tenant isolation architecture, specifically including: A tenant data storage mapping table is established according to the multi-tenant isolation architecture, and each tenant is allocated an independent database storage space or data storage area. The information corresponding to the database storage space or data storage area is recorded in the tenant configuration table. Tenant filtering rules are set in the data access layer. When a data access request is received, the tenant identification in the data access request is used to filter the data storage path information of the corresponding tenant from the tenant configuration table, and then the tenant basic information of the corresponding tenant is filtered. The operation behavior of different tenants is logged and isolated, and the log file path and associated tenant identification are recorded in the tenant configuration table to ensure that the operation logs of each tenant are independent and inaccessible.

[0007] This invention constructs a multi-tenant isolation architecture and effectively separates the data and behaviors of different tenants, significantly improving data security and privacy protection. While allocating independent database storage space or regions to each tenant, relevant information is recorded through a tenant configuration table, facilitating efficient management of each tenant's data storage path and configuration information. Tenant filtering rules are set at the data access layer to ensure that basic information of the corresponding tenant is correctly filtered based on the tenant identifier during data access, thereby achieving precise data access control. Furthermore, by isolating tenant operation logs, it ensures that each tenant's operation logs are independent and inaccessible, effectively preventing data leakage and operational interference, and improving system auditability and security. This architecture ensures system manageability and stability under high concurrency and large-scale usage scenarios, meeting the high-efficiency operation requirements of a multi-tenant environment.

[0008] Preferably, the step of establishing a tenant data storage mapping table and allocating independent database storage space or data storage area for each tenant further includes: A multi-tenant database mode is adopted. Based on the tenant size and data volume, the basic information of the tenant is obtained from the tenant configuration table, and then the independent database mode, the shared database independent schema mode, or the shared database shared schema mode are selected. A unique data storage path identifier is generated for each tenant to associate and store the business data corresponding to the tenant with the data storage path identifier, and the tenant configuration table is updated accordingly. The tenant data storage mapping table is regularly optimized and backed up, and the backup information is recorded in the tenant configuration table to ensure the accuracy and security of data storage.

[0009] This invention establishes a tenant data storage mapping table and allocates independent database storage space or region to each tenant. This facilitates personalized storage management for each tenant, improves data isolation and security, and adopts a multi-tenant database model. The most suitable storage solution is selected based on the tenant's size and data volume, better meeting the needs of different tenants while optimizing system storage efficiency and resource utilization. A unique data storage path identifier is generated for each tenant, ensuring efficient data storage and accurate access. Furthermore, regularly optimizing and backing up the tenant data storage mapping table not only improves data storage accuracy and security but also enhances system disaster recovery capabilities, reducing the risk of data loss or corruption and ensuring business continuity and system stability.

[0010] Preferably, the selection method for choosing between independent database mode, shared database independent schema mode, or shared database shared schema mode is as follows: The basic information of the tenant, including the amount of tenant data and the security requirements, is obtained from the tenant configuration table. When the amount of tenant data is large and the security requirements are extremely high, the independent database mode is selected to create a separate database instance for each tenant and record the instance information in the tenant configuration table. When the amount of tenant data is moderate and a certain degree of data sharing is required, the shared database independent schema mode is selected to allocate independent schema information for each tenant in the same database and record the schema information in the tenant configuration table. When the amount of tenant data is small and the security requirements are sensitive, the shared database shared schema mode is selected, and different tenant data is distinguished by adding a tenant identifier field, and the tenant identifier field is recorded in the tenant configuration table.

[0011] This invention allows for flexible adaptation to different tenant needs by selecting an independent database mode, a shared database independent schema mode, or a shared database shared schema mode based on the tenant's size, data volume, and security requirements. Under conditions of high data volume and high security requirements, the independent database mode provides each tenant with a separate database instance, significantly improving data isolation and security, and reducing the risk of cross-tenant data interference. For medium-sized tenants, choosing the shared database independent schema mode can improve resource utilization and system scalability while ensuring data isolation. For small-scale tenants with lower security requirements, the shared database shared schema mode allows for data differentiation through a tenant identifier field, reducing costs and improving system performance. Flexible selection of the database mode according to different needs effectively optimizes system resources and performance, meeting the personalized needs of different tenants.

[0012] Preferably, when selecting the shared schema mode for the shared database, the method further includes: Establish a data access permission matrix, and set read, write, and modify permissions for different tenants on the data in the shared database based on the permission configuration in the tenant configuration table and the tenant roles and business requirements, and update the tenant configuration table. Sensitive data in the shared database is encrypted using the national standard SM4 algorithm, and the information of the encryption algorithm is recorded in the tenant configuration table. The integrity of the data in the shared database is periodically verified, and the verification results are recorded in the tenant configuration table to ensure that the data has not been illegally tampered with.

[0013] In this invention, when selecting a shared schema mode for a shared database, the establishment of a data access permission matrix and encryption processing ensure data security and privacy protection for different tenants. First, a detailed access permission matrix is ​​established, setting different read and write permissions for each tenant based on permissions in the tenant configuration table and business needs, preventing data leakage and unauthorized access. Simultaneously, sensitive data is encrypted using the national cryptographic algorithm SM4 to enhance data security and ensure confidentiality during transmission and storage. Information about the encryption algorithm is recorded in the tenant configuration table for easy auditing and compliance checks. Furthermore, regular data integrity checks effectively monitor data changes, ensuring that data in the database has not been illegally tampered with, thereby strengthening data credibility and system stability. These measures improve system security, reliability, and compliance, enhance user trust, and support efficient data management and service delivery.

[0014] Preferably, a distributed system architecture is adopted, in which the human resource management function is divided into multiple microservice modules, and message queues are used to achieve event-driven decoupling between the microservice modules, specifically including: The human resource management functions are divided into several microservice modules with clearly defined functions, including core personnel, performance management, democratic evaluation, democratic recommendation, assessment, professional title review, talent map, online examination, online learning, compensation, talent inventory, and integration. Based on the permission configuration in the tenant configuration table, data access permissions for each microservice module are assigned to the corresponding tenant. Deploy message queues among the microservice modules. When a data change or business event occurs in a microservice module, the event information is encapsulated into a message and sent to the message queue. Other microservice modules subscribe to relevant message topics and perform corresponding business processing based on the received messages to achieve loosely coupled communication between microservice modules. During the communication process, data permission verification is performed based on the permission configuration in the tenant configuration table.

[0015] This invention employs a distributed system architecture, breaking down human resource management functions into multiple microservice modules. This enhances the system's scalability, maintainability, and flexibility. Each microservice module focuses on specific business functions, such as core personnel and performance management, and can be independently developed, deployed, and expanded, reducing system complexity. Simultaneously, message queues enable event-driven decoupling between microservice modules, allowing each module to automatically notify relevant modules when data changes, thus achieving efficient business collaboration. This loosely coupled communication method not only improves system fault tolerance but also facilitates data permission verification between different modules, ensuring system security and compliance. Furthermore, the use of message queues effectively improves system response speed and processing efficiency, meeting the demands of high concurrency and high load business operations and optimizing resource utilization.

[0016] Preferably, the specific deployment process for deploying message queues among the microservice modules is as follows: Select a highly reliable message queue middleware, including RabbitMQ or Kafka, and build a message queue cluster based on the message queue middleware. Record the information corresponding to the message queue cluster in the tenant configuration table. Each microservice module is assigned an independent message channel to prevent message conflicts, and the message channel is recorded in the tenant configuration table; Configure the message persistence policy of the message queue to ensure that messages are not lost in the event of system failure, and record the message persistence policy in the tenant configuration table; The message queue is monitored for performance. When the message backlog exceeds the threshold, the message processing expansion mechanism is automatically triggered.

[0017] This invention achieves efficient internal communication and rapid response to business events by deploying highly reliable message queues among microservice modules. By selecting highly reliable message queue middleware such as RabbitMQ or Kafka and building a message queue cluster, it ensures that messages are not lost during transmission. Each microservice module is independently allocated a message channel to avoid message conflicts and guarantee message delivery accuracy. By setting a message persistence strategy, lost messages can be recovered in the event of system failure, ensuring the continuity and reliability of business data. Simultaneously, a performance monitoring mechanism can detect the message queue load in real time. When the message backlog exceeds a threshold, a scaling mechanism is automatically triggered to ensure high availability and processing capacity. These measures help improve system stability and efficiency, ensuring that each microservice module can operate smoothly under high load, effectively supporting efficient business expansion and operation.

[0018] Preferably, the message persistence strategy is as follows: Set the persistence level of important business messages in the message queue to disk persistence to ensure that the important business messages can still be recovered after the server restarts; Non-critical business messages in the message queue are persisted in memory to improve message processing efficiency; Periodically archive and clean up important business messages persisted on the disk to free up disk space, and record the archive and cleanup information in the tenant configuration table; Establish a message persistence status monitoring mechanism to automatically retry or issue an alarm when message persistence failure is detected.

[0019] This invention employs disk persistence for critical business messages and memory persistence for non-critical business messages, effectively ensuring system stability and performance. Disk persistence ensures that important business messages can be recovered after a server restart, reducing the risk of data loss due to system failures or unexpected restarts and guaranteeing system reliability. Meanwhile, memory persistence improves message processing efficiency, avoiding performance bottlenecks caused by disk access. Regularly archiving and cleaning up disk-persistent messages helps free up disk space, prevents excessive storage pressure, and maintains efficient system operation. Recording archiving and cleaning operations in the tenant configuration table facilitates subsequent data management and auditing. Finally, the established message persistence status monitoring mechanism can promptly detect persistence failures and automatically retry or issue alarms, ensuring timely recovery of business messages and normal system operation, thus improving system fault tolerance and stability.

[0020] Preferably, the message persistence state monitoring mechanism specifically includes: A persistent status flag field is set in the message queue to record the persistent status of each message in real time; The message queue is scanned by a scheduled task to check the message persistence status. When an abnormal message is found, it is transferred to the abnormal message queue. The messages in the abnormal message queue are analyzed and processed. If the error is recoverable, a retry operation is performed automatically. If the error is unrecoverable, a detailed error log is generated and an alarm is sent to the operation and maintenance personnel.

[0021] This invention establishes a message persistence status monitoring mechanism that can track and manage the persistence status of each message in the message queue in real time. This provides the system with accurate status monitoring, enabling the immediate detection of persistence failures. Through periodic task scanning and the setting of status flag fields, abnormal messages can be quickly identified and transferred to the abnormal message queue, avoiding potential system failures. By processing messages in the abnormal message queue, when recoverable errors are encountered, automatic retries can be performed, reducing the need for manual intervention and improving the system's automation and intelligence level. For unrecoverable errors, detailed error logs are generated and alarms are sent to notify maintenance personnel, allowing for timely handling of anomalies, preventing serious system problems, and ensuring the high availability and continuous stable operation of the system.

[0022] Preferably, the system upgrade and vulnerability patching operations for all tenants specifically include: Establish an upgrade task management module in the cloud platform to formulate system upgrade and vulnerability remediation plans; Before the upgrade, perform compatibility testing on each tenant and generate a compatibility testing report; A canary rollout approach was adopted to first conduct a pilot upgrade for a select group of tenants, collect feedback, and verify the upgrade's effectiveness. Once the pilot test is successful, automated scripts will be used to perform system upgrades and vulnerability patching operations on all tenants in batches, and the upgrade progress and system status will be monitored in real time during the operation.

[0023] This invention significantly improves the security and stability of the cloud platform by performing system upgrades and vulnerability patching on all tenants. Establishing an upgrade task management module and developing an upgrade plan facilitates comprehensive control over the upgrade process, ensuring the orderly execution of all operations. Compatibility testing effectively identifies potential compatibility issues, preventing system incompatibility or malfunctions caused by the upgrade, thereby improving system stability. The canary release approach, initially piloted on a select group of tenants, effectively gathers feedback, verifies the upgrade's effectiveness, and ensures that the upgraded system's performance and stability are unaffected. Once the pilot is successful, automated scripts are used to batch upgrade all tenants, reducing the risks and costs of manual operations and improving upgrade efficiency. Simultaneously, real-time monitoring of upgrade progress and system status enables rapid response and repair in case of problems, ensuring the smooth progress of the entire upgrade process and ultimately improving the overall reliability and security of the cloud platform.

[0024] The present invention has the following specific beneficial effects: (1) By constructing a multi-tenant isolation architecture, the data and behaviors of different tenants are effectively isolated, ensuring the data privacy and security of each tenant. This architecture can generate an independent identifier for each tenant, which enables efficient and flexible management of the data and behaviors of multiple tenants, ensuring data security and isolation, thereby providing customized services for different tenants and avoiding cross-interference of data and behaviors. Establishing a tenant configuration table can facilitate the management of tenant basic information, data storage paths and permission configurations, ensuring that tenant configurations are flexible and easy to manage. This architecture design can also easily expand or adjust tenant configurations in the future, making it highly maintainable and adaptable. It can be quickly adjusted when the needs of different tenants change without affecting the business operations of other tenants. At the same time, the multi-tenant isolation architecture also plays an important role in improving the resource utilization and operational efficiency of the human resource management system.

[0025] (2) Providing each tenant with a customizable interface and business rule configuration function allows tenants to personalize the display of business modules and processes in their human resource management functions without modifying the underlying code. This function greatly enhances the flexibility and customizability of the system, enabling tenants to customize and optimize the usage of their core personnel, performance management, and professional title evaluation modules according to their own needs, thereby better meeting the management needs of different enterprises. In addition, by customizing the display style and business processes, tenants can also improve the user experience of employees and the adaptability of the system, making the system more efficient and user-friendly in actual application. By setting the associated tenant identifier, the data and configuration of each tenant are perfectly matched with their personalized needs, improving the pertinence and accuracy of the human resource management system.

[0026] (3) By adopting a distributed system architecture and splitting the human resource management function into multiple microservice modules, the scalability, maintainability, and fault tolerance of the system can be greatly improved. Each microservice module handles a specific function, reducing the coupling between modules and making the system more flexible in future function expansion or updates. According to the data storage path in the tenant configuration table, the corresponding tenant data access permissions are assigned, which not only improves the data security of the system but also ensures that the data of each tenant is completely independent, preventing the risk of data leakage. At the same time, the use of message queues to achieve event-driven decoupling between microservice modules further improves the processing efficiency and response speed of human resource management, avoids the mutual dependence problem between modules, and improves the stability and performance of the overall system.

[0027] (4) By monitoring the resource usage of each tenant in real time, the system resources can be dynamically adjusted and allocated according to actual needs, ensuring that the system performance is not affected during peak business periods or high loads. This intelligent resource allocation mechanism can automatically expand microservice nodes according to the business needs of different tenants, ensuring that computing power and bandwidth are expanded in a timely manner and avoiding performance bottlenecks. Especially during peak business periods such as year-end performance evaluations, it can identify and automatically expand in advance to meet the needs of large-scale concurrent access. By dynamically allocating resources, the system performance is not only improved, but also the resource utilization rate is optimized, unnecessary resource waste is reduced, and a more efficient and stable service experience is provided for enterprises.

[0028] (5) By centrally managing tenant basic information through the cloud platform and performing system upgrades and vulnerability patching operations, it is possible to ensure that all tenants enjoy unified services and updates on the same platform. Automated operations improve operational efficiency, reduce the complexity of manual intervention, and use open API interfaces to interact with external systems, ensuring the system's scalability and compatibility with third-party systems. During data interaction, data permission verification is performed based on the permission configuration in the tenant configuration table, which can ensure data security and prevent unauthorized access or data leakage. Through this management model, all tenants can always stay in the latest version of the system environment, reduce potential risks caused by security vulnerabilities, and improve the overall security and stability of the system. Attached Figure Description

[0029] Other features, objects, and advantages of the invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Fig. 1 This is a flowchart illustrating the steps of the distributed SaaS human resource management method of the present invention. Fig. 2 This is a flowchart illustrating the steps involved in constructing a multi-tenant isolation architecture and separating the data and behaviors of different tenants using the multi-tenant isolation architecture. Detailed Implementation

[0030] The present invention will be further described below with reference to the accompanying drawings and embodiments, but this should not be construed as limiting the present invention.

[0031] To achieve the above objectives, please refer to Figs. 1-2 This invention provides a distributed SaaS-based human resource management method, such as... Fig. 1 As shown, it includes the following steps: S1: Construct a multi-tenant isolation architecture, and separate the data and behavior of different tenants through the multi-tenant isolation architecture, so as to generate an independent tenant identifier for each tenant, and establish a tenant configuration table containing basic tenant information, data storage path and permission configuration; In this embodiment of the invention, a multi-tenant isolation architecture is built by using containerization technology (such as Docker) and Kubernetes cluster. Each tenant is assigned an independent Docker container as its running environment. Strict data and behavior isolation is achieved between containers through network policies. Taking a group company as an example, its three subsidiaries are connected to the system as different tenants. The system generates a unique UUID for each subsidiary as a tenant identifier. The tenant configuration table is stored in a MySQL database. The table structure includes tenant ID (i.e., tenant identifier), tenant name, data storage path (such as a folder named after the tenant ID in an AWS S3 bucket), and permission configuration (a list of role permissions stored in JSON format). The data storage path of subsidiary A is s3: / / hrm-system / tenant. Its permission configuration defines the operation permissions of three types of roles: ordinary employees, department managers, and HR administrators.

[0032] S2: Based on the tenant identifier and the tenant configuration table, provide each tenant with a custom interface and business rule configuration function, and enable the tenant to personalize the business module processes and display styles, including core personnel, performance management, democratic evaluation, democratic recommendation, assessment, professional title review, talent map, online examination, online learning, salary, talent inventory and integration of corresponding human resource management functions, without modifying the underlying code. At the same time, associate the business module processes and display styles with the tenant identifier storage. In this embodiment of the invention, based on the generated tenant identifier and tenant configuration table, the front-end framework Vue.js and the back-end framework Spring are used. Boot builds a personalized configuration platform. Personalized settings include core personnel, performance management, democratic evaluation, democratic recommendation, assessment, professional title review, talent mapping, online examination, online learning, compensation, talent inventory, and integrated business module processes and display styles for corresponding human resource management functions. Taking core personnel management as an example, the system provides each tenant with a visual process arrangement tool. In the process design interface, tenants can drag and drop nodes such as "employee onboarding application," "background investigation," and "contract signing" to arrange them according to the actual process sequence of the enterprise, and set the person in charge and approval conditions for each node. For display styles, tenants can choose from 10 preset theme templates and adjust the field display order, color, font size, etc. After configuration, the business module processes are stored in the BPMN (Business Process Model and Representation) 2.0 standard format, and the display styles are stored in the form of CSS style sheets. Both are linked through tenant identifiers and stored in the corresponding tenant's database instance. When a tenant accesses the human resource management system, the system reads the business process and display style configuration from the database based on the tenant identifier and dynamically renders the page, allowing tenants to complete personalized settings without modifying the underlying code.

[0033] S3: Adopting a distributed system architecture, the human resource management function is divided into multiple microservice modules. Data access permissions for each microservice module are assigned to the corresponding tenants according to the data storage path in the tenant configuration table, and event-driven decoupling between the microservice modules is achieved using message queues. In this embodiment of the invention, Kubernetes is used as the container orchestration tool to build a distributed system architecture. The human resource management function is divided into 15 microservice modules, including employee information management, attendance management, and payroll calculation. Each microservice module is deployed as an independent Docker container, and inter-service communication is managed through the service mesh Istio. Based on the data storage path in the tenant configuration table, the corresponding tenant database connection information is set in the data source configuration of each microservice module. For example, when the employee information management microservice starts, it reads the tenant identified as TENANT_001 from the configuration center. Its data storage path is "192.168.1.100:3306 / TENANT_001", and establishes a database connection. RabbitMQ is used as a message queue to achieve event-driven decoupling between microservice modules. When employee attendance data changes, the attendance management microservice encapsulates the change information into a message and sends it to a designated queue in RabbitMQ. The payroll calculation microservice subscribes to this queue and automatically triggers the payroll calculation process upon receiving the message, avoiding direct calls between microservices and improving the system's scalability and stability.

[0034] S4: Monitor the resource usage of each tenant based on the custom interface in real time, and dynamically allocate system resources according to the resource usage. When a business peak period corresponding to the year-end performance assessment is detected, automatically expand the corresponding microservice nodes to complete the elastic allocation of computing power and bandwidth. In this embodiment of the invention, a resource monitoring system is built using Prometheus and Grafana to collect resource usage data of each tenant based on a custom interface in real time. Prometheus continuously collects metrics such as CPU utilization, memory usage, and network traffic by embedding an Exporter component in each microservice container and stores them in a time-series database every 5 seconds. Grafana visualizes this data to form a real-time monitoring panel that includes the tenant name, resource usage curve, and current load status. Taking the peak period of year-end performance evaluation as an example, when it is detected that the CPU utilization of a tenant's performance evaluation microservice exceeds 80% for 10 consecutive minutes and the request queue accumulates more than 500 tasks, the Kubernetes Horizontal Pod Autoscaler (HPA) mechanism is triggered. HPA automatically creates 3 new performance evaluation microservice Pod instances in the Kubernetes cluster based on the pre-set CPU utilization threshold (75%) and memory utilization threshold (80%), and distributes traffic evenly to the new nodes through the service discovery mechanism. Meanwhile, by utilizing Alibaba Cloud's Elastic Bandwidth service, the network bandwidth corresponding to this tenant was temporarily increased from 100Mbps to 500Mbps. The entire elastic allocation process was completed within 2 minutes, ensuring the system's stable operation during peak business periods.

[0035] S5: Read the basic tenant information in the tenant configuration table through the cloud platform, perform system upgrades and vulnerability repair operations for all tenants, and use the open API interface to realize data interaction with external systems. During the interaction, perform data permission verification and management according to the permission configuration in the tenant configuration table.

[0036] In this embodiment of the invention, the AWS Systems Manager tool, based on the AWS cloud platform, is used to perform system upgrades and vulnerability patching operations for all tenants. The AWS Systems Manager's Run Command function filters the tenant configuration table to select tenants whose status is "online" and meet the upgrade conditions. Standardized upgrade scripts are then executed for each tenant's independent database instance and microservice container. For example, when a security vulnerability is discovered in the Spring Boot framework, the upgrade process is first simulated in a test environment. After verification, the Run Command pushes an image file containing the vulnerability patch to all tenants' microservice containers, and the containers are restarted sequentially to complete the upgrade. The entire process is transparent to the tenants. Regarding data interaction, the Swagger specification is used to define open API interfaces. External systems obtain access tokens via the OAuth 2.0 protocol. Each time an API is called, the system reads the caller's corresponding permissions from the tenant configuration table and assigns "salary data read" permission. If the permission is not present, a 403 Forbidden error is returned. Simultaneously, AWS API Gateway is used for traffic control and security protection of API calls, recording all interaction logs to ensure the security and traceability of data interactions.

[0037] Furthermore, such as Fig. 2 As shown, the construction of a multi-tenant isolation architecture, and the separation of data and behavior of different tenants through the multi-tenant isolation architecture, specifically includes: S101: Establish a tenant data storage mapping table according to the multi-tenant isolation architecture, allocate an independent database storage space or data storage area to each tenant, and record the information corresponding to the database storage space or data storage area to the tenant configuration table; In this embodiment of the invention, when constructing the tenant data storage mapping table based on a multi-tenant isolation architecture, a relational database PostgreSQL is used as the storage carrier. For 1000 tenants, a data table named `tenant_storage_mapping` is created. This table contains `tenant_id` (using UUID encoding, such as a1b2c3d4-e5f6-7g8h-i9j0-k1l2m3n4o5p6), `storage_type` (explicitly indicating whether it's an independent database instance or a shared database partition), and `storage_address` (recording the database instance IP and port, such as 192.168.1.1). The system automatically creates an independent database instance or partitions a dedicated data partition in the OpenStack cloud storage platform for newly registered tenants. For example, if tenant TENANT_001 is assigned to an independent database instance at address 192.168.1.101:5432, the system writes the instance information and tenant identifier into the tenant_storage_mapping table and synchronously updates the data storage path field in the tenant configuration table to ensure that each tenant has independent and traceable data storage space.

[0038] S102: Set tenant filtering rules in the data access layer. When a data access request is received, filter the data storage path information of the corresponding tenant from the tenant configuration table according to the tenant identifier in the data access request, and then filter the basic tenant information of the corresponding tenant. In this embodiment of the invention, when implementing tenant filtering rules at the data access layer, Spring Cloud Gateway is used as the API gateway to uniformly intercept all data access requests. When a tenant initiates a request to access employee attendance data, the request carries a unique tenant identifier (e.g., a1b2c3d4-e5f6-7g8h-i9j0-k1l2m3n4o5p6). After receiving the request, the API gateway, through a persistent connection established with the PostgreSQL database, accurately queries the corresponding data storage path information from the tenant configuration table based on the tenant identifier, for example, obtaining 192.168.1.101:5432 / TENANT_001. Simultaneously, it filters the tenant's basic information from the same configuration table, including tenant name, industry type, etc. The retrieved data storage path information is injected into the request parameters, the request is reconstructed, and forwarded to the employee attendance data microservice module. This module, based on the updated request parameters, connects to the specified database instance, reads and returns the attendance data of the corresponding tenant, achieving precise filtering and isolation of data access.

[0039] S103: Log the operation behavior of different tenants in isolation, and record the log file path and associated tenant identifier in the tenant configuration table to ensure that the operation logs of each tenant are independent and inaccessible.

[0040] In this embodiment of the invention, when isolating tenant operation behavior through logging, an ELK (Elasticsearch, Logstash, Kibana) log management system is used. A Logstash client is integrated into each microservice module to collect real-time logs of all operations. For example, if the administrator of tenant TENANT_001 performs an employee information modification operation, this operation is captured by the Logstash client, and a tenant identifier prefix (e.g., [TENANT_001] Administrator modifies employee Zhang San's information) is automatically added to the log content. The collected log data is forwarded to the Elasticsearch cluster via Logstash, where an independent index is created for each tenant, such as tenant_001_logs. Simultaneously, the log file path (e.g., / es / data / tenant_001_logs) and the associated tenant identifier are recorded in the log storage path field of the tenant configuration table. When a tenant needs to query the operation logs, Kibana verifies the tenant identifier and only allows access to the log data in the corresponding index, ensuring that the operation logs of each tenant are independent and preventing log information leakage and unauthorized access between different tenants.

[0041] Furthermore, the step of establishing a tenant data storage mapping table and allocating independent database storage space or data storage area for each tenant further includes: A multi-tenant database mode is adopted. Based on the tenant size and data volume, the basic information of the tenant is obtained from the tenant configuration table, and then the independent database mode, the shared database independent schema mode, or the shared database shared schema mode are selected. In this embodiment of the invention, when using a multi-tenant database mode, a data analysis platform is built based on Apache Superset to automatically extract basic tenant information from the tenant configuration table for judgment. When it is detected that a tenant has more than 5,000 employees and an average daily data write volume of more than 100,000 records, the system automatically selects the independent database mode, creates a dedicated PostgreSQL instance on AWS RDS, and allocates 16 cores, 64GB of memory, and 1TB of SSD storage. For tenants with 500-5,000 employees, a shared database independent schema mode is adopted, creating an independent schema, such as tenant_002_schema, in a single PostgreSQL instance, and completing the creation using the SQL statement CREATESCHEMA tenant_002_schema;. For micro-enterprise tenants (fewer than 500 employees and smaller data volume), a shared database shared schema mode is enabled, and data isolation is achieved by adding a tenant_id field to the public schema. Every Sunday at 2 AM, the system performs a tenant database schema evaluation task. By comparing fields such as the number of employees, average daily data write volume, and total data storage volume in the tenant configuration table, the system automatically adjusts tenants that do not meet the requirements of the current schema. For example, when a tenant grows from a micro-enterprise to a medium-sized enterprise, the system automatically migrates it from a shared schema to an independent schema to ensure that resource allocation is accurately matched with the tenant's scale.

[0042] Furthermore, a unique data storage path identifier is generated for each tenant to associate and store the tenant's corresponding business data with the data storage path identifier, and the tenant configuration table is updated accordingly. In this embodiment of the invention, when generating a unique data storage path identifier for each tenant, a 64-bit distributed ID is generated using the Snowflake algorithm. After a new tenant completes registration and determines its database mode, the system calls the ID generation service to obtain a unique identifier, such as 157896324561234567. For an independent database mode, the data storage path identifier format is {database mode}_{SnowflakeID}, for example, IND_DB_157896324561234567, and is recorded in the data storage path field of the tenant configuration table as jdbc:postgresql: / / 192.168.1.101:5432 / tenant_157896324561234567. When writing data, the MyBatis interceptor automatically injects this identifier into the SQL statement to ensure that the data is written to the correct storage path. For example, the attendance data of tenant 157896324561234567 will be written to the attendance_records table in the tenant_157896324561234567 database. In the shared schema mode, the data storage path identifier is used as the tenant_id field value of the data row. Hibernate's multi-tenant filter ensures that only the data of this tenant is returned when querying, realizing the precise association between business data and storage path identifier.

[0043] Furthermore, the tenant data storage mapping table is periodically optimized and backed up, and the backup information is recorded in the tenant configuration table to ensure the accuracy and security of data storage.

[0044] In this embodiment of the invention, when periodically optimizing and backing up the tenant data storage mapping table, an automated task is configured in the PostgreSQL database using the pg_cron plugin. Every Monday at 3 AM, table analysis and index rebuilding operations are performed. This involves updating query optimizer statistics by executing the `ANALYZE tenant_storage_mapping;` statement and performing the `REINDEX INDEX idx_tenant_id;` operation on the B-tree index of the `tenant_id` field. Every day at 1 AM, the WAL-G tool is used to physically back up the tenant data storage mapping table. The backup files are stored in a dedicated AWS S3 bucket. After each backup, the system automatically updates the most recent backup information field in the tenant configuration table with the backup time, backup file path, and backup size. Simultaneously, monitoring alerts are set in AWS CloudWatch. When a backup task fails or the backup file size is abnormal, SMS and email alerts are immediately triggered. A full recovery exercise is performed on the last Sunday of each month, restoring the most recent backup data from the S3 bucket to the test environment to verify the recoverability of the backup and ensure the accuracy and security of the tenant data storage mapping table.

[0045] Furthermore, the specific method for selecting the independent database mode, the shared database independent schema mode, or the shared database shared schema mode is as follows: The basic information of the tenant, including the amount of tenant data and the security requirements, is obtained from the tenant configuration table. When the amount of tenant data is large and the security requirements are extremely high, the independent database mode is selected to create a separate database instance for each tenant and record the instance information in the tenant configuration table. In this embodiment of the invention, after obtaining basic tenant information from the tenant configuration table, when it is detected that a tenant has more than 5,000 employees and an average daily data write volume of more than 100,000 records, and the security requirement field contains tags such as "financial-grade encryption" and "data localization", the system automatically selects the independent database mode, creates a dedicated database instance in the Azure SQL Database service through Terraform Infrastructure as Code tool, configures it to P15 performance level (300 DTU, 1 TB storage), enables transparent data encryption (TDE) during the creation process to ensure that the data is encrypted when stored, and configures Azure Private Link to enable dedicated network access. After the instance is created, write the database connection string (e.g., Server=tcp:tenant-001.database.windows.net,1433;Database=hrm_tenant_001;) and encryption key information into the data storage path and encryption key fields of the tenant configuration table. Use Azure Policy to enforce network security group rules to restrict access to a list of fixed IP addresses for the corporate headquarters and branch offices. At the same time, configure Azure Monitor to monitor the database in real time. When abnormal login attempts or large-scale data export operations are detected, immediately trigger the Azure Sentinel security response process to ensure the data isolation and security of tenants with high security requirements.

[0046] Furthermore, when the amount of tenant data is moderate and a certain degree of data sharing is required, the shared database independent schema mode is selected to allocate independent schema information for each tenant in the same database and record the schema information in the tenant configuration table. In this embodiment of the invention, when the tenant's data volume is moderate (employee size between 500-5000) and a certain degree of data sharing is required (such as industry benchmark data, general policy documents), the system selects the shared database independent schema mode. In the AWS Aurora PostgreSQL cluster, an independent schema is created for each tenant using the PostgreSQL CREATE SCHEMA statement. For example, a schema named tenant_002_schema is created for tenant TENANT_002. Cross-schema data sharing is managed using AWS Lake Formation. Common industry benchmark data tables (such as industry_salary_benchmark) are set to read-only permissions and managed through Lake Formation. Tag policies control access scope. After creation, the schema name and shared resource permission configuration are written to the data storage path field (format: jdbc:postgresql: / / cluster-endpoint:5432 / hrm_shared_db?currentSchema=tenant_002_schema) and shared resource permission field of the tenant configuration table. At the application layer, Spring Security's multi-tenant filter ensures that each tenant can only access data under its schema, while allowing read-only access to industry data in the shared schema. AWS Glue is used regularly to perform data lineage analysis to ensure that sensitive data is not leaked through shared channels, achieving a balance between data isolation and sharing.

[0047] Furthermore, when the amount of tenant data is small and the security requirements are sensitive, the shared database shared schema mode is selected, and different tenant data is distinguished by adding a tenant identifier field, and the tenant identifier field is recorded in the tenant configuration table.

[0048] In this embodiment of the invention, for tenants with small data volumes (fewer than 500 employees) and sensitive security requirements (such as containing personal privacy data), the system selects a shared database shared schema mode. A common schema is created in a PostgreSQL instance of Google Cloud SQL, and all tenant data is stored in tables of the same schema. However, a tenant_id field is added to each record for differentiation. The PostgreSQL Row-Level Security (RLS) policy is used to create access control rules for each table using the CREATE POLICY statement, for example: CREATE POLICY tenant_access ONemployees FOR ALL USING (tenant_id = current_setting('app.current_tenant')). When the application starts, the current_setting parameter is set through the HikariCP connection pool to ensure that each database session can only access its tenant's data. Tenant identification fields (such as tenant_id) are specified in the data storage path field of the tenant configuration table (format: jdbc:postgresql: / / cloudsql-instance:5432 / hrm_shared?options=-c%20app.current_tenant%3DTENANT_003). Sensitive fields (such as ID card numbers and bank card numbers) are automatically anonymized using Google Cloud Data Loss Prevention (DLP) service, replaced with masked values ​​before query results are returned. Simultaneously, Cloud Audit Logging is configured to record all database operations, especially queries involving sensitive fields, ensuring data access is traceable and meeting the compliance requirements of security-sensitive tenants.

[0049] Furthermore, when selecting a shared schema mode for a shared database, the following is also included: Establish a data access permission matrix, and set read, write, and modify permissions for different tenants on the data in the shared database based on the permission configuration in the tenant configuration table and the tenant roles and business requirements, and update the tenant configuration table. In this embodiment of the invention, Apache Shiro is used as the permission management framework when establishing the data access permission matrix. Based on the permission configuration fields and tenant role information in the tenant configuration table, a three-dimensional permission control model is constructed. For the employee_salary table in the shared database, the system sets different access levels according to tenant roles (such as administrators, department managers, and ordinary employees) and business needs (such as payroll management and attendance statistics). Administrators are granted read, write, and modify permissions; department managers only have permission to read records of employees in their department; and ordinary employees can only view their own records. This permission matrix is ​​stored in the extended permission field of the tenant configuration table in JSON format, for example: json { "employee_salary": { "admin": ["SELECT", "INSERT", "UPDATE", "DELETE"], "manager": ["SELECT WHERE department_id = ?"], "employee": ["SELECT WHERE employee_id = ?"] }, "attendance_records": { "admin": ["ALL"], "manager": ["SELECT", "UPDATE"], "employee": ["SELECT"] } } When a tenant initiates a data access request, the Shiro interceptor reads the corresponding permission matrix from the tenant configuration table based on the tenant identifier and user role in the request, and dynamically generates SQL query conditions. For example, when a department manager queries the employee_salary table, the system automatically adds the condition `department_id = ?` to the SQL statement, ensuring that only the salary data of employees in their department can be accessed. The permission matrix is ​​recalculated every Sunday morning via a scheduled task, automatically adjusting the permission configuration according to changes in tenant business needs to ensure that data access permissions are consistent with business requirements.

[0050] Furthermore, sensitive data in the shared database is encrypted using the national standard SM4 encryption algorithm, and the information of the encryption algorithm is recorded in the tenant configuration table. In this embodiment of the invention, when encrypting sensitive data in the shared database, the CBC mode of the national cryptographic algorithm SM4 is adopted, with a key length of 128 bits. At the database level, MySQL's transparent encryption plugin is used to encrypt and store sensitive fields such as employee_id_card and bank_account. The encryption key is generated and managed through KMS (Key Management Service). Each tenant is assigned an independent encryption key version. After the key is generated, the key ID, encryption algorithm (SM4-CBC), initialization vector (IV), and other information are stored in encrypted form in the encrypted information field of the tenant configuration table. When data is written to the database, the MyBatis interceptor automatically calls the SM4 encryption function to encrypt the sensitive fields before storing them in the database. For example, before an employee's ID number is written to the database, it is converted to ciphertext by calling the SM4_Encrypt(plaintext, tenant_key) function. When querying data, the interceptor automatically decrypts and returns the plaintext data. To ensure key security, KMS rotates the encryption key every quarter. During the rotation process, the system automatically re-encrypts all sensitive data in the database and updates the key information in the tenant configuration table to ensure that sensitive data is always protected by high-strength encryption.

[0051] Furthermore, the integrity of the data in the shared database is periodically verified, and the verification results are recorded in the tenant configuration table to ensure that the data has not been illegally tampered with.

[0052] In this embodiment of the invention, when periodically performing integrity checks on data in the shared database, the PostgreSQL pg_checksums extension and a custom verification script are used. Every Monday at 2:00 AM, the system automatically executes a verification task, generating hash checksums for key data tables such as employees and salary_records. The verification script first calculates the overall hash value for each table, for example, by aggregating the hash values ​​of all records using the md5(array_agg(hash_value ORDER BY primary_key)) function. Simultaneously, a separate hash value is generated for key fields of each record (such as employee_id and create_time), and stored in a dedicated verification table data_integrity_check. The verification result includes information such as table name, verification time, hash value, and number of records, and is written in JSON format to the most recent verification result field of the tenant configuration table. If a hash value mismatch is found, the system immediately triggers an alarm process, notifying the system administrator via SMS and email, and initiating a data tracing program to compare with the previous verification result to determine the time range and specific record where the data was tampered with. At the same time, database audit log analysis is enabled to track the source IPs and user accounts of suspicious operations, ensuring that data integrity issues can be detected and handled in a timely manner.

[0053] Furthermore, the adoption of a distributed system architecture breaks down the human resource management function into multiple microservice modules, and utilizes message queues to achieve event-driven decoupling between the microservice modules, specifically including: The human resource management functions are divided into several microservice modules with clearly defined functions, including core personnel, performance management, democratic evaluation, democratic recommendation, assessment, professional title review, talent map, online examination, online learning, compensation, talent inventory, and integration. Based on the permission configuration in the tenant configuration table, data access permissions for each microservice module are assigned to the corresponding tenant. In this embodiment of the invention, the human resource management function is divided into 12 independent microservice modules, each responsible for a single, clearly defined business domain. A Spring Cloud architecture is adopted, and each microservice has its own independent Git repository and Docker image. For example, the core HR microservice is responsible for managing basic employee information and is deployed in the hrm-core-personnel namespace of the Kubernetes cluster; the payroll microservice is responsible for salary calculation and disbursement and is deployed in the hrm-salary namespace. Based on the permission configuration in the tenant configuration table, fine-grained access control is implemented at the API gateway layer using Spring SecurityOAuth2. When a tenant requests access to payroll data, the gateway service reads the tenant's permission information from the configuration table (e.g., {"salary": ["read", "calculate"]}) and adds the X-Tenant-Permissions field to the request header. After receiving the request, the microservice verifies permissions through AOP aspects. For example, the payroll microservice checks whether the request header permission includes "calculate." If not, it refuses to perform the salary calculation operation. The data source configuration for each microservice is dynamically obtained from the configuration center, and the corresponding database instance or schema is connected based on the tenant identifier to ensure data access isolation.

[0054] Furthermore, message queues are deployed among the microservice modules. When a data change or business event occurs in a microservice module, the event information is encapsulated into a message and sent to the message queue. In this embodiment of the invention, a RabbitMQ message queue cluster is deployed among the various microservice modules, employing a mirrored queue mode to ensure high availability. When the core HR microservice processes employee promotion events, the event handler encapsulates the event information into a JSON-formatted message, including the event type (e.g., EMPLOYEE_STATUS_CHANGED), employee ID, change time, and other information, adding a tenant identifier as the message header. The message is sent to the hrm-events exchange via RabbitTemplate and routed to the employee.status queue based on the event type. To ensure message reliability, PublisherConfirms and Consumer Acknowledgments mechanisms are enabled. After a message is sent, it waits for Broker confirmation and is only marked as processed after successful consumption. Simultaneously, a TTL (Time To Live) of 30 minutes is set in the message queue; expired unprocessed messages are automatically placed in a dead-letter queue to avoid resource consumption. Each microservice is equipped with an independent message producer component responsible for converting business events into standardized message formats and sending them to the corresponding queue.

[0055] Furthermore, other microservice modules subscribe to relevant message topics and perform corresponding business processing based on the received messages to achieve loosely coupled communication between the microservice modules, and perform data permission verification based on the permission configuration in the tenant configuration table during the communication process.

[0056] In this embodiment of the invention, other microservice modules listen to relevant message topics through RabbitMQ's subscription mechanism. For example, the payroll microservice subscribes to the `employee.status` queue. When it receives an employee's promotion message, it triggers a salary adjustment process. The message consumer component parses the message content, extracts the tenant identifier and employee ID, and first verifies the tenant's permissions: it obtains the tenant's operation permissions for payroll data from the tenant configuration table. After confirming that the `salary-adjustment` permission is included, it calls the payroll calculation service to adjust the salary. During data processing, each microservice always carries the tenant identifier to ensure data isolation during cross-service calls. For example, after the talent map microservice receives an employee promotion message, it automatically adds the tenant identifier when updating the talent database to ensure that the data belongs only to the current tenant. To ensure the idempotency of message processing, each microservice checks the unique event ID before processing the message, and messages that have already been processed are ignored. Simultaneously, Spring Cloud Sleuth is used to add a distributed tracking ID to each message, and Zipkin is used to implement end-to-end monitoring to ensure that the flow of business events between microservices is traceable.

[0057] Furthermore, the specific deployment process for deploying message queues among the various microservice modules is as follows: Select a highly reliable message queue middleware, including RabbitMQ or Kafka, and build a message queue cluster based on the message queue middleware. Record the information corresponding to the message queue cluster in the tenant configuration table. In this embodiment of the invention, RabbitMQ is selected as the message queue middleware, and a three-node cluster is built and deployed on an AWS EC2 instance. Each node is configured as m5.xlarge (4 cores and 16GB of memory), and deployed in different availability zones to achieve high availability. A CNAME record pointing to the RabbitMQ cluster, rabbitmq.hrm.example.com, is created using AWS Route 53. Mirrored queues are configured through the RabbitMQ Management API to ensure synchronous replication of messages across all nodes. The cluster enables the Federation plugin to achieve cross-region message transmission, and interconnection between the clusters in Europe, Asia, and North America is configured. Furthermore, the corresponding cluster connection information (e.g., amqp: / / rabbitmq.hrm.example.com:5672) and mirroring policy (e.g., all) are written into the message queue configuration field of the tenant configuration table. The RabbitMQ administrator account password is stored in AWS Secrets Manager, and microservices are authorized to access these credentials through IAM roles to ensure the security of connection information.

[0058] Furthermore, an independent message channel is allocated to each microservice module to prevent message conflicts, and the message channel is recorded in the tenant configuration table; In this embodiment of the invention, an independent message channel is allocated to each microservice module, using a naming convention of "tenant ID-microservice name". For example, the core personnel microservice creates a TENANT_001-core-personnel exchange and queue for tenant TENANT_001. The message spaces of different tenants are isolated using RabbitMQ's vhost functionality. Each tenant has its own dedicated vhost, such as vhost_tenant_001. Within each vhost, an independent exchange and queue are created for each microservice, and message routing is implemented through binding keys. For example, the talent mapping microservice subscribes to the TENANT_001-employee-events queue, with binding keys set to employee.promotion and employee.transfer. The message channel configuration for each tenant (including vhost name, exchange type, and queue name) is recorded in JSON format in the message channel configuration field of the tenant configuration table. Through RabbitMQ's permission management system, read and write permissions are assigned to each tenant's microservice account for its dedicated vhost, ensuring message isolation.

[0059] Furthermore, a message persistence strategy is set for the message queue to ensure that messages are not lost in the event of a system failure, and the message persistence strategy is recorded in the tenant configuration table; In this embodiment of the invention, by setting the message persistence strategy of RabbitMQ, all exchanges and queues are declared as persistent. When creating an exchange, durable=true is specified, and when creating a queue, durable=true and autoDelete=false are set. When publishing a message, deliveryMode is set to 2 (persistent) to ensure that the message is written to disk. For important business events (such as salary payment or employee resignation), the publisher confirms mechanism is used to confirm that the message has been persistently stored. In the RabbitMQ configuration file, disk_free_limit is set to 50% of the available disk space. When the disk space is lower than the threshold, the reception of new messages is paused to prevent message loss due to disk fullness. The persistence strategy (such as persistent) and disk space threshold configuration are recorded in the message persistence configuration field of the tenant configuration table. The queue persistence status is checked periodically using the RabbitMQ Management API to ensure that all critical queues and messages have been correctly configured for persistence.

[0060] Furthermore, the message queue is monitored for performance, and when the message backlog exceeds a threshold, a message processing expansion mechanism is automatically triggered.

[0061] In this embodiment of the invention, RabbitMQ performance is monitored by building a monitoring system using Prometheus and Grafana. RabbitMQ-exporter is deployed to collect metrics such as queue length, message rate, and number of consumers, with data collected every 15 seconds. A monitoring dashboard is created in Grafana, containing charts such as the real-time status of each tenant's message queue, message backlog trends, and consumer processing rates. Alarm rules are set: when the message backlog in a single queue exceeds 1000 messages or the message processing delay exceeds 5 seconds, an alarm is triggered via Alertmanager. Alarm methods include SMS, email, and WeChat notifications. When message backlog exceeds a threshold, the Kubernetes Horizontal Pod Autoscaler (HPA) mechanism is automatically triggered to increase the number of Pod replicas for the corresponding microservice. For example, the HPA configuration for the payroll calculation microservice is to automatically expand the number of Pod replicas from 3 to 10 when the message queue length exceeds 800. The scaling operation is completed within 2 minutes, ensuring that message backlog is handled in a timely manner. The monitoring metric thresholds and scaling strategies are recorded in the message queue monitoring field of the tenant configuration table to achieve tenant-level fine-grained monitoring and automatic scaling.

[0062] Furthermore, the message persistence strategy is specifically as follows: Set the persistence level of important business messages in the message queue to disk persistence to ensure that the important business messages can still be recovered after the server restarts; In this embodiment of the invention, RabbitMQ is used as the message queue middleware for important business messages within the message queue. A disk persistence strategy is enforced when creating the queue and publishing messages. When creating a queue, the queue attribute is set to persistent (durable=true) through the RabbitMQ management interface or configuration file to ensure the queue persists after a server restart. When publishing a message, the message's deliveryMode attribute is set to 2, which ensures the message is written to disk immediately after being received by the Broker. For example, for important business messages involving financial and legal risks, such as payroll payments and employee contract signings, the deliveryMode parameter is explicitly specified as 2 through the message producer component when sending messages from the microservice module. Simultaneously, RabbitMQ's Publisher Confirms mechanism is enabled. After sending a message, the message producer waits for a confirmation signal from the Broker. Only after receiving confirmation is the message considered successfully persisted to disk; otherwise, a message resend process is triggered, ensuring that important business messages can be fully recovered after a server restart.

[0063] Furthermore, non-critical business messages in the message queue are persisted in memory to improve message processing efficiency. In this embodiment of the invention, for non-critical business messages in the message queue, such as employee attendance record synchronization and training course browsing record updates—messages with high timeliness requirements but minimal impact from data loss—a memory persistence approach is adopted. In RabbitMQ, a non-persistent queue (durable=false) and a non-persistent exchange are created, and the message's deliveryMode attribute is set to 1, ensuring the message is stored only in memory. When a microservice module sends such messages, a lightweight message producer component quickly pushes the message into the queue, reducing performance overhead from disk I / O operations. Simultaneously, leveraging RabbitMQ's lazy queue feature, when queue memory usage reaches a certain threshold, some messages are automatically transferred to disk, preventing memory overflow due to a large number of non-critical messages. This balances memory and disk resource usage while ensuring message processing efficiency.

[0064] Furthermore, important business messages persisted on the disk are periodically archived and cleaned up to free up disk space, and the archiving and cleanup information is recorded in the tenant configuration table. In this embodiment of the invention, a custom shell script is used in conjunction with Linux's Cron service to archive and clean up important business messages persisted on disk every Sunday at 2:00 AM. The shell script calls RabbitMQ's management API to query processed message records older than 30 days (based on the message's timestamp field), exports these messages as JSON files, and stores them in a specified directory of an AWS S3 object storage bucket. The directory structure is divided by tenant ID and date, such as / archive / TENANT_001 / 2024-12-01. After exporting, the script executes RabbitMQ's delete command to remove the archived messages from the queue, freeing up disk space. After the operation is completed, information such as the storage path of the archived files, the number of deleted messages, and the operation time are recorded in JSON format in the message archive record field of the tenant configuration table for easy auditing and querying. Simultaneously, lifecycle rules are set in AWS S3 to automatically perform cold storage or deletion on archived files older than 180 days, further optimizing storage costs.

[0065] Furthermore, a message persistence status monitoring mechanism is established, which automatically retryes or issues an alarm when message persistence failure is detected.

[0066] In this embodiment of the invention, a message persistence status monitoring mechanism is built based on Prometheus and Grafana. This mechanism collects persistence status metrics of message queues, such as the number of message persistence failures and the number of unacknowledged persistent messages, by deploying RabbitMQ Exporter. The collection frequency is once every 10 seconds. A dedicated monitoring panel is created in Grafana to display the persistence status of each tenant's message queue in real time. Simultaneously, a threshold is set using Prometheus's alarm rule engine: when the number of persistence failures in a tenant's message queue exceeds 5 within 5 minutes, an alarm is triggered, and the alarm information is sent to the system administrator through multiple channels, including WeChat Work bots and email. Furthermore, retry logic is embedded in the message producer code. When a message persistence failure is detected, three retries are automatically performed, with a 2-second interval between each retry. If a retry fails, the message is stored in a dead-letter queue, and a detailed error log is recorded, facilitating administrator troubleshooting and ensuring the reliability of message persistence.

[0067] Furthermore, the message persistence state monitoring mechanism specifically includes: A persistent status flag field is set in the message queue to record the persistent status of each message in real time; In this embodiment of the invention, a persistent status flag field is set in the RabbitMQ message queue, implemented using a message attribute extension mechanism. A custom header attribute `x-persistence-status` is added to each message, with values ​​ranging from PENDING (pending persistence), SUCCESS (successful persistence), to FAILED (failed persistence). When a message producer sends an important business message, the initial status is set to PENDING. After the message is written to disk, the RabbitMQ storage plugin automatically updates the status to SUCCESS. If the write fails, the storage plugin sets the status to FAILED and records the error code. For example, a payroll payment message is marked as PENDING when sent, and changes to SUCCESS after a successful disk write. Through RabbitMQ's policy mechanism, all messages in important business queues are required to include this status field; otherwise, they are rejected from queuing. The status field value is stored in the message metadata and does not affect the message body content, ensuring compatibility with existing systems.

[0068] Furthermore, the message queue is scanned by a scheduled task to check the message persistence status. When an abnormal message is found, it is transferred to the abnormal message queue. In this embodiment of the invention, a scheduled task scans the message queue to check the persistence status. This is implemented using RabbitMQ's Management API in conjunction with Spring Scheduler. The scan task is executed at 1:00 AM every day, traversing all important business queues. For each message, the x-persistence-status field value is checked: if it is FAILED, the message is immediately transferred to a separate queue named Abnormal Messages - Persistence Failure; if it is PENDING and the time exceeds 5 minutes (normal persistence should be completed within 1 second), it is marked as timeout and transferred to the Abnormal Messages - Persistence Timeout queue. The transfer operation is implemented through the RabbitMQ Shovel plugin, configuring the source queue, target queue, and filtering conditions. For example, messages in the FAILED state are transferred from the salary-events queue to the Abnormal Messages - Persistence Failure queue. After each scan, a detailed report is generated, recording the total number of messages processed, the number of abnormal messages, and the processing results, and stored in the message_scan_logs collection in MongoDB.

[0069] Furthermore, the messages in the abnormal message queue are analyzed and processed. If the error is recoverable, a retry operation is automatically performed; if the error is unrecoverable, a detailed error log is generated and an alarm is sent to the operation and maintenance personnel.

[0070] In this embodiment of the invention, messages in the abnormal message queue are analyzed and processed using a combination of rule engine and manual intervention. For messages in the abnormal message - persistence failure queue, the error code is first checked: if it is DISK_FULL (disk full), a disk cleanup process is automatically triggered and retrying after 10 minutes; if it is FILE_CORRUPTED (file corrupted), data is restored from the most recent backup and retrying is performed. The number of retries is limited to 3, with the interval between each retrieval increasing exponentially (10 seconds, 1 minute, 5 minutes). The retry logic is implemented using Spring Retry, and a fallback mechanism is used to handle messages that ultimately fail. For unrecoverable errors (such as incorrect message format), a detailed log containing the message ID, timestamp, and error details is generated, stored in Elasticsearch, and visualized using Kibana. Simultaneously, an alert is sent to operations personnel via a WeChat Work robot, including the number of abnormal messages, error type, and handling suggestions. Operations personnel can manually handle these messages through the management interface, such as correcting the format and resending. All processing results are recorded in the message abnormality handling field of the tenant configuration table to ensure traceability.

[0071] Furthermore, the system upgrade and vulnerability patching operations for all tenants specifically include: Establish an upgrade task management module in the cloud platform to formulate system upgrade and vulnerability remediation plans; In this embodiment of the invention, an upgrade task management module is established in the AWS cloud platform. AWS StepFunctions is used to build workflow orchestration and create a system upgrade workflow state machine, including steps such as compatibility testing, canary releases, and full upgrades. Upgrade plans are stored using AWS DynamoDB, and an `upgrade_plans` table is defined, containing fields such as plan ID, upgrade type (system upgrade / vulnerability patching), target version, plan execution time, and associated tenant group. Every Monday, a plan generation task is triggered via AWS EventBridge to scan the software versions and security vulnerability status of all tenants and automatically generate upgrade plans. For example, when a Spring Security vulnerability is detected, a vulnerability patching plan is generated for all tenants using that component. After plan generation, a notification email is sent to the tenant administrator via SES, and a list of pending upgrade plans is displayed in the management console. Each plan is associated with a unique ARN (Amazon Resource Name) for subsequent tracking and execution.

[0072] Furthermore, compatibility testing is conducted on each tenant before the upgrade, and a compatibility testing report is generated. In this embodiment of the invention, compatibility testing is performed on each tenant before the upgrade. A testing environment is built using Docker, and an independent testing container is created for each tenant, mounting a read-only copy of its production data. A compatibility testing script is executed via AWS CodeBuild, containing test cases for database structure verification, API interface compatibility testing, and business process simulation. For example, it checks whether the new system supports tenant-defined approval processes and verifies whether data field lengths match. The test results are output in JSON format, including the number of passed tests, details of failed tests, and remediation suggestions. A visual report is generated using AWS QuickSight, displaying the compatibility score and risk level of each tenant. The report is stored in an S3 bucket, and the report position is recorded in the "Most Recently Tested Report" field of the tenant configuration table. If a serious compatibility issue is detected (such as a data model mismatch), the tenant is automatically removed from the current upgrade batch and marked as requiring manual handling.

[0073] Furthermore, a canary release approach was adopted to conduct upgrade pilot tests on a select group of tenants, collect feedback, and verify the upgrade's effectiveness. In this embodiment of the invention, a canary release approach is adopted, dividing tenants into multiple groups based on dimensions such as industry, size, and technological maturity. The pilot group consists of medium-sized enterprises in the financial industry, comprising approximately 10% of the total tenants. The upgraded system version is deployed to a dedicated environment using AWS CloudFormation templates. A weighted DNS policy using Route 53 is used to redirect the pilot tenants' traffic to the new environment. During the pilot period, comprehensive monitoring is enabled: system performance metrics (such as response time and throughput) are collected via AWS CloudWatch, business processes are traced using AWS X-Ray, and Prometheus is deployed to monitor microservice status. Simultaneously, a feedback collection form is added to the management console, allowing pilot tenants to submit their experiences and issues. A daily pilot report is generated, comparing system performance and business metrics before and after the upgrade. If serious issues are found (such as an interface response timeout rate exceeding 5%), an immediate rollback to the old version is performed via AWS Auto Scaling, and the issue is recorded in the upgrade task management module.

[0074] Furthermore, once the pilot test is successful, automated scripts will be used to perform system upgrades and vulnerability patching operations on all tenants in batches, and the upgrade progress and system status will be monitored in real time during the operation.

[0075] In this embodiment of the invention, after a successful pilot test, a batch upgrade is performed using AWS Systems Manager automated scripts. A Run Command document is created, containing steps such as stopping services, backing up data, updating code, and restarting services. Using AWS Organizations' Organizational Unit (OU) structure, tenants are grouped by region and industry, and the upgrade is executed in batches. For example, tenants in the Asia-Pacific region are upgraded first, followed by those in Europe and America. Each upgrade involves 100 tenants, with a 30-minute interval to avoid resource contention. Upgrade progress is monitored using CloudWatch Events. When a tenant's upgrade fails, an AWS Lambda function is automatically triggered to perform a rollback operation, and the failure information is sent to the operations team's Slack channel. During the upgrade process, AWS GuardDuty is used to monitor system security status in real time. If abnormal activity (such as unauthorized access attempts) is detected, the upgrade is immediately paused and a security response process is initiated. All upgrade operations are recorded in AWS CloudTrail to ensure auditability. After the upgrade is complete, the system version and most recent upgrade time fields in the tenant configuration table are updated, and an upgrade completion notification email is sent via SES.

[0076] Therefore, the embodiments should be considered as exemplary and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of the equivalents of the application are intended to be included within the invention.

[0077] 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 present 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. A distributed SaaS-based human resource management method, characterized by: Includes the following steps: Construct a multi-tenant isolation architecture and separate the data and behavior of different tenants through the multi-tenant isolation architecture, so as to generate an independent tenant identifier for each tenant and establish a tenant configuration table containing basic tenant information, data storage path and permission configuration; Based on the tenant identifier and the tenant configuration table, each tenant is provided with a custom interface and business rule configuration function. This allows tenants to personalize the business module processes and display styles, including core personnel, performance management, democratic evaluation, democratic recommendation, assessment, professional title review, talent map, online examination, online learning, salary, talent inventory, and integration of corresponding human resource management functions, without modifying the underlying code. At the same time, the business module processes and display styles are associated with the tenant identifier for storage. A distributed system architecture is adopted, and the human resource management function is divided into multiple microservice modules. Data access permissions for each microservice module are assigned to the corresponding tenant according to the data storage path in the tenant configuration table, and event-driven decoupling between the microservice modules is achieved by using a message queue. The system monitors the resource usage of each tenant based on the custom interface in real time and dynamically allocates system resources according to the resource usage. When a business peak period, including the year-end performance assessment, is detected, the corresponding microservice nodes are automatically expanded to achieve elastic allocation of computing power and bandwidth. The system reads basic tenant information from the tenant configuration table through the cloud platform, performs system upgrades and vulnerability patching operations on all tenants, and uses open API interfaces to achieve data interaction with external systems. During the interaction process, data permission verification and management are performed according to the permission configuration in the tenant configuration table.

2. The distributed SaaS-based human resource management method according to claim 1, characterized in that: The construction of a multi-tenant isolation architecture, and the separation of data and behavior of different tenants through the multi-tenant isolation architecture, specifically includes: Based on the multi-tenant isolation architecture, a tenant data storage mapping table is established, an independent database storage space or data storage area is allocated to each tenant, and the information corresponding to the database storage space or data storage area is recorded in the tenant configuration table. Tenant filtering rules are set in the data access layer. When a data access request is received, the data storage path information of the corresponding tenant is filtered from the tenant configuration table according to the tenant identifier in the data access request, and then the basic tenant information of the corresponding tenant is filtered. Logs of different tenants' operations are isolated, and the log file path and associated tenant identifier are recorded in the tenant configuration table to ensure that each tenant's operation logs are independent and inaccessible.

3. The distributed SaaS-based human resource management method according to claim 2, characterized in that: The establishment of a tenant data storage mapping table, and the allocation of independent database storage space or data storage area to each tenant, further includes: A multi-tenant database mode is adopted. Based on the tenant size and data volume, the basic information of the tenant is obtained from the tenant configuration table, and then the independent database mode, the shared database independent schema mode, or the shared database shared schema mode are selected. A unique data storage path identifier is generated for each tenant to associate and store the business data corresponding to the tenant with the data storage path identifier, and the tenant configuration table is updated accordingly. The tenant data storage mapping table is regularly optimized and backed up, and the backup information is recorded in the tenant configuration table to ensure the accuracy and security of data storage.

4. The distributed SaaS-based human resource management method according to claim 3, characterized in that: The specific selection method for choosing between independent database mode, shared database independent schema mode, or shared database shared schema mode is as follows: The basic information of the tenant, including the amount of tenant data and the security requirements, is obtained from the tenant configuration table. When the amount of tenant data is large and the security requirements are extremely high, the independent database mode is selected to create a separate database instance for each tenant and record the instance information in the tenant configuration table. When the amount of tenant data is moderate and a certain degree of data sharing is required, the shared database independent schema mode is selected to allocate independent schema information for each tenant in the same database and record the schema information in the tenant configuration table. When the amount of tenant data is small and the security requirements are sensitive, the shared database shared schema mode is selected, and different tenant data is distinguished by adding a tenant identifier field, and the tenant identifier field is recorded in the tenant configuration table.

5. The distributed SaaS-based human resource management method according to claim 4, characterized in that: The process of selecting a shared schema for a shared database also includes: Establish a data access permission matrix, and set read, write, and modify permissions for different tenants on the data in the shared database based on the permission configuration in the tenant configuration table and the tenant roles and business requirements, and update the tenant configuration table. Sensitive data in the shared database is encrypted using the national standard SM4 algorithm, and the information of the encryption algorithm is recorded in the tenant configuration table. The integrity of the data in the shared database is periodically verified, and the verification results are recorded in the tenant configuration table to ensure that the data has not been illegally tampered with.

6. The distributed SaaS-based human resource management method according to claim 1, characterized in that: The system adopts a distributed system architecture, which breaks down the human resource management function into multiple microservice modules and uses message queues to achieve event-driven decoupling between the microservice modules. Specifically, this includes: The human resource management functions are divided into several microservice modules with clearly defined functions, including core personnel, performance management, democratic evaluation, democratic recommendation, assessment, professional title review, talent map, online examination, online learning, compensation, talent inventory, and integration. Based on the permission configuration in the tenant configuration table, data access permissions for each microservice module are assigned to the corresponding tenant. Deploy message queues among the microservice modules. When a data change or business event occurs in a microservice module, the event information is encapsulated into a message and sent to the message queue. Other microservice modules subscribe to relevant message topics and perform corresponding business processing based on the received messages to achieve loosely coupled communication between microservice modules. During the communication process, data permission verification is performed based on the permission configuration in the tenant configuration table.

7. The distributed SaaS-based human resource management method according to claim 6, characterized in that: The specific deployment process for deploying message queues among various microservice modules is as follows: Select a highly reliable message queue middleware, including RabbitMQ or Kafka, and build a message queue cluster based on the message queue middleware. Record the information corresponding to the message queue cluster in the tenant configuration table. Each microservice module is assigned an independent message channel to prevent message conflicts, and the message channel is recorded in the tenant configuration table; Configure the message persistence policy of the message queue to ensure that messages are not lost in the event of system failure, and record the message persistence policy in the tenant configuration table; The message queue is monitored for performance. When the message backlog exceeds the threshold, the message processing expansion mechanism is automatically triggered.

8. The distributed SaaS-based human resource management method according to claim 7, characterized in that: The message persistence strategy is as follows: Set the persistence level of important business messages in the message queue to disk persistence to ensure that the important business messages can still be recovered after the server restarts; Non-critical business messages in the message queue are persisted in memory to improve message processing efficiency; Periodically archive and clean up important business messages persisted on the disk to free up disk space, and record the archive and cleanup information in the tenant configuration table; Establish a message persistence status monitoring mechanism to automatically retry or issue an alarm when message persistence failure is detected.

9. The distributed SaaS-based human resource management method according to claim 8, characterized in that: The message persistence state monitoring mechanism specifically includes: A persistent status flag field is set in the message queue to record the persistent status of each message in real time; The message queue is scanned by a scheduled task to check the message persistence status. When an abnormal message is found, it is transferred to the abnormal message queue. The messages in the abnormal message queue are analyzed and processed. If the error is recoverable, a retry operation is performed automatically. If the error is unrecoverable, a detailed error log is generated and an alarm is sent to the operation and maintenance personnel.

10. The distributed SaaS-based human resource management method according to claim 1, characterized in that: The system upgrade and vulnerability patching operations for all tenants specifically include: Establish an upgrade task management module in the cloud platform to formulate system upgrade and vulnerability remediation plans; Before the upgrade, perform compatibility testing on each tenant and generate a compatibility testing report; A canary rollout approach was adopted to first conduct a pilot upgrade for a select group of tenants, collect feedback, and verify the upgrade's effectiveness. Once the pilot test is successful, automated scripts will be used to perform system upgrades and vulnerability patching operations on all tenants in batches, and the upgrade progress and system status will be monitored in real time during the operation.

Images