A microservice method and system for multi-service and multi-tenant

Abstract

The present invention relates to the technical fields of distributed computing and cloud computing, and particularly relates to a microservice method and system for multiple services and multiple tenants, including: constructing a dynamic modular service framework based on pluggable service components, a cross-tenant service module based on resource sharing, modeling the call relationships between microservices and calculating the weight coefficients of various resource requirements of the microservices; and using a dynamic resource allocator to schedule the cross-tenant service module based on resource sharing. By constructing a dynamic modular service framework based on pluggable service components, the present invention can accurately load and unload each service module of the microservices within hundreds of milliseconds, significantly improving the agility of the system. Modeling the call relationships of the cross-tenant service modules and calculating the weight coefficients of resource requirements provides basic data for resource scheduling, also considering the changes in the load, realizing the optimal configuration of resources, and improving the overall performance and response speed of the system.

Description

Technical Field

[0001] The present invention relates to the technical fields of distributed computing and cloud computing, and particularly relates to a microservice method and system for multiple services and multiple tenants. Background Art

[0002] When the current microservice architecture is dealing with a multi-tenant and multi-service environment, it realizes the dynamic loading and combination of modules through technologies such as OSGi and ServiceMesh, enabling business functions to be flexibly configured according to requirements. However, most of the current solutions are limited by a specific language stack (such as the modular system of Java), and the dependency relationships between modules are still statically defined in advance, making it difficult to adapt to the dynamically changing requirements in cross-business scenarios.

[0003] On the other hand, container orchestration technologies such as Kubernetes provide basic auto-scaling capabilities, and combined with monitoring tools such as Prometheus, rule-based resource scheduling based on thresholds can be achieved. However, in the face of a hybrid deployment environment containing multiple heterogeneous resources such as CPUs, GPUs, and FPGAs, these systems lack a deep understanding of business logic and requirements, resulting in resource allocation often not matching business characteristics.

[0004] At the same time, in terms of multi-tenant collaboration, the existing architectures mainly ensure resource independence through namespace isolation or hardware partitioning, but this approach also gives up the opportunities for potential ability sharing and collaborative work between businesses. Summary of the Invention

[0005] (I) Object of the Invention

[0006] The object of the present invention is to provide a microservice method and system for multiple services and multiple tenants that can improve agility and optimize resource allocation.

[0007] (II) Technical Solution

[0008] To solve the above problems, the present invention provides a microservice method for multiple services and multiple tenants, including:

[0009] Constructing a dynamic modular service framework based on pluggable service components, where the dynamic modular service framework supports the dynamic loading and unloading of business modules of each microservice, and supports isolation between tenants and resource sharing of cross-tenant business modules in a multi-service and multi-tenant environment;

[0010] Based on the cross-tenant business modules with resource sharing, modeling the call relationships between microservices and calculating the weight coefficients of various resource requirements of microservices;

[0011] According to the call relationships between microservices and the weight coefficients of various resource requirements of microservices, use a dynamic resource allocator to schedule cross-tenant business modules that share resources.

[0012] On the other hand, preferably, the loading includes: encapsulating business components by adopting virtual images, each image containing the dependency libraries and configuration files of the corresponding microservices, and loading them after verification through a hash algorithm;

[0013] The unloading includes: through a dynamic dependency resolution engine, analyzing the API call graph in real time, generating a minimized running set according to the API call graph, and unloading unused business modules according to the minimized running set.

[0014] On the other hand, preferably, the dynamic modular service framework also supports cross-language calls, and the cross-language calls are implemented by constructing a standardized service gateway, converting heterogeneous APIs into unified RESTful interfaces, and embedding a gRPC protocol conversion middleware.

[0015] On the other hand, preferably, the isolation includes: constructing a trusted execution environment through Intel SGX, and running sensitive business modules within the Enclave; adopting 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 by cross-tenants.

[0016] On the other hand, preferably, the resource sharing of the cross-tenant business modules includes:

[0017] Extracting the characteristics of business modules of different tenants, where the characteristics include interface characteristics, data model characteristics, business process characteristics, and resource consumption characteristics;

[0018] Performing hierarchical clustering and similarity calculation on the characteristics, and determining a shared candidate set of business modules of different tenants according to a sharing threshold;

[0019] The shared candidate set includes business modules that can share resources.

[0020] On the other hand, preferably, the modeling of the call relationships between microservices includes:

