Distributed SaaS software service architecture oriented to separation of front end and rear end

Abstract

The invention discloses a distributed SaaS software service architecture oriented to front and rear end separation. Aiming at the problems of traditional SaaS customization limitation and customized development software, the method combines SaaS and customized development, and is constructed based on a front-end and back-end separation technology. Module splitting and combination are achieved through a micro-service architecture, multiple service modes and authorization mechanisms are designed, dynamic configuration updating is supported, and different service requirements are met. The system flexibility and customization can be improved, the cost is reduced, the method is suitable for enterprise informatization construction, and an efficient, safe and extensible software service solution is provided.

Description

Technical Field

[0001] The present invention relates to the technical field of computer software, and specifically to a distributed software service architecture for front-end and back-end separation, which combines the SaaS service model and customized development. Background Art

[0002] With the increasing demand for enterprise informatization, the SaaS (Software-as-a-Service) model has been widely used due to its advantages such as pay-per-use, rapid deployment, and easy maintenance. However, traditional SaaS services have limitations in customization and are difficult to meet the specific needs of enterprises. On the contrary, although customized software development can meet personalized needs, it has high costs, a long cycle, and complex later maintenance. With the development of Web technology, front-end and back-end separation has become a mainstream software service architecture, which enables the front end to focus on user interfaces and interactions, and the back end to focus on business logic and data management, improving development efficiency and system maintainability. Therefore, there is an urgent need for a software service architecture for front-end and back-end separation that can provide the convenience of SaaS services and support customized requirements. Summary of the Invention

[0003] Figure 1 The traditional centralized SaaS model and the distributed SaaS model are compared. In the centralized SaaS model, all services and data are uniformly managed by the service provider and deployed in the service provider's data center or cloud platform. In this model, the service provider is responsible for resource planning, allocation, monitoring, and maintenance. Users do not need to care about the specific situation of the underlying resources and only need to access the services through the network. The advantage of centralized SaaS is that it simplifies the user's operation and maintenance work, reduces costs, and facilitates the service provider's unified security management and data backup.

[0004] However, with the expansion of business scale and the diversification of user needs, some limitations of centralized SaaS have gradually emerged. For example, a single point of failure may cause service interruption, centralized data storage may increase security risks, and resource scalability is limited. To solve these problems, the present invention proposes a distributed SaaS service model, in which service components and data are dispersed and deployed in the enterprise's own server resources to form a distributed system. The advantages of the distributed SaaS service model are as follows: ① Distributed SaaS improves the system's availability, fault tolerance, and reduces access latency through redundancy and load balancing; ② By deploying services in private resources, enterprises can implement more stringent data access control and encryption measures to ensure data integrity and availability; ③ Enterprises can choose suitable infrastructure such as hardware, operating systems, databases, and middleware, as well as customized business logic according to their own business needs and technical architectures, so as to build SaaS applications that better meet their own needs.

[0005] It should be noted that although distributed SaaS provides higher flexibility and scalability, it also brings more complex management and operation and maintenance challenges. It is necessary to build distributed management of SaaS on the service provider's resources. Therefore, the content involved in the present invention includes:

[0006] ① Distributed SaaS architecture design: Adopt a microservices architecture, split multi-tenant applications into independent service modules to achieve loose coupling and high scalability; propose three types of module mechanisms: common, replacement, and customization, and flexibly combine and configure according to enterprise needs to reduce costs and increase efficiency; design a collaborative workflow for SaaS proxy and SaaS management to achieve distributed SaaS management.

[0007] ② Distributed SaaS services: Design three modes of local services, proxy services, and penetration services, which are respectively oriented to services that do not require SaaS control, SaaS proxy control, and SaaS direct control, and provide different levels of solutions in terms of performance requirements, functional complexity, and security.

[0008] ③ Distributed SaaS development: Adopt front-end container development technology to achieve micro-application registration, routing management, life cycle hooks, and state management, and support dynamic loading and integration. The backend uses reverse proxy technology to handle requests for different types of backend services, achieving transparency of the backend to the front-end.

