A micro-service dynamic merging method, device, equipment and medium

Abstract

The application discloses a dynamic merging method, device and equipment of microservices and a medium. The method comprises the following steps: determining to-be-merged microservices in a cluster according to preset running indexes; stopping the running of the to-be-merged microservices, and merging the to-be-merged microservices into new microservices; starting the new microservices, and modifying the dependent relationships related to the to-be-merged microservices correspondingly. The embodiment of the application can realize the dynamic merging of microservices, and improve the user experience during the merging of microservices.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of system operation and maintenance, and in particular to a dynamic merging method, device and equipment of microservices and a medium. BACKGROUND

[0002] With the wide application of microservice architecture, the number of microservices in the system is increasing, which brings great challenges to system operation and maintenance. At the same time, the increase of microservices leads to the continuous increase of system resource consumption, and a microservice merging technology is needed to reduce the number of services in the system, improve system operation and maintenance efficiency, and save system running resources.

[0003] The existing microservice merging is mostly realized in a static merging manner, that is, the load of microservices is tested before the system goes online. After the test is completed, the developers manually merge the microservices at the code level according to the test results, and the system goes online after the merging is completed.

[0004] However, the test results before the system goes online sometimes greatly deviate from the actual situation, resulting in the need to merge microservices again after the system goes online. At this time, the static merging method needs to take the entire system offline and then online again, which has a greater impact on user experience. SUMMARY

[0005] The present application provides a dynamic merging method, device and equipment of microservices and a medium to realize dynamic merging of microservices and improve user experience during microservice merging.

[0006] According to an aspect of the present application, a dynamic merging method of microservices is provided, comprising:

[0007] determining a to-be-merged microservice in a cluster according to a preset running index;

[0008] stopping the running of the to-be-merged microservice and merging the to-be-merged microservice into a new microservice;

[0009] starting the new microservice and modifying the dependency relationship related to the to-be-merged microservice correspondingly.

[0010] According to another aspect of the present application, a dynamic merging device of microservices is provided, comprising:

[0011] a service determining module configured to determine a to-be-merged microservice in a cluster according to a preset running index;

[0012] a service merging module configured to stop the running of the to-be-merged microservice and merge the to-be-merged microservice into a new microservice;

[0013] a dependency modifying module configured to start the new microservice and modify the dependency relationship related to the to-be-merged microservice correspondingly.

[0014] According to another aspect of the present application, there is provided a computer program product comprising a computer program which, when executed by a processor, implements the method for dynamic merging of microservices according to any embodiment of the present application.

[0015] According to another aspect of the present application, there is provided an electronic device comprising at least one processor and a memory communicatively connected to the at least one processor, wherein the memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor to enable the at least one processor to perform the method for dynamic merging of microservices according to any embodiment of the present application.

[0016] According to another aspect of the present application, there is provided a computer readable storage medium storing computer instructions for causing a processor to perform the method for dynamic merging of microservices according to any embodiment of the present application when executed by the processor.

[0017] The embodiments of the present application dynamically merge microservices, and during the dynamic merging, the entire cluster does not need to be taken offline and restarted, but only a small number of microservices to be merged need to be taken offline for a short time, thereby reducing the impact on the system during the merging of microservices and improving the user experience during the merging of microservices.

[0018] It should be understood that the content described in this section is not intended to identify key or important features of the embodiments of the present application, nor is it used to limit the scope of the present application. Other features of the present application will become apparent from the following description. BRIEF DESCRIPTION OF DRAWINGS

[0019] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed in the embodiment description will be briefly introduced as follows. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can also be obtained by those skilled in the art without creative effort based on these drawings.

[0020] Figure 1 is a flowchart of a method for dynamic merging of microservices according to an embodiment of the present application;

[0021] Figure 2 is a flowchart of a method for dynamic merging of microservices according to another embodiment of the present application;

[0022] Figure 3 is a structural schematic diagram of a device for dynamic merging of microservices according to another embodiment of the present application;

[0023] Figure 4 is a structural schematic diagram of an electronic device for implementing an embodiment of the present application. DETAILED DESCRIPTION

[0024] In order to make the personnel in the technical field better understand the present application scheme, the technical scheme in the embodiment of the present application will be described clearly and completely below in combination with the drawings in the embodiment of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, not all. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor should belong to the scope of protection of the present application.

