Multi-service and multi-tenant-oriented micro-service method and system

Abstract

The invention relates to the technical field of distributed computing and cloud computing, in particular to a multi-service and multi-tenant-oriented micro-service method and system, and the method comprises the steps: constructing a dynamic modular service framework based on a pluggable service component, a cross-tenant service module based on resource sharing, and a multi-service and multi-tenant service module based on resource sharing; modeling the calling relationship between the micro-services and calculating each resource demand weight coefficient of the micro-services; and scheduling the resource-shared cross-tenant service module by using the dynamic resource allocator. According to the method, the dynamic modular service framework based on the pluggable service component is constructed, so that accurate loading and unloading of each service module of the micro-service can be completed within hundreds of milliseconds, and the agility of the system is remarkably improved. According to the method, calling relation modeling is carried out on the cross-tenant service module, the resource demand weight coefficient is calculated, basic data is provided for resource scheduling, load changes are considered, optimal configuration of resources is achieved, and the overall performance and the response speed of the system are improved.

Description

Technical Field

[0001] The present invention relates to the technical field of distributed computing and cloud computing, and in particular to a microservice method and system for multi-business and multi-tenant services. Background Art

[0002] When dealing with multi-tenant and multi-business environments, the current microservice architecture uses technologies such as OSGi and ServiceMesh to dynamically load and combine modules, allowing business functions to be flexibly matched according to needs. However, most current solutions are limited to specific language stacks (such as Java's modular system), and the dependencies between modules are still statically defined in advance, making it difficult to adapt to dynamically changing needs in cross-business scenarios.

[0003] On the other hand, container orchestration technologies such as Kubernetes provide basic automatic scaling capabilities, and combined with monitoring tools such as Prometheus, they can implement threshold-based regular resource scheduling. However, when faced with a mixed deployment environment that includes multiple heterogeneous resources such as CPU, GPU, and FPGA, these systems lack a deep understanding of business logic and requirements, resulting in resource allocation that often does not match business characteristics.

[0004] At the same time, in terms of multi-tenant collaboration, the existing architecture mainly ensures the independence of resources through namespace isolation or hardware partitioning, but this approach also abandons the opportunity for capability sharing and collaborative work between businesses. Summary of the invention

[0005] 1. Purpose of the invention The purpose of the present invention is to provide a microservice method and system for multi-business and multi-tenant services that can improve agility and optimize resource allocation.

[0006] (II) Technical solution To solve the above problems, the present invention provides a microservice method for multi-business and multi-tenants, including: Build a dynamic modular service framework based on pluggable service components, which supports dynamic loading and unloading of business modules of each microservice, isolation between tenants and resource sharing of cross-tenant business modules in a multi-service and multi-tenant environment; Based on the cross-tenant business module of resource sharing, the calling relationship between microservices is modeled and the weight coefficient of each resource requirement of microservices is calculated; According to the calling relationship between microservices and the resource demand weight coefficients of each microservice, a dynamic resource allocator is used to schedule resource-sharing cross-tenant business modules.

[0007] In another aspect of the present invention, preferably, the loading includes: encapsulating the business components by using virtual images, each image containing a dependency library and a configuration file of a corresponding microservice, and loading after verification by a hash algorithm; The uninstallation includes: analyzing the API call graph in real time through a dynamic dependency resolution engine, generating a minimized running set according to the API call graph, and uninstalling unused business modules according to the minimized running set.

[0008] In another aspect of the present invention, preferably, the dynamic modular service framework also supports cross-language calls, and the cross-language calls are implemented by building a standardized service gateway, converting heterogeneous APIs into a unified RESTful interface, and embedding a gRPC protocol conversion middleware.

[0009] In another aspect of the present invention, preferably, the isolation includes: building a trusted execution environment through Intel SGX, and sensitive business modules run in Enclave; using eBPF technology to perform call filtering to block unconventional resource access; deploying a differential privacy protection algorithm to add Gaussian noise to the parameters of business modules shared across tenants.

[0010] In another aspect of the present invention, preferably, the resource sharing of the cross-tenant business modules includes: Extracting features of business modules of different tenants, including interface features, data model features, business process features, and resource consumption features; Performing hierarchical clustering and similarity calculation on the features, and determining a shared candidate set of business modules of different tenants according to a shared threshold; The sharing candidate set includes service modules that can share resources.

[0011] In another aspect of the present invention, preferably, the modeling of the calling relationship between microservices includes: Using graph convolutional neural networks, based on resource-sharing cross-tenant business modules, the calling relationship between microservices is modeled to obtain a service topology prediction model, which is represented as a topological graph of the calling relationship and dependency relationship of the resource-sharing cross-tenant business modules of each microservice in the microservice link; When offline, the service topology prediction model is trained using historical data; When online, an elastic weight solidification algorithm is used to adjust the service topology prediction model.

[0012] In another aspect of the present invention, preferably, each resource requirement weight coefficient of the computing microservice includes: Collect the feature vectors of each microservice business request and the runtime indicators corresponding to each microservice business request in the microservice link in real time, wherein the runtime indicators include response delay, error rate and resource utilization; According to the topology diagram, obtain the position vector of the cross-tenant business module of each microservice that can share resources in the microservice link; Input the position vector, the feature vector of the business request, and the runtime index into the Transformer algorithm to calculate the attention weight of the business module of each microservice; According to the attention weight, each resource requirement weight coefficient of the microservice is calculated.

[0013] In another aspect of the present invention, preferably, the dynamic resource allocator includes a state space and an action space; The dimensions of the state space include microservice queue depth, container resource utilization, and network latency; The dimensions of the action space include CPU core binding strategy, memory dynamic expansion strategy and microservice elastic scaling control strategy.

[0014] In another aspect of the present invention, preferably, the scheduling of resource-sharing cross-tenant business modules using a dynamic resource allocator according to the calling relationship between microservices and the resource demand weight coefficients of each microservice includes: The dynamic resource allocator generates an initial strategy model based on the expert scheduling strategy; Using an imitation learning pre-training mechanism to train the initial strategy model to obtain a first strategy model; Using a Q-learning algorithm to optimize the trained first strategy model to obtain a second strategy model; According to the calling relationship between microservices and the resource demand weight coefficients of each microservice, the second policy model is used to schedule the resource-sharing cross-tenant business module.

[0015] In another aspect of the present invention, preferably, a multi-business multi-tenant oriented microservice system includes: Building modules: Building a dynamic modular service framework based on pluggable service components. The dynamic modular service framework supports dynamic loading and unloading of each microservice, isolation between tenants in a multi-service and multi-tenant environment, and resource sharing between cross-tenant business modules. Computing module: Based on the cross-tenant business module of resource sharing, it models the calling relationship between microservices and calculates the weight coefficient of each resource requirement of microservices; Scheduling module: Based on the calling relationship between microservices and the resource demand weight coefficients of each microservice, the dynamic resource allocator is used to schedule the cross-tenant business modules that share resources.

[0016] (III) Beneficial effects The above technical solution of the present invention has the following beneficial technical effects: The present invention can complete the precise loading and unloading of each business module of microservices within hundreds of milliseconds by constructing a dynamic modular service framework based on pluggable service components, thereby significantly improving the agility of the system. In a multi-business, multi-tenant environment, the dynamic modular service framework can ensure that the business data and logic between tenants are isolated from each other, and ensure the security and privacy of the data. At the same time, under the premise of ensuring secure isolation between tenants, it supports resource sharing of business modules and supports dynamic borrowing of business modules between different tenants, thereby improving resource utilization. The call relationship modeling is performed on cross-tenant business modules, the dependency relationship and interaction process between business modules are clearly displayed, and the resource demand weight coefficient is calculated to provide basic data for resource scheduling. Furthermore, the dynamic resource allocator also takes into account the changes in load, dynamically adjusts resource allocation, realizes optimal resource configuration, and improves the overall performance and response speed of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 is an overall flow chart of an embodiment of the present invention; Figure 2 It is a schematic diagram of the structure of a dynamic modular service framework according to an embodiment of the present invention. DETAILED DESCRIPTION

[0018] In order to make the purpose, technical scheme and advantages of the present invention clearer, the present invention is further described in detail below in conjunction with specific embodiments and with reference to the accompanying drawings. It should be understood that these descriptions are only exemplary and are not intended to limit the scope of the present invention. In addition, in the following description, the description of well-known structures and technologies is omitted to avoid unnecessary confusion of the concept of the present invention.

[0019] Obviously, the described embodiments are only some embodiments of the present invention, but not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0020] In the description of the present invention, it should be noted that the terms “first”, “second” and “third” are only used for descriptive purposes and cannot be understood as indicating or implying relative importance.

