Container group detection method and device, computer equipment and storage medium

Abstract

The invention relates to a container group detection method and device, computer equipment and a storage medium. The method comprises: in response to a state detection request, obtaining availability index parameters of a dependent service corresponding to a target container group, the availability index parameters representing a service request frequency of the target container group and a service response frequency of the dependent service corresponding to the target container group; according to the availability index parameter, performing service state identification on the dependency service to obtain a dependency service state; and determining a container group detection state corresponding to the target container group according to the dependent service state. The method is beneficial to improving the container detection accuracy.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of container state detection, in particular to a container group detection method and device, computer equipment and a storage medium. BACKGROUND

[0002] With the rapid development of the Internet and the continuous progress of digital technology, the amount of underlying data grows exponentially, which brings great challenges to the stability of traditional data computing, processing and analysis underlying applications. In the cloud computing scenario, the kubernetes container orchestration platform is usually used for automatic deployment, expansion and management of containerized applications.

[0003] In order to detect the health status of the container, the related art uses the kubernete pointer to detect the readiness state of the container. However, due to the complex physical environment and diversified cloud network scenarios, the container network will be affected by configuration, delay, congestion and other factors and will fluctuate. For containers that process massive data, once the above-mentioned situations occur, instantaneous high concurrency will cause a large number of thread blocking, at which time the blocked threads will occupy most of the container resources until the resources are exhausted, causing a large number of container restarts or scheduling to other container operations, and in serious cases, the cluster will be paralyzed.

[0004] It can be seen that the related art has the problem of low accuracy of container detection. SUMMARY

[0005] Therefore, it is necessary to provide a container group detection method and device, computer equipment, computer readable storage medium and computer program product capable of improving the accuracy of container detection.

[0006] In a first aspect, the present application provides a container group detection method, comprising:

[0007] In response to a state detection request, obtaining an availability index parameter of a dependent service corresponding to a target container group, wherein the availability index parameter represents a service request frequency of the target container group and a service response frequency of the dependent service corresponding to the target container group;

[0008] According to the availability index parameter, performing service state identification on the dependent service to obtain a dependent service state;

[0009] According to the dependent service state, determining a container group detection state corresponding to the target container group.

[0010] In a second aspect, the present application further provides a container group detection device, comprising:

[0011] The index parameter acquisition module is configured to acquire, in response to the state detection request, an availability index parameter of the dependent service corresponding to the target container group, where the availability index parameter represents a service request frequency of the target container group and a service response frequency of the dependent service corresponding to the target container group.

[0012] The dependent service state identification module is configured to identify, according to the availability index parameter, a service state of the dependent service, to obtain the dependent service state.

[0013] The container group state determination module is configured to determine, according to the dependent service state, a container group detection state of the target container group.

[0014] In a third aspect, the present application also provides a computer device, including a memory and a processor, the memory stores a computer program, and the processor implements the steps in any one of the container group detection method embodiments above when executing the computer program.

[0015] In a fourth aspect, the present application also provides a computer readable storage medium, which stores a computer program, and the computer program implements the steps in any one of the container group detection method embodiments above when executed by a processor.

[0016] In a fifth aspect, the present application also provides a computer program product, including a computer program, and the computer program implements the steps in any one of the container group detection method embodiments above when executed by a processor.

[0017] Compared with the related art in which only containers are detected by probes and containers are restarted according to the detection results, the container group detection method, the container group detection device, the computer device, the computer readable storage medium, and the computer program product acquire, in response to a state detection request, an availability index parameter of a dependent service corresponding to a target container group, where the availability index parameter represents a service request frequency of the target container group and a service response frequency of the dependent service corresponding to the target container group, identify, according to the availability index parameter, a service state of the dependent service, to obtain a dependent service state representing whether the dependent service of the container group is available, and then determine, according to the dependent service state, a container group detection state of the target container group. In this way, the possibility that a large number of containers are frequently restarted due to container network jitter, causing a client to fail to obtain a response, business data to fail to be automatically recovered, and business alarms to fail to be sent is reduced. The container group detection state is determined according to the dependent service state of the dependent service, so that in the case where the dependent service has an availability problem, traffic is not forwarded to the container group, the accuracy of container group availability detection is improved, and the possibility of a "snowball" effect caused by a single-node container failure is reduced. BRIEF DESCRIPTION OF DRAWINGS