[0025] It should be noted that the terms "first", "second" and the like in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and do not necessarily indicate a specific order or sequence. It should be understood that the data thus used can be interchanged under appropriate circumstances, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product or device including a series of steps or units does not have to be limited to those steps or units clearly listed, but can include other steps or units not clearly listed or inherent to these processes, methods, products or devices.

[0026] Figure 1 A flowchart of a microservice dynamic merging method provided by an embodiment of the present application. The embodiment can be applicable to the case of periodically or on-demand merging of microservices in the system according to the running index after the system is put into operation. The method can be executed by a microservice dynamic merging device. The device can be realized in the form of hardware and / or software. The device can be configured in an electronic device with corresponding data processing capability, such as a system deployed with a microservice cluster. As shown in the figure, the method comprises: Figure 1

[0027] S110, determining the to-be-merged microservice in the cluster according to the preset running index.

[0028] S120, stopping the running of the to-be-merged microservice, and merging the to-be-merged microservice into a new microservice.

[0029] S130, starting the new microservice, and modifying the dependency relationship related to the to-be-merged microservice.

[0030] ​Specifically, during system operation, monitoring software is used to collect running index of microservices in the entire cluster, and a merging condition is set in advance. If the running index of any microservice meets the merging condition, it is determined that the microservice can be merged, and it is taken as a to-be-merged service. Through continuous monitoring for a period of time, all to-be-merged microservices in the cluster can be determined.

[0031] After a suitable time is reached, the running of the to-be-merged microservice is stopped. The executable file (jar package) corresponding to the to-be-merged microservice is decompressed one by one, and each file obtained by decompression is combined and packaged to generate a new executable file. The new executable file is deployed to the cluster container, and the new microservice is started. These merging steps can be realized by executing a script set by a person in advance to improve the merging efficiency.

[0032] Since there is a dependency relationship between microservices, after the to-be-merged microservice is merged into a new microservice, the dependency relationship between the corresponding microservices in the cluster needs to be adjusted according to the content of this merging, so that the microservices can still correctly call each other after the microservices are merged.

[0033] The embodiment of the application dynamically merges microservices. During dynamic merging, the entire cluster does not need to be taken offline and restarted, but only a small number of to-be-merged microservices need to be taken offline for a short time, thereby reducing the impact on the system during microservice merging and improving user experience during microservice merging.

[0034] Figure 2 A flowchart of a microservice dynamic merging method provided by another embodiment of the application is shown in FIG. 8. The embodiment is optimized and improved on the basis of the above-mentioned embodiment. As shown in FIG. 8, the method comprises the following steps. Figure 2

[0035] S210, if the number of microservices meeting the merging condition in the cluster is even, the corresponding microservices are divided into to-be-merged microservices that need to be merged in pairs; if the number of microservices meeting the merging condition in the cluster is odd, the microservice closest to the merging condition is excluded from the remaining microservices, and the remaining microservices are divided into to-be-merged microservices that need to be merged in pairs.

[0036] The running index includes processor usage rate, memory usage rate and disk usage rate; and the merging condition includes that the processor usage rate of the microservice is greater than the average processor usage rate of the cluster, the memory usage rate of the microservice is greater than the average memory usage rate of the cluster, and the disk usage rate of the microservice is greater than the average disk usage rate of the cluster.

[0037] ​Specifically, the collected operation indexes are: CPU usage Q1, Q2, Q3...Qn (n is the number of microservices in the cluster); memory usage M1, M2, M3...Mn (n is the number of microservices in the cluster); hard disk space usage D1, D2, D3...Dn (n is the number of microservices in the cluster). And according to this, the average CPU usage of the cluster Q=(Q1+Q2+Q3+...+Qn) / n; the average memory usage of the cluster M=(M1+M2+M3+...+Mn) / n; the average disk usage of the cluster D=(D1+D2+D3+...+Dn) / n are calculated.

[0038] In the monitoring process, if the processor usage of a microservice is greater than the average processor usage of the cluster, the memory usage of the microservice is greater than the average memory usage of the cluster, and the disk usage of the microservice is greater than the average disk usage of the cluster, the microservice is determined as a microservice to be merged.

