A Centralized Management Method for Multi-Tenant Community Application Services

Abstract

This invention discloses a centralized management method for multi-tenant community application services. The method specifically includes the following steps: S1, deploying the application service platform on the Internet, with the application service platform chassis deployed separately on the government network. A security boundary is established between the application service platform and the security boundary, with one application service platform chassis deployed per community. This application demonstrates clear external openness and integration capabilities, possesses complete technical product standards to ensure architectural consistency, manages community information, downloads and manages community applications, supports multi-tenant mode, isolates applications and data among different tenants, enables application developers to implement unified application service access standards, unified permission information, and unified community basic information, and provides application traffic monitoring and user group analysis functions for community operation service providers, optimizing operational planning schemes.

Description

Technical Field

[0001] This invention relates to the field of smart community technology, and in particular to a centralized management method for multi-tenant community application services. Background Technology

[0002] Smart community and future community application services typically encompass nine major scenarios: neighborhood, education, health, entrepreneurship, architecture, transportation, low-carbon development, services, and governance. The smart community and future community industry focuses on creating new urban functional units that offer a sense of belonging, comfort, and a futuristic feel by innovating application services around these nine scenarios, leading to a transformation in lifestyles. During the construction of application services across various scenarios in smart and future communities, there are different application service developers, different competent authorities, different user groups, and different community application needs.

[0003] Currently, there are two common models for building community application services. One is the project customization model, where data such as community personnel, housing, and work records are deployed on the community's server according to the project model. The other is the SaaS software service model, where data such as community personnel, housing, and work records are stored on the server of a single software service provider.

[0004] The aforementioned existing technologies generally suffer from the following drawbacks: They employ a project-customized development model for community application services, integrating these services through single sign-on (SSO). SSO controls access permissions to multiple related but independent systems, allowing users with this permission to access one or more systems using a single ID and password, avoiding the need for different usernames or passwords, or enabling seamless login to each system through configuration. For communities, this lack of a convenient and efficient platform for accessing applications and building application services tailored to their specific needs is problematic. For application developers, different community projects require different applications, resulting in a lack of unified access standards. For operation service providers, application services originate from different developers, leading to a lack of a unified operation and monitoring platform and insufficient data support for eliminating inactive applications. Single SaaS software service providers offer community application services based on their own software functionalities, failing to provide a sufficient number of personalized community applications. The users of these community application services primarily include community residents, property management staff, and others. Therefore, there is an urgent need to propose an application service management method to address these issues and adapt to the application service needs of these users, facilitating seamless integration and management. Summary of the Invention

[0005] The purpose of this invention is to provide a centralized management method for multi-tenant community application services in order to solve the above-mentioned problems.

[0006] To achieve the above objectives, the present invention adopts the following technical solution:

[0007] A centralized management method for multi-tenant community application services, the method specifically includes the following steps:

[0008] S1. Deploy the application service platform on the Internet, and deploy the application service platform chassis separately on the government network. Connect the application service platform through the security boundary. Deploy one application service platform chassis for each community. The application service platform chassis obtains the corresponding community application list from the application service platform. The application service chassis performs security authentication with the application service platform through auth2.0 and adopts the MicroApp architecture component mode to build the front-end framework. Specifically, it includes the following steps;

[0009] S11. The lifecycle is composed of a custom micro-app lifecycle function to listen to the rendering of the element, load the HTML of the sub-application and convert it into the DOM structure, recursively query and load all static JS resources, set element isolation, intercept all dynamically created tags, and extract the tag content.

[0010] S12, js sandbox transfer, through proxy the global object of the sub-application, the js is processed by the plugin system and then put into the sandbox to run, then the formatted elements are put into micro-app, and finally the micro-app elements are rendered as a micro frontend sub-application;

[0011] S13. Create style isolation by formatting the content of the link and style elements of the sub-application to ensure that the styles of the sub-application only apply to itself and cannot affect the outside.

[0012] S14. Create element isolation by using the same id for the root elements of multiple sub-applications, which helps the rendering framework correctly find its own root element.

[0013] S15. Resource address completion: Complete the relative address of the static resource of the sub-application into an absolute address so that the address points to the correct resource path;

