Low-code process platform micro-service elastic scaling method and system

Abstract

The invention discloses a low-code process platform micro-service elastic scaling method and system, and belongs to the field of low-code development, and the method comprises the steps: splitting a low-code process platform into a plurality of micro-services, and distributing a unique identifier for each micro-service; for each micro-service, collecting a plurality of preset load indexes, and calculating a real-time load level of each micro-service in combination with a preset weight of each load index in each micro-service; according to the real-time load level within the preset statistical duration, obtaining the future traffic trend of each micro-service; and according to the future traffic trend of each micro-service, adjusting the number of nodes Node, service instances Pod, threads and / or connections of each micro-service. According to the application, the future traffic trend of the micro-service is evaluated by multiple load indexes, and more targeted elastic scaling is carried out with smaller granularity, so that the accuracy and timeliness of elastic scaling are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of low-code development, in particular to a low-code process platform micro-service elasticity scaling method and system. BACKGROUND

[0002] With the deepening of enterprise digital transformation, low-code platforms have been widely used due to their efficient and convenient development characteristics. As an important part of low-code platforms, low-code process platforms are responsible for handling various business processes within enterprises. However, traditional low-code process platforms usually adopt monolithic architecture or limited micro-service splitting, which is difficult to cope with complex scenarios such as high concurrency and large data volume.

[0003] Currently, there have been some research and practice focusing on the elasticity scaling of micro-service architecture. For example, container orchestration technologies such as Kubernetes provide powerful elasticity scaling capabilities, which can automatically adjust the number of Pods according to the load of the application. However, these technologies mainly focus on the elasticity scaling of general micro-services, and lack optimization for the characteristics of low-code process platforms.

[0004] In summary, the existing technology mainly has the following defects: The elasticity scaling strategy is single, and the existing technology usually uses a single CPU or memory utilization as the index for elasticity scaling, which cannot accurately reflect the load of the low-code process platform. For example, some processes may involve a large number of I / O operations, at which time the CPU utilization may not be high, but the system is already in an overload state.

[0005] The elasticity scaling granularity is too coarse, and the existing technology usually performs elasticity scaling in units of Pods, which has a coarse granularity and cannot make fine adjustments to specific services or components in the low-code process platform. For example, a process engine instance may only need to increase a small number of threads to cope with the load peak, but the existing technology needs to increase the entire Pod, causing resource waste.

[0006] The elasticity scaling speed is slow, and the elasticity scaling process of the existing technology usually takes a long time, which cannot timely cope with sudden traffic peaks. For example, the startup and initialization of a Pod takes a certain amount of time, which may cause performance bottlenecks during the load peak. SUMMARY

[0007] The present application provides a low-code process platform micro-service elasticity scaling method and system, which can solve the technical problem of single elasticity scaling strategy of micro-service architecture in the prior art, and improve the accuracy and timeliness.

[0008] In a first aspect, the embodiments of the present application provide a low-code process platform micro-service elasticity scaling method, which comprises: Split the low-code process platform into multiple microservices; For each microservice, collect multiple preset load indicators respectively, and combine the preset weight of each load indicator in each microservice to calculate the real-time load level of each microservice; According to the real-time load level in the preset statistical time length, the future traffic trend of each microservice is obtained; According to the future traffic trend of each microservice, the number of nodes Node, service instances Pod, threads, and / or connections of each microservice is adjusted.

[0009] In combination with the first aspect, in an implementation manner, the multiple preset load indicators include one or any combination of CPU utilization, memory utilization, I / O load, number of requests, and response time.

[0010] In combination with the first aspect, in an implementation manner, the method comprises: The weight of each load indicator of each microservice is configured in advance, the weight of the memory utilization of the cache microservice is set to the maximum, the weight of the CPU utilization of the process microservice is set to the maximum, and the weight of the I / O load of the message queue microservice is set to the maximum.