[0039] When the microservices are merged, the original microservices to be merged stop running, and the new microservices go online and run, which is not completely non-susceptible. In order to minimize the negative impact of merging, the microservices to be merged are divided into pairs of microservices to be merged, and each pair of microservices to be merged includes two microservices to be merged. During merging, according to a certain merging order, only one pair of microservices to be merged is merged at the same time, and after the merging of the pair of microservices to be merged is completed, the merging of the next pair of microservices to be merged is performed. In this way, at the same time, at most two microservices in the cluster stop running.

[0040] Of course, if the number of microservices to be merged is even, the microservices to be merged can be directly paired. If the number of microservices to be merged is odd, one microservice to be merged needs to be removed first, and then the remaining even number of microservices to be merged are paired. The removed microservice can be the microservice whose usage rate indicators are closest to the average.

[0041] S220, if the current time is a mergable service time, the running of the microservice to be merged is directly stopped; if the current time is an unmergable service time, the running of the microservice to be merged is stopped when the mergable service time is reached.

[0042] Among them, the mergable service time is the time when the load of the microservice to be merged is low, and the unmergable service time is the time when the load of the microservice to be merged is high.

[0043] Specifically, according to the historical load of the to-be-merged microservice, the mergable service time and the un-mergable service time of the to-be-merged microservice are determined. It is determined whether the current time is the mergable service time or the un-mergable service time. If it is the un-mergable service time, the to-be-merged microservice is temporarily not merged, and the running of the to-be-merged microservice is stopped and the merging of the to-be-merged microservice is started when the mergable service time is reached. If it is the mergable service time, the running of the to-be-merged microservice is directly stopped and the merging of the to-be-merged microservice is started without waiting. By setting the mergable service time, the merging of the microservice at an inappropriate time can be avoided, thereby affecting the user experience.

[0044] S230, merging the to-be-merged microservice into a new microservice; starting the new microservice.

[0045] S240, determining an associated microservice that takes the to-be-merged microservice as a dependent service according to a dependency configuration file; modifying the dependent service of the associated microservice to the new microservice in the dependency configuration file; and restarting the associated microservice.

[0046] Wherein, the source service refers to the service caller, and the dependent service refers to the called service.

[0047] Specifically, before the service merging, the associated microservice depends on the to-be-merged microservice. After the service merging, the to-be-merged microservice no longer exists, and it is merged into the new microservice. Therefore, the dependent service of the associated microservice needs to be changed from the to-be-merged microservice to the new microservice. The dependency relationship between services is recorded in the dependency configuration file, and the dependency relationship needs to be queried and modified in the configuration file accordingly. After the modification is completed, the associated microservice also needs to be restarted to make the modified dependency relationship take effect.

[0048] Optionally, an idle service calling address is pre-configured in a domain name server;

[0049] In the domain name server, the service name of the new microservice is associated with the idle service calling address.

[0050] Wherein, the domain name server (DNS) is used to return the service calling address corresponding to the service name to the microservice in response to the service name of the dependent service sent by the microservice. The service calling address can refer to the IP and port of the inter-service call, such as the IP of the service noah-web deployment node is 192.168.1.101, and the port is 20001, the IP of the service noah-business deployment node is 192.168.2.201, and the port is also 20001. If the noah-web service calls the noah-business service, the service calling address 192.168.2.201:20001 is used for calling.

[0051] Specifically, the domain name server stores the service call addresses of each microservice. When a microservice calls a dependent service, the microservice can obtain the service call address of the dependent service from the domain name server and then call the dependent service. An idle service call address is pre-configured. When the microservices are merged, the service name of the new microservice is associated with the idle service call address in the domain name server, and the idle service call address is assigned to the new microservice. At the same time, the association between the service name of the microservice to be merged and the corresponding service call address is cancelled, and the corresponding service call address is used as a new idle service call address, thereby completing the dynamic replenishment of the idle service call address.

[0052] For example, the cluster has the following five microservices: noah-web, noah-platform, noah-core, noah-business, and noah-sync.

[0053] In the monitoring process, the microservices whose running indexes meet the merging condition are noah-platform, noah-business, and noah-sync. The three cannot form two pairs, and one needs to be removed. Among them, noah-sync is removed from the microservices to be merged because the running indexes of noah-sync are closest to the average value.

