Abnormal instance processing method and device, and electronic device

Abstract

The present disclosure provides a processing method and device of abnormal instance and electronic equipment, and relates to the technical field of webpage search such as distributed system. The specific implementation scheme is: when an abnormal instance appears in a distributed service system, a target instance corresponding to the abnormal instance can be determined according to the abnormal type of the abnormal instance, and the target instance is controlled to perform the same service as the abnormal instance; and the abnormal instance is deleted from the distributed service system, so that the automatic processing of the abnormal condition can be realized, the processing time of the abnormal condition is reduced, and the abnormal processing efficiency is improved.

Description

Technical Field

[0001] This disclosure relates to the field of data processing technology, and in particular to the field of web search technology such as distributed systems, specifically to a method, apparatus and electronic device for processing abnormal instances. Background Technology

[0002] The Raft protocol is an easy-to-understand distributed consistent replication protocol with wide applications in the distributed system. Raft services built on the Raft protocol are typically deployed on physical machines, making unified scheduling and management of Raft services impossible.

[0003] In order to achieve unified scheduling and management of the Raft service, considering that Platform as a Service (PaaS) provides a software deployment platform that shields hardware and operating system details, thus enabling unified scheduling and management of the Raft service, the Raft service can be deployed on the PaaS platform for unified scheduling and management. However, if an anomaly occurs, manual intervention is required, resulting in poor anomaly handling efficiency. Summary of the Invention

[0004] This disclosure provides a method, apparatus, and electronic device for handling exception instances.

[0005] According to a first aspect of this disclosure, a method for handling exception instances is provided, which may include:

[0006] Identify abnormal instances in a distributed service system.

[0007] Based on the exception type of the exception instance, determine the target instance corresponding to the exception instance, and control the target instance to execute the same service as the exception instance.

[0008] Delete the abnormal instance from the distributed service system.

[0009] According to a second aspect of this disclosure, an apparatus for processing exception instances is provided, the apparatus for processing exception instances may include:

[0010] The determination unit is used to identify abnormal instances in a distributed service system.

[0011] The processing unit is configured to determine a target instance corresponding to the abnormal instance based on the abnormal type of the abnormal instance, and control the target instance to perform the same service as the abnormal instance;

[0012] The deletion unit is used to delete the abnormal instance from the distributed service system.

[0013] According to a third aspect of this disclosure, an electronic device is provided, which may include:

[0014] At least one processor; and

[0015] A memory communicatively connected to the at least one processor; wherein,

[0016] The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the exception instance handling method described in the first aspect above.

[0017] According to a fourth aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are used to cause the computer to execute the method for handling anomalies described in the first aspect above.

[0018] According to a fifth aspect of this disclosure, a computer program product is provided, the computer program product comprising: a computer program stored in a readable storage medium, at least one processor of an electronic device being able to read the computer program from the readable storage medium, the at least one processor executing the computer program causing the electronic device to perform the method for handling exception instances described in the first aspect.

[0019] According to the technical solution disclosed herein, automated processing of abnormal situations is achieved, thereby improving the efficiency of abnormal processing.

[0020] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0021] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein:

[0022] Figure 1 This is a schematic diagram of an implementation framework provided by an embodiment of this disclosure;

[0023] Figure 2 This is a flowchart illustrating the method for handling abnormal instances according to the first embodiment of this disclosure;

[0024] Figure 3 This is a schematic diagram illustrating the automated handling of abnormal instances in an exit-type scenario provided by an embodiment of this disclosure;

[0025] Figure 4 This is a schematic diagram illustrating automated processing of exception instances in an error type scenario provided by an embodiment of this disclosure;

[0026] Figure 5 This is a schematic diagram illustrating the automated handling of abnormal instances in a seemingly dead scenario provided by an embodiment of this disclosure;

[0027] Figure 6 This is a schematic diagram of the structure of an anomaly processing apparatus according to the third embodiment of this disclosure;

[0028] Figure 7 This is a schematic block diagram of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0029] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0030] In the embodiments of this disclosure, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the access relationship of associated objects, indicating that three relationships can be retained. For example, A and / or B can represent: retaining A alone, retaining both A and B, or retaining B alone, where A and B can be singular or plural. In the textual description of this disclosure, the character " / " generally indicates that the preceding and following associated objects have an "or" relationship. Furthermore, in the embodiments of this disclosure, "first," "second," "third," "fourth," "fifth," and "sixth" are merely used to distinguish the content of different objects and have no other special meaning.