[0018] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the related art, the following will briefly introduce the drawings needed to be used in the description of the embodiments of the present application or the related art. Obviously, the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other related drawings can also be obtained on the basis of these drawings without creative effort.

[0019] Figure 1 An application environment diagram of a container group detection method in an embodiment;

[0020] Figure 2 A flowchart of a container group detection method in an embodiment;

[0021] Figure 3 A flowchart of a container group detection method in another embodiment;

[0022] Figure 4 A flowchart of a container group detection method in still another embodiment;

[0023] Figure 5 A schematic diagram of a container group detection link in an embodiment;

[0024] Figure 6 A flowchart of an availability fuse model in an embodiment;

[0025] Figure 7 A structural block diagram of a container group detection device in an embodiment;

[0026] Figure 8 An internal structure diagram of a computer device in an embodiment. DETAILED DESCRIPTION

[0027] In order to make the purposes, technical solutions and advantages of the present application clearer, the following will further describe the present application in combination with the 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.

[0028] The container group detection method provided by the embodiments of the present application can be applied in an application environment as shown in Figure 1 . The distributed cluster includes a plurality of nodes, and the nodes are deployed with container groups. The nodes can be physical or virtual machines.

[0029] Specifically, the node acquires an availability index parameter of a dependent service corresponding to a target container group in response to a state detection request, where the availability index parameter represents a service request frequency of the target container group and a service response frequency of the dependent service corresponding to the target container group, then performs service state identification on the dependent service according to the availability index parameter to obtain a dependent service state, and finally determines a container group detection state of the target container group according to the dependent service state.

[0030] In one exemplary embodiment, as shown in Figure 2 , a container group detection method is provided, which is applied to a node in Figure 1 for example, and includes the following steps (hereinafter referred to as S) S100 to S300. Wherein:

[0031] S100, acquiring an availability index parameter of a dependent service corresponding to a target container group in response to a state detection request, where the availability index parameter represents a service request frequency of the target container group and a service response frequency of the dependent service corresponding to the target container group.

[0032] Wherein, the state detection request is used to detect whether the container group is in a ready state. If the container group is in an unready state, it will not receive new traffic. The availability index parameter is used to determine a dependent service state of the dependent service, and the dependent service state is used to represent the availability of the dependent service. The availability index parameter can include, but is not limited to, service request frequency information sent by the target container group and service response frequency information of the dependent service.

[0033] In actual application, a container state detection component is deployed on each node, and a distributed cache database Redis is also deployed on each node to record the availability index parameter. In order to avoid too many recorded availability index parameters, an expiration time is added when recording to filter out expired availability index parameters.

[0034] # Redis records request volume, to avoid too much request volume data storage, increase expiration time when recording

[0035] redis_client.set($requests,$nums,5min);

[0036] redis_client.zadd($events_per_min, {current_time: int(datetime.timestamp())})

[0037] # Time period calculation, statistics on possible network latency and interface failures such as 400, 401, 500, etc. (all failure situations in interaction responses with third-party services).

[0038] end_time = datetime.timestamp()

[0039] start_time = end_time - 1min

[0040] result = redis_client.zrangebyscore($events_per_min, start_time, end_time).

[0041] In this embodiment, to detect the availability of dependent services and improve the reliability of container status detection, an availability circuit breaker model is deployed on the nodes. The design principles of the availability circuit breaker model include: 1. Employing fault tolerance mechanisms to ensure system availability and reliability. 2. Providing the ability to fail and recover quickly. 3. Disconnecting requests that may increase container load.

