System lightweight reconfiguration methods and related equipment

Abstract

This application provides a lightweight system refactoring method and related equipment. The method includes: determining the coupling degree between a first microservice and a second microservice based on at least one parameter between them; determining the resource reduction after merging the first and second microservices; and determining X target microservice groups based on multiple coupling degrees and multiple resource reductions between any two microservices in a plurality of microservices. When X is greater than 0, the microservices in each of the X target microservice groups are merged separately, where X is an integer greater than or equal to 0. Using the method provided in this application, it is possible to accurately identify target microservice groups that are tightly coupled and show significant resource savings after merging. Subsequently, microservices in the system can be efficiently integrated accordingly, improving resource utilization and reducing the complexity of the system structure and the burden of operation and maintenance.

Description

Technical Field

[0001] This application relates to the field of lightweight system reconfiguration technology, and in particular to a lightweight system reconfiguration method and related equipment. Background Technology

[0002] As information systems continue to evolve, business applications have gradually evolved from monolithic architectures to distributed and cloud-native architectures. Microservice architecture has been widely adopted due to its advantages such as loose coupling and independent deployment. To support the parallel operation of multiple services and functional decoupling, systems typically need to break down different business functions into numerous microservice modules to enable independent operation and elastic scaling of each module.

[0003] Currently, as the system scale continues to increase, the business scale and deployment scope also increase accordingly, leading to a surge in the number of microservice modules in the system. A large number of microservice modules not only consume significant computing and storage resources, but also make the call relationships and data dependencies between services within the system intricate and complex, significantly increasing the difficulty of operation, maintenance, monitoring, and scheduling.

[0004] Currently, in response to the problems caused by the proliferation of microservice modules, existing integration methods usually rely on manual experience to determine which microservices can be merged. This lacks a systematic and quantifiable merging decision-making mechanism, making it difficult to achieve efficient integration and resulting in low resource utilization, complex system structure, and heavy operation and maintenance burden. Summary of the Invention

[0005] In view of this, this application provides a system lightweight refactoring method and related equipment, which can accurately identify target microservice groups that are tightly coupled and have significant resource savings after merging, and then efficiently integrate the microservices in the system accordingly, improve resource utilization, and reduce the complexity of the system structure and the burden of operation and maintenance.

[0006] In a first aspect, embodiments of this application provide a system lightweight reconfiguration method, the method comprising: The coupling degree between the first microservice and the second microservice is determined based on at least one parameter between the first microservice and the second microservice, wherein each parameter is a parameter characterizing the interrelationship between the first microservice and the second microservice during runtime, and the first microservice and the second microservice are any two different microservices among a plurality of microservices included in the system. Determine the resource reduction amount after merging the first microservice and the second microservice; Based on multiple coupling degrees and multiple resource reductions between any two microservices, X target microservice groups are determined. When X is greater than 0, the microservices in each of the X target microservice groups are merged. X is an integer greater than or equal to 0.

[0007] Therefore, in the embodiments of this application, by introducing parameters characterizing the runtime interrelationships between microservices, the coupling degree between microservices is quantitatively calculated, and combined with the expected reduction in resources after merging, the target microservice group for merging is determined. Compared to relying on manual experience, this method can accurately identify tightly coupled microservice pairs that will result in significant resource savings after merging, and determine the target microservice group for merging, achieving quantifiable and systematic rapid decision-making. This effectively reduces the number of microservice modules in the system, improves resource utilization, and reduces the complexity of the system structure and the burden of operation and maintenance.

[0008] In conjunction with the first aspect, in one possible implementation, the at least one parameter includes: The parameter for the number of calls between the first microservice and the second microservice; The shared data ratio parameter between the first microservice and the second microservice; The resource overlap ratio parameter between the first microservice and the second microservice.

[0009] It is evident that by comprehensively evaluating the degree of correlation between microservices from three dimensions—number of calls, proportion of shared data, and proportion of resource overlap—the coupling degree calculation can reflect the actual degree of interaction, data dependence, and resource contention of microservices at runtime from multiple perspectives. This avoids the one-sided judgment that may be caused by a single indicator, making the coupling degree calculation results more consistent with the actual operating state of the system, thereby improving the rationality and reliability of the merging decision.

[0010] In conjunction with the first aspect, in one possible implementation, determining X target microservice groups based on multiple coupling degrees and multiple resource reductions between any two microservices among the plurality of microservices includes: Arrange the multiple resource reduction amounts in descending order to obtain the first sequence; Obtain the first Y resource reduction amounts in the first sequence, where Y is an integer greater than or equal to 1; Based on a first threshold and Y first coupling degrees, Z second microservice pairs are determined from the Y first microservice pairs, wherein the Y first microservice pairs are the microservice pairs corresponding to the first Y resource reduction amounts, the Y first coupling degrees are the coupling degrees of the Y first microservice pairs, and Z is an integer greater than or equal to 1; The X target microservice groups are determined based on the Z second microservice pairs.

[0011] As can be seen, by combining resource reduction ranking with coupling degree threshold comparison, a progressive microservice pair selection process is constructed. Based on resource reduction, a set of candidate microservice pairs with significant potential for resource savings after merging is identified. Then, a second screening of these candidate microservice pairs is performed using the coupling degree threshold. This process ensures that while prioritizing resource savings, it also considers the closeness of the relationships between microservice pairs, guaranteeing that the final selected merged objects are satisfactory in both resource benefits and technical rationality.

[0012] In conjunction with the first aspect, in one possible implementation, determining Z second microservice pairs from among the Y first microservice pairs based on a first threshold and Y first coupling degrees includes: The first microservice pair with a first coupling degree greater than or equal to the first threshold is determined as the second microservice pair.

[0013] As can be seen, by comparing the first coupling degree with the first threshold, and using whether the coupling degree reaches the threshold as the standard, the second microservice pair is determined from the candidate microservice pairs. Subsequently, using clear quantitative boundaries as screening conditions, the determination of coupling degree no longer relies on subjective experience, improving the repeatability and consistency of the screening process, and ensuring that only microservice pairs with a coupling tightness that meets the preset standard are included in the subsequent merging process.

[0014] In conjunction with the first aspect, in one possible implementation, determining the X groups of target microservices based on the Z pairs of second microservices includes: Determine whether there are multiple second microservice pairs containing the same microservice among the Z second microservice pairs; If they exist, the multiple second microservice pairs containing the same microservice are merged to obtain at least one first microservice group, and the at least one first microservice group and the remaining second microservice pairs are taken as the X target microservice groups. If they do not exist, the Z second microservice pairs will be used as the X target microservice groups; Each target microservice group comprises multiple distinct microservices. Therefore, when determining the target microservice group, it's crucial to identify any overlap among the selected microservice pairs containing the same microservices. Multiple overlapping microservice pairs are then grouped into a single target microservice group containing more microservices. This allows for the unified integration of multiple interdependent microservices into a larger functional module, avoiding the need for multiple iterative operations required by simply merging pairs. This reduces the total number of merge operations, further improving overall efficiency and streamlining the number of microservices.

[0015] In conjunction with the first aspect, in one possible implementation, the method further includes: Based on the Transactions Per Second (TPS) data of each management plane microservice in at least one management plane microservice in the system, determine the 99th Percentile (P99) value of the TPS data of each management plane microservice; Based on the P99 value and resource configuration of each management plane microservice, M target management plane microservices are determined to adjust the resource configuration of each target management plane microservice, where M is an integer greater than or equal to 0.

[0016] As can be seen, by statistically processing the historical TPS data of management plane microservices and extracting their P99 value as a performance evaluation indicator, and combining this P99 value with the current resource configuration, it is possible to determine whether there are target management plane microservices that can be adjusted in terms of resources. Furthermore, based on actual operational data, resource reduction decisions for management plane microservices have objective data support and quantifiable judgment criteria, avoiding misjudgments or omissions that may result from relying solely on human experience.