[0031] The technical solutions provided in this disclosure can be applied to distributed service systems. In distributed service systems, in order to uniformly schedule and manage the Raft service, considering that Platform as a Service (PaaS) provides a software deployment platform and hides hardware and operating system details, thus enabling unified scheduling and management of the Raft service, the Raft service can be deployed on a PaaS platform for unified scheduling and management.

[0032] Currently, when Raft services are uniformly scheduled and managed on PaaS platforms, certain abnormal situations, such as instance migration, disk failures, and service failures, can impact the operation of Raft services. For example, when instance migration or retirement occurs, the instances to be migrated or retired will exit directly, causing a short-term unavailability of the Raft service. When a disk failure occurs, the Raft service logs cannot be written, entering an error state, which also causes a short-term unavailability of the Raft service. Therefore, these abnormal situations need to be handled promptly. However, in existing technologies, these abnormal situations are handled manually, resulting in low efficiency in anomaly handling.

[0033] To improve anomaly handling efficiency, the Raft service can be further deployed on a PaaS platform. By combining the mechanisms provided by the PaaS platform and the Raft protocol, automated handling of anomalies can be achieved, ensuring the highly reliable and stable operation of the Raft service on the PaaS platform. To achieve automated anomaly handling in this embodiment, in addition to deploying the Raft service on the PaaS platform, a controller can also be deployed on the PaaS platform. This controller can act as a bridge between the Raft service and the PaaS platform to automate anomaly handling. For example, see [link to example]. Figure 1 As shown, Figure 1 This is a schematic diagram of an implementation framework provided in this disclosure, which includes a PaaS platform, a controller deployed on the PaaS platform, and a Raft service.

[0034] The PaaS platform is mainly used to provide basic capabilities such as replica keep-alive and unified scheduling management. In particular, in this disclosure, the PaaS platform's custom state probe function supports automatic injection of state through external application programming interfaces (APIs). Therefore, the custom state probe function can support automatic detection of abnormal situations and perform instance migration operations on the Raft service based on the detection results.

[0035] The controller, acting as a bridge between the Raft service and the PaaS platform, is primarily used to receive probe access from the PaaS platform and manage the state of instances within the Raft service. For distributed systems with multiple Raft groups, such as distributed storage systems, there is usually a corresponding master service, which can also act as the controller. For services with a single Raft group, such as a metadata management system, a dedicated controller needs to be built within the PaaS platform.

[0036] The Raft service, built upon the Raft protocol, is the core of the entire implementation framework. The PaaS platform and the controller deployed on it both ensure the stable operation of the Raft service. For example, the Raft service can be a distributed lock service, a distributed storage service, or a high-reliability metadata management service, etc., and can be configured according to actual needs. Taking the high-reliability metadata management service as an example, the corresponding service system typically consists of 3 or 5 instances, including one master instance and multiple slave instances. The master instance can be referred to as the leader instance, and the slave instances as follower instances. The master instance is primarily used for external service, and the master and slave instances maintain their relationship through heartbeats, providing a highly reliable service overall.

[0037] Based on the above Figure 1 The implementation architecture shown allows for the determination of a target instance corresponding to the abnormal instance based on its exception type when an abnormal instance occurs in the distributed service system. The target instance is then controlled to execute the same service as the abnormal instance. The abnormal instance is then deleted from the distributed service system. This enables automated handling of abnormal situations, reduces processing time, and improves exception handling efficiency.

[0038] The method for handling exceptions provided in this disclosure will be described in detail below through specific embodiments. It is understood that the following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0039] Example 1

[0040] Figure 2 This is a flowchart illustrating a method for handling exceptions according to the first embodiment of this disclosure. This method can be executed by software and / or hardware devices, such as a terminal or a server. For example, please refer to [link to example]. Figure 2 As shown, the handling method for this exception instance may include:

[0041] S201. Identify abnormal instances in the distributed service system.

[0042] For example, a distributed service system can be a distributed lock service system, a distributed storage service system, a highly reliable metadata management service system, etc., and can be configured according to actual needs.

[0043] For example, an abnormal instance can be an instance affected by abnormal situations such as instance migration or retirement, disk failure, or service failure itself. For instance, when an abnormal instance is affected by instance retirement, it can be a retired instance; when an abnormal instance is affected by disk failure, it can be an error instance; and when an abnormal instance is affected by service failure itself, it can be a seemingly dead instance.