[0021] In addition, the technical features involved in the different embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0022] Embodiment 1 A microservice approach for multi-business and multi-tenant services. Figure 1FIG. 1 shows an overall flow chart of an embodiment of the present invention, as shown in FIG. Figure 1 As shown, including: Build a dynamic modular service framework based on pluggable service components. Figure 2 A schematic diagram showing the structure of a dynamic modular service framework according to an embodiment of the present invention is shown in FIG. Figure 2 As shown in the figure, the dynamic modular service framework includes a service orchestration layer, a dynamic module layer, an intelligent analysis layer, and a resource scheduling layer connected in sequence; the service orchestration layer is based on the business orchestration engine extended by Kubernetes CRD, and the dynamic module layer supports hot-swappable OSGi++ container clusters; the intelligent analysis layer includes a hybrid AI engine (offline GNN + online Transformer); and the resource scheduling layer includes a DRL-driven multi-dimensional resource allocator.

[0023] The dynamic modular service framework supports dynamic loading and unloading of business modules of each microservice, supports isolation between tenants and resource sharing of cross-tenant business modules in a multi-service and multi-tenant environment; The loading includes: encapsulating the business components by using lightweight virtual images, each image contains the dependency library and configuration files of the corresponding microservice, and loading after verification by hash algorithm; The uninstallation includes: analyzing the API call graph in real time through a dynamic dependency resolution engine, generating a minimized running set according to the API call graph, and uninstalling unused business modules according to the minimized running set.