[0017] In conjunction with the first aspect, in one possible implementation, determining the P99 value of the TPS data of each management plane microservice based on the TPS data of each management plane microservice in at least one management plane microservice in the system includes: Within a preset time period, multiple sets of TPS data for each management plane microservice are acquired. The preset time period is a time period determined under a preset duration, with each set of TPS data corresponding to the same duration. Gamma distribution fitting is performed on multiple sets of TPS data for each management plane microservice to obtain the P99 value of the TPS data for each management plane microservice.

[0018] As can be seen, by collecting TPS data of management microservices at equal time intervals within a preset period and fitting multiple sets of TPS data with a gamma distribution, the P99 value is obtained. Furthermore, the gamma distribution fitting method can better characterize the actual statistical features of the TPS data, making the calculation result of the P99 value more accurate and reliable, and providing a solid data foundation for subsequent resource adjustment decisions based on the P99 value.

[0019] In conjunction with the first aspect, in one possible implementation, determining M target management plane microservices based on the P99 value and resource configuration of each management plane microservice includes: Based on the P99 value of each management plane microservice, determine the standard resource configuration corresponding to the P99 value; Management plane microservices whose resource configurations differ from the standard resource configurations are identified as target management plane microservices.

[0020] As can be seen, by determining the corresponding standard resource configuration based on the P99 value of each management plane microservice, and comparing the current resource configuration with the standard resource configuration, management plane microservices with discrepancies are identified as target management plane microservices. Furthermore, using the standard resource configuration as a comparison benchmark, resource configuration deviations can be objectively quantified, and management plane microservices with redundant or insufficient resource configurations can be accurately identified, improving the accuracy and relevance of resource adjustment decisions.

[0021] In conjunction with the first aspect, in one possible implementation, the method further includes: Based on multiple preset functions, at least one management plane microservice in the system is split into multiple functional module groups, and the multiple functional module groups correspond one-to-one with the multiple functions. The code of the functional modules in each functional module group is integrated to obtain multiple first management plane microservices, and the multiple first management plane microservices correspond one-to-one with the multiple functional module groups.

[0022] As can be seen, by introducing multiple pre-defined functions as the basis for decomposition, the code belonging to the same function in the management plane microservices is collected and integrated to form independent management plane microservices that correspond one-to-one with that function. This eliminates unnecessary coupling caused by mixed functions within the management plane, making the functional boundaries of each management plane microservice clear and their responsibilities singular, reducing the architectural complexity of the management plane itself and the difficulty of subsequent maintenance, and promoting the achievement of the system's lightweight goal from an architectural optimization perspective.

[0023] In conjunction with the first aspect, in one possible implementation, the system's at least one management plane microservice is split based on multiple preset functions to obtain multiple functional module groups, including: Determine whether each management plane microservice contains one or more of the aforementioned functionalities; If included, extract the code of one or more functions contained in each management microservice to obtain one or more functional modules; In the at least one management plane microservice, functional modules with the same function are grouped together to obtain the multiple functional module groups.

[0024] As can be seen, by identifying one or more functions contained in each management plane microservice, extracting the code of the corresponding functions to form functional modules, and grouping functional modules with the same functions together, a functional module group corresponding one-to-one with the preset functions is obtained. This ensures the completeness of functional code extraction and the accuracy of classification, avoiding the omission of the same functional code scattered across different management plane microservices during the splitting process, and providing a reliable implementation foundation for subsequent integration into independent microservices with single responsibilities.

[0025] Secondly, embodiments of this application provide a system lightweight reconfiguration device, the device comprising: The determination module is used to determine the coupling degree between the first microservice and the second microservice based on at least one parameter between the first microservice and the second microservice, wherein each parameter is a parameter characterizing the interrelationship between the first microservice and the second microservice during runtime, and the first microservice and the second microservice are any two different microservices among a plurality of microservices included in the system; Determine the resource reduction amount after merging the first microservice and the second microservice; Based on multiple coupling degrees and multiple resource reductions between any two microservices, X target microservice groups are determined. When X is greater than 0, the microservices in each of the X target microservice groups are merged. X is an integer greater than or equal to 0.

[0026] Thirdly, embodiments of this application provide an electronic device including a memory and a processor. The memory stores a computer program, the computer program includes program instructions, and the processor is configured to invoke the program instructions to execute the steps in the method designed in the first aspect above.

[0027] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program for electronic data interchange, wherein the computer program causes a computer to perform some or all of the steps described in the method of the first aspect of embodiments of this application.

[0028] Fifthly, embodiments of this application provide a computer program product, wherein the computer program product includes a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps described in the method of the first aspect of embodiments of this application. The computer program product may be a software installation package.

[0029] The beneficial effects of the technical solutions in the second to fifth aspects can be found in the technical effects of the technical solution in the first aspect, and will not be repeated here. Attached Figure Description

[0030] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0031] Figure 1 A schematic diagram of the structure of a reconfiguration system provided for an embodiment of this application; Figure 2 A flowchart illustrating a system lightweight reconfiguration method provided for an embodiment of this application; Figure 3 A flowchart illustrating another system lightweight reconfiguration method provided for an embodiment of this application; Figure 4 A flowchart illustrating another system lightweight reconfiguration method provided for an embodiment of this application; Figure 5 A flowchart illustrating another system lightweight reconfiguration method provided for an embodiment of this application; Figure 6 A flowchart illustrating a method for determining multiple middleware instances provided in an embodiment of this application; Figure 7 A flowchart illustrating another system lightweight reconfiguration method provided for an embodiment of this application; Figure 8 A schematic diagram of a service domain topology provided for an embodiment of this application; Figure 9 A schematic diagram of a business domain data mapping matrix provided for an embodiment of this application; Figure 10 A functional unit composition block diagram of a system lightweight reconfiguration device provided for embodiments of this application; Figure 11 This is a schematic diagram of the structure of an electronic device provided for an embodiment of this application. Detailed Implementation

[0032] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings.

[0033] The terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0034] In the embodiments of this application, "at least one item" or similar expressions refer to any combination of these items, including any combination of a single item or a plurality of items. "One or more" refers to one or more items, while "multiple" refers to two or more items. For example, "at least one item" of a, b, or c can represent the following seven cases: a, b, c; a and b; a and c; b and c; a, b, and c. Each of a, b, and c can be an element or a set containing one or more elements.

[0035] In the embodiments of this application, "connection" refers to various connection methods, such as direct connection or indirect connection, to achieve communication between devices. The embodiments of this application do not impose any limitations on this. In the description of this application, it should be noted that, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "connection" should be interpreted broadly. In one example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection, an electrical connection, or a connection that allows mutual communication; it can be a direct connection or an indirect connection through an intermediate medium; it can be the internal communication of two components or the interaction between two components.

[0036] In this document, the term "implementation" means that a specific feature, structure, or characteristic described in connection with an implementation may be included in at least one implementation of this application. The appearance of this phrase in various places in the specification does not necessarily refer to the same implementation, nor is it a separate or alternative implementation mutually exclusive with other implementations. It will be explicitly and implicitly understood by those skilled in the art that the implementations described herein can be combined with other implementations.

[0037] First, the reconfiguration system to which the system lightweight reconfiguration method proposed in this application is applicable will be described. See [link to relevant documentation]. Figure 1 , Figure 1 A schematic diagram of a reconfiguration system applicable to the embodiments of this application is shown below. Figure 1 As shown, the reconfiguration system typically includes a reconfiguration device 110 and a service system cluster 120.

[0038] Specifically, the service system cluster can be a server cluster deployed in a distributed manner, or other device clusters in the field that can realize functions such as service provision and service management; this application does not limit this.

[0039] In this embodiment, the reconfiguration device 110 can be deployed independently of the service system cluster 120 or integrated into the service system cluster 120 and regarded as a functional module of the service system cluster 120. This application does not limit this.