[0044] Among them, "fake dead" usually refers to the primary instance. A primary instance "fake dead" means that the primary instance can notify other slave instances in its Raft group through heartbeats that it is the primary instance. However, the primary instance itself has an abnormal port access status and cannot be accessed, so it cannot provide services to the outside world. This will result in slave instances in the Raft group believing that there is a primary instance, but in fact, it cannot provide services to the outside world.

[0045] Example, combination Figure 1 As shown, the controller deployed on the PaaS platform can identify abnormal instances in the distributed service system. After identifying the abnormal instances, the target instance corresponding to the abnormal instance can be determined based on the exception type of the abnormal instance, and the target instance can be controlled to execute the same service as the abnormal instance, i.e., the following S202 is executed:

[0046] S202. Based on the exception type of the exception instance, determine the target instance corresponding to the exception instance, and control the target instance to execute the same service as the exception instance.

[0047] For example, when the exception instance is an exit instance, the exception type of the exit instance can be the exit type; when the exception instance is an error instance, the exception type of the error instance can be the error type; when the exception instance is a dead instance, the exception type of the dead instance can be the dead type.

[0048] Example, combination Figure 1 As shown, the controller deployed on the PaaS platform can determine the target instance corresponding to the abnormal instance and control the target instance to execute the same service as the abnormal instance, so that the normal operation of the service can be guaranteed by the target instance, thereby realizing the normal operation of the service.

[0049] S203. Remove the abnormal instance from the distributed service system.

[0050] For example, after deleting an abnormal instance from the distributed service system, you can also delete the related configuration information of that abnormal instance from the distributed system. For example, when deleting an abnormal instance from the distributed service system, you can do so through the PaaS platform; when deleting the related configuration information of that abnormal instance from the distributed system, you can do so through a controller deployed on the PaaS platform.

[0051] It should be noted that in this embodiment, there is no specific order between S202 and S203. S202 can be executed first, followed by S203; or S203 can be executed first, followed by S202; or S202 and S203 can be executed simultaneously. The specific order can be set according to actual needs. Here, this embodiment is only used as an example of executing S202 first, followed by S203, but it does not mean that this embodiment is limited to this.

[0052] It is understandable that when an abnormal instance occurs in the distributed service system, S202 is executed first, followed by S203. That is, the target instance corresponding to the abnormal instance is first identified and the target instance is controlled to perform the same service as the abnormal instance. Then the abnormal instance is deleted from the distributed service system. This can, to a certain extent, prioritize the normal operation of the service and solve the problem of Raft service unavailability for a short period of time caused by deleting the abnormal instance first.

[0053] As can be seen from the embodiments of this disclosure, when an abnormal instance occurs in the distributed service system, a target instance corresponding to the abnormal instance can be determined according to the abnormal type of the abnormal instance, and the target instance can be controlled to execute the same service as the abnormal instance; the abnormal instance can be deleted from the distributed service system. This can realize the automated handling of abnormal situations, reduce the handling time of abnormal situations, and thus improve the efficiency of abnormal handling.

[0054] Based on the above Figure 2 In the illustrated embodiment, for example, when determining the target instance corresponding to the abnormal instance based on the abnormal instance's exception type, the target instance can be determined from the expanded instances or from the instance group to which the abnormal instance belongs, based on the exception type of the abnormal instance. This can automatically determine the target instance, ensuring the normal operation of the service through the determined target instance, thereby achieving the normal operation of the service.

[0055] Considering that different exception types of exception instances require different methods for determining the target instance, the following will describe in detail how to determine the target instance corresponding to the exception instance and how to perform the corresponding automated processing operations, based on different exception types. For details, please refer to Example 2 below.

[0056] Example 2

[0057] In one scenario, the exception type is an exit type. When determining the target instance corresponding to the exception instance and executing the corresponding automated processing operation, an example can be found here. Figure 3 As shown, Figure 3 This is a schematic diagram illustrating the automated handling of abnormal instances in an exit-type scenario provided by an embodiment of this disclosure.

[0058] S301. Receive an exit detection request, which includes the identifier of the abnormal instance.