[0024] In this embodiment, loading and unloading can be achieved through the plug-in state machine, dependency resolution algorithm and hot replacement protocol. The plug-in state machine is used to manage the plug-in life cycle; the dependency resolution algorithm can parse the dependency library and configuration file of the corresponding microservice, and ensure consistency through hash locks. The hot replacement protocol includes a two-phase commit protocol: Phase 1: new module preload → old module marked as STANDBY → state synchronization to all gateways; Phase 2: traffic switching → old module unloading → release memory (using Copy-on-Write memory protection mechanism); key parameters: synchronization timeout: T_sync=200ms; memory retention window: T_mem=5s.

[0025] Specifically, the dependency resolution algorithm includes: def resolve_dependencies(module): sorted_modules = [] zero_in_degree = deque([module]) while zero_in_degree: m = zero_in_degree.popleft() sorted_modules.append(m) for dep in m.dependencies: dep.in_degree -= 1 if dep.in_degree == 0: zero_in_degree.append(dep) return sorted_modules The above dependency resolution algorithm introduces a virtual dependency node to handle cross-cluster module calls.

[0026] In another embodiment, loading and unloading are based on the module hot-swap control protocol. By designing an incremental loading mechanism based on event triggering, when the gateway detects a new API request feature (such as the AR makeup trial interface call of a beauty app), the following process is triggered: the module manager matches the candidate module (such as the OpenCV image processing plug-in) from the preset module fingerprint library according to the request feature hash value, and executes the dependency tree minimization algorithm: def minimize_deps(root_module): required = set() queue = deque([root_module]) while queue: mod = queue.popleft() if mod not in required: required.add(mod) for dep in mod.hard_dependencies: # Only load strong dependencies if dep.sla_level>= current_sla: # Filter by SLA level queue.append(dep) return topological_sort(required) Memory pre-mapping technology is used to accelerate loading: a virtual memory mapping table is established during the module download phase, and only the actual content needs to be filled during loading, reducing the loading time of a 100MB module from 2.3s to 0.4s.