[0011] In combination with the first aspect, in an implementation manner, the real-time load level includes a total load level, a main load level, and an associated load level; and the calculation of the real-time load level of each microservice specifically comprises the following steps: For all time points in the preset statistical time length, the total load level, the main load level, and the associated load level of the microservice are calculated respectively, the total load level is obtained by weighted summation of all load indicators, the main load level is calculated based on the load indicator with the maximum weight, and the associated load level includes single-body load levels calculated based on multiple load indicators with an association relationship.

[0012] In combination with the first aspect, in an implementation manner, the method further comprises: According to the future traffic trend and the adjustment content of the microservice, the resources associated with the adjustment content are pre-warmed.

[0013] Secondly, the embodiments of the present application provide a low-code process platform microservice elasticity scaling system, which comprises: The configuration module is configured to split the low-code process platform into multiple microservices; The collection module is configured to collect multiple preset load indicators for each microservice respectively, and combine the preset weight of each load indicator in each microservice to calculate the real-time load level of each microservice; an analysis module configured to obtain a future traffic trend of each microservice according to a real-time load level within a preset statistical time length; a processing module configured to pre-adjust a number of nodes, service instance pods, threads, and / or connections of each microservice according to the future traffic trend of each microservice.

[0014] In combination with the second aspect, in an implementation, the plurality of preset load indicators include one or any combination of CPU utilization, memory utilization, I / O load, number of requests, and response time.

[0015] In combination with the second aspect, in an implementation, the configuration module is further configured to pre-configure a weight of each load indicator of each microservice, set the weight of the memory utilization of the cache microservice to be the maximum, set the weight of the CPU utilization of the flow microservice to be the maximum, and set the weight of the I / O load of the message queue microservice to be the maximum.

[0016] In combination with the second aspect, in an implementation, the real-time load level includes an overall load level, a main load level, and an associated load level; when the collection module calculates the real-time load level of each microservice, the overall load level, the main load level, and the associated load level of the microservice are respectively calculated for all time points within the preset statistical time length, the overall load level is obtained by weighted summation of all load indicators, the main load level is calculated based on the load indicator with the maximum weight, and the associated load level includes a single-body load level calculated based on a plurality of load indicators having an association relationship.

[0017] In combination with the second aspect, in an implementation, the processing module is further configured to pre-warm resources associated with the adjustment content according to the future traffic trend and the adjustment content of the microservice.

[0018] The technical scheme provided by the embodiments of the present application has the beneficial effects of: The future traffic trend of the microservice is evaluated by using a plurality of load indicators, and the elastic scaling is more targeted with a smaller granularity, thereby improving the accuracy and timeliness of the elastic scaling. BRIEF DESCRIPTION OF DRAWINGS

[0019] Figure 1 a flowchart of an embodiment of a low-code process platform microservice elastic scaling method of the present application; Figure 2 a functional module schematic diagram of an embodiment of a low-code process platform microservice elastic scaling system of the present application. DETAILED DESCRIPTION

[0020] In order to enable those skilled in the art to better understand the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the 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 this application.

[0021] In order to make the objectives, technical solutions and advantages of this application clearer, the implementation methods of this application will be further described in detail below with reference to the accompanying drawings.

[0022] In a first aspect, an embodiment of the present application provides a low-code process platform microservice elastic scaling method.

[0023] In one embodiment, referring to Figure 1 , Figure 1 This is a flow chart of an embodiment of the low-code process platform microservice elastic scaling method of this application. Figure 1 As shown in the figure, the elastic scaling methods of microservices in the low-code process platform include: Step S1: Split the low-code process platform into multiple microservices.

[0024] Step S2: For each microservice, collect multiple preset load indicators respectively, and calculate the real-time load level of each microservice by combining the preset weight of each load indicator in each microservice. Step S3: Obtain the future traffic trend of each microservice based on the real-time load level within the preset statistical time period.

[0025] Step S4: Adjust the number of nodes, pods, threads, and / or connections for each microservice based on the future traffic trend of each microservice.