[0042] In practice, the container status detection component can periodically send status detection requests to the target container group. In response to these requests, the target container group invokes the availability circuit breaker model to execute the following steps: First, an isolation mechanism is implemented by building thread pools and queues, reusing memory pools, database connection pools, etc. Second, availability metrics parameters of the dependent services corresponding to the target container group are obtained from the distributed cache database. For example, in a Kubernetes cluster, each node deploys a ReadinessProbe component, which is configured with parameters such as the request period and request path. For example, the request period is 10 seconds, and the request path is the health check interface of the availability circuit breaker model, / healthy.

[0043] The ReadinessProbe component periodically (e.g., every 10 seconds) sends a status probe request (HTTP GET request) to the health check interface of the target container group (Pods). In response to the request, the target container group retrieves service request frequency information and service response frequency information between the target container group and its corresponding dependent services (e.g., third-party service APIs) within a preset time period from the distributed cache database.

[0044] S200 identifies the service status of dependent services based on availability index parameters to obtain the status of dependent services.

[0045] Among them, the dependency service status is used to characterize the availability of the dependency service, which can include an available status and an unavailable status.

[0046] In practical implementation, following the example above, the availability circuit breaker model identifies the service status of dependent services based on availability metric parameters, obtains the dependent service status, and returns the corresponding status code to the container status detection component. Specifically, it can determine the scores corresponding to preset availability metrics based on availability metric parameters, and determine the comprehensive score used to identify the dependent service status through weighted summation. Specifically, availability metrics can include response timeout metrics and failure handling metrics. The scores for response timeout metrics and failure handling metrics can be determined based on the ratio of response timeout frequency and failure handling frequency in service response frequency information to service request frequency in service request frequency information, respectively. Then, the weight of each score is set according to requirements, and the comprehensive score is obtained through weighted summation.

[0047] After obtaining the comprehensive score, it can be compared with a preset score threshold. If the comprehensive score is lower than the preset score threshold, the dependent service status is determined to be available; otherwise, the dependent service status is determined to be unavailable.

[0048] S300 determines the container group probe status corresponding to the target container group based on the status of dependent services.

[0049] The container group detection status can include ready and non-ready states.

[0050] In practice, the container group probe status corresponding to the target container group is determined based on the status of the dependent services. This can be as follows: If the dependent service is available, the container group probe status of the target container group is determined to be ready, and the status code corresponding to the status probe request is returned to the container status probe component. The status code can be 2XX or 3XX, indicating that the container group is ready and can receive traffic. Conversely, if the dependent service is unavailable, the container group probe status of the target container group is determined to be not ready, and the status code corresponding to the status probe request is returned to the container status probe component. The status code can be any code other than 2XX and 3XX, indicating that the container group is not ready, and the cluster will not forward traffic to that target container group.

[0051] In the container group detection method described above, compared to related technologies that only use probes to detect containers and restart them based on the detection results, this method obtains availability metric parameters of the dependent services corresponding to the target container group by responding to status detection requests. These availability metric parameters characterize the service request frequency of the target container group and the service response frequency of its dependent services. Based on these parameters, the service status of the dependent services is identified, indicating their availability. Subsequently, the container group detection status is determined based on these dependent service statuses. This reduces the possibility of frequent restarts of a large number of containers due to container network jitter, which could lead to clients not receiving responses, business data not automatically recovering, and business alarms not being sent. By using the dependent service status to determine the container group detection status, it helps to avoid forwarding traffic to the container group when dependent services have availability issues, improving the accuracy of container group availability detection and reducing the possibility of a "snowball effect" caused by a single-node container failure.

[0052] In one exemplary embodiment, such as Figure 3 As shown, based on availability metric parameters, the service status of dependent services is identified to obtain the dependent service status, including S220 to S240, where:

[0053] S220: Based on availability metric parameters, calculate the availability metrics of dependent services.

[0054] S240: Based on availability metrics and preset availability metric thresholds, identify the service status of dependent services to obtain the status of dependent services.