[0021] Using a graph convolutional neural network to model the call relationships between microservices based on cross-tenant business modules that share resources, and obtaining a service topology prediction model, where the service topology prediction model is represented as a topology graph of the call relationships and dependency relationships of cross-tenant business modules that can share resources in each microservice in the microservice link;

[0022] During offline, training the service topology prediction model using historical data;

[0023] When online, the elastic weight curing algorithm is used to adjust the service topology prediction model.

[0024] On the other hand, preferably, the calculation of the weight coefficients of the resource requirements of each microservice includes:

[0025] Real-time collect the feature vectors of each microservice business request and the runtime metrics corresponding to each microservice business request in the microservice link, where the runtime metrics include response latency, error rate, and resource utilization;

[0026] According to the topology graph, obtain the position vectors of the cross-tenant business modules that can share resources of each microservice in the microservice link;

[0027] Input the position vector, the feature vector of the business request, and the runtime metrics into the Transformer algorithm to calculate the attention weights of the business modules of each microservice;

[0028] According to the attention weights, calculate the weight coefficients of the resource requirements of each microservice.

[0029] On the other hand, preferably, the dynamic resource allocator includes a state space and an action space;

[0030] The dimension of the state space includes microservice queue depth, container resource utilization, and network latency;

[0031] The dimension of the action space includes CPU core binding policy, memory dynamic expansion policy, and microservice elastic scaling control policy.

[0032] On the other hand, preferably, the scheduling of the cross-tenant business modules that share resources by using the dynamic resource allocator according to the call relationship between microservices and the weight coefficients of the resource requirements of each microservice includes:

[0033] The dynamic resource allocator generates an initial policy model based on the expert scheduling strategy;

[0034] Adopt an imitation learning pre-training mechanism to train the initial policy model to obtain a first policy model;

[0035] Adopt the Q-learning algorithm to optimize the trained first policy model to obtain a second policy model;

[0036] According to the call relationship between microservices and the weight coefficients of the resource requirements of each microservice, use the second policy model to schedule the cross-tenant business modules that share resources.

[0037] On the other hand, preferably, a microservice system for multiple services and multiple tenants includes:

[0038] Building module: Build a dynamic modular service framework based on pluggable service components. The dynamic modular service framework supports the dynamic loading and unloading of each microservice, and supports the isolation between tenants and the resource sharing of cross-tenant business modules in a multi-business and multi-tenant environment;

[0039] Calculation module: A cross-tenant business module based on resource sharing, which models the call relationships between microservices and calculates the weight coefficients of various resource requirements of microservices;

[0040] Scheduling module: According to the call relationships between microservices and the weight coefficients of various resource requirements of microservices, use a dynamic resource allocator to schedule cross-tenant business modules with resource sharing.

[0041] (III) Beneficial effects

[0042] The above technical solution of the present invention has the following beneficial technical effects:

[0043] By building a dynamic modular service framework based on pluggable service components, the present invention can accurately load and unload each business module of microservices within milliseconds, significantly improving the agility of the system. In a multi-business and multi-tenant environment, the dynamic modular service framework can ensure the isolation of business data and logic between tenants, ensuring data security and privacy. At the same time, on the premise of ensuring secure isolation between tenants, it supports the resource sharing of business modules, supports the dynamic borrowing of business modules between different tenants, and improves resource utilization. Model the call relationships of cross-tenant business modules, clearly show the dependency relationships and interaction processes between business modules, calculate the weight coefficients of resource requirements, provide basic data for resource scheduling. Furthermore, the dynamic resource allocator also considers changes in load, dynamically adjusts resource allocation, realizes the optimal configuration of resources, and improves the overall performance and response speed of the system. Description of the drawings

[0044] Figure 1 is the overall flowchart of an embodiment of the present invention;

[0045] Figure 2 is the structural schematic diagram of the dynamic modular service framework of an embodiment of the present invention. Detailed implementation manners

[0046] To make the purpose, technical solution and advantages of the present invention clearer and more understandable, the present invention will be further described in detail below in combination with specific implementation manners and with reference to the drawings. It should be understood that these descriptions are exemplary and not intended to limit the scope of the present invention. In addition, in the following description, the descriptions of well-known structures and technologies are omitted to avoid unnecessarily confusing the concepts of the present invention.

[0047] Obviously, the described embodiments are part of the embodiments of the present invention, rather than all of them. All other embodiments obtained by those of ordinary skill in the art based on the embodiments in the present invention without creative efforts fall within the protection scope of the present invention.

[0048] 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 construed as indicating or implying relative importance.

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