[0026] In this embodiment, multiple load indicators are comprehensively considered, and a weight parameter is added to each load indicator. The weight is used to represent the degree of influence of the load indicator on the load level of the microservice. The real-time load level is calculated by combining all the load indicators of the microservice and the corresponding weights, which more accurately reflects the load situation of the low-code process platform and improves the accuracy of elastic scaling.

[0027] Since different load indicators require different microservice resources, the scarcity of various microservice resources can be determined based on future traffic trends. Scarce resources can be expanded and non-scarce resources can be contracted, thereby achieving the goal of elastic scaling at a smaller granularity, utilizing resources more efficiently, and avoiding waste.

[0028] Compared with the scaling operation in the prior art in a unit of a Pod, the application selects a contraction unit in a targeted manner in combination with future traffic trends, so that the contraction operation closely matches the demand, the time of the elastic scaling process is shortened, sudden traffic peaks are responded to in a timely manner, and the stability and reliability of the system are ensured.

[0029] In one specific embodiment, the low-code process platform is split into multiple microservices, such as a process engine service, a task management service, and a form service. Each microservice is assigned a unique identifier, and its dependency relationship is recorded.

[0030] Various load indicators of each microservice are collected, such as CPU utilization, memory utilization, I / O load, number of requests, and response time.

[0031] Based on the multi-dimensional load indicators, different elastic scaling strategies are adopted according to the characteristics of different microservices. In addition, based on historical data and real-time load conditions, future traffic trends are predicted, and elastic scaling is performed in advance. The situations that require elastic scaling in advance include predictable traffic peaks, long expansion time, and services sensitive to delay.

[0032] The traffic peaks in scenarios such as promotion activities of e-commerce platforms, holidays, and hot news events can usually be predicted in advance. Based on various load indicators and weights involved in these scenarios, future traffic is predicted, and resources associated with large weights and large load indicators in these scenarios are prepared in advance.

[0033] The expansion process of some microservices (such as starting new virtual machines / containers, application initialization, and data synchronization) requires a certain time. If the expansion time exceeds the traffic growth rate, the resources associated with the load indicators whose expansion time exceeds the traffic growth rate need to be prepared in advance.

[0034] For microservices that are very sensitive to delay (such as online payment and real-time transactions), in order to ensure service quality, expansion needs to be performed in advance, and sufficient resources need to be reserved, that is, resources associated with load indicators that affect delay need to be prepared in advance. The aforementioned advance time is not fixed and needs to be dynamically adjusted according to actual conditions to achieve the best elastic scaling effect and resource utilization.

[0035] Further, in one embodiment, the aforementioned multiple preset load indicators include one or any combination of CPU utilization, memory utilization, I / O load, number of requests, and response time.

[0036] The weight of the memory utilization of the cache microservice is set to the maximum, the weight of the CPU utilization of the process microservice is set to the maximum, and the weight of the I / O load of the message queue microservice is set to the maximum.

[0037] In this embodiment, different microservices need to use different elastic scaling algorithms to achieve the best effect due to differences in functions, business characteristics, and resource consumption modes.

[0038] CPU-intensive microservices (such as image processing, video transcoding, and scientific computing) have high CPU consumption and high demand for CPU resources, and are scaled according to a CPU usage threshold.

[0039] IO-intensive microservices (such as databases, caches, and message queues) have high disk IO and network IO consumption and high requirements for IO performance, and are scaled according to an IO delay threshold and a queue length threshold.

[0040] Memory-intensive microservices (such as cache services and big data analysis) have high memory consumption and high demand for memory resources, and are scaled according to a memory usage threshold and memory reclamation pressure.

[0041] Further, in an embodiment, the real-time load level includes a total load level, a main load level, and an associated load level. Calculating the real-time load level of each microservice includes the following steps: For all time points within a preset statistical time length, the total load level, the main load level, and the associated load level of the microservice are calculated respectively. The total load level is obtained by weighted summation of all load indicators. The main load level is calculated based on the load indicator with the maximum weight. The associated load level includes single-body load levels calculated based on multiple load indicators having an association relationship.