[0009] ④ Distributed authorization based on role-based access control: Design three authorization modes: SaaS management authorization, local role-based access control authorization, and customization authorization, which are respectively oriented to multi-tenant application super administrators, tenant internal roles, and customization requirement scenarios.

[0010] ⑤ Dynamic configuration and update: Design a building block combination method to achieve module-level dynamic configuration, integrate with third-party platforms through backend API interface calls, adopt guided compilation to achieve cross-platform compatibility and multi-front-end support, and support continuous research on requirements to optimize vertical scenario configuration. Description of the Drawings

[0011] Figure 1 is distributed SaaS compared with centralized SaaS

[0012] Figure 2 is a multi-tenant application

[0013] Figure 3 is a distributed SaaS architecture

[0014] Figure 4 is a distributed SaaS service

[0015] Figure 5 is front-end container development

[0016] Figure 6 It is for the development of backend reverse proxy

[0017] Figure 7 It is a distributed authorization based on role-based access control

[0018] Figure 8 It is SaaS authorization JWT

[0019] Figure 9 It is SaaS role authorization JWT

[0020] Figure 10 It is customized authorization JWT

[0021] Figure 11 It is distributed SaaS dynamic configuration

[0022] Figure 12 It is distributed SaaS backend update

[0023] Figure 13 It is distributed SaaS frontend update Specific implementation manner

[0024] 1. Construction of multi-tenant application

[0025] A multi-tenant application refers to a software instance that can provide services for multiple tenants (i.e., enterprises or individual users) simultaneously under the SaaS service model, and the data and configurations of each tenant are isolated from each other.

[0026] 1.1 Multi-tenant application technology

[0027] ① Front-end and back-end separation technology: Front-end and back-end separation is a technical architecture that decouples the user interface logic from the business logic. By defining clear interfaces and standardized data exchange formats, it enables independent development, deployment, and communication between the front-end and the back-end.

[0028] ② Microservices technology: The microservices architecture splits a large application into a series of small, autonomous service units. Each service runs, deploys, and scales independently, and collaborates with each other through lightweight communication mechanisms to achieve system modularity, high availability, and elastic scalability, reducing system complexity and improving development efficiency.

[0029] 1.2 Composition of multi-tenant application

[0030] Figure 2 Describes the composition of a multi-tenant application based on front-end and back-end separation and microservices technology

[0031] ① Front-end application: The front-end application is the entry point for user interaction. It is responsible for receiving and processing user input requests and returning the results to the front-end for data display.

[0032] ② Back-end services: Back-end services are the core of a multi-tenant system, responsible for processing business logic and data storage. The back-end consumption microservices and back-end production microservices adopt a microservices architecture to represent different roles and functions of the back-end services. The back-end consumption microservices are responsible for processing requests from the front end, calling the production microservices to complete business functions and returning them to the front-end application; the back-end production microservices are responsible for generating and storing data, providing data interfaces for the consumption microservices to call.

[0033] 2. Distributed SaaS Architecture

[0034] Figure 3 Describes the distributed SaaS system architecture proposed by the present invention.

[0035] 2.1 Composition of Distributed SaaS

[0036] The multi-tenant application is split into multiple independent service modules. This modular design enables each module to be developed, deployed, and extended independently. The modules interact through a lightweight communication protocol (such as RESTful API), achieving loose coupling and minimizing the dependency relationship between modules. The sharing and reuse between modules are an important feature of this architecture. By sharing common modules to meet general requirements, it reduces the development cost and maintenance difficulty of enterprises and improves development efficiency. The introduction of replacement modules and customized modules meets specific business needs, enabling enterprises to quickly adjust and optimize their businesses without changing the entire system architecture. The differences between these three types of modules are as follows:

[0037] ① Common modules: Common modules provide general business functions and data management capabilities; these modules are usually designed to be highly configurable and extensible, including basic service modules such as user management, permission management, and log management.

[0038] ② Replacement modules: Replacement modules can replace certain parts of the common modules to achieve functions that better meet the needs of enterprises; replacement modules may exist in the form of plugins or extended services, and they interact with the common modules through interfaces.