[0040] Understandable, Figure 1 In the reconstruction system shown, the form and number of reconstruction devices 110 and service system clusters 120 are for illustrative purposes only and do not constitute a limitation on the implementation of this application.

[0041] For example, the reconfiguration system may also include user equipment or other equipment.

[0042] For example, the reconfiguration system may include other reconfiguration devices besides the reconfiguration device 110 shown.

[0043] For example, the refactored system may include other service system clusters in addition to the service system cluster 120 shown.

[0044] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the above content and the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. At the same time, these embodiments can be related to each other or independent of each other, and the same content between different embodiments can be referenced by each other, which will not be elaborated here.

[0045] The following describes a system lightweight reconfiguration method in the embodiments of this application.

[0046] Implementation Method 1 See Figure 2 , Figure 2 A flowchart illustrating a system lightweight reconfiguration method provided in this application embodiment is shown. This method can be applied to... Figure 1 The reconstruction system shown can be specifically executed by reconstruction device 110. The method includes the following steps: S201: Determine the coupling degree between the first microservice and the second microservice based on at least one parameter between the first microservice and the second microservice.

[0047] In this embodiment, the first microservice and the second microservice are any two different microservices among the multiple microservices included in the system. Each parameter between the first microservice and the second microservice is a parameter characterizing the interrelationship between the first microservice and the second microservice during runtime. For example, the at least one parameter may include: a parameter of the number of calls between the first microservice and the second microservice, a parameter of the proportion of shared data, and a parameter of the proportion of resource overlap.

[0048] Specifically, the call count parameter between the first microservice and the second microservice can be determined by statistically analyzing the call count over a certain period, such as the 30 days preceding the current time. After determining the call count, it can be normalized to the interval [0, 1], so that the higher the call count, the closer the call count parameter is to 1. It should be noted that the call count parameter between the first microservice and the second microservice can also be determined using some methods commonly used in this field, and this application does not impose any restrictions on this.

[0049] In this embodiment, the shared data ratio parameter between the first microservice and the second microservice can be determined by calculating the proportion of shared data between the first and second microservices relative to the total data of the first and second microservices. Specifically, after determining the proportion of shared data, it can be normalized to the range [0, 1], so that the higher the proportion of shared data, the closer the shared data ratio parameter is to 1. It should be noted that the shared data ratio parameter between the first and second microservices can also be determined using some methods commonly used in the art, and this application does not impose any restrictions on this.

[0050] In this embodiment, the resource overlap ratio parameter between the first microservice and the second microservice can be determined by calculating the overlap ratio of resources such as CPU, memory, and network bandwidth used by the first microservice and the second microservice. Specifically, after determining the resource overlap ratio, it can be normalized to the range [0, 1], so that the higher the resource overlap ratio, the closer the resource overlap ratio parameter is to 1. It should be noted that the resource overlap ratio parameter between the first microservice and the second microservice can also be determined by some methods commonly used in the art, and this application does not limit this.

[0051] In this embodiment, the coupling degree can be the Service Coupling Index (SCI). Specifically, after determining the call count parameter, shared data ratio parameter, and resource overlap ratio parameter between the first microservice and the second microservice, the SCI between the first microservice and the second microservice can be determined based on the following formula (1): ………(1) Here, CallFrequency represents the number of calls between the first microservice and the second microservice, DataDependency represents the proportion of shared data between the first microservice and the second microservice, ResourceOverlap represents the proportion of resource overlap between the first microservice and the second microservice, and α, β and γ are weights.

[0052] In this embodiment, the value of α can be 0.4, the value of β can be 0.3, and the value of γ can be 0.3. Alternatively, the values ​​of α, β, and γ can be determined based on the actual operating scenario or requirements, and this application does not impose any restrictions on them.

[0053] It should be noted that the coupling degree between the first microservice and the second microservice can also be determined by other methods in the art that can determine the coupling degree between the first microservice and the second microservice, and this application does not limit this.

[0054] S202: Determine the resource reduction amount after merging the first and second microservices.

[0055] In this implementation, the resource reduction after merging can be obtained by calculating the difference between the total resources currently used by the two microservices and the estimated resource usage after merging. Specifically, the reduced resources may include CPU utilization, memory usage, network bandwidth usage, etc. After obtaining the reduction of each resource, the reduction of each resource can be normalized and then summed to obtain the resource reduction after merging the two microservices.

[0056] S203: Determine X target microservice groups based on multiple coupling degrees and multiple resource reduction amounts between any two microservices in a multi-microservices group.

[0057] In this implementation, X is an integer greater than or equal to 0, meaning there may be a situation where 0 target microservice groups are identified. In this case, it indicates that the microservices in the system do not meet the merging requirements and cannot be merged. When X is greater than 0, it indicates that there are target microservice groups that can be merged, and they can be merged in subsequent processes.

[0058] In this implementation, firstly, multiple resource reduction amounts can be arranged in descending order to obtain a first sequence. Then, the first Y resource reduction amounts in the first sequence are obtained, where Y is an integer greater than or equal to 1. This allows the microservice pairs with the largest predicted resource reduction after merging to be identified. Since these pairs have the largest resource reduction, merging the microservices in each pair can maximize the reduction of resource consumption.

[0059] However, identifying the Y first microservice pairs solely based on the first Y resource reductions only reflects that these Y pairs represent the largest resource reductions after merging. There may be first microservice pairs with low mergeability among them. Forcibly merging such pairs could lead to system errors and cause even larger problems. Therefore, it is necessary to further filter the Y first microservice pairs based on coupling degree to identify those with low mergeability.

[0060] For example, based on Y first coupling degrees and a first threshold corresponding to Y microservice pairs, Z second microservice pairs can be determined from the Y first microservice pairs. Specifically, the Z first microservice pairs can be first microservice pairs with a first coupling degree greater than or equal to the first threshold. Thus, the merging potential between microservices is measured by the coupling degree between them; the higher the coupling degree, the higher the merging potential. Subsequently, by setting the first threshold, the first microservice pairs with higher coupling degrees are selected as second microservice pairs that can be merged.

[0061] Finally, X groups of target microservices can be determined based on Z pairs of second microservices.

[0062] Specifically, it can be determined whether there are multiple second microservice pairs containing the same microservice among the Z second microservice pairs. If so, the multiple second microservice pairs containing the same microservice are merged to obtain at least one first microservice group. The at least one first microservice group and the remaining second microservice pairs are used as X target microservice groups. If not, the Z second microservice pairs are used as X target microservice groups. Each target microservice group includes multiple distinct microservices.

[0063] For example, consider three second microservice pairs: A[microservice 1, microservice 2], B[microservice 1, microservice 3], and C[microservice 4, microservice 5]. First, it can be determined that pairs A and B contain the same microservice: microservice 1. Therefore, pairs A and B can be merged. Simultaneously, the merged microservice group needs to include multiple distinct microservices. This results in the merged first microservice group: [microservice 1, microservice 2, microservice 3]. Pair C, which has no identical microservices with other groups, does not require further processing and can be directly used as the target microservice group. Finally, two target microservice groups are obtained: [microservice 1, microservice 2, microservice 3] and [microservice 4, microservice 5].

[0064] Subsequently, after identifying X target microservice groups, the microservices contained in each target microservice group can be merged. For example, the code of the microservices in the target microservice groups can be manually reorganized and integrated, resolving code conflicts and interface incompatibility issues during the integration process. The modified code is then integrated into a new microservice, deployed to the system, and finally, the relevant modules' calls to the original microservice are modified to point to the merged new microservice. Alternatively, other microservice merging methods available in this field can be used, and this application does not limit this approach.