[0027] Key parameters: module fingerprint similarity threshold: θ=0.82 (based on MinHash algorithm); dependency tree depth limit: L_max=5 (to prevent circular dependencies); pre-mapped memory pool size: dynamically adjusted, accounting for 15%-25% of total memory.

[0028] Furthermore, in this embodiment, the dynamic modular service framework also supports cross-language calls, which are implemented by building a standardized service gateway, converting heterogeneous APIs into a unified RESTful interface, and embedding the gRPC protocol conversion middleware. Specifically, the interaction process of the cross-language service gateway includes: 1) Protocol conversion: converting HTTP / JSON requests into an internal unified communication format (Protocol Buffers); 2) Language adaptation: Java module: directly calling through the JNI interface; Python module: starting a CPython interpreter instance and exchanging data through shared memory; Go module: compiling into a WebAssembly module and executing it in a dedicated runtime; 3) Traffic coloring: injecting the tenant ID + module version number into the request header to achieve grayscale release. The performance optimization of cross-language calls is expressed by defining the language conversion overhead weight using the following formula: W_lang =α·T_serial +β·M_footprint +γ·C_context Among them: α=0.6 (serialization time weight); β=0.3 (memory usage weight); γ=0.1 (context switching cost); by dynamically adjusting the language adaptation order, the cross-language call latency is reduced by 42%.

[0029] Furthermore, in this embodiment, the isolation includes: a three-layer three-dimensional protection system, in which a trusted execution environment is built through IntelSGX at the hardware level, and sensitive business modules run in Enclave; eBPF technology is used at the container layer to implement fine-grained system call filtering and block unconventional resource access; differential privacy protection modules are deployed at the application layer to add Gaussian noise to model parameters shared across tenants. At the same time, a service collaboration bus is developed to allow tenants to trade service capabilities through blockchain smart contracts. For example, the beauty filter service of the catering business can be encrypted and called by beauty tenants, forming a virtuous ecological cycle.

[0030] Further, in this embodiment, the resource sharing of cross-tenant business modules includes: extracting the features of business modules of different tenants, the features including interface features, data model features, business process features and resource consumption features; wherein the interface features represent the extraction of structured data of communication interfaces such as RESTful API endpoints, gRPC service descriptors, message queue topics, etc., and feature encoding is performed using the OpenAPI specification; the data model features represent the database table structure and entity relationship model involved in the parsing module, and extract graph feature parameters such as node degree and association relationship complexity in the ER diagram; the business process features represent the collection of inter-module call chains through the service mesh, and the construction of a time series feature vector including call frequency, response time standard deviation, exception rate and other indicators; the resource consumption features represent the CPU / memory occupancy rate, network IO throughput, and storage access mode of the monitoring module, forming a multi-dimensional resource portrait vector; Performing hierarchical clustering and similarity calculation on the features, and determining a shared candidate set of business modules of different tenants according to a shared threshold; The code example for performing hierarchical clustering and similarity calculation on the features is as follows: for module in all_modules: feature_vector = extract_features(module) First level coarse clustering cluster_label = KMeans(n_clusters=20).fit_predict(feature_vector) Second level density clustering refined_clusters = DBSCAN(eps=0.5).fit(sub_features) Calculate module similarity matrix sim_matrix = cosine_similarity(normalized_features); The sharing threshold is calculated according to the following formula: ; Among them, u represents the mean of feature similarity, with a value range of (0,1), representing the average cosine similarity between the feature vectors of all tenant business modules, reflecting the overall similarity level; σ represents the feature similarity variance, with a value range of ≥0, indicating the degree of dispersion of the feature similarity distribution. The larger the variance, the more significant the similarity difference between modules; α represents the confidence coefficient, with a value of 1.96, which is the Z value coefficient in statistics. Taking 1.96 corresponds to a 95% confidence interval, which is used to control the strictness of sharing judgment.

[0031] The sharing candidate set includes service modules that can share resources.