[0039] ③ Customized modules: Customized modules usually need to be customized according to the specific business needs of enterprises; customized modules can be integrated and interact with other modules and exist in the form of independent service modules.

[0040] 2.2 Distributed SaaS Services

[0041] Design a distributed management mechanism that collaborates between SaaS management and SaaS agents.

[0042] 1) Working mechanism of SaaS agent

[0043] ① Request filtering and authentication: The SaaS proxy acts as a bridge between SaaS management and backend services, checking whether requests come from legitimate users or devices. Only users authenticated by the distributed SaaS can access the backend services.

[0044] ② Session management and state maintenance: The SaaS proxy is responsible for managing and maintaining the session state, ensuring that users maintain a consistent session state when making cross-service requests; distributed caching or session storage mechanisms can be used to store and retrieve session state information.

[0045] ③ Performance monitoring and troubleshooting: The SaaS proxy can also monitor the performance of backend services, including metrics such as response time, throughput, and error rate, to help developers quickly locate and resolve faults.

[0046] 2) Working mechanism of SaaS management

[0047] ① Service configuration and management: SaaS management is responsible for managing and configuring backend services, including starting, stopping, updating, and upgrading services.

[0048] ② Resource allocation and scheduling: SaaS management can dynamically adjust the allocation of computing resources, storage resources, and networks to ensure the performance and scalability of services.

[0049] ③ Security and compliance management: SaaS management needs to ensure that all backend services comply with relevant security standards and regulatory requirements; this involves the implementation and monitoring of measures such as data encryption, access control, and security auditing.

[0050] ④ Multi-tenant support: SaaS management needs to support a multi-tenant architecture, ensuring data isolation and configuration independence between different tenants; this involves using technical means such as database isolation, application layer isolation, or storage isolation to achieve this.

[0051] 3) Distributed SaaS services

[0052] Figure 4 Describes three distributed SaaS service models based on this management mechanism.

[0053] ① Local service: In this mode, the front-end application directly sends requests

[411] to the backend service and receives responses

[412] , which is suitable for SaaS application scenarios with high performance requirements and relatively simple functions and does not require control by SaaS management.

[0054] ② Proxy service: This mode introduces a SaaS proxy between the front-end application and the backend service

[421]

[424] to filter and authenticate requests to the front-end container

[422]

[423] . The SaaS proxy and SaaS management achieve the control of service providers over tenants through asynchronous communication

[425] .

[0055] ③ Penetration service: When the front-end application sends a request to the back-end service

[431] , it will directly penetrate to the SaaS management

[432] , and the response will be returned to the front-end application

[434] through the SaaS proxy

[433] , which is used for the scenario where the back-end service is directly controlled by the SaaS management.

[0056] 3. Distributed SaaS Development

[0057] 3.1 Front-end Application Development

[0058] 1) Technical Foundation

[0059] The front-end container technology is adopted to dynamically load, manage, and coordinate the operation of each micro front-end application. Its core functions are: ① Micro-application registration and routing management. Each micro-application is registered in the main application, and its loading method and activation conditions are specified; the corresponding micro-application is dynamically loaded and activated according to the routing management. ② Lifecycle hooks and state management, which are used to manage the startup, mounting, and unloading processes of micro-applications. ③ Dynamic loading and module federation, which realizes the independent construction and deployment of micro-applications.

[0060] 2) Specific Implementation Steps

[0061] Figure 5 The front-end container development technology is shown.

[0062] ① Main application / container setup: Introduce the container framework in the main application, define the routing table and the global state manager, and dynamically load and manage multiple micro front-end applications [511 / 512 / 513 / 514].

[0063] ② Micro-application development and testing: According to the business requirements, split the front-end application into multiple independent micro-applications and develop them using different front-end technology stacks. Each micro-application implements the lifecycle hook functions of the container and exposes them for the main application to call.

[0064] ③ Micro-application communication: The micro front-end applications perform routing management and communication through the main application to ensure data sharing and synchronization [521 / 522 / 523].