[0054] Therefore, the final merging scheme is to merge noah-platform and noah-business into a new service NS1, and noah-sync remains unchanged. According to this, the following script is executed.

[0055] Stop the services: noah-platform and noah-business.

[0056] Perform merging:

[0057] jar -xf noah-platform.jar -C tempdir /

[0058] jar -xf noah-business.jar -C tempdir /

[0059] jar -cfm NS1.jar manifest.mf -C tempdir /

[0060] Start the new service:

[0061] java -jar NS1.jar.

[0062] Repair the service call address. The service call dependency relationship is recorded in the dependency configuration file (service_dependency.yml).

[0063] The original dependency in the dependency configuration file is as follows:

[0064] Source service Dependent service

[0065] noah-web noah-business

[0066] noah-core noah-platform

[0067] The modified dependency is as follows:

[0068] Source service Dependent service

[0069] noah-web NS1

[0070] noah-core NS1

[0071] According to the service call configuration item, the service call address is changed to the new service address, and the following command is executed to restart the noah-web and noah-core systems.

[0072] java -jar noah-web.jar

[0073] java -jar noah-core.jar

[0074] After executing the above startup command, the services noah-web and noah-core change the dependency on the original services noah-platform and noah-business to NS1, and the dynamic merging of services is completed.

[0075] The embodiment of the application can avoid merging microservices at inappropriate times, thereby affecting user experience, by setting a mergable service time.

[0076] Figure 3 A structural schematic diagram of a microservice dynamic merging device provided by another embodiment of the application is shown in FIG. 3. Figure 3 As shown in the figure, the device comprises:

[0077] A service determination module 310 is configured to determine a to-be-merged microservice in a cluster according to a preset running index.

[0078] A service merging module 320 is configured to stop running of the to-be-merged microservice and merge the to-be-merged microservice into a new microservice.

[0079] A dependency modification module 330 is configured to start the new microservice and modify a dependency relationship related to the to-be-merged microservice.

[0080] The microservice dynamic merging device provided by the embodiment of the application can execute the microservice dynamic merging method provided by any embodiment of the application, and has the corresponding function modules and beneficial effects of the execution method.

[0081] Optionally, the dependency modification module 310 comprises:

[0082] The association determination unit is configured to determine, according to the dependency relationship configuration file, an associated microservice that takes the microservice to be merged as a dependent service;

[0083] The dependency modification unit is configured to modify, in the dependency relationship configuration file, the dependent service of the associated microservice to a new microservice;

[0084] The service restart unit is configured to restart the associated microservice.

[0085] Optionally, the device further comprises:

[0086] The address reservation module is configured to preconfigure an idle service calling address in a domain name server; the domain name server is configured to return, to a microservice, a service calling address corresponding to a service name of a dependent service in response to the microservice sending the service name;

[0087] The address association module is configured to associate, in the domain name server, the service name of the new microservice with the idle service calling address.

[0088] Optionally, the service merging module 320 comprises:

[0089] The direct stop unit is configured to directly stop the running of the microservice to be merged if the current time is the mergable service time;

[0090] The waiting stop unit is configured to stop the running of the microservice to be merged when the mergable service time is reached if the current time is the unmergable service time.

[0091] Optionally, the service determination module 310 comprises:

[0092] The even number division unit is configured to divide the corresponding microservices into the microservices to be merged if the number of the microservices satisfying the merging condition in the cluster is an even number;

[0093] The odd number division unit is configured to divide the microservices other than the microservice closest to the merging condition in the corresponding microservices into the microservices to be merged if the number of the microservices satisfying the merging condition in the cluster is an odd number.

[0094] Optionally, the running index package processor usage rate, memory usage rate and disk usage rate; correspondingly, the merging condition includes that the processor usage rate of the microservice is greater than the average processor usage rate of the cluster, the memory usage rate of the microservice is greater than the average memory usage rate of the cluster, and the disk usage rate of the microservice is greater than the average disk usage rate of the cluster.

[0095] The microservice dynamic merging device further illustrated can also execute the microservice dynamic merging method provided by any embodiment of the application, and has the corresponding function modules and beneficial effects of executing the method.