[0014] S16. Sub-application preloading: Loads the application's static resources during the browser's idle time, and retrieves the resources directly from the cache and renders them when the application is actually rendered.

[0015] S17. Establish data communication. Each micro-app element can only communicate with the child application it points to. In this way, each application has a clear data chain. At the same time, MicroApp supports global communication, which is achieved by registering MicroAppStateActions using initGlobalState.

[0016] S2. The administrator creates basic user information for community tenants and vendor tenants on the platform. Vendor tenants and community tenants log in using the login account and initial password information provided by the administrator to further improve the vendor and tenant information. After improving the information, they submit it to the administrator for authentication.

[0017] S3. The administrator verifies the authenticity of the organizational information of the community or vendor tenant. After the verification is approved, the vendor tenant, as the developer, creates the corresponding application developer information on the platform, including AppID, AppSecret, and application service URL link. After the community tenant information is approved by the administrator, it obtains the credential information for deploying the application service platform chassis, which consists of AppID and AppSecret. The application chassis sends authentication information to the application service platform through AppID and AppSecret and obtains the application chassis token.

[0018] Preferably, the application service platform chassis requests the application to be loaded onto the application service platform. Once the application is loaded onto the application service platform chassis, the application service platform chassis will embed points at the access entry points of the loaded application based on the application usage and send the entry access logs to the application service platform for application data statistics to achieve high-frequency application statistics and identify high-frequency applications.

[0019] Preferably, the application service management platform is built using a microservice architecture. The service layer comprises basic services, business services, service component management, and configuration. Specifically, the service layer also includes:

[0020] Service component management and configuration, including circuit breaker protection, tracing, log analysis, registry center, service discovery, and unified configuration, adopts the Spiring Cloud architecture. The circuit breaker mechanism is implemented through Hystrix. Hystrix monitors the status of calls between microservices. When the number of failed calls reaches a certain threshold, the circuit breaker mechanism will be activated if the default is 20 failed calls within 5 seconds.

[0021] Preferably, the application service platform chassis is developed using a microservice architecture, and service components are managed and configured through a service platform. The application service platform chassis includes a four-layer architecture: basic services, application services, front-end framework, and front-end application. Each community deploys a separate application service chassis. During deployment, tenant credentials information AppID and AppSecret need to be set. The application service platform chassis stores basic community data.

[0022] Preferably, the application service platform is deployed in the form of cloud services. Each new community deploys a set of application service platform chassis locally and maintains network interconnection with the application service platform. The application service platform chassis service information is registered with the application service platform. The application service platform chassis requests application information downloaded from the application service platform. During the use of the application, it requests common service interfaces such as resident login information, resident profile information, and resident points information from the application service chassis.

[0023] Preferably, the application service platform chassis obtains the application service list, application service permissions, and application style configuration information from the application service platform through the tenant AppID and AppSecret, and loads them into the front-end framework of the homepage high-frequency application, scenario application, and back-end management application. The AppSecret and appId correspond, and the AppSecret is generated through the appId. The platform saves the generated appId and AppSecret to the server.

[0024] Preferably, the application service platform chassis and the application are integrated using a micro-frontend approach. The application service platform chassis serves as a container for other applications, while the sub-applications are the embedded components.

[0025] Preferably, the construction of the front-end framework also includes plugin processing, which performs preliminary processing on the incoming static resources and sequentially calls the qualified plugins. The pre-processed static resources are passed to the plugins as parameters, and the plugins further modify the resource content and return the modified content. The plugin system itself is clean and will not affect the resource content. Its role is to coordinate how each plugin executes. When the developer does not set up any plugins, the incoming and outgoing content is consistent.

[0026] Preferably, the process of establishing data communication is as follows:

[0027] S171. Create a new file main-app / src / micros / actions.js;

[0028] S172. Register a MicroAppStateActions instance, use the instance in the components that need to communicate, and register an onGlobalStateChange observer function, where state1 is the changed state and prevState1 is the state before the change;

[0029] S173. Enter the configuration of the sub-application. First, set up an Actions instance by creating a new file vue2-app / src / micros / actions.js;

[0030] S174. After creating the actions instance, inject the actual Actions in the render function of the entry file main.js;