[0065] As can be seen, the method implemented in this application introduces parameters characterizing the runtime interrelationships between microservices, quantifies the coupling degree between microservices, and combines this with the expected resource reduction after merging to determine the target microservice group for merging. Compared to relying on manual experience, this method can accurately identify tightly coupled microservice pairs that will result in significant resource savings after merging, thus determining the target microservice group for merging and achieving quantifiable and systematic rapid decision-making. This effectively reduces the number of microservice modules in the system, improves resource utilization, and reduces the complexity of the system structure and the burden of operation and maintenance.

[0066] Implementation Method 2 Based on the above implementation methods, please refer to Figure 3 , Figure 3 A flowchart illustrating another system lightweight reconfiguration method provided in this application embodiment, which can also be applied to... Figure 1 The reconstruction system shown can be specifically executed by reconstruction device 110. The method includes the following steps: S301: Determine the coupling degree between the first microservice and the second microservice based on at least one parameter between the first microservice and the second microservice.

[0067] S302: Determine the resource reduction amount after merging the first and second microservices.

[0068] S303: Determine X target microservice groups based on multiple coupling degrees and multiple resource reductions between any two microservices in a multi-microservices group.

[0069] In this embodiment, the specific implementation of steps S301-S303 can be referred to the above description of steps S201-S203, and will not be repeated here.

[0070] S304: Based on the TPS data of each management plane microservice in at least one management plane microservice in the system, determine the P99 value of the TPS data of each management plane microservice.

[0071] In this embodiment, multiple sets of TPS data for each management plane microservice can be acquired within a preset time period. The preset time period is defined as the time interval from which the multiple sets of TPS data are acquired, and each set of TPS data corresponds to the same duration. For example, within a time period corresponding to 90 days prior to the current time, 2160 sets of TPS data can be acquired using one-hour time units. Each set of TPS data can be the average TPS within a corresponding one-hour period.

[0072] Then, gamma distribution fitting is performed on multiple sets of TPS data for each management plane microservice to obtain the P99 value of the TPS data for each management plane microservice. The P99 value is the value that 99% of the TPS data is less than or equal to.

[0073] S305: Based on the P99 value and resource configuration of each management plane microservice, determine M target management plane microservices.

[0074] In this embodiment, the P99 value of each management plane microservice can be used as the resource baseline for that microservice to measure its maximum resource utilization. Specifically, based on the task requirements of the management plane microservice, corresponding standard resource configurations can be pre-set for each microservice at different P99 values. These standard resource configurations can be determined by the maximum resource utilization of the microservice at the corresponding P99 value. For example, they can be set to exactly meet the maximum resource utilization of the microservice at the corresponding P99 value, or to have redundancy above the maximum resource utilization of the microservice at the corresponding P99 value.

[0075] Subsequently, after obtaining the P99 value, its corresponding standard resource configuration can be determined first. Then, this standard resource configuration is compared with the current resource configuration of the management plane microservice. If the two are different, the management plane microservice is determined to be the target management plane microservice.

[0076] In this implementation, M is an integer greater than or equal to 0, meaning there may be a case where 0 target management plane microservices are identified. In this case, it indicates that the resource configurations of all management plane microservices in the system do not need to be adjusted. When M is greater than 0, it indicates that there are target management plane microservices that need adjustment, and these can be adjusted subsequently according to the standard resource configuration.

[0077] As can be seen, the method of this application statistically processes the historical TPS data of management plane microservices, extracts their P99 value as a performance evaluation indicator, and combines this P99 value with the current resource configuration to determine whether there are target management plane microservices that can be adjusted in terms of resources. Then, based on actual operational data, the resource reduction decision for management plane microservices has objective data support and quantifiable judgment criteria, avoiding misjudgments or omissions that may occur due to relying solely on human experience. Simultaneously, based on the merging of microservices, further resource configuration adjustments are made to the management plane microservices in the system, thereby further reducing the resource consumption of fragmented resource entities and achieving a lightweight transformation of the system.

[0078] Implementation Method 3 Based on the above implementation methods, please refer to Figure 4 , Figure 4 A flowchart illustrating another system lightweight reconfiguration method provided in this application embodiment, which can also be applied to... Figure 1 The reconstruction system shown can be specifically executed by reconstruction device 110. The method includes the following steps: S401: Determine the coupling degree between the first microservice and the second microservice based on at least one parameter between the first microservice and the second microservice.

[0079] S402: Determine the resource reduction amount after merging the first and second microservices.

[0080] S403: Determine X target microservice groups based on multiple coupling degrees and multiple resource reductions between any two microservices in a multi-microservices group.

[0081] In this embodiment, the specific implementation of steps S401-S403 can be referred to the above description of steps S201-S203, and will not be repeated here.

[0082] S404: Based on multiple preset functions, split at least one management plane microservice in the system to obtain multiple functional module groups.

[0083] In this implementation, multiple functional module groups correspond one-to-one with multiple functions. That is, multiple functions are pre-defined, and then it is determined whether each management plane microservice contains one or more of these functions. If so, the code for one or more functions contained in each management plane microservice is extracted to obtain one or more functional modules. Then, functional modules with the same function in at least one management plane microservice are grouped together to obtain multiple functional module groups. In simpler terms, each management plane microservice is split according to whether it contains the pre-defined multiple functions, and the extracted functional modules are placed into the corresponding functional module groups.

[0084] For example, four functions can be pre-configured: user management, access control, system monitoring, and log management, corresponding to four functional module groups. If the management plane microservice 1 has user management and log management functions, then the user management and log management code in the management plane microservice 1 can be extracted and placed into the corresponding functional module groups.

[0085] It should be noted that the preset functions can be determined based on the actual application scenarios and needs, and this application does not impose any restrictions on this.

[0086] S405: Integrate the code of the functional modules in each functional module group to obtain multiple first-level management microservices.

[0087] In this implementation, static analysis and deduplication can be performed on the code of the functional modules within each functional module group to identify and eliminate duplicate utility classes, redundant entities, and common logic that is copied and pasted. Then, lightweight refactoring can be performed on the code within the group, completing interface definitions, aggregate roots, and repository layers to achieve high cohesion within the same functional domain. Finally, the code is integrated into a new first-level management plane microservice corresponding to that function, configured with an independent deployment environment and resource quotas.

[0088] It should be noted that other methods in the art can also be used to integrate the code of the functional modules in the functional module group, and this application does not limit this.

[0089] As can be seen, the method of this application, by introducing multiple preset functions as the basis for decomposition, gathers and integrates the code belonging to the same function in the management plane microservices, forming independent management plane microservices that correspond one-to-one with that function. This eliminates unnecessary coupling caused by functional mixing within the management plane, making the functional boundaries of each management plane microservice clear and their responsibilities singular, reducing the architectural complexity and subsequent maintenance difficulty of the management plane itself, and promoting the realization of the system's lightweight goal from an architectural optimization perspective. Simultaneously, based on the merging of microservices, further integration of the management plane microservices in the system can achieve comprehensive integration of fragmented resource entities in the system, systematically reducing the number of various fragmented resource entities in the system as a whole, changing resource distribution from dispersed to centralized, improving resource utilization efficiency, and reducing system complexity.

[0090] Implementation Method 4 Based on the above implementation methods, please refer to Figure 5 , Figure 5 A flowchart illustrating another system lightweight reconfiguration method provided in this application embodiment, which can also be applied to... Figure 1 The reconstruction system shown can be specifically executed by reconstruction device 110. The method includes the following steps: S501: Determine the coupling degree between the first microservice and the second microservice based on at least one parameter between the first microservice and the second microservice.

[0091] S502: Determine the resource reduction amount after merging the first and second microservices.

[0092] S503: Determine X target microservice groups based on multiple coupling degrees and multiple resource reduction amounts between any two microservices in a multi-microservices group.

[0093] S504: Based on the TPS data of each management plane microservice in at least one management plane microservice in the system, determine the P99 value of the TPS data of each management plane microservice.

[0094] S505: Based on the P99 value and resource configuration of each management plane microservice, determine M target management plane microservices.