[0059] For example, the PaaS platform may proactively send an exit probe request to the controller deployed on the PaaS platform due to reasons such as load balancing scheduling and instance scaling. The exit probe request may include the identifier of the abnormal instance that needs to be exited, so as to inquire with the controller whether the exit operation can be performed directly on the abnormal instance.

[0060] Correspondingly, after receiving the exit probe request from the PaaS platform, the controller can determine the exception type of the abnormal instance as exit. Considering that if the abnormal instance is a running primary instance, direct exit will cause the service to be unavailable for at least the election period, the controller will first determine whether the abnormal instance is a primary instance after receiving the exit probe request, that is, execute the following S302:

[0061] S302. If the exception type is exit type, then determine whether the exception instance is the main instance.

[0062] For example, when the controller determines whether an abnormal instance is the primary instance, it will send a check service to the Raft service to determine whether the abnormal instance is the primary instance. If the check result indicates that the abnormal instance is not the primary instance, i.e., a secondary instance, the PaaS platform can directly perform an exit operation on the abnormal instance. Conversely, if the check result indicates that the abnormal instance is the primary instance, the following S303 is executed, and the Raft service reports back to the controller that the abnormal instance is the primary instance.

[0063] S303, Feedback the exception instance to the controller as the main instance.

[0064] S304. If the abnormal instance is the primary instance, then the target instance is determined from the secondary instances in the instance group to which the abnormal instance belongs.

[0065] When the controller determines that an abnormal instance is the master instance, it will send a master instance transfer command to the Raft service to select a target instance from the slave instances of the instance group to which the abnormal instance belongs to execute the master instance service. In this way, the target instance can replace the abnormal instance and execute the service corresponding to the abnormal instance, thereby ensuring the normal operation of the service.

[0066] S305. Send a response message to the PaaS platform stating that the abnormal instance cannot be decommissioned.

[0067] For example, the controller sends a response message to the PaaS platform indicating that the abnormal instance cannot be retired. After receiving the response message, the PaaS platform will not directly perform a retirement operation on the abnormal instance. Instead, it will need to perform further probing before it receives a response message from the controller indicating that the instance can be retired. Only then will the PaaS platform perform a retirement operation on the abnormal instance and delete the abnormal instance from the distributed service system. See S306-S310 below.

[0068] It should be noted that in this embodiment, there is no specific order between S304 and S305. S304 can be executed first, followed by S305; or S305 can be executed first, followed by S304; or S304 and S305 can be executed simultaneously. The specific order can be set according to actual needs. Here, this embodiment is only used as an example of executing S304 first, followed by S305, but it does not mean that this embodiment is limited to this.

[0069] S306. Receive an exit detection request, which includes the identifier of the abnormal instance.

[0070] S307. Re-evaluate whether the abnormal instance is the primary instance.

[0071] For example, after receiving the exit probe request from the PaaS platform, the controller will initiate a check service to the Raft service to re-determine whether the abnormal instance is the primary instance. If the check result indicates that the abnormal instance is the primary instance, the above steps S303-S306 can continue to be executed, and the abnormal instance can be re-determined to be the primary instance. Conversely, if the check result indicates that the abnormal instance is not the primary instance, the following step S308 is executed, and the Raft service reports to the controller that the abnormal instance is not the primary instance.

[0072] S308, The exception instance reported to the controller is not the primary instance.

[0073] After determining that the abnormal instance reported by the Raft service is not the primary instance, the controller sends a response message to the PaaS platform indicating that the abnormal instance can be decommissioned.

[0074] S309. Send a response message to the PaaS platform indicating that the abnormal instance can be decommissioned.

[0075] S310. Remove the abnormal instance from the distributed service system.

[0076] After receiving a response message indicating that an abnormal instance can be decommissioned, the PaaS platform can delete the abnormal instance from the distributed service system, thus achieving automated cleanup of abnormal instances within the Raft group.

[0077] As can be seen, in this embodiment of the disclosure, when performing the abnormal instance exit operation, the abnormal instance is first determined to be a primary instance, and the exit operation is only performed on the abnormal instance after it is determined to be a non-primary instance. This achieves automated handling of abnormal situations and can effectively reduce the time of service unavailability caused by the exit of the primary instance, thereby improving the efficiency of abnormal handling.