[0096] Figure 4 A structural schematic diagram of an electronic device 40 that can be used to implement embodiments of the application is shown. The electronic device is intended to represent various forms of digital computers, such as laptops, desktops, tablets, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular telephones, smart phones, wearable devices (e.g., headsets, glasses, watches, etc.), and other similar computing devices. The components shown here, their connections and relationships, and their functions, are meant to be examples only, and are not intended to limit the implementations of the applications described and / or claimed in this document.

[0097] As shown in Figure 4 The electronic device 40 includes at least one processor 41, and a memory, such as a read-only memory (ROM) 42, a random access memory (RAM) 43, etc., which is communicatively connected to the at least one processor 41, wherein the memory stores a computer program that can be executed by the at least one processor. The processor 41 can perform various appropriate actions and processes according to the computer program stored in the read-only memory (ROM) 42 or the computer program loaded from the storage unit 48 into the random access memory (RAM) 43. In the RAM 43, various programs and data required for the operation of the electronic device 40 can also be stored. The processor 41, the ROM 42 and the RAM 43 are connected to each other through a bus 44. An input / output (I / O) interface 45 is also connected to the bus 44.

[0098] The plurality of components in the electronic device 40 are connected to the I / O interface 45, including: an input unit 46, such as a keyboard, a mouse, etc.; an output unit 47, such as various types of displays, speakers, etc.; a storage unit 48, such as a magnetic disk, an optical disk, etc.; and a communication unit 49, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 49 allows the electronic device 40 to exchange information / data with other devices through a computer network, such as the Internet, and / or various telecommunication networks.

[0099] The processor 41 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the processor 41 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various specialized artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, and the like. The processor 41 performs various methods and processes described above, such as the dynamic merging method of microservices.

[0100] In some embodiments, the dynamic merging method of microservices can be implemented as a computer program tangibly embodied in a computer readable storage medium, such as the storage unit 48. In some embodiments, part or all of the computer program can be loaded and / or installed onto the electronic device 40 via the ROM 42 and / or the communication unit 49. When the computer program is loaded onto the RAM 43 and executed by the processor 41, one or more steps of the dynamic merging method of microservices described above can be performed. Alternatively, in other embodiments, the processor 41 can be configured to perform the dynamic merging method of microservices by any other suitable means, such as by means of firmware.

[0101] Various implementations of the systems and techniques described above can be realized in digital electronic circuitry, integrated circuitry, a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), a system on a chip (SOC), a programmable logic device (CPLD), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include implementation in one or more computer programs that are executable and / or interpretable on a programmable system including at least one programmable processor, which can be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.

[0102] Computer programs used to implement the methods of the application can be written in any combination of one or more programming languages. These computer programs can be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the computer program, when executed, implements the functions / acts specified in the flowcharts and / or block diagrams. The computer program can be executed entirely on a machine, partially on a machine, partially on a machine as a stand-alone software package, and partially on a machine or a remote machine or a server.

[0103] In the context of the present application, a computer-readable storage medium can be a tangible medium that can contain or store a computer program for use by or in connection with an instruction execution system, apparatus, or device. A computer-readable storage medium can include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium can be a machine-readable signal medium. More specific examples of a machine-readable storage medium will include one or more lines of a program of instructions in a transitory signal, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0104] To provide for interaction with a user, the systems and techniques described here can be implemented on an electronic device having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user and a keyboard and a pointing device (e.g., a mouse or a trackball) by which the user can provide input to the electronic device. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form, including acoustic, speech, or tactile input.