[0095] In this embodiment, the specific implementation of steps S501-S505 can be referred to the above description of steps S301-S305, and will not be repeated here.

[0096] It should be noted that steps S504-S505 can also be replaced by S404-S405, which will not be elaborated here.

[0097] S506: Merge multiple middleware instances into a middleware cluster.

[0098] In this implementation, a middleware instance can be understood as a running instance of a middleware software component that provides common support capabilities for different functional modules in the system. This type of instance typically resides between business services and underlying infrastructure resources, and is used to implement functions such as configuration management, service registration, message communication, data caching, and task scheduling.

[0099] Specifically, during multiple architectural evolutions or business expansions, systems often deploy multiple middleware components with similar functions or overlapping responsibilities, resulting in a large number of independent middleware instances with low resource utilization. These independently running instances lead to resource dispersion and maintenance complexity, thus requiring consolidation. By merging multiple middleware instances into a middleware cluster, the number of independent instances can be reduced, enabling unified management and scheduling.

[0100] In this embodiment, the merged middleware cluster may include a primary instance and at least one secondary instance, wherein the total number of primary and secondary instances may be the same as the number of merged middleware instances. Specifically, if five middleware instances are merged into one middleware cluster, the middleware cluster may include one primary instance and four secondary instances. The primary instance can be elected from the five middleware instances through preset rules or an election mechanism, and the other middleware instances that do not become the primary instance automatically become secondary instances.

[0101] It should be noted that the total number of primary and secondary instances may not be the same as the number of middleware instances merged. In addition, the determination of the primary instance may also adopt other determination methods in the art, and this application does not limit this.

[0102] In this implementation, after multiple middleware instances are merged into a middleware cluster, the primary instance will be used first when calling the middleware cluster. Secondary instances will only be used if the primary instance is unavailable or resources are insufficient. This approach ensures the stability and availability of the system after integrating the middleware instances.

[0103] In this embodiment, the plurality of middleware instances are middleware instances identified from the middleware instances included in the system that possess a high degree of merging feasibility. Specifically, this application proposes a method for determining the plurality of middleware instances, such as... Figure 6 As shown, the method includes: S601: Determine the evaluation value of each middleware instance based on the first parameter of each middleware instance in the system.

[0104] In this embodiment, the valuation is used to identify the feasibility of merging the corresponding middleware instances. Specifically, multi-dimensional operational characteristics of the middleware instances during actual operation can be collected as a first parameter. Therefore, the valuation value determined based on the first parameter can accurately reflect the actual operating status of the middleware instances. Consequently, merging decisions based on this valuation value have higher rationality and accuracy.

[0105] In this embodiment, the first parameter may include: communication latency, load similarity, and consistency requirement parameters.

[0106] The communication latency can be taken as the average communication latency of the middleware instance over a certain period of time, for example, taking the current time as the endpoint and the time period corresponding to the previous 3 days, and normalized to the interval [0, 1], so that the smaller the latency, the closer it is to 1. It should be noted that the communication latency can also be determined by some methods commonly used in this field, and this application does not limit it in this way.

[0107] In this embodiment, load similarity can refer to the similarity of CPU and memory usage rates corresponding to a middleware instance. Specifically, the CPU usage rate and memory usage rate corresponding to the middleware instance can be obtained separately, and then the cosine similarity between the CPU usage rate and memory usage rate can be calculated as the load similarity of the middleware instance. It should be noted that the usage rates of other components corresponding to the middleware instance can also be used to determine load similarity, such as the disk and graphics processing unit (GPU) usage rates corresponding to the middleware instance. Other similarity determination methods can also be used to determine load similarity, and this application does not impose any limitations on this.

[0108] In this embodiment, the consistency requirement parameter of a middleware instance is the mode of a plurality of values ​​determined by data consistency requirements between the middleware instance and the remaining middleware instances in the system. In other words, let the first middleware instance represent any one of the middleware instances included in the system, and the second middleware instance represent any one of the remaining middleware instances in the system excluding the first middleware instance. Then, the consistency requirement parameter of the first middleware instance is the mode of a plurality of values ​​determined by data consistency requirements between the first middleware instance and each second middleware instance.

[0109] Specifically, when the data consistency requirements of the first middleware instance and a certain second middleware instance are the same, the value determined by the data consistency requirements between the first middleware instance and the second middleware instance is 1; when the data consistency requirements are different, the value is 0. Therefore, after determining multiple values ​​determined by the data consistency requirements between the first middleware instance and each second middleware instance, the mode of these multiple values ​​is determined as the consistency requirement parameter of the first middleware instance.

[0110] For example, if there are 6 middleware instances in the system: instance 1, instance 2, instance 3, instance 4, instance 5, and instance 6. Taking instance 1 as the first middleware instance, then instances 2, 3, 4, 5, and 6 are the remaining 5 second middleware instances. First, determine whether the data consistency requirements of instance 1 are the same as those of instances 2, 3, 4, 5, and 6. Assume that instance 1 has the same data consistency requirements as instances 2, 3, and 6, but different data consistency requirements as instances 4 and 5. Then, the value determined between instance 1 and instance 2 is 1, between instance 1 and instance 3 is 1, between instance 1 and instance 4 is 0, between instance 1 and instance 5 is 0, and between instance 1 and instance 6 is 1, resulting in 5 values ​​[1, 1, 0, 0, 1]. Then, determine the mode of these 5 values, 1, as the consistency requirement parameter for instance 1.

[0111] In this embodiment, after determining the communication latency, load similarity, and consistency requirement parameters of the middleware instance, the evaluation value of the middleware instance can be determined based on the following formula (2): ………(2) Where P represents the evaluation value of the middleware instance, C represents the communication latency of the middleware instance, S represents the load similarity of the middleware instance, D represents the consistency requirement parameter of the middleware instance, and ω1, ω2 and ω3 are weights.

[0112] In this embodiment, the value of ω1 can be 0.3, the value of ω2 can be 0.4, and the value of ω3 can be 0.3. Alternatively, the values ​​of ω1, ω2, and ω3 can be determined based on the actual operating scenario or requirements, and this application does not impose any restrictions on them.

[0113] It should be noted that the evaluation value of a middleware instance can also be determined by other methods in the art that can determine the feasibility of merging middleware instances, and this application does not impose any restrictions on this.

[0114] S602: Based on the evaluation value of each middleware instance and a first threshold, identify multiple middlewares.

[0115] In this embodiment, the evaluation value of a middleware instance can be compared with a first threshold, and the middleware with an evaluation value greater than or equal to the first threshold is identified as one of a plurality of middleware that can be merged. For example, the first threshold can be 0.7, or the value of the first threshold can be determined based on the actual operating scenario or requirements, and this application does not limit it in this way.

[0116] In this embodiment, the middleware instance may include an ETCD instance and / or a single-point master node. The ETCD instance can be used to store system configuration data or metadata, while the single-point master node can be used to perform specific control tasks or management operations.

[0117] It should be noted that ETCD instances and single-point master nodes cannot be merged. That is, the method provided in this application can only merge multiple ETCD instances into an ETCD instance cluster, and multiple single-point master nodes into a node cluster. Therefore, if the system contains both ETCD instances and single-point master nodes, they will be merged separately.

[0118] For example, if the middleware instance is an ETCD instance, when merging multiple ETCD instances, the cluster building tool provided by ETCD can be used to designate any one of the multiple ETCD instances as the primary instance, and then the remaining ETCD instances can be added to the cluster as secondary instances in sequence. Finally, the cluster communication address, election timeout time, and heartbeat interval are configured for the merged cluster to complete the unified cluster setup. The election timeout time can be 5 seconds, and the heartbeat interval can be 1 second, or it can be determined based on the actual operating scenario or requirements; this application does not impose any restrictions on this.