[0078] In addition to identifying the target instance from the slave instances in the instance group to which the abnormal instance belongs, and controlling the target instance as the master instance to execute the services of the master instance, for example, considering that the services corresponding to the target instance will be suspended when it is a slave instance, an additional instance can be added, which can be called the first instance. The first instance is then added to the instance group to which the abnormal instance belongs, and the first instance is controlled to execute the same services as the target instance. This ensures that the services corresponding to the target instance run normally when it is a slave instance.

[0079] It should be noted that in this embodiment, the first instance can be expanded first, and then the exit operation of the abnormal instance can be performed; the exit operation of the abnormal instance can be performed first, and then the expansion of the first instance can be performed; or the expansion of the first instance and the exit operation of the abnormal instance can be performed simultaneously. The specific settings can be configured according to actual needs.

[0080] In another scenario, the exception type is an error type. When determining the target instance corresponding to the exception instance and executing the corresponding automated processing operation, an example can be found here. Figure 4 As shown, Figure 4 This is a schematic diagram illustrating the automated handling of exception instances in an error type scenario provided by an embodiment of this disclosure.

[0081] S401, Receive health detection request.

[0082] Currently, when a serious error occurs in the system, such as a full disk or a read-only disk, the corresponding Raft service instance will enter an error state and will no longer accept new update requests until the system error is resolved and the service is restarted to resume operation.

[0083] To address this issue, in this embodiment, the PaaS platform can proactively and periodically send health probe requests to the deployed controller to actively detect the status of Raft service instances. This status includes a healthy state or an unhealthy state; unhealthy instances are considered faulty instances. For example, the periodicity can be at minute intervals, which can be configured according to actual needs.

[0084] Correspondingly, after receiving a health probe request from the PaaS platform, the controller can check the status of all instances based on the health probe request.

[0085] S402. Check the status of all instances.

[0086] For example, when the controller checks the status of all instances, it sends a check service to the Raft service to check whether all instances are healthy. If the check result indicates that all instances are healthy, it can directly send a response message to the PaaS platform indicating that all instances are healthy. Conversely, if the check result indicates that there are unhealthy instances, these unhealthy instances can be recorded as abnormal instances, and the exception type of these abnormal instances is error. In this case, S403 is executed, and the Raft service sends a message to the controller indicating that there are unhealthy instances.

[0087] S403: Report to the controller that an instance exists that is not healthy.

[0088] After the controller determines that an instance is unhealthy, it reports the existence of an unhealthy instance to the PaaS platform, that is, it executes the following S404. In this way, the PaaS platform can proactively discover abnormal instances in an unhealthy state through health probe requests.

[0089] S404: Report to the PaaS platform that an instance is an unhealthy instance.

[0090] The PaaS platform will initiate instance migration for the unhealthy instance. During instance migration, you can first expand the scale of one instance (referred to as the second instance), add the second instance to the instance group to which the abnormal instance belongs, and designate the second instance as the target instance, i.e., execute the following S405:

[0091] S405. Expand the second instance, add the second instance to the instance group to which the abnormal instance belongs, and identify the second instance as the target instance.

[0092] Once the PaaS platform identifies the second instance as the target instance, this second instance can replace the abnormal instance and be used to execute the service corresponding to the abnormal instance to ensure the normal operation of the service.

[0093] S406. Remove unhealthy instances from the distributed service system.

[0094] This achieves automated cleanup of error-type instances within the Raft group by removing unhealthy and abnormal instances from the distributed service system.

[0095] Through the above S401-S406, the PaaS platform can actively detect the instance status through a health probe request and perform corresponding processing operations when an abnormal instance is detected. Subsequently, after another cycle, it can actively detect and process the instance status again through a health probe request. The corresponding detection and processing methods are similar to the detection and processing methods in S401-S406 above, and will not be described in detail here.

[0096] As can be seen, in this embodiment of the disclosure, when performing the abnormal instance detection operation of the error type, the status of all instances is requested to be detected through the health probe, and after it is determined that there is an abnormal instance of the error type, the abnormal instance is migrated to realize the automated handling of abnormal situations, and the automated cleanup of error type instances within the Raft group is also realized.

[0097] In another scenario, the exception type is a "dead" type. For an example of determining the target instance corresponding to the exception instance and executing the corresponding automated processing operations, please refer to [link to example]. Figure 5 As shown, Figure 5 This is a schematic diagram illustrating the automated handling of abnormal instances in a seemingly dead scenario provided by an embodiment of this disclosure.