[0050] Embodiment 1

[0051] A microservice method for multiple services and multiple tenants Figure 1 shows the overall flowchart of an embodiment of the present invention, as Figure 1 shown, including:

[0052] Construct a dynamic modular service framework based on pluggable service components Figure 2 shows the structural schematic diagram of the dynamic modular service framework of an embodiment of the present invention, as Figure 2 shown, 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 a business orchestration engine based on Kubernetes CRD extension, and the dynamic module layer supports a hot-pluggable OSGi++ container cluster; the intelligent analysis layer includes a hybrid AI engine (offline GNN + online Transformer); the resource scheduling layer includes a DRL-driven multi-dimensional resource allocator.

[0053] The dynamic modular service framework supports the dynamic loading and unloading of business modules of each microservice, and supports the isolation between tenants and the resource sharing of cross-tenant business modules in a multi-service and multi-tenant environment;

[0054] Among them, the loading includes: encapsulating business components by using lightweight virtual images, each image contains the dependency libraries and configuration files of the corresponding microservice, and loading after verification by a hash algorithm;

[0055] The unloading includes: through a dynamic dependency resolution engine, analyzing the API call graph in real time, generating a minimized running set according to the API call graph, and unloading unused business modules according to the minimized running set.

[0056] In this embodiment, loading and unloading can be achieved through a plug-in state machine, a dependency resolution algorithm, and a hot replacement protocol. The plug-in state machine is used for managing the life cycle of the plug-in; the dependency resolution algorithm can resolve the dependency libraries and configuration files of the corresponding microservices, and ensure consistency through a hash lock. The hot replacement protocol includes a two-phase commit protocol: Phase1: Pre-load the new module → Mark the old module as STANDBY → Synchronize the status to all gateways; Phase2: Switch traffic → Unload the old module → Release memory (using the Copy-on-Write memory protection mechanism); Key parameters: Synchronization timeout: T_sync = 200ms; Memory retention window: T_mem = 5s.

[0057] Specifically, the dependency resolution algorithm includes: def resolve_dependencies(module):

[0058] sorted_modules = []

[0059] zero_in_degree = deque([module])

[0060] while zero_in_degree:

[0061] m = zero_in_degree.popleft()

[0062] sorted_modules.append(m)

[0063] for dep in m.dependencies:

[0064] dep.in_degree -= 1

[0065] if dep.in_degree == 0:

[0066] zero_in_degree.append(dep)

[0067] return sorted_modules

[0068] The above-mentioned dependency resolution algorithm introduces virtual dependency nodes to handle cross-cluster module calls.

[0069] In another embodiment, loading and unloading are based on the module hot-plug control protocol. By designing an event-triggered incremental loading mechanism, when the gateway detects new API request features (such as the AR makeup try-on interface call of a beauty makeup App), the following process is triggered: The module manager matches candidate modules (such as the OpenCV image processing plugin) from the pre-set module fingerprint library according to the request feature hash value, and executes the minimum dependency tree algorithm:

[0070] def minimize_deps(root_module):

[0071] required = set()

[0072] queue = deque([root_module])

[0073] while queue:

[0074] mod = queue.popleft()

[0075] if mod not in required:

[0076] required.add(mod)

[0077] for dep in mod.hard_dependencies: # Only load strong dependencies

[0078] if dep.sla_level>= current_sla: # Filter according to SLA level

[0079] queue.append(dep)

[0080] return topological_sort(required)

[0081] Adopt memory pre-mapping technology to accelerate loading: Establish a virtual memory mapping table during the module download phase. During loading, only the actual content needs to be filled, shortening the loading time of a 100MB module from 2.3s to 0.4s.

[0082] Key parameters: Module fingerprint similarity threshold: θ = 0.82 (based on the 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 the total memory.

[0083] Furthermore, in this embodiment, the dynamic modular service framework also supports cross-language calls, which are implemented by constructing a standardized service gateway to convert heterogeneous APIs into unified RESTful interfaces and embedding a 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 called through the JNI interface; Python module: starting a CPython interpreter instance and exchanging data through shared memory; Go module: compiled into a WebAssembly module and executed at a dedicated runtime; 3) Traffic coloring: injecting the tenant ID + module version number into the request header to achieve gray release. The performance optimization of cross-language calls is represented by the following formula by defining the language conversion overhead weights:

[0084] W_lang =α·T_serial +β·M_footprint +γ·C_context