[0031] S175. Register the observer function using onGlobalStateChange in the page, and use setGlobalState to get the message passed from the sub-application. The basic communication between the main application and the sub-application is then established.

[0032] Preferably, the service layer further includes application service management platform business services, specifically composed of application service management business services and tenant application services. The application service management business services include tenant registration process services, application service listing application process services, and application service download application services.

[0033] Tenant registration process services, including community tenant registration management and vendor tenant registration management;

[0034] Application service application process service, including application service addresses of various manufacturers;

[0035] Application service download application service, including service download review and community application service list.

[0036] In summary, due to the adoption of the above technical solution, the beneficial effects of the present invention are:

[0037] 1. In this application, on the one hand, cross-departmental and multi-business application scenarios in the construction of the digital society system must be implemented in future communities. On the other hand, the smart service platform of future communities must have cross-departmental and multi-business application scenarios of the digital society. Cross-departmental and multi-business application scenarios in relatively mature fields such as education and elderly care can be implemented and presented in future communities first. It has clear external openness and integration capabilities, complete technical product standards to ensure the consistency of architecture, management of community information, download and management of community applications, support for multi-tenant mode, isolation of applications and data for different tenants, unified application service access standards for application developers, unified permission information and community basic information, and provides application traffic monitoring functions and user group analysis functions for community operation service providers to optimize operation planning schemes.

[0038] 2.js sandboxes use proxies to proxy the global objects of sub-applications, preventing conflicts between global variables between applications. They can also record or clear global side-effect functions of sub-applications and inject global variables into sub-applications for customized processing. Style isolation refers to formatting the CSS content of the link and style elements of sub-applications to ensure that the styles of sub-applications only apply to themselves and cannot affect external elements. Element isolation can effectively prevent sub-applications from accidentally manipulating elements of the base application and other sub-applications. Multiple applications use the same ID for their root elements, and element isolation ensures that the rendering framework of a sub-application can correctly find its own root element. Resource loss often occurs in micro-frontends because the base application loads the resources of the sub-applications into its own page rendering. If the static resource address of the sub-application is a relative address, the browser will use the domain address of the base application to complete the static resource, resulting in resource loss. In a micro-frontend architecture, a sub-application is not a module but an independent application. Dividing sub-applications according to business functions can provide better maintainability and decoupling. Sub-applications should have the ability to run independently. Frequent communication between applications increases the complexity and coupling of the application. Attached Figure Description

[0039] Figure 1 A schematic diagram of the functional structure of an application service platform provided according to an embodiment of the present invention is shown;

[0040] Figure 2 A schematic diagram of the application service platform base structure provided according to an embodiment of the present invention is shown;

[0041] Figure 3 A schematic diagram of the service structure of the application service platform provided according to an embodiment of the present invention is shown;

[0042] Figure 4 A schematic diagram of the application service platform base service structure provided according to an embodiment of the present invention is shown;

[0043] Figure 5 A schematic diagram of the integrated structure of the vendor application and application service platform base provided according to an embodiment of the present invention is shown;

[0044] Figure 6 This diagram illustrates the authentication interaction structure of the vendor application and application service platform base provided according to an embodiment of the present invention. Detailed Implementation

[0045] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0046] Example 1

[0047] Please see Figure 1-6 The present invention provides a technical solution:

[0048] A centralized management method for multi-tenant community application services, characterized in that the system used in the centralized management method for multi-tenant community application services includes:

[0049] The application service platform is a smart service platform that manages community application services in a multi-tenant manner, including three types of users: administrators, community tenants, and vendor tenants.

[0050] Administrators can manage the application center, application downloads, data statistics, tenants, vendors, product approval, and personal information. Application vendors can create, publish, manage downloads, collect data, manage development, and manage personal information. Tenants can access the application center, their apps, their favorites, data statistics, their collections, and personal information management. The application service platform enables application vendors to register and manage their applications, and allows community tenants to browse, download, and manage their applications.

[0051] The application service platform chassis is a base platform on the PC that carries various application services. The application service platform chassis includes three types of user information: resident users, property service users, and community management users.

[0052] The centralized management method for multi-tenant community application services specifically includes the following steps:

[0053] S1. Deploy the application service platform on the Internet, and deploy the application service platform chassis separately on the government network. Connect the application service platform through the security boundary. Deploy one application service platform chassis for each community. The application service platform chassis obtains the corresponding community application list from the application service platform. The application service chassis performs security authentication with the application service platform through auth2.0 and adopts the MicroApp architecture component mode to build the front-end framework. Specifically, it includes the following steps;

[0054] S11. The lifecycle is composed of a custom micro-app lifecycle function to listen to the rendering of the element, load the HTML of the sub-application and convert it into the DOM structure, recursively query and load all static JS resources, set element isolation, intercept all dynamically created tags, and extract the tag content.

[0055] S12, js sandbox transfer, through proxy the global object of the sub-application, the js is processed by the plugin system and then put into the sandbox to run, then the formatted elements are put into the micro-app, and finally the micro-app elements are rendered as a micro frontend sub-application. The js sandbox proxies the global object of the sub-application through proxy to prevent conflicts of global variables between applications, record or clear the global side-effect functions of the sub-application, and can also inject global variables into the sub-application for customized processing;

[0056] S13. Create style isolation by formatting the content of the link and style elements of the sub-application to ensure that the styles of the sub-application only apply to itself and cannot affect the outside.

[0057] S14. Create element isolation by using the same id for the root elements of multiple sub-applications, which helps the rendering framework correctly find its own root element.

[0058] S15. Resource address completion: Complete the relative address of the static resource of the sub-application into an absolute address so that the address points to the correct resource path;

[0059] Resource loss often occurs in micro-frontends because the base application loads the resources of the child application into its own page rendering. If the static resource address of the child application is a relative address, the browser will use the domain address of the base application to complete the static resource, thus causing resource loss.

[0060] S16. Sub-application preloading: Loads the application's static resources during the browser's idle time, and retrieves the resources directly from the cache and renders them when the application is actually rendered.

[0061] S17. Establish data communication. In MicroApp, data is bound to communication, meaning each micro-app element can only communicate with the child applications it points to. This ensures that each application has a clear data chain. MicroApp also supports global communication, which is achieved by registering WlsqMicroAppStateActions using initGlobalState. The specific process is as follows:

[0062] S171. For example, the "Take a Photo" application in the future community needs to communicate with the main application of the future community. Community residents need to complete their personal registration information before they can use the "Take a Photo" function. After the photo is uploaded, the main application will display a message that the photo upload is complete. First, create a new file wlsq-mianapp / src / wlsq / micros / main.js in the main application.

[0063]

[0064]

[0065] S172. In the main application of the future community, register a WlsqMicroAppStateActions instance, use the instance in the components that need to communicate, and register an onGlobalStateChange observer function, where state1 is the changed state and prevState1 is the state before the change.

[0066]

[0067]

[0068]

[0069] S173. Enter the configuration of the Snap & Shoot app. First, set up an Actions instance by creating a new file shuishoupai / src / wlsq / micros / actions.js.

[0070]

[0071]

[0072] S174. After creating the actions instance, inject the actual Actions in the render function of the entry file main.js;

[0073] S175. Use the onGlobalStateChange function to register an observer function on the page, and use setGlobalState to get messages passed from the Suishoupai app. In the future, the basic communication between the main community app and the Suishoupai app will be established.

[0074]

[0075] S85, Used on the page

[0076]

[0077]

[0078]

[0079] S2. The administrator creates basic user information for community tenants and vendor tenants on the platform. Vendor tenants and community tenants log in using the login account and initial password information provided by the administrator to further improve the vendor and tenant information. After improving the information, they submit it to the administrator for authentication.

[0080] S3. The administrator verifies the authenticity of the organizational information of the community or vendor tenant. After the verification is approved, the vendor tenant, as the developer, creates the corresponding application developer information on the platform, including AppID, AppSecret, and application service URL link. After the community tenant information is approved by the administrator, it obtains the credential information for deploying the application service platform chassis, which consists of AppID and AppSecret. The application chassis sends authentication information to the application service platform through AppID and AppSecret and obtains the application chassis token.

[0081] After a vendor's application service is developed, it can apply to list the application service individually or in batches. The application requires uploading an operation manual and other information. After submitting the application, the vendor will submit the operation manual and the application service URL to the administrator. The administrator will test the application based on the operation manual and then review the application. If the application fails the review, the vendor can view the reason for the failure; if the application passes the review, community residents can view the listed application service.