[0098] S501. Periodically check whether the port access status of the main instance is normal.

[0099] For example, when the controller periodically checks whether the port access status of the primary instance is normal, it will send a check service to the Raft service to check whether the port access status of the primary instance is normal. If the check result indicates that the port access status is normal, it means that the primary instance can execute the corresponding service; conversely, if the check result indicates that the port access status is abnormal, the following S502 is executed, and the Raft service reports the abnormal port access status to the controller.

[0100] S502, Reports an abnormal port access status to the controller.

[0101] S503. Determine the target instance from the instances in the instance group to which the abnormal instance belongs.

[0102] For example, after the controller determines that the primary instance is a dead or suspended instance based on abnormal port access status, it can randomly select a secondary instance to initiate an election. At the same time, the controller marks the dead primary instance as unhealthy. By periodically and proactively checking whether the port access status of the primary instance is normal, and randomly selecting a secondary instance to initiate an election when an abnormal port access is detected, a target instance is elected as the new primary instance to execute the service corresponding to the dead primary instance. This not only automates the handling of abnormal situations, but also ensures the normal operation of the service as much as possible.

[0103] It is understandable that during the automated handling of abnormal situations, a health probe request may be received from the health PaaS platform, i.e., the following S504 is executed to check the port access status of the main instance through the health probe request.

[0104] S504, Receive health probe request.

[0105] For example, health probe request messages can be received during the election of a new primary instance or after the election of a new primary instance. The specific timing can be set according to actual needs. Here, this embodiment of the disclosure does not impose specific restrictions on the timing of receiving health probe requests.

[0106] The PaaS platform sends a health probe request to the controller to detect whether all instances are in a healthy state. If the detection result indicates that all instances are in a healthy state, a response message confirming that all instances are in a healthy state is sent back to the PaaS platform. If the detection result indicates that there is a master instance that is in a dead state, the following S505 is executed:

[0107] S505: Send a response message to the PaaS platform indicating that the main instance of the "frozen" type can be terminated.

[0108] S506. Remove the dead main instance from the distributed service system.

[0109] Once the PaaS platform determines that a dead primary instance can be removed from the distributed service system, it can also remove the relevant configuration information of the dead primary instance from the Raft configuration.

[0110] It should be noted that, considering that unhealthy primary instances are no longer able to execute the corresponding services, the PaaS platform can directly delete the dead primary instance from the distributed service system after receiving a response message that the dead primary instance can be retired, without needing to know whether a new primary instance has been elected and is executing the corresponding service.

[0111] As can be seen from the present embodiment, when performing the abnormal instance detection operation of the dead type, the port access status of the master instance is pre-periodically and actively detected to see if it is normal. When the port access of the master instance is detected to be abnormal, a slave instance is randomly selected to initiate an election, and a target instance is elected as the new master instance to execute the service corresponding to the dead type master instance. This not only realizes the automated handling of abnormal situations, but also reduces the time when the Raft service is unavailable to a certain extent, and ensures the normal operation of the service.

[0112] It is understood that this disclosure only illustrates the three possible scenarios described above, and other scenarios may also be included, such as the scenario of automatic changes to Raft group members. In this scenario, when the PaaS platform detects the migration of a certain instance, the Raft group member configuration also needs to be changed synchronously. First, the PaaS platform will expand by one instance, so the currently expected configuration of instances will be one more than the actual running configuration of the Raft service. The controller periodically detects the difference between the actual running configuration of the Raft service and the current expected configuration, and adds the instances that are expected to exist in the Raft configuration but do not actually exist to the Raft group. Second, the PaaS platform uses a health probe to request and detect the status of the newly added instance. When the controller determines that the status of the newly added instance is healthy, it triggers an instance deletion operation to delete the instance that needs to be migrated. In addition, the controller will also delete the relevant configuration information of the instance that needs to be migrated from the Raft configuration, thereby realizing the automatic change of Raft group members.

[0113] For example, the periodicity can be a second-level interval, which can be set according to actual needs.

[0114] Example 3

[0115] Figure 6 This is a schematic diagram of the structure of the exception handling apparatus 60 provided according to the third embodiment of this disclosure. For example, please refer to [link to example]. Figure 6 As shown, the processing device 60 for this exception instance may include:

[0116] The determination unit 601 is used to determine abnormal instances in the distributed service system.