[0055] Availability metrics can include, but are not limited to, the total number of service requests, the number of service requests that timed out, and the number of service requests that failed to process. Availability metrics may include response timeout rate and failure processing rate.

[0056] In specific implementations of S220, the ratio of the number of timed-out service requests to the total number of service requests can be determined to obtain the response timeout rate. Then, the ratio of the number of service requests that failed to be processed to the total number of service requests can be determined to obtain the failure processing rate.

[0057] For S240, in specific implementation, the service status identification of dependent services can be achieved by comparing availability metrics with corresponding preset availability metric thresholds, and determining the dependent service status based on the comparison result. Specifically, the availability metric threshold corresponding to the response timeout rate is the response timeout rate threshold. If the response timeout rate is detected to be greater than or equal to the preset response timeout rate threshold, it is determined that the thread is blocked, and the dependent service status is unavailable. The availability metric threshold corresponding to the failure handling rate is the failure handling rate threshold. If the failure handling rate is detected to be greater than or equal to the preset failure handling rate threshold, it is determined that the thread is blocked, and the dependent service status is unavailable.

[0058] In this embodiment, availability metrics are calculated based on availability metric parameters, and the status of dependent services is identified based on availability metrics and preset availability metric thresholds, thereby improving the accuracy of dependent service status identification.

[0059] In one exemplary embodiment, such as Figure 4 As shown, availability metric parameters include service request frequency information and failure handling frequency information. Based on availability metric parameters, availability metrics for dependent services are calculated, including S222, where:

[0060] S222, determine the failure rate of business requests based on service request frequency information and failure handling frequency information.

[0061] The service request frequency information represents the total number of service requests sent from the target container group to its dependent services. The failure handling frequency information represents the number of service requests that failed to be handled by the dependent services.

[0062] In practical implementation, availability metrics include the failure handling rate. The failure handling rate for business requests can be determined as follows: Let the total number of service requests be `total`, and the number of service requests that failed be `fail`. Then, the failure handling rate for business requests = `fail` / `total`.

[0063] Based on availability metrics and preset availability metric thresholds, the service status of dependent services is identified to obtain the dependent service status, including S242, where:

[0064] S242, if the failure handling rate is greater than or equal to the preset failure handling rate threshold, determine that the dependent service of the dependent service is in an unavailable state.

[0065] In practice, network failures in cluster containers are one of the factors that can lead to service and communication paralysis. These network failures can include whitelist loss, network configuration changes, and network device failures. When a thread is in a blocked state (besides failures of dependent services, operations such as wait, sleep, and join on threads by the data container can also cause blocking), it will not return a response for a certain period of time, thus gradually increasing the failure rate. Let the preset failure rate threshold be M. When failure / total ≥ M is detected, the circuit breaker will trigger a thread termination operation (Open), determine that the dependent service is unavailable, and return a status code representing the unavailable state to the Call method of the availability circuit breaker model.

[0066] In this embodiment, the status of the dependent service is determined based on the failure handling rate of the dependent service, which helps to improve the accuracy of determining the container group detection status based on the status of the dependent service.

[0067] In an exemplary embodiment, the availability metrics include service request frequency information and successful processing frequency information. After obtaining the availability metric parameters corresponding to the target container group, the method further includes steps S250 to S270, wherein:

[0068] S250 determines the success rate of service requests based on service request frequency information and successful processing frequency information.

[0069] Among them, the service request frequency information represents the total number of service requests sent by the target container group, and the successful processing frequency information represents the number of service requests that the dependent services successfully processed.

[0070] In practice, if the total number of service requests is total and the number of successfully processed service requests is receive, then the success rate of service requests = receive / total.

[0071] S260, if the success rate is less than a preset success rate threshold, a degradation instruction is generated, wherein the degradation instruction is used to instruct the container group to execute a preset processing method.