[0119] For example, if the middleware instance is a single-point master node, multiple single-point master nodes can be merged into a multi-master cluster. Specifically, a node election mechanism based on the Raft protocol can be used, configuring each node in the cluster to have the same voting weight and setting a node failure detection time. In use, a node in the cluster can be randomly or pre-determined to be given priority as the master node, with other nodes acting as slave nodes. When the master node fails, the remaining slave nodes complete the election of a new master node within the failure detection time, ensuring the high availability of the cluster. The failure detection time can be 3 seconds, or it can be determined based on the actual operating scenario or requirements; this application does not impose any restrictions on this.

[0120] In this implementation, some fragmented static files in the system can also be considered as middleware instances, such as Cascading Style Sheets (CSS) files. For CSS files, a CSS compression and merging tool can be used to perform syntax checks and deduplication on each CSS file, removing duplicate style rules and invalid code. Then, the processed multiple CSS files are merged into a single CSS resource file. At the same time, the CSS file reference path in the front-end code is modified to point to the merged single CSS resource file, thus completing the CSS file merging.

[0121] As can be seen, the method of this application, by merging multiple middleware instances into a middleware cluster and setting a primary instance and at least one secondary instance in the cluster, allows the system to prioritize the use of the primary instance during runtime, and activate the secondary instance when the primary instance is unavailable or resources are insufficient. It is evident that by establishing a unified middleware cluster structure, the number of independent middleware instances in the system can be reduced, enabling efficient integration of middleware instances. Furthermore, based on merging microservices and adjusting management plane microservices, further merging the middleware in the system can reduce resource waste caused by dispersed instance deployment, improve resource utilization, reduce system structural complexity and operational maintenance burden, and enhance the centralization and reliability of system operation.

[0122] Implementation Method 5 Based on the above implementation methods, please refer to Figure 7 , Figure 7 A flowchart illustrating another system lightweight reconfiguration method provided in this application embodiment, which can also be applied to... Figure 1 The reconstruction system shown can be specifically executed by reconstruction device 110. The method includes the following steps: S701: Determine the coupling degree between the first microservice and the second microservice based on at least one parameter between the first microservice and the second microservice.

[0123] S702: Determine the resource reduction amount after merging the first and second microservices.

[0124] S703: Determine X target microservice groups based on multiple coupling degrees and multiple resource reductions between any two microservices in a multi-microservices framework.

[0125] S704: Based on the TPS data of each management plane microservice in at least one management plane microservice in the system, determine the P99 value of the TPS data of each management plane microservice.

[0126] S705: Based on the P99 value and resource configuration of each management plane microservice, determine M target management plane microservices.

[0127] S706: Merge multiple middleware instances into a middleware cluster.

[0128] In this embodiment, the specific implementation of steps S701-S706 can be referred to the above description of steps S501-S506, and will not be repeated here.

[0129] It should be noted that steps S704-S705 can also be replaced by S404-S405, which will not be elaborated here.

[0130] S707: Based on the description vector of the service corresponding to each data pool in the system, multiple services are clustered to obtain multiple clusters.

[0131] In this implementation, multiple services correspond one-to-one with multiple data pools. That is, when merging data pools, the services corresponding to the data pools are processed to determine which data pools to merge. Specifically, the description information of the services corresponding to each data pool is first vectorized to obtain the description vector of each service.

[0132] In this embodiment, the service description information may include textual information such as functional descriptions, interface documents, and data dictionaries. After collecting the description information of each service, it can be stored uniformly to construct a service description corpus. Then, a pre-trained Bidirectional Encoder Representations from Transformers-Base (BERT-base) model is used to preprocess the text in the corpus, such as word segmentation and part-of-speech tagging, to convert the description information of each service into a multi-dimensional vector representation, such as a 768-dimensional vector, to obtain the description vector of each service. Each element in the description vector corresponds to the semantic features in the description information.

[0133] It should be noted that other methods in the art can also be used to determine the description vector of the service, and this application does not limit this.

[0134] Then, the K-means clustering algorithm (K-means) is used to cluster the description vectors of each service. Specifically, the number of clusters is first determined using the elbow rule, and then the description vectors of each service are clustered using this number of clusters. During the clustering process, the Euclidean distance between the description vectors is used as a similarity measure, and the cluster centers are iteratively updated until the cluster centers no longer change or the maximum number of iterations is reached, such as 100, resulting in multiple clusters.

[0135] It should be noted that other methods in the field can also be used to cluster the description vectors of each service, and this application does not limit this.

[0136] S708: Analyze each cluster to obtain multiple business domain topology diagrams.

[0137] In this embodiment, multiple service domain topology maps correspond one-to-one with multiple clusters, meaning that each cluster can determine a service topology map. Hereinafter, the method of determining the service topology map will be explained by referring to any one of the multiple service domain topology maps as the first service domain topology map.

[0138] Specifically, in the first business domain topology graph, nodes represent services within the corresponding clusters. The lines connecting nodes represent the relationships between services, and the thickness of the lines indicates the strength of the relationship. This strength can be determined by calculating the Service Correlation Index (SCI) between the services corresponding to the nodes. For example, if a cluster contains 5 services: Service 1, Service 2, Service 3, Service 4, and Service 5, then based on the pairwise relationship strength, we can obtain... Figure 8 The business domain topology diagram is shown.

[0139] S709: Based on multiple business domain topology diagrams, merge the data pools corresponding to the services in each cluster.

[0140] In this embodiment, a business domain data mapping matrix can be determined based on the business domain topology map, and then the data pools corresponding to services in each cluster can be merged based on the business domain data mapping matrix. Specifically, the horizontal and vertical columns of the business domain data mapping matrix correspond to the services in each cluster, and the value of each element in the matrix represents the correlation strength (SCI) between the service corresponding to that horizontal column and the service corresponding to that vertical column. For example, for Figure 8 The business domain topology diagram shown can be used to obtain... Figure 9 The business domain data mapping matrix shown.

[0141] It should be noted that each cluster can also be analyzed directly to obtain multiple business domain data mapping matrices. That is, the business domain data mapping matrices can be obtained directly without intermediate transitions in the business domain topology diagram. Alternatively, other methods in this field can be used to obtain the business domain data mapping matrices, and this application does not impose any restrictions on this method.

[0142] In this implementation, after obtaining the business domain data mapping matrix, the data pools corresponding to services with a correlation strength greater than the third threshold in the matrix can be merged. During the merging process, a distributed database architecture, such as a Hadoop Database (HBase) architecture, can be used to store and manage the data in the data pool according to a unified data model, configure data sharding strategies and replication mechanisms, and ensure data reliability and query performance.

[0143] It should be noted that other methods for merging data pools in this field can also be used to merge the determined data pools, and this application does not impose any restrictions on this.

[0144] As can be seen, by using the method of this application, on the basis of merging microservices, middleware, and adjusting management plane microservices, the data pool in the system can be further integrated, which can realize the comprehensive integration of fragmented resource entities in the system, reduce the number of various fragmented resource entities in the system in an orderly manner, change the resource distribution from decentralized to centralized, improve resource utilization efficiency, and reduce system complexity.

[0145] It should be noted that each of the above implementation methods can be implemented independently without relying on other implementation methods. At the same time, the implementation methods for merging or adjusting middleware instances, microservices, data pools, and management plane microservices can also be implemented independently without relying on other implementation methods.

[0146] The foregoing primarily describes the implementation scheme of this application from a methodological perspective. It is understood that, to achieve the above functions, the apparatus may include hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in a hardware or computer software-driven hardware manner depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0147] The embodiments of this application can divide the device into functional units according to the above method examples. For example, each function can be divided into separate functional units, or two or more functions can be integrated into one processing unit. The integrated unit can be implemented in hardware or as a software program module. It should be noted that the unit division in the embodiments of this application is illustrative and is only a logical functional division, while other division methods may be used in actual implementation.