[0065] ④ Micro-application isolation: Adopt technical means such as JS isolation and CSS style isolation to ensure the independence between micro front-end applications [531 / 532].

[0066] ⑤ Dynamic configuration and update: Implement a dynamic loading and update mechanism for service module configuration, and new configurations can be applied without restarting the service. Adopt a version control strategy to ensure the stability and traceability of configuration updates.

[0067] 3.2 Back-end Reverse Proxy Development

[0068] To implement three different service modes of local, proxy, and penetration for distributed SaaS, a backend reverse proxy development technology is designed as a bridge between the front-end and the back-end. According to the content and context of the request, the request is forwarded to the correct backend service, so that the front-end does not need to be aware of the different service modes and technical details of the back-end.

[0069] Figure 6 The following shows its specific implementation method:

[0070] ① Request reception and parsing

[0071] The backend reverse proxy first receives HTTP requests from the front-end. These requests may contain information such as URL paths, query parameters, request headers, etc. The reverse proxy needs to parse these request information to determine the target backend service [601 / 602 / 603] of the request.

[0072] ② Routing rule matching

[0073] According to the business logic and predefined routing rules, the reverse proxy matches the request with the corresponding backend service. If it is the local or proxy service mode, the request is further forwarded to the backend general service module

[604] , backend replacement service module

[605] , and backend customization service module

[606] that provide business functions and data management according to the project nature and business requirements respectively; if it is the penetration service mode, the request is forwarded to the SaaS management service

[607] .

[0074] 4. Distributed authorization based on role-based access control

[0075] 4.1 SaaS management authorization

[0076] This mode is used for the authorization mode controlled by SaaS management, facing the super administrator of multi-tenant applications. When the SaaS multi-tenant administrator initiates an access request, the user identity identification information is first submitted to the SaaS authorization agent

[711] . This agent receives and conducts a preliminary verification on the legitimacy of the request source and the tenant relevance. After confirmation, it is forwarded to the SaaS authorization

[712] . The SaaS authorization matches the user identity identification information based on the SaaS management database [713 / 714]. If successful, a JWT token carrying the tenant identifier and complete permission information is generated ( Figure 8), and is returned to the front - end by the SaaS authorized agent

[715]

[716] . Thereafter, the front - end accesses the back - end service with this token

[717] . The back - end service uses the token parsing suite and security verification mechanism to verify the validity of the token, the scope of permissions, and the tenant attribution. After passing the verification, it matches the corresponding business function modules and SaaS tenant database access permissions according to the tenant identifier

[718] , ensuring that the data access of each tenant is limited within its exclusive data space to achieve isolation.

[0077] 4.2 Local Authorization Based on Role - Based Access Control

[0078] In the local authorization based on role - based access control, it is for access control of various roles within the tenant. When the front - end application executes various business operations by the user, while encapsulating the user identity identifier (such as user name, tenant ID, etc.), the front - end will attach the tenant context information (such as tenant ID, tenant - specific configuration, etc.) to the request

[721] , ensuring that the back - end service can identify the tenant to which it belongs. The SaaS authorized agent identifies the local authorization request, retrieves the authorization policy stored in the local SaaS tenant database according to this tenant ID, assigns the corresponding user role (such as ordinary user, administrator, etc.) and operation permissions to the current request [722 / 723], and returns a token to the front - end

[724] . The front - end carries the token to request the back - end service

[725] , and the back - end service parses the tenant identifier information and role identifier information in the token ( Figure 9 ), accesses the corresponding tenant database and completes the business functions allowed by the role permissions

[726] , and returns the result to the front - end application.

[0079] 4.3 Customized Authorization

[0080] This authorization mechanism is used for customized scenarios. The front - end directly sends the user identity identifier (such as user name, tenant ID, etc.) to the customized authorization module

[731] ; the back - end matches the authorization policy according to the customized tenant database [732 / 733]; upon successful authorization, it returns a token carrying customized information to the front - end container

[734] . The front - end container carries the token to request the back - end service