[0072] In practice, under normal circumstances, the thread runs in the Normal state. When a dependent service experiences a business failure, the success rate gradually decreases. If the success rate falls below a preset threshold (e.g., N=0.85), a fallback instruction is generated. This instruction directs the container group to execute a preset processing method to degrade the service, and the running state changes from Normal to Fallback. The target container group calls its local fallback method. The fallback method is a pre-provided processing method used after service degradation. The fallback typically returns a default value or data from a cache. It's understandable that service degradation can be implemented not only on the target container group but also on the dependent service side. For example, the preset processing method could be to disable non-core functions, return fallback data, or execute simplified service logic to release service resources and ensure the normal or efficient operation of core business processes.

[0073] S270, if the success rate is greater than or equal to a preset success rate threshold, a recovery instruction is generated, wherein the recovery instruction is used to instruct the container group to resume business processing.

[0074] In practice, if the success rate is detected to be greater than or equal to the preset success rate threshold, a recovery instruction is generated to instruct the container group to resume normal business processing steps.

[0075] In this embodiment, the thread terminates normally in both Normal and Fallback states and returns a status code to the availability circuit breaker model, indicating that the dependent service is in an available state.

[0076] In this embodiment, service degradation and recovery are performed by monitoring the success rate, thereby improving the availability and reliability of the system.

[0077] In an exemplary embodiment, when it is determined that the status of a dependent service is unavailable, the method further includes steps S282 to S288, wherein:

[0078] S282, start the timer and get the timer duration.

[0079] S282, when the timeout period reaches the preset timeout threshold, obtain the success rate of service request processing.

[0080] S282, if the success rate is greater than the preset success rate threshold, determine that the status of the dependent service of the dependent service is available.

[0081] S282, if the success rate is less than or equal to the preset success rate threshold, determine that the dependent service of the dependent service is in an unavailable state.

[0082] In this embodiment, a preset duration threshold is set to characterize the retry freeze period of the thread pool.

[0083] In real-time, if the failure rate is detected to be greater than or equal to the preset failure rate threshold, the thread circuit breaker (Open) is triggered. At this time, a timer is started and the duration of the timer is obtained.

[0084] Subsequently, when the timeout period reaches a preset threshold, indicating that the thread has reached the retry freeze period, the thread state switches from the circuit breaker state (Open) to the retry state (HalfOpen). At this time, the blocked thread will perform polling retries. During a large number of retries, the thread pool terminates some threads according to the rejection policy. The success rate of service requests within a preset time period is statistically analyzed during the retry process.

[0085] Then, if the success rate is detected to be greater than the preset success rate threshold, the thread can be switched from HalfOpen to Normal, the status of the dependent service can be determined to be available, and a status code representing the available status can be returned to the Call method.

[0086] Otherwise, if the success rate is detected to be less than or equal to the preset success rate threshold, the thread switches from HalfOpen to Open, determines that the dependent service is in an unavailable state, and returns a status code indicating the unavailable state to the Call method.

[0087] In this embodiment, the reliability of container state detection is improved by monitoring thread status and service request success rate through an availability circuit breaker model.

[0088] In an exemplary embodiment, determining the container group probe status corresponding to the target container group based on the dependent service status includes:

[0089] If the dependent service status indicates that the dependent service is available, the container group probe status corresponding to the target container group is determined to be ready.

[0090] In practice, when the dependent service is determined to be available, the target container group sends back a status code indicating its availability to the node. The node then determines that the container group corresponding to the target container group is in a ready state and can receive traffic.

[0091] If the dependent service status indicates that the dependent service is unavailable, the container group detection status corresponding to the target container group is determined to be in a non-ready state. The container group detection status includes both ready and non-ready states.

[0092] In practice, when a dependent service is determined to be unavailable, the target container group sends a status code indicating the unavailable state to the node. As a result, the node determines that the container group corresponding to the target container group is in a non-ready state, and the cluster will not forward traffic to the target container group.

[0093] In this embodiment, the dependency service status of the container's dependent services is introduced to determine the ready status of the container group. This reduces the possibility that the ready probe may not receive a response from the client, business data may not be automatically restored, or business alarms may not be sent due to frequent offline or container restarts, thus improving the reliability of ready status detection.