[0085] where: α = 0.6 (serialization time weight); β = 0.3 (memory footprint weight); γ = 0.1 (context switching cost); By dynamically adjusting the language adaptation order, the cross-language call latency is reduced by 42%.

[0086] Furthermore, in this embodiment, the isolation includes: a three-layer three-dimensional protection system. At the hardware level, a trusted execution environment is constructed through Intel SGX, and sensitive business modules run within the Enclave; at the container layer, the eBPF technology is used to achieve fine-grained system call filtering and block unconventional resource access; at the application layer, a differential privacy protection module is deployed to add Gaussian noise to the model parameters shared across tenants. At the same time, a service collaboration bus is developed to allow tenants to conduct service capability transactions through blockchain smart contracts. For example, the beauty filter service of the catering business can be called by the beauty makeup tenant after encryption, forming a virtuous ecological cycle.

[0087] Furthermore, in this embodiment, the resource sharing of the cross-tenant business module includes: extracting the characteristics of the business modules of different tenants, where the characteristics include interface characteristics, data model characteristics, business process characteristics, and resource consumption characteristics; among them, the interface characteristics represent extracting structured data of communication interfaces such as RESTful API endpoints, gRPC service descriptors, and message queue topics, and encoding the characteristics using the OpenAPI specification; the data model characteristics represent the database table structure and entity relationship model involved in the parsing module, and extracting graph feature parameters such as the node degree and association relationship complexity in the ER diagram; the business process characteristics represent collecting the call chains between modules through a service mesh and constructing a time series feature vector containing indicators such as call frequency, standard deviation of response time, and exception rate; the resource consumption characteristics represent the CPU / memory occupancy rate, network IO throughput, and storage access mode of the monitoring module to form a multi-dimensional resource portrait vector.

[0088] Performing hierarchical clustering and similarity calculation on the characteristics, and determining the shared candidate set of the business modules of different tenants according to the sharing threshold;

[0089] Among them, the code example for performing hierarchical clustering and similarity calculation on the characteristics is as follows

[0090] for module in all_modules:

[0091] feature_vector = extract_features(module)

[0092] First-layer rough clustering

[0093] cluster_label = KMeans(n_clusters=20).fit_predict(feature_vector)

[0094] Second-layer density clustering

[0095] refined_clusters = DBSCAN(eps=0.5).fit(sub_features)

[0096] Calculating the module similarity matrix

[0097] sim_matrix = cosine_similarity(normalized_features);

[0098] The sharing threshold is calculated according to the following formula,

[0099] ;

[0100] Among them, u represents the mean of feature similarity, with a value range of (0, 1), which characterizes the average cosine similarity between the feature vectors of all tenant business modules and reflects the overall similarity level. σ represents the variance of feature similarity, with a value range ≥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 and is used to control the strictness of sharing determination.

[0101] The shared candidate set includes business modules that can share resources.

[0102] Furthermore, a multi-level cache system is constructed for the business modules that can share resources in the shared candidate set:

[0103] It can be graded according to response time and hit rate. For example, the response time of the first level is <5ms and the hit rate is below 85%. Typical business module examples include user authentication and payment callback. The response time of the second level is 10 - 50ms and the hit rate is 85% - 92%. Typical business module examples include commodity inventory management and order tracking. The response time of the third level is 50 - 100ms and the hit rate is 92% - 98%. Typical business module examples include log service and location query. By using feature decoupling technology to extract common features of different business scenarios, the cold start time of new tenants is shortened by 60%.

[0104] Based on the cross-tenant business modules with resource sharing, model the call relationship between microservices and calculate the weight coefficients of various resource requirements of microservices;

[0105] In this embodiment, the modeling of the call relationship between microservices includes:

[0106] Using a graph convolutional neural network, based on the cross-tenant business modules with resource sharing, model the call relationship between microservices to obtain a service topology prediction model, and the service topology prediction model is represented as a topology graph of the call relationship and dependency relationship of the cross-tenant business modules that can share resources among each microservice in the microservice link;

[0107] During offline, use historical data to train the service topology prediction model;

[0108] During online, use the elastic weight consolidation algorithm to adjust the service topology prediction model, keep important parameters unchanged, and prevent catastrophic forgetting.

[0109] Furthermore, in this embodiment, the calculation of the weight coefficients of various resource requirements of microservices includes:

[0110] Real-time collect the feature vectors of each microservice business request and the runtime metrics corresponding to each microservice business request in the microservice link, where the runtime metrics include response latency, error rate, and resource utilization rate;