[0148] When using integrated units, Figure 10 This is a functional unit block diagram of a system lightweight reconfiguration device proposed in an embodiment of this application. The system lightweight reconfiguration device 1000 includes a determination module 1001.

[0149] In this embodiment, the determination module 1001 can be a module unit used to receive and process signals, information, etc., or to determine the monitoring mechanism, and there are no specific limitations on it.

[0150] In this embodiment, the system lightweight reconfiguration device 1000 may further include a storage unit for storing computer program code or instructions executed by the system lightweight reconfiguration device 1000. The storage unit may be a memory.

[0151] In this embodiment, the system lightweight reconfiguration device 1000 can be a chip or a chip module.

[0152] In this embodiment, the determining module 1001 can be integrated into the communication unit. The communication unit can be a communication interface, transceiver, transceiver circuit, etc.

[0153] In this embodiment, the determination module 1001 can be integrated into the processing unit.

[0154] It should be noted that the processing unit can be a processor or controller, such as a baseband processor, baseband chip, central processing unit (CPU), general-purpose processor, digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other programmable logic device, transistor logic device, hardware component, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. The processing unit can also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0155] In this embodiment, the system lightweight reconfiguration device 1000 is used to perform any of the steps performed by network devices / chips / chip modules, etc., as described in the above method embodiments.

[0156] In specific implementation, the determination module 1001 is used to execute any step in the above method implementation, and when performing actions such as sending, it can selectively call other units to complete the corresponding operation. A detailed explanation follows.

[0157] The determination module 1001 is used to determine the coupling degree between the first microservice and the second microservice based on at least one parameter between the first microservice and the second microservice, wherein each parameter is a parameter characterizing the interrelationship between the first microservice and the second microservice during runtime, and the first microservice and the second microservice are any two different microservices among a plurality of microservices included in the system. Determine the resource reduction amount after merging the first microservice and the second microservice; Based on multiple coupling degrees and multiple resource reductions between any two microservices, X target microservice groups are determined. When X is greater than 0, the microservices in each of the X target microservice groups are merged. X is an integer greater than or equal to 0.

[0158] In this embodiment, the at least one parameter includes: The parameter for the number of calls between the first microservice and the second microservice; The shared data ratio parameter between the first microservice and the second microservice; The resource overlap ratio parameter between the first microservice and the second microservice.

[0159] In this embodiment, regarding the determination of X target microservice groups based on multiple coupling degrees and multiple resource reduction amounts between any two microservices among the plurality of microservices, the determining module 1001 is specifically used for: Arrange the multiple resource reduction amounts in descending order to obtain the first sequence; Obtain the first Y resource reduction amounts in the first sequence, where Y is an integer greater than or equal to 1; Based on a first threshold and Y first coupling degrees, Z second microservice pairs are determined from the Y first microservice pairs, wherein the Y first microservice pairs are the microservice pairs corresponding to the first Y resource reduction amounts, the Y first coupling degrees are the coupling degrees of the Y first microservice pairs, and Z is an integer greater than or equal to 1; The X target microservice groups are determined based on the Z second microservice pairs.

[0160] In this embodiment, regarding the determination of Z second microservice pairs among the Y first microservice pairs based on a first threshold and Y first coupling degrees, the determining module 1001 is specifically used for: The first microservice pair with a first coupling degree greater than or equal to the first threshold is determined as the second microservice pair.

[0161] In this embodiment, regarding the determination of the X target microservice groups based on the Z second microservice pairs, the determining module 1001 is specifically used for: Determine whether there are multiple second microservice pairs containing the same microservice among the Z second microservice pairs; If they exist, the multiple second microservice pairs containing the same microservice are merged to obtain at least one first microservice group, and the at least one first microservice group and the remaining second microservice pairs are taken as the X target microservice groups. If they do not exist, the Z second microservice pairs will be used as the X target microservice groups; Each target microservice group contains multiple distinct microservices.

[0162] In this embodiment, the determining module 1001 is further configured to: Based on the transactions per second (TPS) data of each management plane microservice in at least one management plane microservice in the system, determine the 99th percentile (P99) value of the TPS data of each management plane microservice. Based on the P99 value and resource configuration of each management plane microservice, M target management plane microservices are determined to adjust the resource configuration of each target management plane microservice, where M is an integer greater than or equal to 0.

[0163] In this embodiment, regarding determining the P99 value of the TPS data of each management plane microservice based on the TPS data of each management plane microservice in at least one management plane microservice in the system, the determining module 1001 is specifically used for: Within a preset time period, multiple sets of TPS data for each management plane microservice are acquired. The preset time period is a time period determined under a preset duration, with each set of TPS data corresponding to the same duration. Gamma distribution fitting is performed on multiple sets of TPS data for each management plane microservice to obtain the P99 value of the TPS data for each management plane microservice.

[0164] In this embodiment, regarding the determination of M target management plane microservices based on the P99 value and resource configuration of each management plane microservice, the determination module 1001 is specifically used for: Based on the P99 value of each management plane microservice, determine the standard resource configuration corresponding to the P99 value; Management plane microservices whose resource configurations differ from the standard resource configurations are identified as target management plane microservices.

[0165] In this embodiment, the determining module 1001 is further configured to: Based on multiple preset functions, at least one management plane microservice in the system is split into multiple functional module groups, and the multiple functional module groups correspond one-to-one with the multiple functions. The code of the functional modules in each functional module group is integrated to obtain multiple first management plane microservices, and the multiple first management plane microservices correspond one-to-one with the multiple functional module groups.

[0166] In this embodiment, regarding the process of splitting at least one management plane microservice in the system based on multiple preset functions to obtain multiple functional module groups, module 1001 is specifically used for: Determine whether each management plane microservice contains one or more of the aforementioned functionalities; If included, extract the code of one or more functions contained in each management microservice to obtain one or more functional modules; In the at least one management plane microservice, functional modules with the same function are grouped together to obtain the multiple functional module groups.

[0167] It should be noted that, Figure 10 The specific implementation of each operation in the implementation method can be found in the description of the method implementation method shown above, and will not be repeated here.

[0168] See Figure 11 , Figure 11 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. The electronic device 1100 may include a processor 1110, a memory 1120, and a communication bus for connecting the processor 1110 and the memory 1120.

[0169] Optionally, the memory 1120 may include, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or compact disc read-only memory (CD-ROM). The memory 1120 is used to store program code executed by the electronic device 1100 and data transmitted therefrom.

[0170] In this embodiment, the electronic device 1100 also includes a communication interface for receiving and sending data.

[0171] In this embodiment, the processor 1110 may be one or more CPUs. When the processor 1110 is a CPU, the CPU may be a single-core CPU or a multi-core CPU.

[0172] In this embodiment, the processor 1110 can be a baseband chip, a chip, a CPU, a general-purpose processor, a DSP, an ASIC, an FPGA, or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof.

[0173] In a specific implementation, the processor 1110 in the electronic device 1100 executes the computer program or instructions 1121 stored in the memory 1120 to perform the following operations: The coupling degree between the first microservice and the second microservice is determined based on at least one parameter between the first microservice and the second microservice, wherein each parameter is a parameter characterizing the interrelationship between the first microservice and the second microservice during runtime, and the first microservice and the second microservice are any two different microservices among a plurality of microservices included in the system. Determine the resource reduction amount after merging the first microservice and the second microservice; Based on multiple coupling degrees and multiple resource reductions between any two microservices, X target microservice groups are determined. When X is greater than 0, the microservices in each of the X target microservice groups are merged. X is an integer greater than or equal to 0.

[0174] It should be noted that, Figure 11 The specific implementation of each operation in the above-described method implementation can be found in the description of the method implementation, and will not be repeated here.

[0175] This application also provides a computer storage medium storing a computer program for electronic data interchange, which causes a computer to perform some or all of the steps of any of the methods described in the above method embodiments, wherein the computer includes an electronic device.