[0032] Furthermore, a multi-level cache system is built for the business modules that can share resources in the shared candidate set: For example, the first-level response time is <5ms, the hit rate is below 85%, and typical business module examples are user authentication and payment callback; the second-level response time is 10-50ms, the hit rate is 85%-92%, and typical business module examples are product inventory management and order tracking; the third-level response time is 50-100ms, the hit rate is 92%-98%, and typical business module examples are log service and geographic location query; through feature decoupling technology, common features of different business scenarios are extracted, which can shorten the cold start time of new tenants by 60%.

[0033] Based on the cross-tenant business module of resource sharing, the calling relationship between microservices is modeled and the resource demand weight coefficient of each microservice is calculated; In this embodiment, modeling the calling relationship between microservices includes: Using graph convolutional neural networks, based on resource-sharing cross-tenant business modules, the calling relationship between microservices is modeled to obtain a service topology prediction model, which is represented as a topological graph of the calling relationship and dependency relationship of the resource-sharing cross-tenant business modules of each microservice in the microservice link; When offline, the service topology prediction model is trained using historical data; When online, an elastic weight solidification algorithm is used to adjust the service topology prediction model, keeping important parameters unchanged to prevent catastrophic forgetting.

[0034] Furthermore, in this embodiment, the resource requirement weight coefficients of the computing microservice include: Collect the feature vectors of each microservice business request and the runtime indicators corresponding to each microservice business request in the microservice link in real time, wherein the runtime indicators include response delay, error rate and resource utilization; According to the topology diagram, obtain the position vector of the cross-tenant business module of each microservice that can share resources in the microservice link; Input the position vector, the feature vector of the business request, and the runtime index into the Transformer algorithm to calculate the attention weight of the business module of each microservice; According to the attention weight, each resource requirement weight coefficient of the microservice is calculated.

[0035] According to the resource demand weight coefficients and loads of each microservice, a dynamic resource allocator is used to schedule resource-sharing cross-tenant business modules.

[0036] Through the Transformer algorithm for microservice links, the position vector, feature vector of business requests, and runtime indicators such as service response delay and error rate are added to the calculation attention weight, thereby improving resource utilization.

[0037] Further, in this embodiment, the dynamic resource allocator includes a state space and an action space; The dimensions of the state space include microservice queue depth, container resource utilization, and network latency; The dimensions of the action space include CPU core binding strategy, memory dynamic expansion strategy and microservice elastic scaling control strategy.

[0038] The elastic scaling control strategies include: Scaling factor = (current load - baseline) / (predicted peak - baseline) IF scaling factor > θ_scale_up; trigger horizontal expansion (number of new instances = ceil(current instance × scaling factor)) ELIF scaling factor <θ_scale_down; perform safe scaling down (retain N instances: N ≥ min_instances + safety margin) The baseline value can be predicted by the Holt-Winters algorithm, and θ_scale_up can be 0.75; θ_scale_down can be 0.35.

[0039] The method of scheduling the resource-sharing cross-tenant business module by using a dynamic resource allocator according to the resource demand weight coefficient and load of each microservice includes: The dynamic resource allocator generates an initial strategy model based on the expert scheduling strategy; Using an imitation learning pre-training mechanism to train the initial strategy model to obtain a first strategy model; Using a Q-learning algorithm to optimize the trained first strategy model to obtain a second strategy model; According to the resource demand weight coefficients and loads of the microservices, the second policy model is used to schedule the resource-sharing cross-tenant business modules, including calculating the scheduling weights of the shared business modules that can be scheduled in the second policy model, and scheduling according to the scheduling weights.

[0040] The scheduling weight is exemplarily expressed as: Among them, ω1 represents the CPU weight coefficient, ω2 represents the memory weight coefficient; CPU_load represents the CPU load rate; Mem_free represents the memory free rate.

[0041] For example, the beauty and catering business collaboration scenario: During the lunchtime catering peak period: The scheduler detects that the order service queue is accumulated (queue length > 200); triggers horizontal expansion: adds 3 order processing instances; borrows GPU resources from the beauty business (the beauty business is in the off-peak period at this time); and dynamically adjusts the dish recommendation strategy of the large model (lowers the image rendering priority).