[0117] The processing unit 602 is used to determine the target instance corresponding to the abnormal instance based on the abnormal instance's exception type, and control the target instance to perform the same service as the abnormal instance.

[0118] Deletion unit 603 is used to delete abnormal instances from the distributed service system.

[0119] Optionally, the processing unit 602 includes a first processing module.

[0120] The first processing module is used to determine the target instance from the expanded instances or from the instance group to which the abnormal instance belongs, based on the abnormal type of the abnormal instance.

[0121] Optionally, the first processing module includes a first processing submodule and a second processing submodule.

[0122] The first processing submodule is used to determine whether the exception instance is the main instance if the exception type is exit type.

[0123] The second processing submodule is used to determine the target instance from the sub-instances of the instance group to which the exception instance belongs if the exception instance is the main instance.

[0124] Optionally, the second processing submodule is specifically used to receive an exit detection request, which includes the identifier of the abnormal instance; re-determine whether the abnormal instance is the primary instance; if the abnormal instance is not the primary instance, then delete the abnormal instance from the distributed service system.

[0125] Optionally, the first processing module may also include a third processing submodule and a fourth processing submodule.

[0126] The third processing submodule is used to expand the first instance.

[0127] The fourth processing submodule is used to add the first instance to the instance group to which the abnormal instance belongs, and to control the first instance to perform the same service as the target instance.

[0128] Optionally, the first processing module may also include a fifth processing submodule and a sixth processing submodule.

[0129] The fifth processing submodule is used to expand the second instance if the exception type is an error type.

[0130] The sixth processing submodule is used to add the second instance to the instance group to which the abnormal instance belongs, and to identify the second instance as the target instance.

[0131] Optionally, the first processing module may also include a seventh processing submodule.

[0132] The seventh processing submodule is used to determine the target instance from the instances in the instance group to which the exception instance belongs if the exception type is a dead type. The port access status of the dead type instance is abnormal.

[0133] The abnormal instance processing device 60 provided in this embodiment can execute the technical solution of the abnormal instance processing method shown in any of the above embodiments. Its implementation principle and beneficial effects are similar to those of the abnormal instance processing method. Please refer to the implementation principle and beneficial effects of the abnormal instance processing method. It will not be repeated here.

[0134] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0135] According to embodiments of this disclosure, this disclosure also provides a computer program product comprising: a computer program stored in a readable storage medium, at least one processor of an electronic device being able to read the computer program from the readable storage medium, and the at least one processor executing the computer program causing the electronic device to perform the scheme provided in any of the above embodiments.

[0136] Figure 7 This is a schematic block diagram of an electronic device 70 provided in an embodiment of this disclosure. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0137] like Figure 7 As shown, device 70 includes a computing unit 701, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 702 or a computer program loaded from storage unit 708 into random access memory (RAM) 703. RAM 703 may also store various programs and data required for the operation of device 70. The computing unit 701, ROM 702, and RAM 703 are interconnected via bus 704. Input / output (I / O) interface 705 is also connected to bus 704.

[0138] Multiple components in device 70 are connected to I / O interface 705, including: input unit 706, such as keyboard, mouse, etc.; output unit 707, such as various types of monitors, speakers, etc.; storage unit 708, such as disk, optical disk, etc.; and communication unit 709, such as network card, modem, wireless transceiver, etc. Communication unit 709 allows device 70 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0139] The computing unit 701 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 701 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 701 performs the various methods and processes described above, such as methods for handling abnormal instances. For example, in some embodiments, methods for handling abnormal instances may be implemented as computer software programs tangibly contained in a machine-readable medium, such as storage unit 708. In some embodiments, part or all of the computer program may be loaded and / or installed on device 70 via ROM 702 and / or communication unit 709. When the computer program is loaded into RAM 703 and executed by the computing unit 701, one or more steps of the methods for handling abnormal instances described above may be performed. Alternatively, in other embodiments, the computing unit 701 may be configured to perform methods for handling abnormal instances by any other suitable means (e.g., by means of firmware).

[0140] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0141] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0142] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0143] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0144] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with embodiments of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0145] Computer systems can include clients and servers. Clients and servers are generally geographically separated and typically interact via communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. A server can be a cloud server, also known as a cloud computing server or cloud host, a hosting product within the cloud computing service ecosystem, addressing the shortcomings of traditional physical hosts and VPS (Virtual Private Server, or simply "VPS") services, such as high management difficulty and weak business scalability. Servers can also be servers for distributed systems or servers incorporating blockchain technology.