[0105] The systems and techniques described here can be implemented in a computing system that includes a back end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front end component (e.g., a user computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such back end, middleware, or front end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network (LAN), a wide area network (WAN), a blockchain network, and the Internet.

[0106] The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a host product in the cloud computing service system, to solve the defects of large management difficulty and weak business scalability in traditional physical host and VPS service.

[0107] It should be understood that the various forms of flow shown above can be used to reorder, add or delete steps. For example, each step described in the present application can be executed in parallel, sequentially or in a different order, as long as the desired results of the technical solutions of the present application can be achieved, which is not limited herein.

[0108] The above detailed description does not constitute a limitation on the scope of protection of the present application. Those skilled in the art should understand that various modifications, combinations, sub-combinations and substitutions can be made according to design requirements and other factors. Any modifications, equivalent replacements and improvements made within the spirit and principles of the present application shall be included in the scope of protection of the present application.

Claims

1. A method for dynamically merging microservices, characterized in that, The method includes: The microservices to be merged in the cluster are determined based on preset operational metrics. Stop the operation of the microservice to be merged, and merge the microservice to be merged into a new microservice; Start the new microservice and modify the dependencies related to the microservice to be merged accordingly; The step of stopping the operation of the microservice to be merged and merging the microservice to be merged into a new microservice includes: Stop the operation of the microservices to be merged, and decompress the executable files corresponding to the microservices to be merged one by one; The extracted files are combined and packaged to create a new executable file; Deploy the new executable file to the cluster container and start the new microservice; The corresponding modifications to the dependencies related to the microservices to be merged include: Determine the associated microservices that depend on the microservices to be merged based on the dependency configuration file; In the dependency configuration file, modify the dependent service of the associated microservice to the new microservice; Restart the associated microservice; The step of determining the microservices to be merged in the cluster based on preset operational indicators includes: If the number of microservices in the cluster that meet the merging conditions is even, then the corresponding microservices will be divided into microservices to be merged in pairs. If the number of microservices in the cluster that meet the merging conditions is odd, then the remaining microservices, except for the one closest to the merging conditions, are divided into microservices to be merged in pairs. Each microservice to be merged includes two microservices to be merged. Only one microservice to be merged needs to be merged at a time, so that at most two microservices in the cluster stop running at the same time. Before modifying the dependencies related to the microservices to be merged, the method further includes: An idle service call address is pre-configured in the domain name server; the domain name server is used to return the service call address corresponding to the service name of the dependent service sent by the microservice to the microservice. The service name of the new microservice is associated with the idle service call address in the domain name server.

2. The method according to claim 1, characterized in that, The step of stopping the operation of the microservices to be merged includes: If the current time is a time when services can be merged, then the operation of the microservices to be merged should be stopped directly. If the current time is a non-mergeable service time, then the operation of the microservice to be merged will be stopped when the mergeable service time is reached.

3. The method according to claim 1, characterized in that, The operational metrics include processor utilization, memory utilization, and disk utilization; correspondingly, the merging conditions include the microservice's processor utilization being greater than the cluster average processor utilization, the microservice's memory utilization being greater than the cluster average memory utilization, and the microservice's disk utilization being greater than the cluster average disk utilization.

4. A dynamic merging device for microservices, characterized in that, The device includes: The service determination module is used to determine the microservices to be merged in the cluster based on preset operating indicators. The service merging module is used to stop the operation of the microservice to be merged and merge the microservice to be merged into a new microservice. The dependency modification module is used to start the new microservice and modify the dependencies related to the microservice to be merged accordingly. Specifically, the service merging module is used to: stop the operation of the microservice to be merged, and decompress the executable files corresponding to the microservice to be merged one by one; combine and package the decompressed files to generate a new executable file; deploy the new executable file to the cluster container and start the new microservice; The dependency modification module includes: The association determination unit is used to determine the associated microservices that depend on the microservice to be merged, based on the dependency configuration file. A dependency modification unit is used to modify the dependent service of the associated microservice to a new microservice in the dependency configuration file. The service restart unit is used to restart the associated microservice; The service determination module includes: Even-number partitioning units are used to divide the corresponding microservices into pairs of microservices to be merged if the number of microservices in the cluster that meet the merging conditions is even. Odd-number partitioning units are used to divide the remaining microservices that need to be merged in pairs into microservices that need to be merged if the number of microservices that meet the merging conditions in the cluster is odd. Each microservice to be merged includes two microservices to be merged. Only one microservice to be merged needs to be merged at a time, so that at most two microservices in the cluster stop running at the same time. The address reservation module is used to pre-configure idle service call addresses in the domain name server; the domain name server is used to return the service call address corresponding to the service name of the dependent service sent by the microservice to the microservice. The address association module is used to associate the service name of the new microservice with the idle service call address in the domain name server.

5. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the dynamic merging method of microservices according to any one of claims 1-3.

6. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the dynamic merging method of microservices as described in any one of claims 1-3.

Images