[0042] In this embodiment, the number of Nodes, Pods, threads, and connections can be adjusted according to the total load level.

[0043] The number of Nodes, Pods, threads, and connections can be adjusted in combination with the total load level and the main load level, and the influence of the main load level on the number adjustment target is increased during the analysis.

[0044] The number adjustment target of a node, a pod, a thread, and a connection can be analyzed in combination with the overall load level, the subject load level, and the associated load level, and when analyzing, the influence of the subject load level on the number adjustment target is increased, and the number adjustment target of the corresponding resource of the load index with the association relationship is coordinated, for example, the load index a corresponds to the resource A, A is CPU, the load index b corresponds to the resource B, B is memory, for the micro service, according to the future traffic prediction, it is necessary to increase the resource A and at the same time reduce all other resources including the resource B, and the A growth will finally cause the B to grow, at this time, the growth rate of A needs to be coordinated, so that the resource after the elastic scaling meets the overall demand.

[0045] Further, in an embodiment, the method further comprises: According to the future traffic trend and the adjustment content of the micro service, the resources associated with the adjustment content are pre-warmed.

[0046] In this embodiment, the core idea of the pre-warming technology is to perform necessary initialization work in advance before the service instance formally provides services to the outside, so as to reduce the cold start time. It includes application code preloading and precompilation, dependent component pre-initialization, core data or configuration preloading, and cache pre-warming.

[0047] Taking the cache technology as an example, the cache technology is not only used for pre-warming, but also can be used throughout multiple links of the elastic scaling process to accelerate configuration loading and data access. It includes caching the configuration information (such as database connection information, service parameters, etc.) of the process engine to the local memory or distributed cache, reducing the delay of pulling the configuration from the configuration center each time the service starts or the configuration is updated. Cache the commonly used process definition in the memory to avoid re-parsing the process definition each time the process instance is executed. Cache the metadata of the process instance, task metadata, etc. to accelerate the process state query and task operation.

[0048] By applying the cache technology to the key links of the elastic scaling process and using it in combination with the pre-warming technology, pre-resource preparation, etc., a complete fast elastic scaling solution is formed. For example, a cache strategy specially designed for accelerating the scaling process can be designed, for example, which data to load and cache first in the scaling process to maximize the acceleration effect.

[0049] In a specific embodiment, when fine-grained elastic scaling (such as adjusting the number of threads and connections) is performed, since no new instance needs to be added, the scaling time itself is relatively short. At this time, the focus of fast elastic scaling can be placed on ensuring that the configuration changes take effect quickly, for example, by pushing the changes through the configuration center and quickly applying them to the running instances.

[0050] The pre-advance warm-up strategy can predict load changes and trigger elastic scaling in advance. In combination with the fast elastic scaling technology, capacity expansion can be completed more timely before the load peak arrives, avoiding insufficient service capacity.

[0051] For different granularity scaling operations, different fast scaling strategies can be adopted. For example, instance-level expansion can rely more on the reserved resource pool technology, while thread number adjustment relies more on the configuration fast-acting mechanism.

[0052] In a second aspect, the embodiments of the present application also provide a low-code process platform micro-service elastic scaling system.

[0053] In an embodiment, with reference to Figure 2 , Figure 2 The figure is a functional module diagram of an embodiment of the low-code process platform micro-service elastic scaling system of the present application. As shown in the figure, the low-code process platform micro-service elastic scaling system comprises: Figure 2 A configuration module 1 is configured to split the low-code process platform into multiple micro-services and assign a unique identifier to each micro-service.

[0054] A collection module 2 is configured to collect multiple preset load indicators for each micro-service and calculate the real-time load level of each micro-service in combination with the preset weight of each load indicator in each micro-service. An analysis module 3 is configured to obtain the future traffic trend of each micro-service according to the real-time load level within the preset statistical time length.

[0055] A processing module 4 is configured to pre-adjust the number of nodes Node, service instances Pod, threads, and / or connections for each micro-service according to the traffic trend of each future micro-service.