[0146] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0147] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A method for handling exception instances, comprising: By using a controller deployed on the PaaS platform, the system receives probe access from the PaaS platform, manages the status of instances in the Raft service, and identifies abnormal instances of the Raft service deployed on the PaaS platform in the distributed service system. Based on the exception type of the exception instance, determine the target instance corresponding to the exception instance from the expanded instances or from the instance group to which the exception instance belongs, and control the target instance to perform the same service as the exception instance; Delete the abnormal instance from the distributed service system.

2. The method according to claim 1, wherein, Determining the target instance from the instance group to which the abnormal instance belongs includes: If the exception type is an exit type, then determine whether the exception instance is the main instance; If the abnormal instance is the primary instance, then the target instance is determined from the secondary instances in the instance group to which the abnormal instance belongs.

3. The method according to claim 2, wherein, Deleting the abnormal instance from the distributed service system includes: Receive an exit detection request, the exit detection request including the identifier of the abnormal instance; Reassess whether the abnormal instance is the primary instance; If the abnormal instance is not the primary instance, then the abnormal instance is deleted from the distributed service system.

4. The method according to claim 2 or 3, further comprising: First instance of expansion; Add the first instance to the instance group to which the abnormal instance belongs, and control the first instance to perform the same service as the target instance.

5. The method according to claim 1, wherein, Determining the target instance from the expanded instances includes: If the exception type is an error type, then expand the second instance; Add the second instance to the instance group to which the abnormal instance belongs, and identify the second instance as the target instance.

6. The method according to claim 1, wherein, Determining the target instance from the instance group to which the abnormal instance belongs includes: If the exception type is a dead type, then the target instance is determined from the instances in the instance group to which the exception instance belongs, wherein the port access status of the dead type instance is abnormal.

7. An apparatus for handling exception instances, comprising: The determination unit is used to receive probe access from the PaaS platform through the controller deployed on the PaaS platform, manage the status of instances in the Raft service, and determine abnormal instances of the Raft service deployed on the PaaS platform in the distributed service system. The processing unit is configured to determine a target instance corresponding to the abnormal instance based on the abnormal type of the abnormal instance, and control the target instance to perform the same service as the abnormal instance; A deletion unit is used to delete the abnormal instance from the distributed service system; The processing unit includes a first processing module; The first processing module is configured to determine the target instance from the expanded instances or from the instance group to which the abnormal instance belongs, based on the abnormal type of the abnormal instance.

8. The apparatus according to claim 7, wherein, The first processing module includes a first processing submodule and a second processing submodule; The first processing submodule is used to determine whether the exception instance is the main instance if the exception type is the exit type. The second processing submodule is used to determine the target instance from the sub-instances of the instance group to which the abnormal instance belongs if the abnormal instance is the main instance.

9. The apparatus according to claim 8, wherein, The second processing submodule is specifically used to receive an exit detection request, which includes the identifier of the abnormal instance; re-determine whether the abnormal instance is the primary instance; and if the abnormal instance is not the primary instance, delete the abnormal instance from the distributed service system.

10. The apparatus according to claim 8 or 9, wherein the first processing module further comprises a third processing submodule and a fourth processing submodule; The third processing submodule is used to expand the first instance; The fourth processing submodule is used to add the first instance to the instance group to which the abnormal instance belongs, and control the first instance to perform the same service as the target instance.

11. The apparatus according to claim 7, wherein, The first processing module further includes a fifth processing submodule and a sixth processing submodule; The fifth processing submodule is used to expand the second instance if the exception type is an error type; The sixth processing submodule is used to add the second instance to the instance group to which the abnormal instance belongs, and to determine the second instance as the target instance.

12. The apparatus according to claim 7, wherein, The first processing module further includes a seventh processing submodule; The seventh processing submodule is used to determine the target instance from the instances in the instance group to which the abnormal instance belongs if the exception type is a dead type, wherein the port access status of the dead type instance is abnormal.

13. An electronic device, comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the method for handling an exception instance as described in any one of claims 1-6.

14. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to execute the method for handling an exception instance according to any one of claims 1-6.

15. A computer program product comprising a computer program that, when executed by a processor, implements the steps of the method for handling an exception instance as described in any one of claims 1-6.

Images