[0094] To provide a clearer explanation of the container group detection method provided in this application, a specific embodiment is described below, which includes the following steps:

[0095] S1, Periodically send status probe requests: Use Kubernetes related components and third-party API platforms to implement the availability probe chain. Since data containers consume a lot of computing resources, this article uses the ReadinessProbe - HTTP GET probe to send GET requests (status probe requests) to the container group (Pods).

[0096] During the operation of the node container, such as Figure 5 As shown, traffic passes through Ingress (forwarding) -> Service -> Pods (container group) -> API (dependent service).

[0097] Container availability detection chain: ReadinessProbe — Availability circuit breaker model (between Pods and API).

[0098] The script for the HTTP GET probe is as follows:

[0099] apiVersion: v1

[0100] kind: Pod

[0101] metadata:

[0102] name: readiness-probe-http

[0103] labels:

[0104] app: readiness-probe-http

[0105] spec:

[0106] containers:

[0107] - name: readiness-probe-http

[0108] image: xx.com / test-readiness-probe-http:v1

[0109] ports:

[0110] - name: server

[0111] containerPort: 8080

[0112] ReadinessProbe:

[0113] initialDelaySeconds: The delay time for sending the initial probe request on #30

[0114] periodSeconds: 10# Request period, performs a probe every 10 seconds.

[0115] timeoutSeconds: 15#Extremely long duration

[0116] httpGet:

[0117] scheme: HTTP

[0118] port: 8081

[0119] path: / healthy # HTTP request path (health check interface provided by the availability circuit breaker model)

[0120] S2 invokes the availability circuit breaker model to determine the status of dependent services and maintain thread states. Its execution flow is as follows: Figure 6 As shown:

[0121] S201, firstly, enters the availability model's Init, implementing isolation mechanisms through thread pools and queues, and reusing memory pools, database connection pools, etc. Note: Thread pools add additional CPU overhead, and the container has timeout or thread interruption response strategies configured.

[0122] S202. Under normal circumstances, the thread is in the running state. The availability fuse model calculates and determines whether to trigger degradation by defining the call() method. In this method, the following availability metric parameters are recorded using the distributed cache database Redis: (1) The total number of service requests initiated by the requester, total. (2) The sum of the number of service requests successfully processed by the receiver, receive. (3) The preset success rate threshold N.

[0123] Under normal circumstances, total = receive. However, if the dependent service starts to experience business failures, then receive will gradually be less than total. Once receive / total < N is satisfied, a degradation instruction is generated and the degradation mechanism is triggered. The thread is converted from Normal to the FallBack state. On the contrary, if this limit is not satisfied, a recovery operation is triggered and the thread is converted from FallBack to the Normal state. Here, in both the Normal and FallBack states, the thread normally ends and returns a health status code indicating that the dependent service is in an available state to Call. During the normal operation of the thread (even if the counterparty experiences business failures, the thread can always terminate normally), the availability requirements in the availability fuse model have been met.

[0124] S203. Fuse handling. In the Kubernetes environment, network failures of cluster containers are also one of the biggest factors leading to service and communication paralysis, such as white list loss, network configuration changes, network device failures, etc. At this time, the thread is in a blocked state (except for failures of third-party platforms, operations such as wait, sleep, and join of data containers on the thread will also cause blocking). The distributed cache database Redis also records the number of failed processes by the receiver, fail, and the failure processing rate M. The fail and total within a preset time period are obtained from Redis, and the failure processing rate fail / total is calculated. Since the blocked thread will not return a response within a certain period of time, therefore, when it is detected that fail / total ≥ M, the fuse triggers the thread termination operation (Open) and returns a failure status code indicating that the dependent service is in an unavailable state to Call.