[735] , and the back - end service parses the customized information in the token ( Figure 10 ), accesses the corresponding customized tenant database and completes the business functions allowed by the role permissions

[736] , and returns the result to the front - end application.

[0081] 5. Dynamic Configuration and Update

[0082] 5.1 Distributed SaaS Dynamic Configuration

[0083] Figure 11 The SaaS dynamic configuration shown has four modes: module - level, docking with third - party platforms, multi - terminal compatibility, and vertical scenario support, allowing users to flexibly adjust the settings.

[0084] 1) Dynamic configuration of modular combinations

[0085] In the dynamic configuration of modules, modular design is carried out first. The system is divided into multiple independent and reusable modules, and each module encapsulates specific functions or business logics. Then, a configuration file or configuration center is established to manage the configuration information of these modules, including the enable / disable status of modules, parameter settings, etc. At runtime, the system dynamically loads or unloads the required modules according to this configuration information without restarting the system. Finally, through configuration and dynamic loading, different modules are combined to form a function set that meets specific business requirements, realizing the flexible construction and rapid response of the system.

[0086] 2) Integration of API interfaces at the backend of third-party platforms

[0087] When integrating third-party platforms, first obtain the API interface documents from the third-party platforms to understand information such as the URL of the interface, request parameters, response format, etc. Then, encapsulate these APIs at the backend of the system to form internal call methods and handle communication details. Next, integrate these encapsulated API call methods into the business logic of the system, call the corresponding API interfaces according to business requirements, and process the returned data. In this way, the system can expand its functions and service scope and achieve data exchange and business collaboration with third-party platforms.

[0088] 3) Guided compilation at the front end

[0089] In front-end development, to achieve cross-platform compatibility, specific compilation directives such as #ifdef H5 are inserted into the front-end code first to control conditional compilation of the code. Then, use the compiler to perform conditional compilation on this code to generate code segments that only contain the code that meets specific platform conditions. In this way, the front-end code can be applicable to multiple front-end environments such as H5, mini programs, and APPs to achieve cross-platform operation.

[0090] 4) Vertical scenario configuration

[0091] In scenario configuration, first conduct a requirements survey for different tenants to understand their business processes, functional requirements, and specific scenarios. Then, sort out different scenarios and requirement points based on the survey results to form specific configuration items and functional modules. Next, form different vertical domain applications according to these configuration items and functional modules. During the actual application process, the system will continuously collect user feedback and requirement changes and continuously optimize and update the application.

[0092] 5.2 Back-end program update

[0093] ① Unified update of back-end service SaaS

[0094] In a distributed SaaS architecture, when all backend services are entrusted to be implemented in SaaS management, such as Figure 12 the left flowchart, the backend program update mode is as follows: The program update request

[1211] is mainly initiated by the SaaS management party; after receiving the request, the backend service interacts with the SaaS management in the

[1212] link, and feedbacks its own running status, including business processing conditions, resource occupancy, and instance health status. The SaaS management evaluates the update feasibility to ensure the stable and efficient operation of the system during the update, and balances improvement and business continuity.

[0095] ② Backend service independent tenant update

[0096] In a distributed SaaS architecture, for the update mode where the backend service runs in the tenant's own resources, such as Figure 12 the right flowchart, the program update request

[1221] is mainly initiated by the tenant, and the reasons include the completion of customized function development, changes in internal system integration requirements, or business process adjustments, etc. After receiving the request, the backend service conducts a preliminary verification from the SaaS management side during the program update decision

[1222] stage, including tenant identity, request format, and content rationality, and then determines whether it can be updated based on its own running status and system configuration rules. If it can be updated, it obtains the update file

[1223] from the SaaS management source, verifies the legitimacy and integrity of the source, and operates according to the tenant's customized process, involving creating a temporary environment, isolation testing, gradually applying the update, and post-start function and performance testing

[1224] .

[0097] 5.3 Front-end program update

[0098] ① Front-end hosted in SaaS management mode

[0099] In the update mode where the front-end is hosted in SaaS management, the program update request