[0056] In the embodiment, multiple load indicators are considered comprehensively, and a weight parameter is added to each load indicator to represent the influence degree of the load indicator on the micro-service load level. The real-time load level is calculated in combination with all load indicators and corresponding weights of the micro-service, which more accurately reflects the load condition of the low-code process platform and improves the accuracy of elastic scaling.

[0057] Since different load indicators require different micro-service resources, the degree of shortage of various micro-service resources can be known according to the future traffic trend, the shortage resources are expanded, and the non-shortage resources are contracted, so as to achieve the purpose of elastic scaling with smaller granularity, more effectively utilize resources, and avoid waste.

[0058] ​Compared with the scaling operation in the prior art in a Pod unit, the application selects a contraction unit in a targeted manner in combination with future traffic trends, so that the contraction operation closely matches the demand, the time of the elastic scaling process is shortened, sudden traffic peaks are responded to in a timely manner, and the stability and reliability of the system are ensured.

[0059] Further, in an embodiment, the plurality of preset load indicators include one or any combination of CPU utilization, memory utilization, I / O load, request number, and response time.

[0060] In the embodiment, different microservices need to use different elastic scaling algorithms to achieve the best effect due to differences in their functions, business characteristics, and resource consumption modes.

[0061] CPU-intensive microservices (such as image processing, video transcoding, and scientific computing) have high CPU consumption and high demand for CPU resources, and are scaled according to a CPU usage threshold.

[0062] IO-intensive microservices (such as databases, caches, and message queues) have high disk IO and network IO consumption and high requirements for IO performance, and are scaled according to an IO delay threshold and a queue length threshold.

[0063] Memory-intensive microservices (such as cache services and big data analysis) have high memory consumption and high demand for memory resources, and are scaled according to a memory usage threshold and memory recovery pressure.

[0064] Further, in an embodiment, the configuration module 1 is further configured to pre-configure the weight of each load indicator for each microservice, set the weight of the memory utilization of the cache microservice to be the maximum, set the weight of the CPU utilization of the flow microservice to be the maximum, and set the weight of the I / O load of the message queue microservice to be the maximum.

[0065] Further, in an embodiment, the real-time load level includes a total load level, a main load level, and an associated load level. When the collection module 2 calculates the real-time load level of each microservice, the total load level, the main load level, and the associated load level of the microservice are calculated for all time points within a preset statistical time period, the total load level is obtained by weighted summation of all load indicators, the main load level is calculated based on the load indicator with the maximum weight, and the associated load level includes single-body load levels calculated based on a plurality of load indicators having an association relationship.

[0066] In the embodiment, the number of nodes, pods, threads, and connections can be adjusted according to the total load level.

[0067] The quantity adjustment target of Node, Pod, thread, and connection can be analyzed in combination with the overall load level and the subject load level, and the influence of the subject load level on the quantity adjustment target is increased during the analysis.

[0068] The quantity adjustment target of Node, Pod, thread, and connection can be analyzed in combination with the overall load level, the subject load level, and the associated load level, and the influence of the subject load level on the quantity adjustment target is increased during the analysis, and the quantity adjustment target of the resource corresponding to the load index with the association relationship is coordinated, for example, the load index a corresponds to the resource A, A is CPU, the load index b corresponds to the resource B, B is memory, for the micro service, according to the future traffic prediction, it is necessary to increase the resource A and at the same time reduce all other resources including the resource B, and the growth of A will eventually lead to the growth of B, at this time, it is necessary to coordinate the growth rate of A, so that the resource after the elastic scaling meets the overall demand.

[0069] Further, in an embodiment, the processing module 4 is further configured to preheat the resource associated with the adjustment content according to the future traffic trend and the adjustment content of the micro service.

[0070] In this embodiment, the core idea of the preheating technology is to perform necessary initialization work in advance before the service instance formally provides services to the outside, so as to reduce the cold start time. It includes application code preloading and precompilation, dependent component preinitialization, core data or configuration preloading, and cache preheating.