[0082] The algorithm for generating AppID is as follows:

[0083]

[0084]

[0085] The algorithm for generating AppSecret is as follows:

[0086]

[0087]

[0088] The AppID needs to be unique and at least 8 characters long. The system uses 62 printable characters to randomly generate a 32-bit UUID, adding additional characters. Since the UUIDs are all hexadecimal, they are divided into 8 groups of 4, and then a modulo-62 operation is performed. The result is used as an index to retrieve characters, thus greatly reducing the duplication rate. Testing showed no duplicates even after generating ten million data entries, perfectly meeting application requirements.

[0089] The AppID is the application developer identifier, which, together with the AppSecret, allows access to the application's API capabilities. The AppSecret is a password used to verify the application developer's identity, providing extremely high security. The application service URL is the URL access link for the corresponding application service, and it needs to support the HTTPS protocol. Applications loaded onto the application service platform request a token from the platform using their AppID and AppSecret. The platform compares the received AppID and AppSecret with the AppID and AppSecret generated during the application request. If successful, it returns a 10-minute valid application token to the frontend. The application uses this token to request application services from the platform. The platform will record application usage logs. The token generation algorithm is as follows:

[0090]

[0091] Here, `claims` is a map that stores basic user information, permissions, and other data returned to the application from the application platform. The method to retrieve `claims` is as follows:

[0092]

[0093]

[0094] AppSecret corresponds to appId. AppSecret is generated using appId. The platform saves the generated appId and AppSecret to the server for application service request verification and generation of the corresponding token. AppSecret can be updated based on appId so that a new AppSecret can be generated when appId and AppSecret are leaked.

[0095] The application service platform chassis obtains the application service list, application service permissions, and application style configuration information from the application service platform through the tenant's AppID and AppSecret, and loads them into the front-end framework of the homepage's high-frequency applications, scenario applications, and back-end management applications.

[0096] The application service platform chassis requests the application to be loaded onto the application service platform. The application is loaded onto the application service platform chassis. Based on the application usage, the application service platform chassis will embed points at the access entry points of the loaded application and send the entry access logs to the application service platform for application data statistics to realize high-frequency application statistics and identify high-frequency applications.

[0097] The application service management platform is built using a microservice architecture. The service layer consists of basic services, business services, service component management, and configuration. Specifically, the service layer also includes:

[0098] Service component management and configuration, including circuit breaker protection, tracing, log analysis, registry center, service discovery, and unified configuration, adopts the Sping Cloud architecture. The circuit breaker mechanism is implemented through Hystrix. Hystrix monitors the status of calls between microservices. When the number of failed calls reaches a certain threshold, the circuit breaker mechanism will be activated if the default is 20 failed calls within 5 seconds.

[0099] Microservice tracing is implemented using the Spring Cloud Sleuth component. Spring Cloud Sleuth is based on Zipkin, which consists of a server and a client. If the server-side user enables distributed tracing, the client needs to communicate with the Zipkin server when making network requests. Log analysis uses Logstash as the data collection engine. It integrates numerous plugins, supports rich data source collection, and can filter, analyze, and format the collected data. Nacos is used for the registry, service discovery, and unified configuration. Nacos provides a simple and easy-to-use feature set that enables rapid dynamic service discovery, service configuration, service metadata, and traffic management.

[0100] The application service platform chassis is developed using a microservice architecture and manages and configures service components through the handling service platform. The application service platform chassis includes a four-layer architecture: basic services, application services, front-end framework, and front-end application. Each community deploys a separate application service chassis. During deployment, tenant credential information AppID and AppSecret need to be set. The application service platform chassis stores the community's basic data.

[0101] The application service platform is deployed in the form of cloud services. Each new community has a corresponding application service platform chassis deployed locally, and maintains network interconnection with the application service platform. The application service platform chassis service information is registered with the application service platform. The application service platform chassis requests application information downloaded from the application service platform. During the use of the application, it requests common service interfaces such as resident login information, resident profile information, and resident points information from the application service chassis.