[0111] According to the topology map, obtain the position vectors of the cross-tenant business modules of each microservice that can share resources in the microservice link;

[0112] Input the position vector, the feature vector of the business request, and the runtime metrics into the Transformer algorithm to calculate the attention weights of the business modules of each microservice;

[0113] According to the attention weights, calculate the weight coefficients of each resource requirement of the microservice.

[0114] According to the weight coefficients of each resource requirement of the microservice and the load, use the dynamic resource allocator to schedule the cross-tenant business modules that share resources.

[0115] By using the Transformer algorithm for the microservice link, adding the position vector, the feature vector of the business request, and runtime metrics such as service response latency and error rate to calculate the attention weights, the resource utilization rate is improved.

[0116] Furthermore, in this embodiment, the dynamic resource allocator includes a state space and an action space;

[0117] The dimension of the state space includes microservice queue depth, container resource utilization rate, and network latency;

[0118] The dimension of the action space includes CPU core binding policy, memory dynamic expansion policy, and microservice elastic scaling control policy.

[0119] The elastic scaling control policy includes:

[0120] Scaling factor = (current load - baseline) / (predicted peak - baseline)

[0121] IF scaling factor > θ_scale_up; trigger horizontal expansion (number of new instances = ceil(current instances × scaling factor))

[0122] ELIF scaling factor < θ_scale_down; perform safe scaling down (retain N instances: N ≥ min_instances + safety margin)

[0123] The baseline value can be predicted by the Holt-Winters algorithm, θ_scale_up can be 0.75; θ_scale_down can be 0.35.

[0124] 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:

[0125] The dynamic resource allocator generates an initial strategy model based on the expert scheduling strategy;

[0126] Using an imitation learning pre-training mechanism to train the initial strategy model to obtain a first strategy model;

[0127] The trained first strategy model is optimized by using a Q-learning algorithm to obtain a second strategy model;

[0128] 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.

[0129] The scheduling weight is exemplarily expressed as:

[0130]

[0131] 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.

[0132] For example, the beauty and catering business collaboration scenario: During the lunchtime catering peak period:

[0133] 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).

[0134] 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.

[0135] Table 1 Core technical indicators

[0136]

[0137] 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.

[0138] Through the construction of a dynamic modular service framework based on pluggable service components, the present invention can accurately load and unload each business module of microservices within milliseconds, significantly improving the agility of the system. In a multi-business and multi-tenant environment, the dynamic modular service framework can ensure the isolation of business data and logic between tenants, guaranteeing data security and privacy. At the same time, on the premise of ensuring secure isolation between tenants, it supports resource sharing of business modules, supports dynamic borrowing of business modules between different tenants, and improves resource utilization. By modeling the call relationships of cross-tenant business modules, clearly showing the dependency relationships and interaction processes between business modules, and calculating the resource demand weight coefficients, it provides basic data for resource scheduling. Furthermore, the dynamic resource allocator also considers changes in load, dynamically adjusts resource allocation, realizes the optimal configuration of resources, and improves the overall performance and response speed of the system.

[0139] Embodiment 2

[0140] A microservice system for multi-business and multi-tenant scenarios, comprising:

[0141] A construction module: constructing a dynamic modular service framework based on pluggable service components, the dynamic modular service framework supporting the dynamic loading and unloading of each microservice, supporting isolation between tenants and resource sharing of cross-tenant business modules in a multi-business and multi-tenant environment;

[0142] A calculation module: based on cross-tenant business modules with resource sharing, modeling the call relationships between microservices and calculating the resource demand weight coefficients of each microservice;

[0143] A scheduling module: according to the resource demand weight coefficients and load of microservices, using a dynamic resource allocator to schedule cross-tenant business modules with resource sharing.

[0144] It should be understood that the above specific embodiments of the present invention are only used for exemplary illustration or explanation of the principles of the present invention, and do not constitute a limitation to the present invention. Therefore, any modifications, equivalent replacements, improvements, etc. made without departing from the spirit and scope of the present invention should be included within the protection scope of the present invention. In addition, the appended claims of the present invention are intended to cover all changes and modification examples falling within the scope and boundaries of the appended claims, or equivalent forms of such scope and boundaries.

[0145] The present invention has been described above with reference to the embodiments of the present invention. However, these embodiments are only for illustrative purposes and not for limiting 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, those skilled in the art can make various substitutions and modifications, and these substitutions and modifications should all fall within the scope of the present invention.

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