[0125] Here, when the thread is in a circuit breaker state, a timer is started. When the timer reaches a preset duration, indicating that the retry freeze period has passed, the thread switches from Open to HalfOpen and performs polling retries: for example, re-counting the success rate multiple times and detecting the number of times the failure rate is less than the threshold M. If the ratio of the failure rate to the total number of polling attempts reaches or exceeds a preset threshold, the state switches from HalfOpen to Normal, and a fault status code indicating that the dependent service is available is returned to Call; otherwise, a fault status code indicating that the dependent service is unavailable is returned to Call.

[0126] S3, Container group readiness status determination: The availability circuit breaker model returns a health status code or a fault status code. If a health status code is returned, it indicates that the dependent service is available, and the container group is determined to be in a ready state. If a fault status code is returned, it indicates that the dependent service is unavailable, and the container group is determined to be in a non-ready state. Considering the dependencies between services, the fault will propagate. The container group is restarted to release blocked threads and avoid the "avalanche" effect caused by the failure of a single node container.

[0127] For example, the cluster environment is a Kubernetes environment, the target container group contains 3 containers, and the built-in availability circuit breaker model is used.

[0128] Experimental steps:

[0129] 1. Gradually block data requests to the third container and observe whether the container changes. Note: Use performance testing tools to count the amount of data requested; the actual data may deviate within an acceptable range.

[0130] Total requests: 20 threads are built per second, looping 60 times. (Total time: 7900s - 8200s). The following data was obtained:

[0131]

[0132] Conclusion: If the thread terminates normally, even if the availability circuit breaker triggers a degradation, the container will not restart (business class exceptions do not involve resource consumption issues, and the fault will not be automatically resolved even if the container is shut down or restarted).

[0133] 2. Gradually increase the reception time of data requests for the third container and observe whether the container changes:

[0134]

[0135] Conclusion: When a thread is blocked, once the availability circuit breaker exception threshold is triggered, a restart will occur, releasing the blocked thread.

[0136] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed 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 performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0137] In one exemplary embodiment, such as Figure 7 As shown, a container group detection device 600 is provided, including: an indicator parameter acquisition module 610, a dependent service status identification module 620, and a container group status determination module 630, wherein:

[0138] The indicator parameter acquisition module 610 is used to obtain the availability indicator parameters of the dependent services corresponding to the target container group in response to the status detection request. The availability indicator parameters represent the service request frequency of the target container group and the service response frequency of the dependent services corresponding to the target container group.

[0139] The dependent service status identification module 620 is used to identify the service status of dependent services based on availability index parameters to obtain the dependent service status.

[0140] The container group status determination module 630 is used to determine the container group probe status corresponding to the target container group based on the status of dependent services.

[0141] In an exemplary embodiment, the dependent service status identification module 620 is further configured to: count the availability index of the dependent service according to the availability index parameter; and identify the service status of the dependent service according to the availability index and a preset availability index threshold to obtain the dependent service status.

[0142] In an exemplary embodiment, the dependent service status identification module 620 is further configured to determine the failure rate of the business request based on the service request frequency information and the failure processing frequency information; and to determine that the dependent service status of the dependent service is unavailable if the failure processing rate is greater than or equal to a preset failure processing rate threshold.

[0143] In an exemplary embodiment, the service status identification module 620 is further configured to determine the success rate of service requests based on service request frequency information and success processing frequency information; generate a degradation instruction if the success rate is less than a preset success rate threshold, wherein the degradation instruction is used to instruct the container group to execute a preset processing method; and generate a recovery instruction if the success rate is greater than or equal to the preset success rate threshold, wherein the recovery instruction is used to instruct the container group to resume business processing.

[0144] In an exemplary embodiment, the dependent service status identification module 620 is further configured to start a timer and obtain the time duration; if the time duration reaches a preset duration threshold, obtain the success rate of the service request; if the success rate is greater than a preset success rate threshold, determine that the dependent service status of the dependent service is available; if the success rate is less than or equal to the preset success rate threshold, determine that the dependent service status of the dependent service is unavailable.

[0145] In an exemplary embodiment, the container group state determination module 630 is further configured to determine that the container group probe state corresponding to the target container group is ready when the dependent service state indicates that the dependent service is available; and to determine that the container group probe state corresponding to the target container group is not ready when the dependent service state indicates that the dependent service is unavailable; the container group probe state includes ready and not ready states.