[0102] The application service platform chassis obtains the application service list, application service permissions, and application style configuration information from the application service platform through the tenant's AppID and AppSecret, and loads them into the front-end framework of the homepage's high-frequency applications, scenario applications, and back-end management applications.

[0103] The application service platform chassis and applications are integrated using a micro-frontend approach. The application service platform chassis serves as a container for other applications, while the sub-applications are the embedded components.

[0104] The front-end framework also includes plugin processing, which performs preliminary processing on the incoming static resources and calls the corresponding plugins in sequence. The pre-processed static resources are passed to the plugins as parameters, and the plugins further modify the resource content and return the modified content. The plugin system itself is clean and will not affect the resource content. Its role is to coordinate how the various plugins execute. When the developer does not set up any plugins, the incoming and outgoing content is consistent.

[0105] AppSecret corresponds to appId. AppSecret is generated using appId, and the platform saves the generated appId and AppSecret to the server.

[0106] The service layer also includes application service management platform business services, specifically composed of application service management business services and tenant application services. The application service management business services include tenant registration process services, application service listing application process services, and application service download application services.

[0107] Tenant registration process services, including community tenant registration management and vendor tenant registration management;

[0108] Application service application process service, including application service addresses of various manufacturers;

[0109] Application service download application service, including service download review and community application service list.

[0110] Example 2

[0111] Based on Example 1

[0112] Please see Figure 5 and Figure 6 The process by which Community A, through Application 1, obtains resident management services is as follows:

[0113] Application 1 initiates an authentication and authorization request to the application service platform base. After the application service platform base authenticates the application, it sends a Community A+ Application 1 auth authentication request to the application service platform. The application service platform successfully authenticates the application and returns a token to the application service platform base. The application service platform base returns the token to Application 1. Application 1 then sends the token to the resident management service to receive the return.

[0114] The community platform adopts a modular architecture design, which can not only meet the personalized requirements of different communities, but also facilitate the rapid implementation and deployment of applications.

[0115] The above description of the embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A centralized management method for multi-tenant community application services, characterized in that, The centralized management method for multi-tenant community application services specifically includes the following steps: S1. Deploy the application service platform on the Internet, and deploy the application service platform chassis separately on the government network. Connect the application service platform through the security boundary. Deploy one application service platform chassis for each community. The application service platform chassis obtains the corresponding community application list from the application service platform. The application service chassis performs security authentication with the application service platform through auth2.0 and adopts the MicroApp architecture componentization mode to build the front-end framework, including the following steps; S11. The lifecycle is composed of a custom micro-app lifecycle function to listen to the rendering of the element, load the HTML of the sub-application and convert it into the DOM structure, recursively query and load all static JS resources, set element isolation, intercept all dynamically created tags, and extract the tag content. S12, js sandbox transfer, through proxy the global object of the sub-application, the js is processed by the plugin system and then put into the sandbox to run, then the formatted elements are put into micro-app, and finally the micro-app elements are rendered as a micro frontend sub-application; S13. Create style isolation by formatting the content of the link and style elements of the sub-application to ensure that the styles of the sub-application only apply to itself and cannot affect the outside. S14. Create element isolation by using the same id for the root elements of multiple sub-applications, which helps the rendering framework correctly find its own root element. S15. Resource address completion: Complete the relative address of the static resource of the sub-application into an absolute address so that the address points to the correct resource path; S16. Sub-application preloading: Loads the application's static resources during the browser's idle time, and retrieves the resources directly from the cache and renders them when the application is actually rendered. S17. Establish data communication. Each micro-app element can only communicate with the child application it points to. In this way, each application has a clear data chain. At the same time, MicroApp supports global communication, which is achieved by registering MicroAppStateActions using initGlobalState. S2. The administrator creates basic user information for community tenants and vendor tenants on the platform. Vendor tenants and community tenants log in using the login account and initial password information provided by the administrator to further improve the vendor and tenant information. After improving the information, they submit it to the administrator for authentication. S3. The administrator verifies the authenticity of the organizational information of the community or vendor tenant. After the verification is approved, the vendor tenant, as the developer, creates the corresponding application developer information on the platform, including AppID, AppSecret, and application service URL link. After the community tenant information is approved by the administrator, it obtains the credential information for deploying the application service platform chassis, which consists of AppID and AppSecret. The application chassis sends authentication information to the application service platform through AppID and AppSecret and obtains the application chassis token.