[0042] During the evening makeup peak period: the AR makeup trial module automatically loads the NVIDIA AR SDK plug-in; the resource arbitrator binds the CPU core to NUMA Node 0 and the GPU to A100-80G; the analysis engine predicts a sudden increase in lipstick color trial requests and preheats the relevant model parameters to the video memory. Table 1 shows the core technical indicators of the beauty and catering business collaboration scenario. Table 1 Core technical indicators As shown in Table 1, through the deep collaboration between the dynamic modular architecture and intelligent resource flow control of this embodiment, resource utilization is maximized while ensuring business.

[0043] The present invention can complete the precise loading and unloading of each business module of microservices within hundreds of milliseconds by constructing a dynamic modular service framework based on pluggable service components, thereby significantly improving the agility of the system. In a multi-business, multi-tenant environment, the dynamic modular service framework can ensure that the business data and logic between tenants are isolated from each other, and ensure the security and privacy of the data. At the same time, under the premise of ensuring secure isolation between tenants, it supports resource sharing of business modules and supports dynamic borrowing of business modules between different tenants, thereby improving resource utilization. The call relationship modeling is performed on cross-tenant business modules, the dependency relationship and interaction process between business modules are clearly displayed, and the resource demand weight coefficient is calculated to provide basic data for resource scheduling. Furthermore, the dynamic resource allocator also takes into account the changes in load, dynamically adjusts resource allocation, realizes optimal resource configuration, and improves the overall performance and response speed of the system.

[0044] Embodiment 2 A multi-business and multi-tenant microservice system, including: Building modules: Building a dynamic modular service framework based on pluggable service components. The dynamic modular service framework supports dynamic loading and unloading of each microservice, isolation between tenants in a multi-service and multi-tenant environment, and resource sharing between cross-tenant business modules. Computing module: Based on the cross-tenant business module of resource sharing, it models the calling relationship between microservices and calculates the weight coefficient of each resource requirement of microservices; Scheduling module: Based on the resource demand weight coefficients and loads of each microservice, a dynamic resource allocator is used to schedule resource-sharing cross-tenant business modules.

[0045] It should be understood that the above specific embodiments of the present invention are only used to illustrate or explain the principles of the present invention, and do not constitute a limitation of the present invention. Therefore, any modifications, equivalent substitutions, improvements, etc. made without departing from the spirit and scope of the present invention should be included in the protection scope of the present invention. In addition, the appended claims of the present invention are intended to cover all changes and modifications that fall within the scope and boundaries of the appended claims, or the equivalent forms of such scope and boundaries.

[0046] The present invention has been described above with reference to the embodiments of the present invention. However, these embodiments are for illustrative purposes only and are not intended to limit the scope of the present invention. The scope of the present invention is defined by the appended claims and their equivalents. Without departing from the scope of the present invention, a person skilled in the art may make various substitutions and modifications, which should all fall within the scope of the present invention.

[0047] Although the embodiments of the present invention have been described in detail, it should be understood that the various changes, substitutions, and alterations could be made hereto without departing from the spirit and scope of the invention.

[0048] Obviously, the above embodiments are merely examples for the purpose of clear explanation, and are not intended to limit the implementation methods. For those skilled in the art, other different forms of changes or modifications can be made based on the above description. It is not necessary and impossible to list all the implementation methods here. The obvious changes or modifications derived therefrom are still within the scope of protection of the invention.

Claims

1. A microservice method for multi-business and multi-tenants, characterized in that: include: Build a dynamic modular service framework based on pluggable service components, which supports dynamic loading and unloading of business modules of each microservice, isolation between tenants and resource sharing of cross-tenant business modules in a multi-service and multi-tenant environment; Based on the cross-tenant business module of resource sharing, the calling relationship between microservices is modeled and the weight coefficient of each resource requirement of microservices is calculated; According to the resource demand weight coefficients and loads of each microservice, a dynamic resource allocator is used to schedule resource-sharing cross-tenant business modules.