[0147] Obviously, the above embodiments are merely examples given for clear illustration and are not limitations on the embodiments. For those of ordinary skill in the art, other different forms of changes or alterations can be made based on the above description. It is not necessary and impossible to enumerate all the embodiments here. And the obvious changes or alterations derived therefrom are still within the protection scope of the present invention.

Claims

1. A microservice method for multiple services and multiple tenants, characterized in that, Including: Construct a dynamic modular service framework based on pluggable service components. The dynamic modular service framework supports the dynamic loading and unloading of business modules of each microservice, and supports the isolation between tenants and the resource sharing of cross-tenant business modules in a multi-business and multi-tenant environment; Based on the cross-tenant business module with resource sharing, model the call relationship between microservices and calculate the weight coefficients of various resource requirements of microservices; According to the weight coefficients of various resource requirements and the load of microservices, use a dynamic resource allocator to schedule the cross-tenant business module with resource sharing; The resource sharing of the cross-tenant business module includes: Extract the characteristics of business modules of different tenants, and the characteristics include interface characteristics, data model characteristics, business process characteristics, and resource consumption characteristics; Perform hierarchical clustering and similarity calculation on the characteristics, and determine the shared candidate set of business modules of different tenants according to the sharing threshold; The shared candidate set includes business modules that can share resources.

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

3. The microservice method for multi-service and multi-tenant according to claim 1, characterized in that The dynamic modular service framework also supports cross-language calls, and the cross-language calls are realized by constructing a standardized service gateway, converting heterogeneous APIs into unified RESTful interfaces, and embedding a gRPC protocol conversion middleware.

4. The microservice method for multi-service and multi-tenant according to claim 1, characterized in that The isolation includes: constructing a trusted execution environment through Intel SGX, and sensitive business modules run 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 microservice method for multiple services and multiple tenants according to claim 1, wherein The modeling of the call relationship between microservices includes: Using a graph convolutional neural network, based on the cross-tenant business module with resource sharing, model the call relationship between microservices to obtain a service topology prediction model, and the service topology prediction model is represented as a topology graph of the call relationship and dependency relationship of the cross-tenant business modules that can share resources of each microservice in the microservice link; Offline, train the service topology prediction model using historical data; Online, use an elastic weight consolidation algorithm to adjust the service topology prediction model.

6. The microservice method for multi-service and multi-tenant according to claim 5, characterized in that The calculation of the weight coefficients of various resource requirements of microservices includes: Real-time collect the feature vectors of business requests of each microservice and the runtime metrics corresponding to the business requests of each microservice in the microservice link, and the runtime metrics include response latency, error rate, and resource utilization rate; According to the topology graph, obtain the position vectors of the cross-tenant business modules that can share resources of each microservice in the microservice link; Input the position vector, the feature vector of the business request, and the runtime metrics into the Transformer algorithm to calculate the attention weights of the business modules of each microservice; Calculate the weight coefficients of the resource requirements of each microservice according to the attention weights.

7. The microservice method for multiple services and multiple tenants 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 the microservice queue depth, container resource utilization rate, and network latency; The dimensions of the action space include the CPU core binding policy, memory dynamic expansion policy, and microservice elastic scaling control policy.

8. The microservice method for multi-service and multi-tenant according to claim 1, characterized in that, The scheduling of the cross-tenant service module with resource sharing according to the weight coefficients of the resource requirements of each microservice and the load, using the dynamic resource allocator includes: The dynamic resource allocator generates an initial policy model based on the expert scheduling strategy; Adopt an imitation learning pre-training mechanism to train the initial policy model to obtain a first policy model; Use the Q-learning algorithm to optimize the trained first policy model to obtain a second policy model; According to the weight coefficients of the resource requirements of each microservice and the load, use the second policy model to schedule the cross-tenant service module with resource sharing.

9. A system applying the microservices method for multiple services and multiple tenants according to claim 1, characterized in that, It includes: Construction module: Construct a dynamic modular service framework based on pluggable service components. The dynamic modular service framework supports the dynamic loading and unloading of each microservice, supports the isolation between tenants and the resource sharing of cross-tenant service modules in a multi-service and multi-tenant environment; Calculation module: Based on the cross-tenant service module with resource sharing, model the call relationship between microservices and calculate the weight coefficients of the resource requirements of each microservice; Scheduling module: According to the weight coefficients of the resource requirements of each microservice and the load, use the dynamic resource allocator to schedule the cross-tenant service module with resource sharing.

Images