2. The method for centralized management of multi-tenant community application services according to claim 1, characterized in that, The application service platform chassis requests the application to be loaded onto the application service platform. The application is loaded onto the application service platform chassis. Based on the application usage, the application service platform chassis will embed points at the access entry points of the loaded application and send the entry access logs to the application service platform for application data statistics to realize high-frequency application statistics and identify high-frequency applications.

3. The method for centralized management of multi-tenant community application services according to claim 1, characterized in that, The application service platform chassis is built using a microservice architecture. The service layer consists of basic services, business services, service component management, and configuration. Specifically, the service layer also includes: Service component management and configuration, including circuit breaker protection, tracing, log analysis, registry center, service discovery, and unified configuration, adopts the Spiring Cloud architecture. The circuit breaker mechanism is implemented through Hystrix. Hystrix monitors the status of calls between microservices, and when the number of failed calls reaches a certain threshold, the circuit breaker mechanism will be activated.

4. The method for centralized management of multi-tenant community application services according to claim 1, characterized in that, The application service platform chassis is developed using a microservice architecture and manages and configures service components through a service platform. The application service platform chassis includes a four-layer architecture: basic services, application services, front-end framework, and front-end application. Each community deploys a separate application service chassis. During deployment, tenant credentials information AppID and AppSecret need to be set. The application service platform chassis stores the community's basic data.

5. The method for centralized management of multi-tenant community application services according to claim 1, characterized in that, The application service platform is deployed in the form of cloud services. Each new community deploys an application service platform chassis locally and maintains network interconnection with the application service platform. The application service platform chassis service information is registered with the application service platform. The application service platform chassis requests application information downloaded from the application service platform. During the use of the application, it requests resident login information, resident profile information, and resident points information from the application service chassis via general service interfaces.

6. The method for centralized management of multi-tenant community application services according to claim 4, characterized in that, The application service platform chassis obtains the application service list, application service permissions, and application style configuration information from the application service platform through the tenant's AppID and AppSecret, and loads them into the front-end framework of the homepage high-frequency application, scenario application, and back-end management application. The AppSecret and appId correspond to each other, and the AppSecret is generated through the appId. The platform saves the generated appId and AppSecret to the server.

7. The method for centralized management of multi-tenant community application services according to claim 5, characterized in that, The application service platform chassis and applications are integrated using a micro-frontend approach. The application service platform chassis serves as a container for other applications, while the sub-applications are the embedded components.

8. The method for centralized management of multi-tenant community application services according to claim 1, characterized in that, The construction of the front-end framework also includes plugin processing, which performs preliminary processing on the incoming static resources and calls the qualified plugins in sequence. The preliminary processed static resources are passed to the plugins as parameters, and the plugins further modify the resource content and return the modified content. The plugin system itself is clean and will not affect the resource content. Its role is to coordinate how the various plugins execute. When the developer does not set up any plugins, the incoming and outgoing content is consistent.

9. The method for centralized management of multi-tenant community application services according to claim 1, characterized in that, The process of establishing data communication is as follows: S171. Create a new file main-app / src / micros / actions.js; S172. Register a MicroAppStateActions instance, use the instance in the components that need to communicate, and register an onGlobalStateChange observer function, where state1 is the changed state and prevState1 is the state before the change; S173. Enter the configuration of the sub-application. First, set up an Actions instance by creating a new file vue2-app / src / micros / actions.js; S174. After creating the actions instance, inject the actual Actions in the render function of the entry file main.js; S175. Register the observer function using onGlobalStateChange in the page, and use setGlobalState to get the message passed from the sub-application. The basic communication between the main application and the sub-application is then established.

10. The method for centralized management of multi-tenant community application services according to claim 3, characterized in that, The service layer also includes application service management platform business services, which consist of application service management business services and tenant application services. The application service management business services include tenant registration process services, application service listing application process services, and application service download application services. Tenant registration process services, including community tenant registration management and vendor tenant registration management; Application service application process service, including application service addresses of various manufacturers; Application service download application service, including service download review and community application service list.

Images