[0071] Taking the cache technology as an example, the cache technology is not only used for preheating, but also can be used throughout multiple links of the elastic scaling process to accelerate configuration loading and data access. It includes caching the configuration information (such as database connection information, service parameters, etc.) of the process engine to the local memory or distributed cache, reducing the delay of pulling the configuration from the configuration center each time the service is started or the configuration is updated. Cache the commonly used process definition in the memory to avoid re-parsing the process definition each time the process instance is executed. Cache the metadata of the process instance, task metadata, etc. to accelerate the process state query and task operation.

[0072] By applying the cache technology to the key links of the elastic scaling process and using it in combination with the preheating technology, pre-resource preparation, etc., a complete fast elastic scaling solution is formed. For example, a cache strategy specially designed for accelerating the scaling process can be designed, such as which data to load and cache first during the scaling process to maximize the acceleration effect.

[0073] In one specific embodiment, when fine-tuning elasticity (e.g., adjusting the number of threads, the number of connections) is performed, the scaling time itself is short because no new instance needs to be added. At this time, the focus of fast elasticity can be placed on ensuring that the configuration change takes effect quickly, for example, by pushing the change through the configuration center and quickly applying it to the running instance.

[0074] The pre-warming strategy can predict load changes and trigger elasticity in advance. Combined with fast elasticity technology, capacity expansion can be completed more timely before the load peak arrives, avoiding insufficient service capacity.

[0075] For different granularity scaling operations, different fast scaling strategies can be used. For example, instance-level expansion may rely more on the reserved resource pool technology, while thread number adjustment relies more on the configuration fast effect mechanism.

[0076] Among them, the function implementation of each module in the low-code process platform micro-service elasticity scaling system described above corresponds to each step in the low-code process platform micro-service elasticity scaling method embodiment described above, and its functions and implementation processes will not be repeated here.

[0077] It should be noted that the sequence numbers of the embodiments of the application described above are only for description, and do not represent the advantages and disadvantages of the embodiments.

[0078] The terms "comprise" and "have" and any variations thereof in the specification and claims of the present application and the above drawings are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device that includes a series of steps or units is not limited to the listed steps or units, but can optionally include steps or units not listed, or can optionally include other steps or units inherent to these processes, methods, products or devices. The terms "first", "second" and "third" and the like descriptions are used to distinguish different objects, etc., and do not represent the order of sequence, nor limit the "first", "second" and "third" to be different types.

[0079] In the description of the embodiments of the present application, "exemplary", "for example" or "for instance" is used to represent as an example, illustration or description. Any embodiment or design scheme described as "exemplary", "for example" or "for instance" in the embodiments of the present application should not be interpreted as more preferred or more advantageous than other embodiments or design schemes. Rather, the words "exemplary", "for example" or "for instance" are intended to present the relevant concept in a specific manner.

[0080] In the description of the embodiments of the present application, unless otherwise specified, " / " means the meaning of or, for example, A / B can mean A or B. The "and / or" in the text only describes the association relationship of the associated objects, which means that there can be three relationships, for example, A and / or B, which can represent: A exists alone, A and B exist together, and B exists alone. In addition, in the description of the embodiments of the present application, "multiple" means two or more than two.

[0081] In some processes described in the embodiments of the present application, a plurality of operations or steps are included in a specific order, but it should be understood that these operations or steps can be executed or executed in parallel without the order in which they appear in the embodiments of the present application. The serial number of the operation is only used to distinguish different operations, and the serial number itself does not represent any execution order. In addition, these processes can include more or fewer operations, and these operations or steps can be executed in sequence or in parallel, and these operations or steps can be combined.

[0082] From the above description of the embodiments, those skilled in the art can clearly understand that the above-mentioned embodiment method can be realized by means of software and the necessary general hardware platform, of course, it can also be realized by hardware, but in many cases the former is the better embodiment. Based on such understanding, the technical solutions of the present application can be embodied in the form of a software product, which is stored in a storage medium such as a ROM / RAM, a magnetic disk, an optical disk, etc., and includes a plurality of instructions for making a terminal device execute the above-mentioned method of each embodiment of the present application.

