Service group container shutdown method, device, computer equipment and storage medium
By introducing a service group container shutdown method in a large distributed system, the problem of resource interaction link disconnection during container shutdown is solved, and containers are quickly removed, shortening maintenance time and improving maintenance efficiency.
Patent Information
- Application Number
- CN202211039755.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-08-29
- Publication Date
- 2025-06-17
- Estimated Expiration
- 2042-08-29
AI Technical Summary
In large enterprise-level distributed systems, the downtime of application containers is likely to cause the resource interaction link to be disconnected, resulting in the interruption of some operational resource interaction requests, affecting customer experience and increasing operation and maintenance workload. The prior art is difficult to ensure that all resource interactions are completed during shutdown, and the container cannot handle resource interactions during shutdown, resulting in inefficient maintenance.
Provide a service group container shutdown method, by obtaining the container's shutdown instructions, deleting the container information, checking resource interaction information, starting the shutdown timer, and releasing the running resources and executing the container's shutdown and downline when the calculation time of the shutdown timer is greater than the preset waiting time.
This method can quickly remove the containers of the service group without interrupting the interactive processing of the current target resource, shorten maintenance time, improve container maintenance efficiency, and improve the downtime speed of the application system and version upgrade efficiency.
Smart Images

Figure CN115373886B_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of big data technology, and in particular, to a method and device for stopping a service group container, a computer device, and a storage medium. Background Art
[0002] With the development of big data technology, especially the application of distributed systems, a technology for stopping application containers has emerged. Due to business complexity, large enterprise-level distributed systems usually require thousands of containers. This technical architecture can greatly improve the system concurrency. However, when a large number of application containers restart and upgrade versions, it is extremely easy to cause disconnection of upstream and downstream containers in the resource interaction link, resulting in interruption of some unclosed running resource interaction requests. It is necessary to retrospectively analyze the cause of the failure and perform data backfilling operations afterwards, which not only affects the customer experience, but also increases the workload of background operation and maintenance and generates the risk of resource loss.
[0003] Currently, the shutdown process of most distributed system application containers in the industry is to wait for a fixed time before the system stops service to allow the running resource interaction to continue to be processed, and then stop the server. However, the method of waiting for a fixed time is difficult to ensure that all running resource interactions are completed during shutdown, and it is easy to cause resource waste and too much time consumption in the case of less or no resource interaction in the server resource interaction. In addition, the container cannot process resource interaction during shutdown, and at the same time, the registration center of most distributed systems can only check whether the registered service interfaces are normal and cannot determine whether the container itself is already in the shutdown process, resulting in low shutdown maintenance efficiency of the container. Summary of the Invention
[0004] Based on this, in view of the above technical problems, it is necessary to provide a method and device for stopping a service group container, a computer device, a computer-readable storage medium, and a computer program product that can effectively shorten the maintenance time and improve the container maintenance efficiency.
[0005] In a first aspect, the present application provides a method for stopping a service group container. The method includes: obtaining a stop instruction corresponding to each container in the service group, and deleting the corresponding container information in the container list according to the stop instruction; checking the resource interaction information in the corresponding resource exchange queue in each container according to each stop instruction to obtain a resource interaction information check result; and starting a stop timer corresponding to each container according to the stop instruction; in the case where the resource interaction information check result indicates the existence of a target resource interaction, comparing the stop calculation duration of the stop timer with a preset stop waiting duration; the target resource interaction is the resource interaction being processed by the container; in the case where the stop calculation duration is greater than the preset stop waiting duration, releasing the running resources corresponding to the container, and stopping the operation of the container and taking the container offline from the service group according to the stop instruction.
[0006] In one embodiment, the method further includes: obtaining the reading situation of the container set list corresponding to all the containers in the service group, and the reading situation of the list of non-stopped containers in the service group; in the case where the reading situations of the container set list and the list of non-stopped containers are successful, comparing the container set list with the list of non-stopped containers to select a corresponding available container list for the service group to call the corresponding container; and invoking the container according to the available container list to process the to-be-processed service requirements corresponding to the service group.
[0007] In one embodiment, the invoking the container according to the available container list to process the to-be-processed service requirements corresponding to the service group includes: obtaining an interface call chain corresponding to the service group, and at least one load balancing method preset for the interface call chain, the load balancing method being calculated by a preset load balancing algorithm in the service group; determining an optimal callable container combination list that meets the to-be-processed service requirements of the service group according to the available container list and the at least one load balancing method corresponding to the interface call chain; and invoking the container according to the optimal callable container combination list to process the to-be-processed service requirements corresponding to the service group.
[0008] In one embodiment, after obtaining the reading status of the container set list corresponding to all the containers in the service group and the reading status of the list of non-shutdown containers in the service group, the method further includes: if the reading status of the container set list is unsuccessful, or the reading status of the list of non-shutdown containers is unsuccessful, or the reading status of the container set list and the reading status of the list of non-shutdown containers are both unsuccessful, then execute the step of obtaining the interface call chain corresponding to the service group.
[0009] In one embodiment, the invoking of the container includes: executing the interface call chain corresponding to the interface invoked by the current container according to the distributed call request corresponding to the previous container; adding a monitoring probe processor to the interface call chain based on the bytecode corresponding to the interface call chain, and generating an event number according to the monitoring probe processor, where the event number is an identifier of the resource interaction information; executing the service requirements to be processed corresponding to the interface call chain of the current container, and using the distributed call request to generate a response message for the next container; feeding back the response message of the next container to the previous container, and deleting the resource interaction information according to the event number.
[0010] In one embodiment, the generating of the event number includes: generating an incrementing serial number corresponding to the container according to the resource interaction information corresponding to the container; generating the event number according to the incrementing serial number, the channel type dictionary, the server number, the resource interaction date, the resource interaction time, and the resource interaction operator number.
[0011] In one embodiment, after comparing the shutdown calculation duration of the shutdown timer with a preset shutdown waiting duration when the resource interaction information check result indicates the existence of running resource interaction, the method further includes: if the shutdown duration comparison result is that the shutdown calculation duration is less than or equal to the preset shutdown waiting duration, then return to execute the step of checking the resource interaction information in the resource exchange queue corresponding to each container to obtain the resource interaction information check result; until the resource interaction information check result indicates the non-existence of running resource interaction, or the shutdown duration comparison result is that the shutdown calculation duration is greater than the preset shutdown waiting duration.
[0012] Second aspect, the present application also provides a service group container shutdown device. The device includes: an instruction acquisition module, configured to acquire shutdown instructions corresponding to each container in the service group, and delete the corresponding container information in the container list according to the shutdown instructions; an information check module, configured to check the resource interaction information in the corresponding resource exchange queue in each container according to each shutdown instruction to obtain a resource interaction information check result; and start a shutdown timer corresponding to each container according to the shutdown instruction; a duration comparison module, configured to compare the shutdown calculation duration of the shutdown timer with a preset shutdown waiting duration when the resource interaction information check result indicates the existence of target resource interaction; the target resource interaction is the resource interaction being processed by the container; a shutdown execution module, configured to release the running resources corresponding to the container and execute stopping the operation of the container and taking the container offline from the service group according to the shutdown instruction when the shutdown calculation duration is greater than the preset shutdown waiting duration.
[0013] In one embodiment, the available container list obtaining module is configured to: acquire the reading situation of the container set list corresponding to all the containers in the service group and the reading situation of the list of non-shutdown containers in the service group; when the reading situation of the container set list and the reading situation of the list of non-shutdown containers are successful, compare the container set list with the list of non-shutdown containers, and select the available container list corresponding to the container, where the available container list is used for the service group to call the corresponding container; and according to the available container list, retrieve the container to process the to-be-processed service requirements corresponding to the service group.
[0014] In one embodiment, the available container list obtaining module is configured to: acquire the interface call chain corresponding to the service group and at least one load balancing method preset for the interface call chain, where the load balancing method is calculated by a preset load balancing algorithm in the service group; determine an optimal callable container combination list corresponding to the to-be-processed service requirements of the service group according to the available container list and the at least one load balancing method corresponding to the interface call chain; and retrieve the container to process the to-be-processed service requirements corresponding to the service group through the optimal callable container combination list.
[0015] In one embodiment, the available container list obtaining module is configured to: execute the step of acquiring the interface call chain corresponding to the service group when the reading situation of the container set list is unsuccessful, or the reading situation of the list of non-shutdown containers is unsuccessful, or the reading situations of the container set list and the list of non-shutdown containers are both unsuccessful at the same time.
[0016] In one embodiment, the available container list obtaining module is configured to: execute the interface call chain corresponding to the interface called by the current container according to the distributed call request corresponding to the previous container; based on the bytecode corresponding to the interface call chain, add a monitoring probe processor to the interface call chain, and generate an event number according to the monitoring probe processor, where the event number is an identifier of the resource interaction information; execute the to-be-processed service requirements corresponding to the interface call chain of the current container, and use the distributed call request to generate an answer message for the next container; feedback the answer message of the next container to the previous container, and delete the resource interaction information according to the event number.
[0017] In one embodiment, the available container list obtaining module is configured to: generate an incrementing serial number corresponding to the container according to the resource interaction information corresponding to the container; generate the event number according to the incrementing serial number, the channel type dictionary, the server number, the resource interaction date, the resource interaction time, and the resource interaction operator number.
[0018] In one embodiment, the duration comparison module is configured to: when the shutdown duration comparison result is that the shutdown calculation duration is less than or equal to the preset shutdown waiting duration, return to execute the step of checking the resource interaction information in the corresponding resource exchange queue of each container to obtain a resource interaction information check result; until the resource interaction information check result is that there is no running resource interaction, or the shutdown duration comparison result is that the shutdown calculation duration is greater than the preset shutdown waiting duration.
[0019] In a third aspect, the present application further provides a computer device. The computer device includes a memory and a processor. The memory stores a computer program. When the processor executes the computer program, the following steps are implemented: obtain shutdown instructions corresponding to each container in the service group, and delete the corresponding container information in the container list according to the shutdown instructions; check the resource interaction information in the corresponding resource exchange queue of each container according to each shutdown instruction to obtain a resource interaction information check result; and start a shutdown timer corresponding to each container according to the shutdown instructions; when the resource interaction information check result is that there is a target resource interaction, compare the shutdown calculation duration of the shutdown timer with the preset shutdown waiting duration; the target resource interaction is the resource interaction being processed by the container; when the shutdown calculation duration is greater than the preset shutdown waiting duration, release the running resources corresponding to the container, and execute stop running of the container and take the container offline from the service group according to the shutdown instructions.
[0020] Fourth aspect, the present application further provides a computer-readable storage medium. On the computer-readable storage medium, there is a computer program stored, and when the computer program is executed by a processor, the following steps are implemented: obtaining a shutdown instruction corresponding to each container in a service group, and deleting the corresponding container information in a container list according to the shutdown instruction; checking, according to each shutdown instruction, resource interaction information in a corresponding resource exchange queue in each container to obtain a resource interaction information check result; and starting a shutdown timer corresponding to each container according to the shutdown instruction; when the resource interaction information check result indicates the existence of a target resource interaction, comparing the shutdown calculation duration of the shutdown timer with a preset shutdown waiting duration; the target resource interaction is the resource interaction being processed by the container; when the shutdown calculation duration is greater than the preset shutdown waiting duration, releasing the running resources corresponding to the container, and executing stopping the operation of the container and taking the container offline from the service group according to the shutdown instruction.
[0021] Fifth aspect, the present application further provides a computer program product. The computer program product includes a computer program, and when the computer program is executed by a processor, the following steps are implemented: obtaining a shutdown instruction corresponding to each container in a service group, and deleting the corresponding container information in a container list according to the shutdown instruction; checking, according to each shutdown instruction, resource interaction information in a corresponding resource exchange queue in each container to obtain a resource interaction information check result; and starting a shutdown timer corresponding to each container according to the shutdown instruction; when the resource interaction information check result indicates the existence of a target resource interaction, comparing the shutdown calculation duration of the shutdown timer with a preset shutdown waiting duration; the target resource interaction is the resource interaction being processed by the container; when the shutdown calculation duration is greater than the preset shutdown waiting duration, releasing the running resources corresponding to the container, and executing stopping the operation of the container and taking the container offline from the service group according to the shutdown instruction.
[0022] The above service group container shutdown method, device, computer device, storage medium, and computer program product obtain shutdown instructions corresponding to each container in the service group, and delete the corresponding container information in the container list according to the shutdown instructions; check the resource interaction information in the corresponding resource exchange queue in each container according to each shutdown instruction to obtain a resource interaction information check result; and start the shutdown timer corresponding to each container according to the shutdown instruction; in the case where the resource interaction information check result indicates the existence of a target resource interaction, compare the shutdown calculation duration of the shutdown timer with a preset shutdown waiting duration; the target resource interaction is the resource interaction being processed by the container; in the case where the shutdown calculation duration is greater than the preset shutdown waiting duration, release the running resources corresponding to the container, and stop the operation of the container and take the container offline from the service group according to the shutdown instruction.
[0023] By treating mechanisms such as service registration, service routing, and caching in the distributed system, when starting the container shutdown process of the service group, it is ensured that no new resource interaction requests enter the current container, and on the premise of not interrupting the processing of the current target resource interaction, the containers of the service group are quickly taken offline in the shortest time, realizing the quick shutdown of the application system, reducing the time window for version maintenance, and improving the efficiency of application version upgrade. BRIEF DESCRIPTION OF THE DRAWINGS
[0024] Figure 1 It is an application environment diagram of the service group container shutdown method in an embodiment;
[0025] Figure 2 It is a flowchart of the service group container shutdown method in an embodiment;
[0026] Figure 3 It is a flowchart of the method for obtaining an available container list in an embodiment;
[0027] Figure 4 It is a flowchart of the method for obtaining an optimal callable container combination list in an embodiment;
[0028] Figure 5 It is a flowchart of the method for unsuccessful reading in an embodiment;
[0029] Figure 6 It is a flowchart of the method for invoking a container in an embodiment;
[0030] Figure 7 It is a flowchart of the method for generating a time number in an embodiment;
[0031] Figure 8 It is a flowchart of the method for not satisfying the condition that the shutdown calculation duration is greater than the shutdown waiting duration in an embodiment;
[0032] Figure 9 It is a structural block diagram of a distributed system device in an embodiment;
[0033] Figure 10 It is a structural block diagram of a service group container shutdown device in an embodiment;
[0034] Figure 11 It is an internal structure diagram of a computer device in an embodiment. Detailed implementation manners
[0035] In order to make the objectives, technical solutions and advantages of the present application more clear and understandable, the present application will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.
[0036] The service group container shutdown method provided by the embodiments of the present application can be applied to an application environment such as Figure 1 as shown. The terminal 102 acquires data, the server 104 responds to the instruction of the terminal 102 to receive the data of the terminal 102, and calculates the acquired data. The server 104 transmits the calculation result of the data back to the terminal 102, and the terminal 102 displays it. Among them, the terminal 102 communicates with the server 104 through a network. The data storage system can store the data that the server 104 needs to process. The data storage system can be integrated on the server 104, or placed in the cloud or other network servers. The server 104 acquires the shutdown instructions corresponding to each container in the service group from the terminal 102, and deletes the corresponding container information in the container list according to the shutdown instructions; according to each shutdown instruction, checks the resource interaction information in the corresponding resource exchange queue in each container to obtain a resource interaction information check result; and, starts the shutdown timer corresponding to each container according to the shutdown instruction; in the case where the resource interaction information check result is that there is a target resource interaction, compares the shutdown calculation duration of the shutdown timer with a preset shutdown waiting duration; the target resource interaction is the resource interaction being processed by the container; in the case where the shutdown calculation duration is greater than the preset shutdown waiting duration, releases the running resources corresponding to the container, and stops the container from running and takes the container offline from the service group according to the shutdown instruction. Among them, the terminal 102 can be but is not limited to various personal computers, laptop computers, smart phones, tablet computers, Internet of Things devices and portable wearable devices. The Internet of Things devices can be smart speakers, smart TVs, smart air conditioners, smart vehicle-mounted devices, etc. The portable wearable devices can be smart watches, smart bracelets, head-mounted devices, etc. The server 104 can be implemented by an independent server or a server cluster composed of multiple servers.
[0037] In one embodiment, such as Figure 2As shown, a method for stopping service group containers is provided. Taking the server in Figure 1 as an example for illustration, the method includes the following steps:
[0038] Step 202: Obtain the stop instructions corresponding to each container in the service group, and delete the corresponding container information in the container list according to the stop instructions.
[0039] Among them, the service group can be a server farm, which is used to describe a group of enterprise servers located at a certain location. These servers are connected to the enterprise intranet at high speed and are usually placed together with a security firewall and a WEB cache server. The server farm provides various services including database access, email, and DNS. The servers in the group are often used as multicast sources.
[0040] Among them, the container can be one of the engines in the server, which allows developers to package their applications and dependent packages in a unified manner into a portable container, and then publish it to any server installed with the engine (including popular Linux machines and Windows machines), and virtualization can also be achieved. Containers fully use the sandbox mechanism and there will be no interfaces between them.
[0041] Among them, the stop instruction can be an instruction that causes the container in the service group to pause running the corresponding program and go offline from the service group.
[0042] Among them, the container list can be a list that stores the container information of each container in the service group and the data related to the container.
[0043] Among them, the container information can be the inherent information carried by each container in the service group, such as the container IP, etc.
[0044] Specifically, the server responds to the instruction of the terminal, obtains the stop instructions corresponding to at least two containers from the terminal, and executes the command to delete the corresponding container information in the container list according to the code in the stop instructions. Each service group supports a distributed composition that does not interrupt business during shutdown, as shown in Figure 9 as follows: including: Service Group 1, Service Group 2, Service Group 3... Service Group n. Any service group is composed of multiple application containers deployed with the same program. The service group has a distributed service registry, a cache device, and a monitoring center device.
[0045] Among them, the distributed service registry is used to record information about each microservice, such as the name, IP, port, etc. of the microservice. When the microservice application container starts, it registers its own information with the registry. The registry provides query APIs and management APIs. The query APIs are used to query available microservice instances, and the management APIs are used for service registration and deregistration.
[0046] Among them, the cache device is managed and controlled by a server, and multiple account endpoints store data, enabling high-performance data reading for distributed group containers.
[0047] Among them, the monitoring center device is used to receive various system performance indicators, transaction data, alarm information, etc. during the operation of the service cluster, and realizes functions such as fault troubleshooting, event analysis, application warning, and management cockpit.
[0048] Each service group application container realizes the publication and subscription of service interfaces through the distributed registry. When the application container starts as an interface provider, it first writes relevant information to the registry, such as the interface name, container IP address, and port, etc. After waiting for all functions inside the container to be initialized and the container to have the ability to provide services, it then writes the current container information to the available status container list of the cache device.
[0049] For example, the server 104 obtains the shutdown instruction A corresponding to each container of the service groups 1-10 from the terminal 102, and deletes the container information of the corresponding container from the container list containing the container information of each container in the service groups 1-10 according to the obtained shutdown instruction A.
[0050] Step 204, according to each shutdown instruction, check the resource interaction information in the corresponding resource exchange queue of each container to obtain a resource interaction information check result; and start the shutdown timer corresponding to each container according to the shutdown instruction.
[0051] Among them, the resource exchange queue can be a queue of data such as commands, information, and status for resource exchange required by each container in the service group.
[0052] Among them, the resource interaction information can be information in the resource exchange queue indicating whether there is ongoing resource interaction, already completed resource interaction, or no resource interaction.
[0053] Among them, the resource interaction information check result can be the result obtained after traversing the resource exchange information in the resource exchange queue. Generally, the resource interaction information check result is that there is ongoing resource interaction, no resource interaction has started, or the resource interaction has ended.
[0054] Among them, the shutdown timer can be used to calculate the time interval from when each container in the service group receives the shutdown command to the current time.
[0055] Specifically, for any container shutdown in any service cluster, first delete the container information of this container from the container list in the storage unit of the cache. At the same time, in response to the shutdown instruction, start the shutdown timer. When starting the shutdown timer, synchronously check whether there is any ongoing unclosed resource interaction in the resource interaction information in the resource exchange queue corresponding to the current container, and obtain the resource interaction information check result. Among them, deleting the container information, starting the shutdown timer, and checking whether there is any ongoing unclosed resource interaction are executed simultaneously by the service group according to the code in the shutdown instruction. Among them, when the resource interaction is closed-loop, the corresponding event number will be deleted from the resource exchange queue. Therefore, when the resource exchange queue is not empty, it means that there is still unclosed resource interaction.
[0056] For example, when the server points to the shutdown instruction A, traverse the resource interaction information in the resource exchange queue of any container in the service group 1-10, and at the same time input the resource interaction information result (traversal result); at the same time, the shutdown timer of the container will be started to calculate the time interval t from the start of shutdown to the current time.
[0057] Step 206, in the case where the resource interaction information check result indicates the existence of target resource interaction, compare the shutdown calculation duration of the shutdown timer with the preset shutdown waiting duration.
[0058] Among them, the target resource interaction can be that the current container is processing a resource interaction task, that is, any resource exchange task in the resource exchange queue is being executed.
[0059] Among them, the shutdown calculation duration can be the time interval from when the shutdown timer starts to calculate from the execution of the shutdown instruction to the current time.
[0060] Among them, the shutdown waiting duration can be the longest shutdown waiting duration preset in the server for comparison. That is to say, if the shutdown calculation duration exceeds the shutdown waiting duration, subsequent commands will be executed. This time is configured according to the average consumption time of resource interaction in different environments and business scenarios.
[0061] Specifically, if the resource interaction information check result indicates that the container is in the process of handling a resource interaction task, then further compare the downtime calculation duration calculated by the downtime timer with the preset downtime waiting duration in the server to obtain the comparison result of the downtime calculation duration and the downtime waiting duration; in the case where the resource interaction information check result indicates that the container is not in the process of handling a resource interaction task, then execute the stop operation on the container and take the container offline from the service group according to the downtime instruction.
[0062] For example, if the resource interaction information check result indicates that containers a - g are in the process of handling a resource interaction task, then further compare the downtime calculation duration t calculated by the downtime timer with the preset downtime waiting duration T in the server to obtain the comparison result of the downtime calculation duration t and the downtime waiting duration T.
[0063] Step 208, in the case where the downtime calculation duration is greater than the preset downtime waiting duration, release the running resources corresponding to the container, and execute the stop operation on the container and take the container offline from the service group according to the downtime instruction.
[0064] Among them, the running resources can include database connections, network connections, local cache spaces, etc. in the server.
[0065] Specifically, if the resource interaction information check result indicates that there is a container in the process of handling a resource interaction task and at the same time the downtime calculation duration is greater than the preset downtime waiting duration, then execute the instruction for releasing container resources in the downtime command, that is, release including database connections, network connections, local cache spaces, etc., and then according to the downtime steps in the downtime instruction, correspondingly execute the stop operation on the corresponding container and take the container offline from the service group; in the case where the resource interaction information check result indicates that there is a container in the process of handling a resource interaction task and the downtime calculation duration is not greater than the preset downtime waiting duration, then return to the step of checking the resource interaction information in the corresponding resource exchange queue in each container to obtain the resource interaction information check result until one of the two conditions is met: the resource interaction information check result indicates that the container is not in the process of handling a resource interaction task, or the downtime calculation duration is greater than the preset downtime waiting duration.
[0066] For example, if it is checked that the resource interaction information check result of containers a - g is that there is a container in the process of handling a resource interaction task and at the same time the downtime calculation duration t is greater than the preset downtime waiting duration T, then execute the instruction b for releasing container resources in the downtime command A, and then according to the downtime steps in the downtime command A, correspondingly execute the stop operation on the corresponding containers a - g and take the containers a - g offline from the service group.
[0067] In the above method for stopping the service group containers, stop instructions corresponding to each container in the service group are obtained, and the corresponding container information in the container list is deleted according to the stop instructions; according to each stop instruction, the resource interaction information in the corresponding resource exchange queue in each container is checked to obtain a resource interaction information check result; and, a stop timer corresponding to each container is started according to the stop instruction; when the resource interaction information check result indicates the existence of a target resource interaction, the stop calculation duration of the stop timer is compared with a preset stop waiting duration; the target resource interaction is the resource interaction being processed by the container; when the stop calculation duration is greater than the preset stop waiting duration, the running resources corresponding to the container are released, and the container is stopped and taken offline from the service group according to the stop instruction.
[0068] By means of mechanisms such as service registration, service routing, and caching in the distributed system to be processed, when starting the container stop process of the service group, it is ensured that no new resource interaction requests enter the current container, and on the premise of not interrupting the processing of the current target resource interaction, the containers of the service group are quickly taken offline in the shortest time, the application system is quickly stopped, the time window for version maintenance is reduced, and the application version upgrade efficiency is improved.
[0069] In one embodiment, as Figure 3 shown, the method further includes:
[0070] Step 302, obtaining the reading situation of the container set list corresponding to all containers in the service group and the reading situation of the list of non-stopped containers in the service group.
[0071] Among them, the reading situation may be the result of whether the service group successfully reads the container set list and the list of non-stopped containers in the containers.
[0072] Specifically, the changed situation of each container in the service group will be returned to the monitoring center device of the service group, and the container set list in the monitoring center device and the list of non-stopped containers in the cache will be updated in real time. When the service group responds to the stop instruction, the service group will read the container set list corresponding to all containers in the monitoring center device and the list of non-stopped containers that have not been stopped in the cache, and output the reading situation indicating whether the reading is successful. A successful reading is indicated by "yes", and an unsuccessful reading is indicated by "no".
[0073] For example, the container set list h of all containers 1-n in the service group and the list i of non-stopped containers that have not been stopped among containers 1-n in the service group are read, and the reading situations of the container combination list h and the list of non-stopped containers i are output respectively.
[0074] Step 304, when the reading of the container set list and the reading of the list of non-shutdown containers are successful, the container set list is compared with the list of non-shutdown containers to select the available container list corresponding to the container.
[0075] Among them, the available container list can be the list corresponding to the containers that can be used for service group calls. For subsequent container calls, containers will be selected from the available container list.
[0076] Specifically, if the reading of the container set list is "yes" and the reading of the list of non-shutdown containers is also "yes", satisfying the condition for comparing the container set list with the list of non-shutdown containers, then the list information corresponding to the container set list is compared with the list information corresponding to the list of non-shutdown containers, and the list corresponding to the containers that can be used for service group calls is selected from the comparison results.
[0077] For example, if the readings of both the container set list h and the list of non-shutdown containers i are output as "yes", then the list information of the container set list h is further compared with the list information of the list of non-shutdown containers i to select the available container list j corresponding to the containers that can be called.
[0078] Step 306, according to the available container list, retrieve containers to process the pending business requirements corresponding to the service group.
[0079] Among them, the pending business requirements can be at least one resource interaction task to be processed in the service group, which is input into the service group in a queued manner.
[0080] Specifically, according to the available container information in the available container list, the container corresponding to the service group with the largest computing power is preferentially selected to execute the pending business requirements. If the service group with the largest computing power cannot meet the current pending business requirements, multiple service groups are sequentially selected for combined processing according to the computing power to meet the pending business requirements corresponding to the service group.
[0081] For example, according to the available container list j, appropriate containers 1-m are selected from it to be used for the service group to process the corresponding pending business requirements.
[0082] In this embodiment, by obtaining the reading of the container combination list and the list of non-shutdown containers, further comparing the differences between the container combination list and the list of non-shutdown containers, selecting the containers that can meet the business requirements to form an available container list, and selecting appropriate containers from the available container list for calculation, it is possible to use appropriate container configurations to solve the business requirements and improve the computing efficiency of the service group.
[0083] In one embodiment, as Figure 4 shown, according to the available container list, retrieve containers to process the to-be-processed service requirements corresponding to the service group, including:
[0084] Step 402, obtain the interface call chain corresponding to the service group, and at least one load balancing method preset for the interface call chain.
[0085] Among them, the interface call chain can be the process of a system completing a business call. During this process, the interface call information between services is logged, and then all the logged interface data is connected into a tree-like chain.
[0086] Among them, the load balancing method can be calculated through a preset load balancing algorithm in the service group, and the load balancing algorithm can be an algorithm that distributes the load to multiple operating units (servers, middleware) for execution.
[0087] Specifically, obtain the data of the interfaces of all service groups corresponding to the previous processing resource interaction tasks, and log them into the log data table. Then, generate an interface call chain based on the logged data in the log data table for subsequent resource interaction tasks to use. At the same time, use the preset load balancing algorithm in the service group to calculate multiple load balancing methods for subsequent balanced allocation of resource interaction tasks. Among them, the load balancing algorithm can be round-robin, ratio, priority, least connections, fastest mode, observed mode, predictive mode, dynamic performance allocation, dynamic server supplementation, quality of service, service type, and rule mode.
[0088] For example, obtain the interface call chain corresponding to interfaces 1 - 100 in the service group. At the same time, three different dynamic load methods calculated by the dynamic performance allocation load balancing algorithm, rule mode, and predictive mode are preset for the interface call chain.
[0089] Step 404, determine the optimal list of callable container combinations that meet the to-be-processed service requirements of the service group according to the available container list and at least one load balancing method corresponding to the interface call chain.
[0090] Among them, the optimal list of callable container combinations can be a list formed by containers that can be called by the service group and have the best load pattern.
[0091] Specifically, based on the available containers in the available container list and the service groups corresponding to the available containers, at least one load balancing method is selected from multiple load balancing methods corresponding to the interface call chain for calculation, so as to further determine the optimal callable container combination list corresponding to the pending service requirements of the service group. The optimal callable container combination list includes multiple callable containers and the service groups corresponding to the callable containers.
[0092] For example, based on the available container list j, and selecting load balancing methods 1-3 from the load balancing methods 1-10 corresponding to the interface call chain, further determine the optimal callable container combination list k corresponding to the pending service requirements of the service group.
[0093] Step 406, through the optimal callable container combination list, retrieve containers to process the pending service requirements corresponding to the service group.
[0094] Specifically, according to the optimal container information in the optimal callable container combination list, preferentially select the containers corresponding to the service group with the largest computing power to execute the pending service requirements. If the service group with the largest computing power cannot meet the current pending service requirements, then select multiple service groups for combined processing in sequence according to the computing power size, so as to meet the pending service requirements corresponding to the processing service group.
[0095] For example, according to the optimal callable container combination list k, select appropriate containers 1-h therefrom for use in processing the pending service requirements corresponding to the service group.
[0096] In this embodiment, by using the interface call chain and the load balancing method to select the optimal callable container combination from the available container list to form a list, and selecting the optimal container combination from the optimal callable container combination list for calculation, it is possible to use the optimized container configuration to solve the business requirements and improve the computing efficiency of the service group.
[0097] In one embodiment, as Figure 5 shown, after obtaining the reading situation of the container set list corresponding to all containers in the service group and the reading situation of the list of non-shutdown containers in the service group, it further includes:
[0098] Step 502, if the reading situation of the container set list is unsuccessful, or the reading situation of the list of non-shutdown containers is unsuccessful, or the reading situations of the container set list and the list of non-shutdown containers are both unsuccessful at the same time, then execute the step of obtaining the interface call chain corresponding to the service group.
[0099] Specifically, if the reading status of the container set list is false, or the reading status of the non-shutdown container list is false, or if the reading status of the container set list is false and at the same time the reading status of the non-shutdown container list is also false, then return to execute the step of "obtaining the data of all service groups corresponding to the previous processing resource interaction task, logging it to the log data table, and generating an interface call chain based on the large point data in the log data table for subsequent resource interaction tasks to use".
[0100] For example, if the reading status output of the container set list h is false, or the reading status output of the non-shutdown container list i is false, or if both the reading status of the container set list h and the non-shutdown container list i are false, then return to execute the step of "obtaining the interface call chain corresponding to interfaces 1-100 in the service group".
[0101] In this embodiment, by monitoring the unsuccessful reading of the container set list and the non-shutdown container list, and immediately jumping to the step of obtaining the interface call chain when the reading is unsuccessful, it is possible to reduce the waste of resources in the service group caused by further reading due to reading problems and improve the working efficiency of the service group.
[0102] In one embodiment, as Figure 6 shown, retrieving a container includes:
[0103] Step 602, execute the interface call chain corresponding to the interface called by the current container according to the distributed call request corresponding to the previous container.
[0104] Among them, the distributed call request can be a set of resource interaction tasks that at least one service group needs to process.
[0105] Specifically, receive the distributed remote procedure call request corresponding to the previous container and start executing the interface call chain for the interface by which the current container is to be called.
[0106] For example, according to the distributed call request corresponding to container No. 1, start executing the interface call chain corresponding to the interface called by container No. 2
[0107] Step 604, based on the bytecode corresponding to the interface call chain, add a monitoring probe processor to the interface call chain and generate an event number according to the monitoring probe processor.
[0108] Among them, the bytecode can be a binary file containing an execution program, consisting of a sequence of op code / data pairs, and is an intermediate code.
[0109] Among them, the monitoring probe processor can monitor the wireless network environment by listening to wireless packets sent by devices supporting the 802.11 protocol, quickly discover and obtain wireless devices existing in the surrounding wireless network environment, obtain relevant information of the devices, generate corresponding entries and directly send them to the specified server.
[0110] Among them, the event number can be the unique identifier for any resource interaction task, and the situation of the resource interaction task can be read from this identifier.
[0111] Specifically, based on the bytecode, JVM virtual machine technology, and the filter mechanism of the distributed framework, a monitoring probe processor is added to the interface call chain. The monitoring probe processor is triggered before the interface logic is executed, and the event number formed by concatenating the fields of the request packet generated by the monitoring probe processor is used as the unique identifier of the resource interaction task and recorded in the resource exchange queue.
[0112] For example, according to the bytecode, JVM virtual machine technology, and the filter mechanism of the distributed framework, a monitoring probe processor C is added to the interface call chain, and the event number S is generated according to the monitoring probe processor C.
[0113] Step 606, execute the to-be-processed business requirements corresponding to the interface call chain of the current container, and use the distributed call to request the next container to generate an answer packet.
[0114] Among them, the answer packet can be data used for information communication between different containers.
[0115] Specifically, after executing the to-be-processed business requirements corresponding to the interface call chain of the current container, use the distributed remote procedure call to request to call the next container, and the next container generates an answer packet, or just execute the to-be-processed business requirements corresponding to the interface call chain of the current container.
[0116] For example, execute the to-be-processed business requirements corresponding to the interface call chain of the current container 2, and use the distributed call to request the next container 3 to generate an answer packet 3.
[0117] Step 608, feedback the answer packet of the next container to the previous container, and delete the resource interaction information according to the event number.
[0118] Specifically, generate an answer packet, and feedback the answer packet of the next container to the previous container, and then find and delete the current resource interaction information from the resource exchange queue according to the event number generated in step 604, or just execute finding and deleting the current resource interaction information from the resource exchange queue according to the event number generated in step 604.
[0119] In this embodiment, in the method of the interface call chain according to the distributed call request, when there is a resource interaction task in the resource exchange queue that has not completed the closed loop within the preset threshold time range, the resource interaction task is deleted from the resource exchange queue, and the event number and resource interaction information are sent to the monitoring center device. It can achieve timely discovery of resource interaction tasks that do not meet the threshold time requirements and improve the efficiency of the current service group.
[0120] In one embodiment, as Figure 7 shown, generating an event number includes:
[0121] Step 702, generate an incrementing serial number corresponding to the container according to the resource interaction information corresponding to the container.
[0122] Among them, the incrementing serial number can be the case where any one condition is triggered and then the serial number is incremented.
[0123] Specifically, an atomic variable with thread safety is generated in the container memory. Each time the container receives a resource interaction, the atomic variable is used to increment and obtain the incrementing serial number. When the value of the atomic variable increments to the maximum value, it is reset to the minimum value.
[0124] Step 704, generate an event number according to the incrementing serial number, channel type dictionary, server number, resource interaction date, resource interaction time, and resource interaction operator number.
[0125] Specifically, the event number corresponding to the resource interaction is generated by sequentially concatenating the channel type dictionary + server number + resource interaction date + resource interaction time + resource interaction operator number + incrementing serial number.
[0126] For example, if the dictionary of the channel of the resource interaction machine is 02, when the server number is 0012, the resource interaction date and resource interaction time are 9:30:15 on May 15, 2022, and the resource interaction operator number is 00689741, and the obtained incrementing serial number is 109657, the concatenated event number is 0200122022051509301500689741109657.
[0127] In this embodiment, through the above combination method, it can be ensured that the event numbers of each resource interaction in the service group are unique, avoiding the generation of the same event number for different resource interactions, which may lead to misjudgment when checking ongoing resource transactions in the subsequent shutdown process. At the same time, it also makes the event number have a certain meaning, providing convenience for troubleshooting problems and monitoring and analyzing using the event number in the future.
[0128] In one embodiment, as Figure 8As shown, when the resource interaction information check result indicates the existence of running resource interactions, after comparing the shutdown calculation duration of the shutdown timer with the preset shutdown waiting duration, the following steps are also included:
[0129] Step 802, when the shutdown duration comparison result shows that the shutdown calculation duration is less than or equal to the preset shutdown waiting duration, return to the step of checking the resource interaction information in the corresponding resource exchange queue in each container to obtain the resource interaction information check result.
[0130] Specifically, if the resource interaction information check result indicates that there is a resource interaction task in progress, but at the same time the shutdown calculation duration is less than or equal to the preset shutdown waiting duration, then return to execute the step of "for any container shutdown in any service cluster, first delete the container information of this container in the container list in the cache storage unit, and at the same time check whether there are ongoing unclosed resource interactions in the resource interaction information in the resource exchange queue corresponding to the current container to obtain the resource interaction information check result".
[0131] For example, if the resource interaction information check result for containers a - g is found to have a resource interaction task in progress, and at the same time the shutdown calculation duration t is less than or equal to the preset shutdown waiting duration T, then return to execute "when the server points to the shutdown instruction A, traverse the resource interaction information in the resource exchange queue of any one container in service groups 1 - 10, and at the same time input the resource interaction information result (traversal result)".
[0132] Step 804, until the resource interaction information check result indicates the non - existence of running resource interactions, or the shutdown duration comparison result shows that the shutdown calculation duration is greater than the preset shutdown waiting duration.
[0133] Specifically, repeatedly execute step 802 until either of the two conditions is met: the resource interaction information check result indicates that the container has no resource interaction task in progress, or the shutdown calculation duration is greater than the preset shutdown waiting duration. Then stop executing the loop; if the number of loops is greater than the preset threshold, directly execute to stop the loop, jump out of the shutdown instruction, and output an error reminder.
[0134] For example, repeatedly execute step 802 until the resource interaction information check result for containers a - g meets the condition that there is no resource interaction task in progress, or the shutdown calculation duration t is greater than the preset shutdown waiting duration T, and then stop executing the loop.
[0135] In this embodiment, by performing a loop operation when the downtime calculation duration is less than or equal to a preset downtime waiting duration until the resource interaction information check result is that there is no running resource interaction or the downtime duration comparison result is that the downtime calculation duration is greater than the preset downtime waiting duration, all resource interaction tasks can be maximally satisfied with the calculation conditions, improving the efficiency and accuracy of the system.
[0136] It should be understood that although the steps in the flowcharts involved in the above embodiments are shown in sequence according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless there is a clear indication in this article, the execution of these steps has no strict order limit, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily executed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be executed alternately or alternately with at least a part of other steps or steps in other steps.
[0137] Based on the same inventive concept, an embodiment of the present application also provides a service group container downtime device for implementing the service group container downtime method involved above. The implementation solution provided by this device to solve problems is similar to the implementation solution described in the above method. Therefore, the specific limitations in one or more embodiments of the service group container downtime device provided below can refer to the limitations on the service group container downtime method in the above text, and will not be repeated here.
[0138] In one embodiment, as Figure 10 shown, a service group container downtime device is provided, including: an instruction acquisition module 1002, an information check module 1004, a duration comparison module 1006, and a downtime execution module 1008, where:
[0139] The instruction acquisition module 1002 is configured to acquire a downtime instruction corresponding to each container in the service group, and delete the corresponding container information in the container list according to the downtime instruction;
[0140] The information check module 1004 is configured to check the resource interaction information in the corresponding resource exchange queue in each container according to each downtime instruction to obtain a resource interaction information check result; and start a downtime timer corresponding to each container according to the downtime instruction;
[0141] The duration comparison module 1006 is configured to compare the downtime calculation duration of the downtime timer with a preset downtime waiting duration when the resource interaction information check result is that there is a target resource interaction; the target resource interaction is the resource interaction being processed by the container;
[0142] The shutdown execution module 1008 is used to release the running resources corresponding to the container and stop the container from running and take the container offline from the service group according to the shutdown instruction when the shutdown calculation duration is greater than the preset shutdown waiting duration.
[0143] In one embodiment, the available container list obtaining module is used to: obtain the reading situation of the container set list corresponding to all containers in the service group and the reading situation of the list of non-shutdown containers in the service group; when the reading situation of the container set list and the reading situation of the list of non-shutdown containers are successful, compare the container set list with the list of non-shutdown containers, select the available container list corresponding to the container, and the available container list is used for the service group to call the corresponding container; according to the available container list, retrieve the container to process the to-be-processed service requirements corresponding to the service group.
[0144] In one embodiment, the available container list obtaining module is used to: obtain the interface call chain corresponding to the service group and at least one load balancing method preset for the interface call chain, and the load balancing method is calculated by a preset load balancing algorithm in the service group; determine the optimal callable container combination list corresponding to the to-be-processed service requirements of the service group according to the available container list and at least one load balancing method corresponding to the interface call chain; retrieve the container to process the to-be-processed service requirements corresponding to the service group through the optimal callable container combination list.
[0145] In one embodiment, the available container list obtaining module is used to: execute the step of obtaining the interface call chain corresponding to the service group when the reading situation of the container set list is unsuccessful, or the reading situation of the list of non-shutdown containers is unsuccessful, or the reading situations of the container set list and the list of non-shutdown containers are both unsuccessful.
[0146] In one embodiment, the available container list obtaining module is used to: execute the interface call chain corresponding to the interface called by the current container according to the distributed call request corresponding to the previous container; add a monitoring probe processor to the interface call chain based on the bytecode corresponding to the interface call chain, and generate an event number according to the monitoring probe processor, and the event number is an identifier of the resource interaction information; execute the to-be-processed service requirements corresponding to the interface call chain of the current container, and use the distributed call request to generate a response message for the next container; feedback the response message of the next container to the previous container, and delete the resource interaction information according to the event number.
[0147] In one embodiment, the available container list obtaining module is configured to: generate an auto-increment serial number corresponding to a container according to the resource interaction information corresponding to the container; generate an event number according to the auto-increment serial number, the channel type dictionary, the server number, the resource interaction date, the resource interaction time, and the resource interaction operator number.
[0148] In one embodiment, the duration comparison module is configured to: when the downtime duration comparison result is that the downtime calculation duration is less than or equal to the preset downtime waiting duration, return to execute the step of checking the resource interaction information in the corresponding resource exchange queue in each container to obtain the resource interaction information check result; until the resource interaction information check result is that there is no running resource interaction, or the downtime duration comparison result is that the downtime calculation duration is greater than the preset downtime waiting duration.
[0149] Each module in the above service group container downtime device can be implemented in whole or in part by software, hardware, and their combination. The above modules can be embedded in the processor of the computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to the above respective modules.
[0150] In one embodiment, a computer device is provided. The computer device can be a server, and its internal structure diagram can be as Figure 11 shown. The computer device includes a processor, a memory, and a network interface connected through a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store server data. The network interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, it implements a service group container downtime method.
[0151] Those skilled in the art can understand that Figure 11 the structure shown in
[0152] is only a block diagram of some structures related to the solution of this application, and does not constitute a limitation on the computer device to which the solution of this application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine some components, or have a different component layout.
[0153] In one embodiment, a computer-readable storage medium is provided, storing a computer program, and when the computer program is executed by a processor, the steps in the foregoing method embodiments are implemented.
[0154] In one embodiment, a computer program product or a computer program is provided. The computer program product or the computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the steps in the foregoing method embodiments.
[0155] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in this application are all information and data that have been authorized by the user or fully authorized by all parties.
[0156] Those of ordinary skill in the art can understand that all or part of the processes in the methods of the above embodiments can be completed by instructing relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above methods. Among them, any reference to a memory, database, or other medium used in the embodiments provided in the present application can include at least one of non-volatile and volatile memories. Non-volatile memory can include Read-Only Memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc. The databases involved in the embodiments provided in the present application can include at least one of relational databases and non-relational databases. Non-relational databases can include distributed databases based on blockchain, etc., without limitation. The processors involved in the embodiments provided in the present application can be general-purpose processors, central processors, graphics processors, digital signal processors, programmable logic devices, data processing logics based on quantum computing, etc., without limitation.
[0157] The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity of description, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, it should be considered as the scope described in this specification.
[0158] The above-described embodiments only represent several implementation manners of the present application. Their descriptions are relatively specific and detailed, but they should not be construed as limiting the patent scope of the present application. It should be noted that for those of ordinary skill in the art, without departing from the concept of the present application, several modifications and improvements can still be made, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the appended claims.
Claims
1. A method for shutting down a service group container, characterized in that The method includes: Obtaining shutdown instructions corresponding to each container in the service group, and deleting the corresponding container information in the container list according to the shutdown instructions; Checking the resource interaction information in the corresponding resource exchange queue of each container according to each shutdown instruction to obtain a resource interaction information check result; and starting a shutdown timer corresponding to each container according to the shutdown instruction; When the resource interaction information check result indicates the existence of a target resource interaction, comparing the shutdown calculation duration of the shutdown timer with a preset shutdown waiting duration; the target resource interaction is the resource interaction being processed by the container; When the shutdown calculation duration is greater than the preset shutdown waiting duration, releasing the running resources corresponding to the container, and stopping the container from running and taking the container offline from the service group according to the shutdown instruction; The method further includes: retrieving a container according to an available container list to process the to-be-processed service requirements corresponding to the service group; the available container list is used by the service group to retrieve the corresponding container; The retrieving of the container includes: Executing an interface call chain corresponding to the interface called by the current container according to a distributed call request corresponding to the previous container; Based on the bytecode corresponding to the interface call chain, adding a monitoring probe processor to the interface call chain, and generating an event number according to the monitoring probe processor, where the event number is an identifier of the resource interaction information; Executing the to-be-processed service requirements corresponding to the interface call chain of the current container, and using the distributed call request to generate an answer message for the next container; Feeding back the answer message of the next container to the previous container, and deleting the resource interaction information according to the event number.
2. The method according to claim 1, characterized in that The method further includes: Obtaining the reading situation of the container set list corresponding to all the containers in the service group, and the reading situation of the list of non-shutdown containers in the service group; When the reading situation of the container set list and the reading situation of the list of non-shutdown containers are successful, comparing the container set list with the list of non-shutdown containers to select an available container list corresponding to the container.
3. The method according to claim 2, characterized in that The retrieving of the container according to the available container list to process the to-be-processed service requirements corresponding to the service group includes: Obtaining an interface call chain corresponding to the service group, and at least one load balancing method preset for the interface call chain, where the load balancing method is calculated by a preset load balancing algorithm in the service group; Determining an optimal callable container combination list corresponding to the to-be-processed service requirements of the service group according to the available container list and the at least one load balancing method corresponding to the interface call chain; Retrieving the container through the optimal callable container combination list to process the to-be-processed service requirements corresponding to the service group.
4. The method according to claim 3, characterized in that After obtaining the reading status of the container set list corresponding to all the containers in the service group and the reading status of the list of non - stopped containers in the service group, the following steps are further included: If the reading status of the container set list is unsuccessful, or the reading status of the list of non - stopped containers is unsuccessful, or both the reading status of the container set list and the reading status of the list of non - stopped containers are unsuccessful, then execute the step of obtaining the interface call chain corresponding to the service group.
5. The method according to claim 1, characterized in that The generation of the event number includes: Generate an incrementing serial number corresponding to the container according to the resource interaction information corresponding to the container; Generate the event number according to the incrementing serial number, the channel type dictionary, the server number, the resource interaction date, the resource interaction time, and the resource interaction operator number.
6. The method according to claim 1, characterized in that After comparing the downtime calculation duration of the downtime timer with the preset downtime waiting duration when the resource interaction information check result indicates the existence of running resource interaction, the following steps are further included: If the downtime duration comparison result shows that the downtime calculation duration is less than or equal to the preset downtime waiting duration, then return to execute the step of checking the resource interaction information in the resource exchange queue corresponding to each container to obtain the resource interaction information check result; Until the resource interaction information check result indicates the non - existence of the running resource interaction, or the downtime duration comparison result shows that the downtime calculation duration is greater than the preset downtime waiting duration.
7. A device for shutting down a service group container, characterized in that The device includes: An instruction acquisition module, configured to acquire the shutdown instructions corresponding to each container in the service group, and delete the corresponding container information in the container list according to the shutdown instructions; An information check module, configured to check the resource interaction information in the resource exchange queue corresponding to each container according to each shutdown instruction to obtain a resource interaction information check result; and start the downtime timer corresponding to each container according to the shutdown instruction; A duration comparison module, configured to compare the downtime calculation duration of the downtime timer with the preset downtime waiting duration when the resource interaction information check result indicates the existence of a target resource interaction; the target resource interaction is the resource interaction being processed by the container; A shutdown execution module, configured to release the running resources corresponding to the container and execute the stop operation of the container and take the container offline from the service group according to the shutdown instruction when the downtime calculation duration is greater than the preset downtime waiting duration; An available container list acquisition module, configured to retrieve containers according to the available container list to process the pending service requirements corresponding to the service group; the available container list is used for the service group to call the corresponding containers; An available container list obtaining module is used to execute an interface call chain corresponding to an interface called by a current container according to a distributed call request corresponding to a previous container; based on bytecodes corresponding to the interface call chain, add a monitoring probe processor to the interface call chain, and generate an event number according to the monitoring probe processor, where the event number is an identifier of the resource interaction information; execute a to-be-processed service requirement corresponding to the interface call chain of the current container, and use the distributed call request to generate an answer message for the next container; feedback the answer message of the next container to the previous container, and delete the resource interaction information according to the event number.
8. A computer device, comprising a memory and a processor, the memory storing a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.
9. A computer-readable storage medium, having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.
10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.
Citation Information
Patent Citations
Cloud computing capacity expansion method and device based on service call link
CN112346872A
Container management and application ingestion engine
US20170126432A1