[0146] Each module in the aforementioned container group detection device 600 can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0147] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 8As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The database stores data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When executed by the processor, the computer program implements a container group detection method.

[0148] Those skilled in the art will understand that Figure 8 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0149] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in any of the above-described container group detection method embodiments.

[0150] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps in any of the above-described container group detection method embodiments.

[0151] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in any of the above-described container group detection method embodiments.

[0152] 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 used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0153] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. 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), magnetic 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 take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0154] The technical features of the above embodiments can be combined in any way. For the sake of brevity, 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, they should be considered to be within the scope of this application.

[0155] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for detecting container groups, characterized in that, The method includes: In response to a state probe request, the availability metric parameters of the dependent services corresponding to the target container group are obtained, wherein the availability metric parameters characterize the service request frequency of the target container group and the service response frequency of the dependent services corresponding to the target container group. Based on the availability index parameters, the service status of the dependent services is identified to obtain the dependent service status; Based on the dependent service status, determine the container group detection status corresponding to the target container group.

2. The method according to claim 1, characterized in that, The step of identifying the service status of the dependent services based on the availability index parameters to obtain the dependent service status includes: Based on the availability metric parameters, the availability metrics of the dependent services are calculated. Based on the availability metrics and preset availability metric thresholds, the service status of the dependent services is identified to obtain the dependent service status.

3. The method according to claim 2, characterized in that, The availability metrics include service request frequency information and failure handling frequency information; The step of calculating the availability metrics of the dependent services based on the availability metric parameters includes: The failure rate of the business request is determined based on the service request frequency information and the failure handling frequency information. The step of identifying the service status of the dependent services based on the availability metrics and preset availability metric thresholds to obtain the dependent service status includes: If the failure handling rate is greater than or equal to a preset failure handling rate threshold, the dependent service status of the dependent service is determined to be unavailable.

4. The method according to claim 3, characterized in that, The availability metrics include service request frequency information and successful processing frequency information; After obtaining the availability metric parameters corresponding to the target container group, the method further includes: The success rate of service requests is determined based on the service request frequency information and the success processing frequency information. If the success rate is less than the preset success rate threshold, a degradation instruction is generated, wherein the degradation instruction is used to instruct the container group to execute a preset processing method; If the success rate is greater than or equal to the preset success rate threshold, a recovery instruction is generated, wherein the recovery instruction is used to instruct the container group to resume business processing.

5. The method according to claim 3, characterized in that, If the dependent service of the dependent service is determined to be in an unavailable state, the method further includes: Start the timer and get the duration. If the timeout period reaches a preset timeout threshold, the success rate of the service request is obtained. If the success rate is greater than a preset success rate threshold, the dependent service status of the dependent service is determined to be available. If the success rate is less than or equal to a preset success rate threshold, the dependent service status of the dependent service is determined to be unavailable.

6. The method according to any one of claims 1 to 5, characterized in that, Determining the container group detection status corresponding to the target container group based on the dependent service status includes: If the dependent service status indicates that the dependent service is available, the container group detection status corresponding to the target container group is determined to be ready. If the dependent service status indicates that the dependent service is unavailable, the container group detection status corresponding to the target container group is determined to be non-ready. The container group detection status includes the ready state and the non-ready state.

7. A cluster container detection device, characterized in that, The device includes: The indicator parameter acquisition module is used to obtain the availability indicator parameters of the dependent services corresponding to the target container group in response to the status detection request. The availability indicator parameters represent the service request frequency of the target container group and the service response frequency of the dependent services corresponding to the target container group. The dependent service status identification module is used to identify the service status of the dependent service based on the availability index parameters, and obtain the dependent service status. The container group status determination module is used to determine the container group detection status corresponding to the target container group based on the status of the dependent services.

8. A computer device comprising a memory and a processor, wherein the memory stores 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.

Images