[0176] This application also provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps of any of the methods described in the above method embodiments. The computer program product may be a software installation package, and the computer may include an electronic device.

[0177] It should be noted that, for the sake of simplicity, the various embodiments described above are all presented as a series of actions. Those skilled in the art should understand that this application is not limited by the described order of actions, as some steps in the embodiments of this application can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions, steps, modules, or units involved are not necessarily essential to the embodiments of this application.

[0178] In the above embodiments, the descriptions of each embodiment in this application have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0179] The steps of the methods or algorithms described in this application can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in RAM, flash memory, ROM, EPROM, electrically erasable programmable read-only memory (EEPROM), registers, hard disk, portable hard disk, read-only optical disk (CD-ROM), or any other form of storage medium known in the art. An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and storage medium can reside in an ASIC. Furthermore, the ASIC can reside in a terminal device or management device. Alternatively, the processor and storage medium can exist as discrete components in the terminal device or management device.

[0180] Those skilled in the art will recognize that, in one or more of the examples above, the functions described in the embodiments of this application can be implemented, in whole or in part, by software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. This computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital video discs (DVDs)), or semiconductor media (e.g., solid-state disks (SSDs)).

[0181] The modules / units included in the various devices and products described in the above embodiments can be software modules / units, hardware modules / units, or a combination of both. For example, for devices and products applied to or integrated into a chip, all modules / units can be implemented using hardware methods such as circuits, or at least some modules / units can be implemented using software programs that run on a processor integrated within the chip, while the remaining (if any) modules / units can be implemented using hardware methods such as circuits. For devices and products applied to or integrated into a chip module, all modules / units can be implemented using hardware methods such as circuits. Different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or different components of the chip module, or at least some modules / units can be implemented using hardware methods such as circuits. The implementation is achieved through a software program that runs on the processor integrated within the chip module. The remaining modules / units (if any) can be implemented using hardware methods such as circuits. For various devices and products applied to or integrated into terminal equipment, each of their modules / units can be implemented using hardware methods such as circuits. Different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or different components within the terminal equipment. Alternatively, at least some modules / units can be implemented through a software program that runs on the processor integrated within the terminal equipment, while the remaining modules / units (if any) can be implemented using hardware methods such as circuits.

[0182] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the embodiments of this application. It should be understood that the above description is only a specific embodiment of the embodiments of this application and is not intended to limit the protection scope of the embodiments of this application. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solution of the embodiments of this application should be included within the protection scope of the embodiments of this application.

Claims

1. A method for lightweight system reconfiguration, characterized in that, The method includes: The coupling degree between the first microservice and the second microservice is determined based on at least one parameter between the first microservice and the second microservice, wherein each parameter is a parameter characterizing the interrelationship between the first microservice and the second microservice during runtime, and the first microservice and the second microservice are any two different microservices among a plurality of microservices included in the system. Determine the resource reduction amount after merging the first microservice and the second microservice; Based on multiple coupling degrees and multiple resource reductions between any two microservices, X target microservice groups are determined. When X is greater than 0, the microservices in each of the X target microservice groups are merged. X is an integer greater than or equal to 0.

2. The method according to claim 1, characterized in that, The at least one parameter includes: The parameter for the number of calls between the first microservice and the second microservice; The shared data ratio parameter between the first microservice and the second microservice; The resource overlap ratio parameter between the first microservice and the second microservice.

3. The method according to claim 1 or 2, characterized in that, The determination of X target microservice groups based on multiple coupling degrees and multiple resource reductions between any two microservices among the multiple microservices includes: Arrange the multiple resource reduction amounts in descending order to obtain the first sequence; Obtain the first Y resource reduction amounts in the first sequence, where Y is an integer greater than or equal to 1; Based on a first threshold and Y first coupling degrees, Z second microservice pairs are determined from the Y first microservice pairs, wherein the Y first microservice pairs are the microservice pairs corresponding to the first Y resource reduction amounts, the Y first coupling degrees are the coupling degrees of the Y first microservice pairs, and Z is an integer greater than or equal to 1; The X target microservice groups are determined based on the Z second microservice pairs.

4. The method according to claim 3, characterized in that, The step of determining Z second microservice pairs from the Y first microservice pairs based on a first threshold and Y first coupling degrees includes: The first microservice pair with a first coupling degree greater than or equal to the first threshold is determined as the second microservice pair.

5. The method according to claim 3 or 4, characterized in that, The process of determining the X target microservice groups based on the Z second microservice pairs includes: Determine whether there are multiple second microservice pairs containing the same microservice among the Z second microservice pairs; If they exist, the multiple second microservice pairs containing the same microservice are merged to obtain at least one first microservice group, and the at least one first microservice group and the remaining second microservice pairs are taken as the X target microservice groups. If they do not exist, the Z second microservice pairs will be used as the X target microservice groups; Each target microservice group contains multiple distinct microservices.

6. The method according to any one of claims 1-5, characterized in that, The method further includes: Based on the transactions per second (TPS) data of each management plane microservice in at least one management plane microservice in the system, determine the 99th percentile (P99) value of the TPS data of each management plane microservice. Based on the P99 value and resource configuration of each management plane microservice, M target management plane microservices are determined to adjust the resource configuration of each target management plane microservice, where M is an integer greater than or equal to 0.

7. The method according to claim 6, characterized in that, The step of determining the P99 value of the TPS data of each management plane microservice based on the TPS data of each management plane microservice in at least one management plane microservice in the system includes: Within a preset time period, multiple sets of TPS data for each management plane microservice are acquired. The preset time period is a time period determined under a preset duration, with each set of TPS data corresponding to the same duration. Gamma distribution fitting is performed on multiple sets of TPS data for each management plane microservice to obtain the P99 value of the TPS data for each management plane microservice.

8. The method according to claim 6 or 7, characterized in that, Based on the P99 value and resource configuration of each management plane microservice, M target management plane microservices are determined, including: Based on the P99 value of each management plane microservice, determine the standard resource configuration corresponding to the P99 value; Management plane microservices whose resource configurations differ from the standard resource configurations are identified as target management plane microservices.

9. The method according to any one of claims 1-5, characterized in that, The method further includes: Based on multiple preset functions, at least one management plane microservice in the system is split into multiple functional module groups, and the multiple functional module groups correspond one-to-one with the multiple functions. The code of the functional modules in each functional module group is integrated to obtain multiple first management plane microservices, and the multiple first management plane microservices correspond one-to-one with the multiple functional module groups.

10. The method according to claim 9, characterized in that, The system's management plane microservice is split based on multiple preset functions to obtain multiple functional module groups, including: Determine whether each management plane microservice contains one or more of the aforementioned functionalities; If included, extract the code of one or more functions contained in each management microservice to obtain one or more functional modules; In the at least one management plane microservice, functional modules with the same function are grouped together to obtain the multiple functional module groups.

11. A lightweight reconfigurable system device, characterized in that, The device includes: The determination module is used to determine the coupling degree between the first microservice and the second microservice based on at least one parameter between the first microservice and the second microservice, wherein each parameter is a parameter characterizing the interrelationship between the first microservice and the second microservice during runtime, and the first microservice and the second microservice are any two different microservices among a plurality of microservices included in the system; Determine the resource reduction amount after merging the first microservice and the second microservice; Based on multiple coupling degrees and multiple resource reductions between any two microservices, X target microservice groups are determined. When X is greater than 0, the microservices in each of the X target microservice groups are merged. X is an integer greater than or equal to 0.

12. An electronic device, characterized in that, The device includes a memory and a processor, the memory being used to store a computer program, the computer program including program instructions, and the processor being configured to invoke the program instructions to perform the method as described in any one of claims 1-10.

13. A computer-readable storage medium, characterized in that, The computer storage medium stores computer-readable instructions that, when executed on a computer, cause the computer to perform the method of any one of claims 1-10.

Images