[1311] is initiated by the SaaS management party, and the purposes include improving the user experience, fixing security vulnerabilities, etc. It covers detailed update content such as pages and components and the expected effects. After the front-end container receives the request, it interacts with the SaaS management in the

[1312] link and feedbacks the running status, such as page display, user operations, and resource occupancy. The SaaS management evaluates the update feasibility based on this, considers the impact on users such as page reconstruction, and decides whether to wait or update gradually to ensure the smooth update of the front-end, optimize the user experience, and maintain system stability.

[0100] ② Front-end in the tenant's independent resources mode

[0101] The program update request

[1321] is initiated by the tenant due to its own business needs, such as brand image adjustment or addition of customized functions, and includes customized content and the scope of influence. After receiving the request, in the program update decision-making

[1322] phase, the front-end container first preliminarily verifies the tenant identity, the rationality of the request format and content. If the front-end is busy or there are conflicts, such as a large number of user interactions or architectural incompatibilities, the process enters a pause and feedback; if feasible, it enters

[1323] preparation for update. During the program update execution

[1324] , the front-end container obtains the update file from the source specified by the tenant, and after verification, operates according to the customized process, including creating a temporary environment, isolation testing, applying the update, and post-startup inspection, to ensure that the tenant's needs are met and the existing business is not affected.

[0102] ③ The front-end runs in a third-party container and is updated through a template

[0103] In the mode where the front-end runs in a third-party container and is updated through a template, the program update request (1331) is initiated by the tenant. Based on business needs, such as adapting to changes in third-party platform rules or optimizing front-end functions, the tenant submits an update request

[1332] to the third-party template management system (maintained by SaaS management

[1335] ), including desired function improvements, interface adjustments, etc. After receiving the request, the third-party template management system evaluates its rationality and feasibility. If feasible, it prepares for template update

[1333] . During the program update execution (1334) phase, the front-end container obtains the update file from the third-party template management system and operates according to the specified process, including replacing the template file, updating relevant resources, re-initializing components, and finally starting the updated front-end and performing function and display checks.

Claims

1. A distributed SaaS software service architecture for front-end and back-end separation, characterized by Distributed SaaS architecture design uses microservice architecture to split multi-tenant applications into independent modules, which interact with each other through lightweight communication protocols to achieve high scalability through pine coupling. Public, replacement, and customized modules can be flexibly combined, and there are SaaS agent and management collaborative processes to ensure system stability and security; distributed SaaS services include local, agent, and penetration service modes. SaaS agents are responsible for request filtering and authentication, and SaaS management is responsible for service configuration, etc., to adapt to the needs of different scenarios; distributed SaaS development, the front end uses microcontainer technology to achieve micro-application management and dynamic loading, and the back end relies on reverse proxy to forward requests according to rules; distributed authorization based on role-based access control has three modes for different role scenarios, all of which use token verification to achieve multi-tenant data isolation according to different database strategies; dynamic configuration and update, with module dynamic configuration, platform integration, front-end cross-platform compilation, and scenario configuration functions, supports multiple update modes for back-end and front-end programs, and improves the overall performance and flexibility of the system.

2. According to the three-type module mechanism as described in claim 1, the common modules are universal, the replacement modules can replace some functions, and the customized modules can be customized as needed.

3. According to the three types of distributed SaaS service models as described in claim 1, the local service front end is directly connected to the back end, the proxy service introduces the SaaS proxy, and the penetration service back end is directly controlled by the SaaS management.

4. The front-end containerized development method and the back-end reverse proxy development method as described in claim 1.

5. The three distributed authorization methods of SaaS management authorization, local authorization based on role access control and customized authorization as described in claim 1.

6. As described in claim 1, a four-level dynamic configuration and update mechanism covering modules, platforms, front-ends and scenarios is provided.

7. As described in claim 1, there are two backend service update methods: SaaS unified update and independent tenant update; three front-end update methods: front-end hosted in SaaS management, front-end in tenant independent resource mode, and front-end running in a third-party container through template update.

Images