[0083] The above is only the preferred embodiment of the present application, and does not limit the patent scope of the present application, and any equivalent structure or equivalent process transformation using the content of the present application specification and drawings, or direct or indirect application in other related technical fields, are also included in the patent protection scope of the present application.

Claims

1. A low-code process platform microservice elasticity scaling method, characterized in that, The method comprises: splitting a low-code process platform into multiple microservices; for each microservice, collecting multiple preset load indicators respectively, and combining the preset weight of each load indicator in each microservice to calculate the real-time load level of each microservice; obtaining the future traffic trend of each microservice according to the real-time load level within the preset statistical duration; adjusting the number of nodes, service instances, threads, and / or connections of each microservice according to the future traffic trend of each microservice.

2. The low-code flow platform microservices elasticity scaling method of claim 1, wherein, The multiple preset load indicators include one or any combination of CPU utilization, memory utilization, I / O load, number of requests, and response time.

3. The low-code flow platform microservice elasticity scaling method of claim 2, wherein, The method comprises: pre-configuring the weight of each load indicator of each microservice, setting the weight of the memory utilization of the cache microservice to the maximum, setting the weight of the CPU utilization of the process microservice to the maximum, and setting the weight of the I / O load of the message queue microservice to the maximum.

4. The low-code flow platform microservices elasticity scaling method of claim 1, wherein, The real-time load level includes overall load level, main load level, and associated load level; the calculation of the real-time load level of each microservice specifically comprises the following steps: for all time points within the preset statistical duration, the overall load level, the main load level, and the associated load level of the microservice are calculated respectively, the overall load level is obtained by weighted summation of all load indicators, the main load level is calculated based on the load indicator with the maximum weight, and the associated load level includes single-body load levels calculated based on multiple load indicators with an association relationship.

5. The low-code process platform microservice elastic scaling system according to claim 1, characterized in that: The method further comprises: According to the future traffic trend and the adjustment content of the microservice, the resources associated with the adjustment content are pre-warmed.

6. A low-code process platform microservice elasticity scaling system, characterized in that, The system comprises: a configuration module for splitting a low-code process platform into multiple microservices; a collection module for collecting multiple preset load indicators for each microservice respectively, and combining the preset weight of each load indicator in each microservice to calculate the real-time load level of each microservice; an analysis module for obtaining the future traffic trend of each microservice according to the real-time load level within the preset statistical duration; a processing module for pre-adjusting the number of nodes, service instances, threads, and / or connections of each microservice according to the future traffic trend of each microservice.

7. The low-code flow platform microservices elasticity system of claim 6, wherein, The multiple preset load indicators include one or any combination of CPU utilization, memory utilization, I / O load, number of requests, and response time.

8. The low-code flow platform microservices elasticity system of claim 7, wherein, The configuration module is further used to pre-configure the weight of each load indicator of each microservice, set the weight of the memory utilization of the cache microservice to the maximum, set the weight of the CPU utilization of the process microservice to the maximum, and set the weight of the I / O load of the message queue microservice to the maximum.

9. The low-code flow platform microservices elasticity system of claim 6, wherein, The real-time load level includes a total load level, a subject load level, and an associated load level; when the collection module calculates the real-time load level of each microservice, the total load level, the subject load level, and the associated load level of the microservice are calculated respectively for all time points within a preset statistical time length, the total load level is obtained by weighted summation of all load indicators, the subject load level is calculated based on the load indicator with the largest weight, and the associated load level includes single-body load levels calculated based on multiple load indicators with an association relationship respectively.

10. The low-code flow platform microservices elasticity system of claim 6, wherein, The processing module is further configured to pre-warm resources associated with the adjustment content according to the future traffic trend and the adjustment content of the microservice.

Images