2. The multi-business and multi-tenant microservice method according to claim 1, characterized in that: The loading includes: encapsulating the business components by using virtual images, each image contains the dependency library and configuration files of the corresponding microservice, and loading after verification by a hash algorithm; The uninstallation includes: analyzing the API call graph in real time through a dynamic dependency resolution engine, generating a minimized running set according to the API call graph, and uninstalling unused business modules according to the minimized running set.

3. The multi-business and multi-tenant oriented microservice method according to claim 1, characterized in that: The dynamic modular service framework also supports cross-language calls, which are implemented by building a standardized service gateway, converting heterogeneous APIs into a unified RESTful interface, and embedding gRPC protocol conversion middleware.

4. The multi-business and multi-tenant oriented microservice method according to claim 1, characterized in that: The isolation includes: building a trusted execution environment through Intel SGX, and running sensitive business modules in the Enclave; using eBPF technology for call filtering to block unconventional resource access; deploying a differential privacy protection algorithm to add Gaussian noise to the parameters of business modules shared across tenants.

5. The multi-business and multi-tenant oriented microservice method according to claim 1, characterized in that: The resource sharing of the cross-tenant business modules includes: Extracting features of business modules of different tenants, including interface features, data model features, business process features, and resource consumption features; Performing hierarchical clustering and similarity calculation on the features, and determining a shared candidate set of business modules of different tenants according to a shared threshold; The sharing candidate set includes service modules that can share resources.

6. The multi-business and multi-tenant oriented microservice method according to claim 1, characterized in that: The modeling of the calling relationship between microservices includes: Using graph convolutional neural networks, based on resource-sharing cross-tenant business modules, the calling relationship between microservices is modeled to obtain a service topology prediction model, which is represented as a topological graph of the calling relationship and dependency relationship of the resource-sharing cross-tenant business modules of each microservice in the microservice link; When offline, the service topology prediction model is trained using historical data; When online, an elastic weight solidification algorithm is used to adjust the service topology prediction model.

7. The multi-business and multi-tenant oriented microservice method according to claim 6, characterized in that: The resource requirement weight coefficients of the computing microservice include: Collect the feature vectors of each microservice business request and the runtime indicators corresponding to each microservice business request in the microservice link in real time, wherein the runtime indicators include response delay, error rate and resource utilization; According to the topology diagram, obtain the position vector of the cross-tenant business module of each microservice that can share resources in the microservice link; Input the position vector, the feature vector of the business request, and the runtime index into the Transformer algorithm to calculate the attention weight of the business module of each microservice; According to the attention weight, each resource requirement weight coefficient of the microservice is calculated.

8. The multi-business and multi-tenant oriented microservice method according to claim 1, characterized in that: The dynamic resource allocator includes a state space and an action space; The dimensions of the state space include microservice queue depth, container resource utilization, and network latency; The dimensions of the action space include CPU core binding strategy, memory dynamic expansion strategy and microservice elastic scaling control strategy.

9. The multi-business and multi-tenant oriented microservice method according to claim 1, characterized in that: The method of scheduling the resource-sharing cross-tenant business module by using a dynamic resource allocator according to the resource demand weight coefficient and load of each microservice includes: The dynamic resource allocator generates an initial strategy model based on the expert scheduling strategy; Using an imitation learning pre-training mechanism to train the initial strategy model to obtain a first strategy model; Using a Q-learning algorithm to optimize the trained first strategy model to obtain a second strategy model; According to the resource demand weight coefficients and loads of each microservice, the second strategy model is used to schedule the resource-sharing cross-tenant business modules.

10. A microservice system for multi-business and multi-tenants, characterized in that: include: Building modules: Building a dynamic modular service framework based on pluggable service components. The dynamic modular service framework supports dynamic loading and unloading of each microservice, isolation between tenants in a multi-service and multi-tenant environment, and resource sharing between cross-tenant business modules. Computing module: Based on the cross-tenant business module of resource sharing, it models the calling relationship between microservices and calculates the weight coefficient of each resource requirement of microservices; Scheduling module: Based on the resource demand weight coefficients and loads of each microservice, a dynamic resource allocator is used to schedule resource-sharing cross-tenant business modules.

Images