A method, system, server and storage medium for starting a distributed service

Abstract

Embodiments of the present application provide a distributed service starting method and system, a server and a storage medium. The method comprises: when a service starting instruction is acquired, starting a first thread and a second thread; the first thread determines whether a service is started every time the service is traversed, if yes, records the starting state of the service, if no, traverses the next service, and returns to determine whether the traversed service is started every time the service is traversed until all services are traversed; the second thread determines whether a target service corresponding to an unstarted service is started based on the starting state recorded by the first thread every time the unstarted service is traversed, if yes, starts the unstarted service, if no, traverses the next unstarted service, and returns to determine whether the unstarted service is started based on the starting state recorded by the first thread every time the unstarted service is traversed until all unstarted services are traversed, wherein the target service is a service relied on by the unstarted service.

Description

Technical Field

[0001] The present invention relates to the technical field of distributed services, and in particular to a method, system, server and storage medium for starting a distributed service. Background Art

[0002] Distributed services are widely used in many Internet scenarios. Distributed services are multiple distributed services deployed across servers in a distributed system. As Internet business complexity increases, the number of services in distributed systems continues to increase. Because services have dependencies, they must be started in the order corresponding to their dependencies to ensure successful startup. Consequently, starting services in distributed systems becomes increasingly difficult.

[0003] Currently, distributed services can be started manually in the order determined by their dependencies. However, this method is labor-intensive and inefficient, making it unsuitable for scenarios with a large number of services. For scenarios with a large number of services, services can be started based on Docker containers. However, this method starts all services simultaneously. Services that do not depend on other services can be started successfully once, while services that depend on other services must be started multiple times. Alternatively, services within a Docker container can only be started after the Docker container is started. However, because starting a Docker container takes a long time, this can still cause startup failures for services with dependencies.

[0004] It can be seen that the current methods of starting distributed services all have the problem of failure to start services with dependencies, resulting in low efficiency in starting distributed services. Summary of the Invention

[0005] The purpose of the embodiments of the present invention is to provide a distributed service startup method, system, server, and storage medium to solve the problem of startup failure of services with dependencies and improve the startup efficiency of distributed services. The specific technical solution is as follows:

[0006] In a first aspect, an embodiment of the present invention provides a method for starting a distributed service, which is applied to a startup program deployed by a master server in a distributed system, wherein the distributed system further includes multiple slave servers, each of which has at least one service deployed thereon, and the method includes:

[0007] When a service start instruction is obtained, the first thread and the second thread are started;

[0008] The first thread traverses each service, and each time it traverses a service, it determines whether the traversed service has been started. If so, it records the startup status of the service. If not, it traverses the next service and returns to the process of traversing each service to determine whether the traversed service has been started until all services are traversed;

[0009] The second thread traverses each unstarted service, and each time it traverses an unstarted service, it determines whether the target service corresponding to the traversed unstarted service has been started based on the startup status recorded by the first thread. If so, it starts the unstarted service; if not, it traverses the next unstarted service and returns to the startup status recorded by the first thread for each traversal of the unstarted service until all the unstarted services are traversed, wherein the target service is the service that the unstarted service depends on.

[0010] Optionally, the service is a microservice; and determining whether the traversed service has been started includes:

[0011] A preset service discovery interface is called to obtain feedback results of the service discovery interface for the traversed service, and based on the feedback results, it is determined whether the traversed service has been started.

[0012] Optionally, calling a preset service discovery interface to obtain a feedback result of the service discovery interface for the traversed service, and determining whether the traversed service has been started based on the feedback result includes:

[0013] Call the preset service discovery interface, request the address of the traversed service from the service discovery request, and obtain the feedback result of the service discovery interface;

[0014] If the feedback result includes the address of the traversed service, it is determined that the traversed service has been started.

[0015] Optionally, the method further includes:

[0016] After the traversal of the unstarted services is completed, the second thread determines whether the services are all started based on the start status recorded by the first thread, and if not, performs a sleep action;

[0017] After the traversal of the services is completed, the first thread determines whether the services have been started, and if not, wakes up the second thread;

[0018] The second thread returns to the traversal of each unstarted service until each service is started.

[0019] Optionally, if the first thread determines that all services have not been started, the method further includes:

[0020] After waiting for a preset time, the first thread traverses each unstarted service and returns to each traversed service to determine whether the traversed service has been started, until all the services have been started.

[0021] Optionally, before starting the first thread and the second thread, the method further includes:

[0022] Sending a service startup script to the slave server, so that the slave server installs the service startup script when it is determined that the service startup script does not exist locally, determines whether the received service startup script is the same as the locally stored service startup script when it is determined that the service startup script exists locally, and uses the received service startup script to overwrite the locally stored service startup script if the received service startup script is different from the locally stored service startup script;

[0023] The starting of the unstarted service includes:

[0024] The second thread calls a service startup script corresponding to the unstarted service and installed from the server to start the unstarted service.

[0025] Optionally, before starting the first thread and the second thread, the method further includes:

[0026] In at least one of the following situations, it is determined that the service startup instruction has been obtained:

[0027] When the deployment of the master server and the slave server in the distributed system is completed; the master server and / or the slave server in the distributed system is restarted; and the startup program is updated.

[0028] In a second aspect, an embodiment of the present invention provides a distributed service system, the distributed system comprising a master server and multiple slave servers, the master server being deployed with a startup program, and each slave server being deployed with at least one service, wherein:

[0029] The startup program is used to start the first thread and the second thread when obtaining the service startup instruction;

[0030] The first thread is used to traverse each service, and each time it traverses a service, it determines whether the traversed service has been started. If so, it records the startup status of the service. If not, it traverses the next service and returns to the process of traversing each service to determine whether the traversed service has been started until all services are traversed;

[0031] The second thread is used to traverse each unstarted service, and each time it traverses an unstarted service, it determines whether the target service corresponding to the traversed unstarted service has been started based on the startup status recorded by the first thread; if so, it starts the unstarted service; if not, it traverses the next unstarted service, and returns each time it traverses an unstarted service based on the startup status recorded by the first thread until all the unstarted services are traversed, wherein the target service is the service that the unstarted service depends on.

[0032] Optionally, the service is a microservice;

[0033] The first thread is specifically configured to call a preset service discovery interface, obtain a feedback result of the service discovery interface for the traversed service, and determine whether the traversed service has been started based on the feedback result.

[0034] Optionally, the first thread is specifically used to call a preset service discovery interface, request the address of the traversed service from the service discovery, and obtain a feedback result of the service discovery interface; if the feedback result includes the address of the traversed service, it is determined that the traversed service has been started.

[0035] Optionally, the second thread is further configured to, after the traversal of all the unstarted services is completed, determine whether all the services have been started based on the startup status recorded by the first thread, and if not, perform a sleep action;

[0036] The first thread is further configured to determine whether all services have been started after the traversal of all services is completed, and if not, wake up the second thread;

[0037] The second thread is further configured to return to the process of traversing each unstarted service until all services are started.

[0038] Optionally, the first thread is also used to wait for a preset period of time if the first thread determines that the services have not all been started, traverse the unstarted services, and return each traversed service to determine whether the traversed service has been started until the services have all been started.

[0039] Optionally, the startup program is further configured to, before starting the first thread and the second thread, send a service startup script to the slave server, so that when the slave server determines that the service startup script does not exist locally, it installs the service startup script; when it determines that the service startup script exists locally, it determines whether the received service startup script is the same as the locally stored service startup script; and when the received service startup script is different from the locally stored service startup script, it uses the received service startup script to overwrite the locally stored service startup script;

[0040] The second thread is specifically configured to call a service startup script corresponding to the unstarted service and installed from the server to start the unstarted service.

[0041] Optionally, the startup program is further configured to, before starting the first thread and the second thread, determine that a service startup instruction is obtained in at least one of the following situations:

[0042] When the deployment of the master server and the slave server in the distributed system is completed; the master server and / or the slave server in the distributed system is restarted; and the startup program is updated.

[0043] In a third aspect, an embodiment of the present invention provides a server, wherein a startup program is deployed on the server, and when the server executes the startup program, any method step described in the first aspect is implemented.

[0044] In a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium, wherein a startup program is stored in the computer-readable storage medium. When the startup program is executed by a server, any method step described in the first aspect is implemented.

[0045] Beneficial effects of the embodiments of the present invention:

[0046] In the solution provided by an embodiment of the present invention, a master server in a distributed system is deployed with a startup program, and the distributed system also includes multiple slave servers, each of which is deployed with at least one service. When the startup program obtains a service startup instruction, it starts a first thread and a second thread; the first thread traverses each service, and each time it traverses a service, it determines whether the traversed service has been started. If so, it records the startup status of the service. If not, it traverses the next service and returns to each traversed service to determine whether the traversed service has been started until all services are traversed; the second thread traverses each unstarted service, and each time it traverses an unstarted service, it determines whether the target service corresponding to the traversed unstarted service has been started based on the startup status recorded by the first thread. If so, it starts the unstarted service. If not, it traverses the next unstarted service and returns to each traversed unstarted service based on the startup status recorded by the first thread until all unstarted services are traversed, wherein the target service is the service on which the unstarted service depends. Since the first thread can determine the startup status of each service by traversing each service, the second thread can determine whether the services on which the service to be started depends have been started based on the startup status of each service determined by the first thread when starting each unstarted service. Therefore, if the services on which the service to be started depends have been started, the service to be started can be successfully started. If the services on which the service to be started depends have not been started, the next unstarted service can be traversed without the problem of service startup failure due to the dependent service not being started, which can greatly improve the startup efficiency of distributed services. Of course, any product or method implementing the present invention does not necessarily need to achieve all of the advantages described above at the same time. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other embodiments can also be obtained based on these drawings.

[0048] Figure 1 A schematic diagram of the structure of a distributed service system provided by an embodiment of the present invention;

[0049] Figure 2 A flowchart of a method for starting a distributed service provided by an embodiment of the present invention;

[0050] Figure 3 Based on Figure 2 A flow chart of a method for determining service startup in the illustrated embodiment;

[0051] Figure 4 Based on Figure 3 A schematic flow chart of a method for determining a startup state based on service discovery provided in the illustrated embodiment;

[0052] Figure 5 Based on Figure 2 Another flow chart of the method for starting a distributed service according to the illustrated embodiment;

[0053] Figure 6 Based on Figure 2 A specific flow chart of the method for starting a distributed service according to the embodiment shown;

[0054] Figure 7 A schematic diagram of the structure of a server provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0055] The following will be combined with the accompanying drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the embodiments described are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field based on this application are within the scope of protection of the present invention.

[0056] To solve the problem of service startup failure with dependencies and improve the startup efficiency of distributed services, embodiments of the present invention provide a distributed service startup method, system, server, storage medium, and computer program product. The following first introduces a distributed service startup method provided by an embodiment of the present invention.

[0057] A distributed service startup method provided by an embodiment of the present invention can be applied to Figure 1 The distributed system shown includes a startup program 120 deployed by the master server 110, and the distributed system also includes multiple slave servers 130, each of which is deployed with at least one service 140, wherein the master server 110 establishes a communication connection with each slave server 130, and the startup program 120 can start each service 140 in the slave server 130 through the first thread 121 and the second thread 122.

[0058] like Figure 2 As shown, a method for starting a distributed service includes:

[0059] S201, when a service start instruction is obtained, start a first thread and a second thread;

[0060] S202, the first thread traverses each service, and each time it traverses a service, it determines whether the traversed service has been started. If so, it records the startup status of the service. If not, it traverses the next service and returns to the process of traversing each service to determine whether the traversed service has been started, until all services are traversed;

[0061] S203, the second thread traverses each unstarted service, and each time it traverses an unstarted service, determines whether the target service corresponding to the traversed unstarted service has been started based on the startup status recorded by the first thread. If so, start the unstarted service; if not, traverse the next unstarted service, and return to the startup status recorded by the first thread for each traversed unstarted service until the traversal of each unstarted service is completed.

[0062] The target service is a service that the unstarted service depends on.

[0063] It can be seen that in the solution provided by the embodiment of the present invention, the main server in the distributed system is deployed with a startup program, and the distributed system also includes multiple slave servers, each of which is deployed with at least one service. When the startup program obtains the service startup instruction, it starts the first thread and the second thread; the first thread traverses each service, and each time it traverses a service, it determines whether the traversed service has been started. If so, it records the startup status of the service. If not, it traverses the next service and returns to each traversed service to determine whether the traversed service has been started until all services are traversed; the second thread traverses each unstarted service, and each time it traverses an unstarted service, it determines whether the target service corresponding to the traversed unstarted service has been started based on the startup status recorded by the first thread. If so, it starts the unstarted service. If not, it traverses the next unstarted service and returns to each traversed unstarted service based on the startup status recorded by the first thread until all unstarted services are traversed, wherein the target service is the service on which the unstarted service depends. Since the first thread can determine the startup status of each service by traversing each service, the second thread can determine whether the service on which the service to be started depends has been started based on the startup status of each service determined by the first thread when starting each unstarted service. Furthermore, if the service on which the service to be started depends has been started, the service to be started can be successfully started. If the service on which the service to be started depends has not been started, the next unstarted service can be traversed without the problem of service startup failure due to the fact that the dependent service has not been started, which can greatly improve the startup efficiency of distributed services.

[0064] As internet traffic increases, the performance of a single server can no longer meet demand. Multiple servers are often required to handle large-scale traffic scenarios. Distributed systems, which can deploy multiple servers, are widely used. In a distributed system, a master server and multiple slave servers can be deployed, with the master server controlling and managing the multiple slave servers.

[0065] As the complexity of Internet business increases, the number of services in distributed systems continues to increase. Dependencies often exist between services, and each service must be started in the order corresponding to the dependencies to ensure smooth startup of each service. To ensure smooth startup of each service, the solution provided in the embodiment of the present invention can deploy a startup program on the master server in the distributed system. Based on this startup program, the services deployed on each slave server are started in the order corresponding to the dependencies.

[0066] In step S201, when the startup program obtains the service startup instruction, it can start a first thread and a second thread, wherein the first thread can be used to monitor the startup status of each service, and the second thread can be used to start each service.

[0067] The startup program can determine that it has obtained the service startup instruction in at least one of the following situations:

[0068] In the first case, each service in the distributed system has been deployed to each slave server. The master server can connect to each slave server to realize communication between the master server and the slave server. That is, when the master server and the slave server are deployed, the startup program can obtain the service startup instruction.

[0069] In the second scenario, when the master server and / or slave server in the distributed system is restarted, such as by rebooting, reloading the operating system, or recovering from a failure, the startup program can obtain the server startup instruction. For example, if the master server in the distributed system fails and is restarted, the startup program can obtain the service startup instruction and start the first thread and the second thread.

[0070] In the third case, the content of the startup program is modified, that is, when the startup program is updated, the startup program can obtain the server startup instruction.

[0071] As an implementation method, the startup program can first start the second thread and obtain the thread number of the second thread, that is, the PID (Process ID). Then, the startup program can start the first thread and pass the thread number of the second thread to the first thread. In this way, when the second thread needs to be operated later, the first thread can operate the second thread based on the thread number.

[0072] After starting the first and second threads, in step S202, the first thread may traverse each service deployed from the server. Each time it traverses a service, it may determine whether the traversed service is started. If the traversed service is already started, the first thread may record the service's startup status, which indicates that the service has been started. If it is determined that the traversed service is not started, the first thread may continue to traverse the next service and return to the above step of traversing each service and determining whether the traversed service is started until all services have been traversed.

[0073] That is, the first thread can traverse each service deployed from the server one by one, and if the currently traversed service is in the started state, record its started state; if the currently traversed service is in the not started state, continue to traverse the next service.

[0074] In one embodiment, when the first thread traverses the services deployed from the server, if the traversed service has been started, then the preset flag corresponding to the service can be set to "ready" in the shared memory area of ​​the distributed system, that is, the startup status of the service is recorded.

[0075] For example, the services deployed from the server include service 1, service 2, service 3, service 4, service 5, and service 6, among which service 1, service 3, and service 6 have already been started. When the startup program obtains the service startup instruction, it can start a first thread T1 and a second thread T2. T1 can traverse the services deployed from the server. When T1 traverses to service 1, it can detect that service 1 has been started. Then, the preset flag corresponding to service 1 in the shared memory area of ​​the distributed system can be set to "ready".

[0076] Then, T1 can continue to check whether the next service, Service 2, is started. If it detects that Service 2 is not started, it can continue to check Service 3 until all services are traversed. After all services are traversed, the preset flag bits corresponding to Service 1, Service 3, and Service 6 are set to "Ready", indicating that Service 1, Service 3, and Service 6 are started.

[0077] In step S203, the second thread may traverse each unstarted service deployed from the server. For each unstarted service traversed, the second thread may determine whether a target service corresponding to the unstarted service is started based on the startup status of each service recorded by the first thread. The target service is a service that the unstarted service depends on. In other words, for each unstarted service traversed, the second thread may determine whether the service that the unstarted service depends on is started based on the startup status of each service recorded by the first thread.

[0078] If the target service corresponding to the traversed unstarted service has been started, then it means that the service on which the unstarted service depends has been started. At this time, the unstarted service can be successfully started, so the second thread can start the unstarted service. If the target service corresponding to the traversed unstarted service has not been started, then it means that the service on which the unstarted service depends has not been started. At this time, if the unstarted service is started, it will fail. Therefore, the second thread can continue to traverse the next unstarted service instead of starting the currently traversed unstarted service. The second thread can return to the steps of traversing each unstarted service based on the startup status recorded by the first thread until all unstarted services are traversed.

[0079] That is, the second thread can traverse each unstarted service one by one. If the service on which the currently traversed unstarted service depends is already started, the currently traversed unstarted service will be started. If the service on which the currently traversed unstarted service depends is not started, to avoid startup failure, the traversal will continue to the next unstarted service. If the currently traversed unstarted service is started when the service on which the currently traversed unstarted service depends is not started, the currently traversed unstarted service will fail to start. Furthermore, developers and / or operation and maintenance personnel will need to troubleshoot each service to determine the cause of the startup failure and other related information. This is time-consuming and labor-intensive, and will seriously reduce the startup efficiency of distributed services.

[0080] In one embodiment, the second thread can determine whether the service on which the currently traversed unstarted service depends has been started by using the preset flags of each service set by the first thread. If the preset status flag corresponding to the service on which the unstarted service depends is "ready", it can be determined that the target service corresponding to the unstarted service has been started, and then the second thread can start the unstarted service. If the preset flag corresponding to the service on which the unstarted service depends is not set to "ready", it can be determined that the target service corresponding to the unstarted service has not been started, and then the second thread can continue to traverse the next unstarted service.

[0081] For example, the services deployed from the server include Service 1, Service 2, Service 3, Service 4, Service 5, and Service 6. Among them, the unstarted services include Service 2, Service 4, and Service 5, and the started services include Service 1, Service 3, and Service 6. Service 1 is the service that Service 2 depends on, Service 4 is the service that Service 5 depends on, and Service 3 and Service 6 do not depend on other services. When the second thread T2 traverses to Service 2, it can determine, based on the startup status of each service recorded by the first thread T1, that the preset flag corresponding to Service 1, on which Service 2 depends, is "Ready". This means that it can be determined that the target service corresponding to Service 2 has been started. Then, T2 can start Service 2.

[0082] Then T2 can continue to traverse the next unstarted service, that is, traverse service 5. Based on the startup status of each service recorded by T1, T2 can determine that the preset flag of service 4 on which service 5 depends is not set to "ready", then it can be determined that the target service corresponding to service 5 is not started. At this time, if service 5 is started, the startup will fail, so T2 can traverse the next unstarted service until all unstarted services in the slave server are traversed.

[0083] It should be noted that there is no limitation on the execution order between the above-mentioned step S202 and step S203. Step S202 and step S203 can be executed simultaneously, that is, the first thread and the second thread can execute the steps to be executed at the same time.

[0084] In the solution of this embodiment, since the first thread can determine the startup status of each service by traversing each service, the second thread can determine whether the service on which the service to be started depends has been started based on the startup status of each service determined by the first thread when starting each unstarted service. Furthermore, if the service on which the service to be started depends has been started, the service to be started can be successfully started. If the service on which the service to be started depends has not been started, the next unstarted service can be traversed without the problem of service startup failure due to the fact that the dependent service has not been started, which can greatly improve the startup efficiency of distributed services.

[0085] In addition, the solution provided in this embodiment is simple to deploy, low-cost, and suitable for small cluster delivery. It can be applied to private deployment delivery scenarios, agile delivery scenarios, etc. Private deployment means that the transmission and storage of all programs, information, and data are carried out in independent private servers. Because some science and technology parks, institutions, banks, transportation units, etc. have high requirements for information security and do not want any data to be exposed to the public network, they generally have their own computer rooms and independent private servers. Therefore, delivery scenarios such as parks, finance, politics and education, and transportation all belong to private deployment delivery scenarios. The solution provided in this embodiment can very well meet the needs of private deployment delivery scenarios, agile delivery scenarios, and other scenarios for sequential startup of various services.

[0086] As an implementation method of an embodiment of the present invention, the types of services deployed from the server may be different. The above services may be microservices or other types of services, for example, middleware services. In the case where the above services are microservices, the above step of determining whether the traversed services have been started may include:

[0087] A preset service discovery interface is called to obtain feedback results of the service discovery interface for the traversed service, and based on the feedback results, it is determined whether the traversed service has been started.

[0088] After the startup program starts the first thread, the first thread can traverse each service in the slave server to determine whether the traversed service has been started. Due to different service types, the first thread can use a monitoring method for the service type based on the service type to determine whether the service of the service type is started.

[0089] In one case, the currently traversed service may be a microservice. In this case, the first thread may determine whether the service is started based on service discovery. Service discovery refers to using a registry to record information about services in a distributed system so that the status of the registered services can be quickly obtained.

[0090] Specifically, when determining whether each microservice is started, the first thread can call a preset service discovery interface, request the service discovery, and then obtain feedback results from the service discovery interface for the traversed microservices. As an implementation method, if the microservice information is recorded in the service discovery registry, the service discovery can feedback the microservice information. Then, the first thread can determine that the microservice is started based on the feedback of the microservice information from the service discovery. If the microservice information is not recorded in the service discovery registry, the service discovery cannot feedback the microservice information. Then, the first thread can determine that the microservice is not started.

[0091] The service discovery mentioned above may be a functional service such as Nacos, Eureka, or Consul that can record information about each service in a distributed system, and is not specifically limited here.

[0092] In another case, for a middleware service, the first thread can monitor the middleware port to determine whether the service is started. By monitoring the middleware port, the first thread can obtain a corresponding indication message when the middleware service is started, and then determine that the middleware service is started.

[0093] It can be seen that in this embodiment, for microservices, the first thread can call the preset service discovery interface, obtain the feedback results of the service discovery interface for the traversed services, and determine whether the traversed services have been started based on the feedback results, thereby accurately determining whether the traversed services are started, and ensuring the accuracy of the startup status of each service recorded by the first thread.

[0094] As an implementation method of the embodiment of the present invention, Figure 3 As shown, the above-mentioned steps of calling a preset service discovery interface, obtaining feedback results of the service discovery interface for the traversed services, and determining whether the traversed services have been started based on the feedback results may include:

[0095] S301, calling a preset service discovery interface, requesting the address of the traversed service from the service discovery interface, and obtaining a feedback result of the service discovery interface;

[0096] In one embodiment, the first thread can call a preset service discovery interface and request the address of the traversed service from the service discovery. The service discovery can feedback the result to the first thread through the service discovery interface based on the address of each service recorded by itself, and the first thread can obtain the feedback result of the service discovery interface.

[0097] If the service finds that the addresses of the various services recorded by itself include the address of the service requested by the first thread, the address of the service requested by the first thread can be sent to the first thread as a feedback result. If the service finds that the addresses of the various services recorded by itself do not include the address of the service requested by the first thread, an empty feedback result can be sent to the first thread. Of course, no result can be sent to the first thread. This is all reasonable.

[0098] For example, Figure 4 As shown, the first thread traverses microservice 2. When determining whether the traversed microservice 2 is started, it can call the preset service discovery interface, namely the Nacos API (Application Programming Interface), and then request the IP (Internet Protocol) address and port of microservice 2 from Nacos. Nacos can return feedback to the first thread based on the recorded microservice information, namely the recorded IP address and port of microservice 2. The first thread can then obtain the feedback result returned by the service discovery interface. If the feedback result includes the IP address of microservice 2, it means that microservice 2 is started and can be called by other services.

[0099] S302: If the feedback result includes the address of the traversed service, determine that the traversed service has been started.

[0100] The service discovery interface feedback result obtained by the first thread includes the address of the traversed service, indicating that the service discovery record has the address of the service. Then, it can be determined that the traversed service has been started. Otherwise, it can be determined that the traversed service has not been started.

[0101] For example, continuing with the example in S301 above, the first thread traverses microservice 2 and obtains the feedback result returned by the service discovery interface. If the feedback result includes the IP address and port of microservice 2, it can be determined that microservice 2 is started. Of course, if the feedback result does not include the IP address and port of microservice 2, it can be determined that microservice 2 is not started.

[0102] It can be seen that in this embodiment, the first thread can call the preset service discovery interface, request the address of the traversed service from the service discovery, and obtain the feedback result of the service discovery interface. If the feedback result includes the address of the traversed service, it can be determined that the traversed service has been started. In this way, based on whether the feedback result of the service discovery interface includes the address of the traversed service, it is possible to accurately determine whether the traversed service has been started, thereby further improving the accuracy of the startup status of each service recorded by the first thread.

[0103] As an implementation method of the embodiment of the present invention, Figure 5 As shown, the above method may further include:

[0104] S501, after all the inactive services are traversed, the second thread determines whether all the services are activated based on the activation status recorded by the first thread, and if not, performs a sleep action;

[0105] After the second thread has completed traversing all unstarted services, it can determine whether all services have been started based on the startup status of each service recorded by the first thread. If it is determined that all services have not been started, the second thread can perform a sleep action to wait for a period of time because the startup of one or more services may take a certain amount of time. If it is determined that all services have been started, the startup program can determine that all services are ready and terminate the second process and the first thread.

[0106] For example, after traversing the unstarted services Service 1 to Service 6, the second thread can determine that Service 1, Service 2, Service 3, and Service 6 are started, and Service 4 and Service 5 are not started based on the startup status of each service record recorded by the first thread, then the second thread can perform a sleep action.

[0107] S502, after the traversal of the services is completed, the first thread determines whether the services have been started, and if not, wakes up the second thread;

[0108] S503: The second thread returns to the process of traversing each unstarted service until all services are started.

[0109] After the first thread has traversed all services deployed from the server, it can record the startup status of each service and then determine whether all services have been started. If it is determined that there are services that have not been started, it is necessary to continue to start the services that have not been started. At this time, the second thread can be awakened, so that the second thread continues to repeatedly execute the above step S203. If it is determined that all services have been started, it can be determined that all services are ready, and then the first thread and the second thread are terminated.

[0110] For example, after traversing services 1 to 6, the first thread determines that services 1, 2, 3, and 6 have been started, and services 4 and 5 have not been started. Then, the first thread can wake up the second thread, and the second thread can continue to traverse each unstarted service, and the cycle continues until all services are started.

[0111] As an implementation manner, the first thread may wake up the second thread through the operating system, or may use other reasonable methods to wake up the second thread, which is not specifically limited here.

[0112] It can be seen that in this embodiment, after all unstarted services have been traversed, the second thread can determine whether all services have been started based on the startup status recorded by the first thread. If not, a sleep action is performed. After all services have been traversed, the first thread can determine whether all services have been started. If not, the second thread is awakened, and the second thread can return to the step of traversing all unstarted services until all services are started. In this way, if there are unstarted services, the first thread can awaken the second thread to loop through the steps of traversing all unstarted services to start the unstarted services until all services are successfully started, which can ensure that all services can be successfully started in the end.

[0113] As an implementation manner of an embodiment of the present invention, if the first thread determines that all the services have not been started, the method may further include:

[0114] After waiting for a preset time, the first thread traverses each unstarted service and returns to each traversed service to determine whether the traversed service has been started, until all the services have been started.

[0115] When the first thread determines that all services have not been started, the first thread can wake up the second thread. Since the second thread loops through the above-mentioned step of "traversing each unstarted service, and each time it traverses an unstarted service, determining whether the target service corresponding to the traversed unstarted service has been started based on the startup status recorded by the first thread, and if so, starting the unstarted service; if not, traversing the next unstarted service, and returning to the step of each traversal of an unstarted service based on the startup status recorded by the first thread", it takes a certain amount of time. Therefore, the first thread can also perform a waiting action. After waiting for a preset period of time, it can continue to traverse each unstarted service and return to the step of traversing a service each time to determine whether the traversed service has been started until all services have been started.

[0116] Among them, the preset duration can be set according to the duration required for the second thread to loop through the above steps once, and can generally be slightly longer than the duration required for the second thread to loop through the above steps once, to ensure that when continuing to traverse each unstarted service, the second thread has already started some services, so as to avoid frequently looping through each service to determine whether the traversed service has been started, thereby avoiding waste of resources.

[0117] For example, if the preset duration is 10 seconds, after the first thread traverses all services and determines that among Service 1, Service 2, Service 3, Service 4, Service 5, and Service 6, Service 2 and Service 3 are not started, then the first thread can wake up the second thread and perform a wait action. After waiting for 10 seconds, it continues to traverse each unstarted service and returns to the step of determining whether the traversed service is started for each traversed service until it determines that Service 1, Service 2, Service 3, Service 4, Service 5, and Service 6 are all started. During the 10 seconds that the first thread performs the wait action, the second thread can continue to start some services that have not yet started.

[0118] It can be seen that in this embodiment, if the first thread determines that all services have not been started, it can also wait for a preset period of time, traverse all unstarted services, and return to execute each traversal of a service to determine whether the traversed service has been started, until all services have been started. Since the first thread waits for the preset period of time, it can be guaranteed that the unstarted service will be started by the second thread within the preset period of time, so that the first thread cooperates with the second thread to ensure that all services can be started smoothly in the end.

[0119] As an implementation manner of an embodiment of the present invention, before the above step of starting the first thread and the second thread, the above method further includes:

[0120] Send a service startup script to the slave server so that when the slave server determines that the service startup script does not exist locally, it installs the service startup script; when it determines that the service startup script exists locally, it determines whether the received service startup script is the same as the locally stored service startup script; and when the received service startup script is different from the locally stored service startup script, it uses the received service startup script to overwrite the locally stored service startup script.

[0121] In order for the second thread to successfully start each service deployed in the slave server, before starting each service, the startup program can send a service startup script to each slave server, wherein the service startup script is a pre-written code script for starting the service.

[0122] After receiving the startup script from the server, it can be determined whether the startup script exists locally. If it is determined that the service startup script does not exist locally, the service startup script can be installed. If it is determined from the server that the service startup script exists locally, the received service startup script can be verified with the locally stored service startup script to determine whether the received service startup script is the same as the locally stored service startup script.

[0123] If the received service startup script is different from the locally stored service startup script, the slave server can use the received service startup script to overwrite the locally stored service startup script. If the received service startup script is the same as the locally stored service startup script, the slave server can ignore the received service startup script and not perform other operations.

[0124] In one embodiment, the slave server can use MD5 (Message-Digest Algorithm) to verify the received service startup script and the locally stored service startup script. MD5 is a cryptographic hash function. Performing an MD5 operation on a file can generate a 128-bit (16-byte) hash value, which can be used to ensure the integrity and / or consistency of information transmission. Therefore, the slave server can use MD5 to calculate the MD5 values ​​corresponding to the received service startup script and the locally stored service startup script, respectively, and then determine whether the two MD5 values ​​are the same. If they are the same, it can be determined that the received service startup script and the locally stored service startup script are the same. If the two MD5 values ​​are different, it can be determined that the received service startup script and the locally stored service startup script are different.

[0125] For example, if a service startup script M1 exists locally on the slave server and a service startup script M2 is received, the slave server can calculate the MD5 values ​​of M1 and M2, which are m1 and m2 respectively, and then compare m1 and m2. If m1 and m2 are the same, it can be determined that the locally stored service startup script M1 is the same as the received service startup script M2, and the received service startup script M2 can be ignored. If m1 and m2 are different, the slave server can determine that the locally stored service startup script M1 is different from the received service startup script M2, and then the received service startup script M2 can be used to overwrite the locally stored service startup script M1.

[0126] Accordingly, the step of starting the inactive service may include:

[0127] The second thread calls a service startup script corresponding to the unstarted service and installed from the server to start the unstarted service.

[0128] After the service startup script is installed in the slave server, when it is necessary to start the unstarted service deployed in the slave server, the second thread can call the service startup script installed in the slave server corresponding to the unstarted service, so that the slave server runs the service startup script to start the unstarted service.

[0129] For example, service a is deployed in the slave server and service startup script A is installed. When the second thread starts service a, it can call the service startup script A installed in the slave server to make the slave server run service startup script A, thereby starting service a.

[0130] It can be seen that in this embodiment, the startup program can send a service startup script to the slave server, so that when the slave server determines that the service startup script does not exist locally, it installs the service startup script. When it is determined that the service startup script exists locally, it determines whether the received service startup script is the same as the locally stored service startup script. If the received service startup script is different from the locally stored service startup script, the received service startup script is used to overwrite the locally stored service startup script. After the service startup script is installed in the slave server, the second thread can call the service startup script installed in the slave server corresponding to the unstarted service to start the unstarted service. In this way, the second thread can call the service startup script installed in the slave server corresponding to the unstarted service to start the unstarted service, which can ensure the smooth startup of the unstarted service.

[0131] As an implementation manner of an embodiment of the present invention, before the above step of starting the first thread and the second thread, the above method may further include:

[0132] In at least one of the following situations, it is determined that the service startup instruction has been obtained:

[0133] When the deployment of the master server and the slave server in the distributed system is completed; the master server and / or the slave server in the distributed system is restarted; and the startup program is updated.

[0134] When the startup program obtains the service startup instruction, it may start the first thread and the second thread to perform the distributed service startup method described in any of the above embodiments. The startup program may determine that the service startup instruction is obtained in at least one of the following circumstances.

[0135] In the first case, when the master server and the slave server are deployed in the distributed system, that is, when the distributed system is deployed for the first time, the startup program can determine that the service startup instruction has been obtained. In one embodiment, when the distributed system is deployed, one server can be selected as the master server (master) from multiple servers, and the other servers can be selected as slave servers (slave). Then, the startup program is deployed in the master server, and the IP address and access account password of the slave server are configured. The startup mode of the startup program can be set to self-start at power-up, that is, the startup program automatically runs after the master server is turned on. Then, the startup program can be started, and at this time, the startup program determines that the service startup instruction has been obtained.

[0136] In the second case, when the master server and / or slave server in the distributed system is restarted, the startup program can determine that the service startup instruction has been obtained. The restart of the master server and / or slave server can include situations where the master server and / or slave server needs to be restarted, such as manually controlling the restart of the master server and / or slave server, restarting the master server and / or slave server after a crash, or updating the operating system of the master server and / or slave server.

[0137] When the master server and / or slave server are restarted, if the startup program's startup mode is set to auto-start, the startup program will automatically run after the master server is restarted, and the startup program can obtain the server startup command. If the startup program is not set to auto-start, you can also set a startup command to trigger the startup program to run when the master server and / or slave server is restarted.

[0138] In the third case, when the startup program is updated, it can confirm that it has received the service startup instructions. When adding or removing services, fixing program vulnerabilities, or improving program functionality, the startup program code needs to be modified (that is, updated). In this case, the startup program can obtain the server startup instructions. That is, after the startup program is updated, it confirms that it has received the server startup instructions and starts each service on the slave server.

[0139] It can be seen that in this embodiment, the startup program can determine that the service startup instruction is obtained when the deployment of the master server and the slave server in the distributed system is completed, when the master server and / or the slave server in the distributed system is restarted, when the startup program is updated, etc., thereby starting the first thread and the second thread to start each service in the distributed system. This can ensure that when it is necessary to start each service in the distributed system, the startup program can be run smoothly, so that each service in the distributed system can be successfully started through the first thread and the second thread, which can solve the problem of sequential startup of each service in a distributed service system such as delivery project deployment, restart service, and single point failure restart.

[0140] The following combination Figure 6 The flowchart shown in FIG. 1 is used as an example to introduce the method for starting a distributed service provided by an embodiment of the present invention. Figure 6 As shown, the startup program deployed on the master server begins running, i.e., running the program. Furthermore, the startup program distributes files to each slave server, i.e., distributes the service startup script to each slave server. Each slave server can install the service startup script. When the startup program receives the service startup instruction, it can start two threads: a first thread (service status monitoring thread T1) and a second thread (service startup thread T2).

[0141] Next, the service startup thread T2 loops through each unstarted service. For each unstarted service, it determines whether its dependent service is "ready" based on the service startup status recorded by the service status monitoring thread T1. In other words, it determines whether its corresponding target service has been started. If so, it starts the service. If not, it continues looping through the unstarted services, moving on to the next unstarted service.

[0142] After looping through all unstarted services, the service startup thread T2 can determine whether all services have been started. If so, it means that all services are ready and the startup process can be terminated. At this time, the startup program can terminate the first thread and the second thread. If all services have not been started, the service startup thread T2 can perform a waiting action, that is, sleep.

[0143] After the service status monitoring thread T1 is started, it can loop through each service. Each time it traverses a service, it can detect whether the service is started based on service discovery and other factors. If so, it can set the service status to "Ready", that is, record the startup status of the server as started. If it is detected that the service is not started, it can return to looping through each service, that is, continue to traverse the next service.

[0144] After looping through all services, the service status monitoring thread T1 can determine whether all services have been started. If so, it means that all services are ready and the startup process can be terminated. At this time, the startup program can terminate the first thread and the second thread. If all services have not been started, the service status monitoring thread T1 can wake up the service startup thread T2, causing the service startup thread T2 to continue to loop through all unstarted services.

[0145] At the same time, the service status monitoring thread T1 can also wait for a preset time, such as 10 seconds, that is, sleep for 10 seconds and then continue the loop. In the subsequent loop, the service status monitoring thread T1 can only traverse the services that have not been started. According to the above method, the service status monitoring thread T1 and the service startup thread T2 traverse the loop and cooperate with each other to start each service until each service is successfully started.

[0146] Since the manner in which the service status monitoring thread T1 and the service starting thread T2 execute various steps has been described in detail in the above embodiments, they will not be repeated here.

[0147] Corresponding to the above-mentioned distributed service startup method, an embodiment of the present invention further provides a distributed service system. The following introduces a distributed service system provided by an embodiment of the present invention.

[0148] like Figure 1 As shown, a distributed service system includes a master server 110 and multiple slave servers 130. The master server is deployed with a startup program 120, and each slave server is deployed with at least one service 140, wherein:

[0149] The startup program 120 is used to start the first thread and the second thread when obtaining the service startup instruction;

[0150] The first thread 121 is used to traverse each service, and each time it traverses a service, it determines whether the traversed service has been started. If so, it records the startup status of the service. If not, it traverses the next service and returns to the process of traversing each service to determine whether the traversed service has been started until all services are traversed;

[0151] The second thread 122 is used to traverse each unstarted service, and each time it traverses an unstarted service, it determines whether the target service corresponding to the traversed unstarted service has been started based on the startup status recorded by the first thread. If so, it starts the unstarted service; if not, it traverses the next unstarted service and returns each time it traverses an unstarted service based on the startup status recorded by the first thread until all the unstarted services are traversed, wherein the target service is the service that the unstarted service depends on.

[0152] It can be seen that in the solution provided by the embodiment of the present invention, the master server in the distributed system is deployed with a startup program, and the distributed system also includes multiple slave servers, each of which is deployed with at least one service. When the startup program obtains the service startup instruction, it starts the first thread and the second thread; the first thread traverses each service, and each time it traverses a service, it determines whether the traversed service has been started. If so, it records the startup status of the service. If not, it traverses the next service and returns each time it traverses a service to determine whether the traversed service has been started until all services are traversed; the second thread traverses each unstarted service, and each time it traverses an unstarted service, it determines whether the target service corresponding to the traversed unstarted service has been started based on the startup status recorded by the first thread. If so, it starts the unstarted service. If not, it traverses the next unstarted service and returns each time it traverses an unstarted service based on the startup status recorded by the first thread until all unstarted services are traversed, wherein the target service is the service on which the unstarted service depends. Since the first thread can determine the startup status of each service by traversing each service, the second thread can determine whether the service on which the service to be started depends has been started based on the startup status of each service determined by the first thread when starting each unstarted service. Furthermore, if the service on which the service to be started depends has been started, the service to be started can be successfully started. If the service on which the service to be started depends has not been started, the next unstarted service can be traversed without the problem of service startup failure due to the fact that the dependent service has not been started, which can greatly improve the startup efficiency of distributed services.

[0153] As an implementation method of the embodiment of the present invention, the service may be a microservice;

[0154] The first thread 121 may be specifically configured to call a preset service discovery interface, obtain a feedback result of the service discovery interface for the traversed service, and determine whether the traversed service has been started based on the feedback result.

[0155] As an implementation method of an embodiment of the present invention, the first thread 121 can be specifically used to call a preset service discovery interface, request the address of the traversed service from the service discovery, and obtain the feedback result of the service discovery interface; if the feedback result includes the address of the traversed service, it is determined that the traversed service has been started.

[0156] As an implementation of the embodiment of the present invention, the second thread 122 may also be configured to determine whether all the services have been started based on the start status recorded by the first thread after the traversal of all the unstarted services is completed, and if not, perform a sleep action;

[0157] The first thread 121 may also be used to determine whether all services have been started after the traversal of all services is completed, and if not, wake up the second thread;

[0158] The second thread 122 may also be used to return to the process of traversing each unstarted service until all services are started.

[0159] As an implementation method of an embodiment of the present invention, the first thread 121 can also be used to, if the first thread determines that the services have not all been started, wait for a preset period of time, traverse each unstarted service, and return each traversed service to determine whether the traversed service has been started until all the services have been started.

[0160] As an implementation manner of an embodiment of the present invention, the startup program 120 may also be used to send a service startup script to the slave server before starting the first thread and the second thread, so that the slave server installs the service startup script when it is determined that the service startup script does not exist locally, and when it is determined that the service startup script exists locally, determines whether the received service startup script is the same as the locally stored service startup script, and if the received service startup script is different from the locally stored service startup script, uses the received service startup script to overwrite the locally stored service startup script;

[0161] The second thread 122 may be specifically configured to call a service startup script corresponding to the unstarted service and installed from the server to start the unstarted service.

[0162] As an implementation of an embodiment of the present invention, the startup program 120 may also be configured to determine that a service startup instruction is obtained before starting the first thread and the second thread in at least one of the following situations:

[0163] When the deployment of the master server and the slave server in the distributed system is completed; the master server and / or the slave server in the distributed system is restarted; and the startup program is updated.

[0164] The embodiment of the present invention further provides a server, such as Figure 7 As shown, it includes a processor 701, a communication interface 702, a memory 703 and a communication bus 704, wherein the processor 701, the communication interface 702, and the memory 703 communicate with each other through the communication bus 704.

[0165] Memory 703, used for storing the startup program;

[0166] The processor 701 is configured to implement the distributed service startup method described in any one of the above embodiments when executing the startup program stored in the memory 703 .

[0167] It can be seen that in the solution provided by the embodiment of the present invention, the master server in the distributed system is deployed with a startup program, and the distributed system also includes multiple slave servers, each of which is deployed with at least one service. When the startup program obtains the service startup instruction, it starts the first thread and the second thread; the first thread traverses each service, and each time it traverses a service, it determines whether the traversed service has been started. If so, it records the startup status of the service. If not, it traverses the next service and returns each time it traverses a service to determine whether the traversed service has been started until all services are traversed; the second thread traverses each unstarted service, and each time it traverses an unstarted service, it determines whether the target service corresponding to the traversed unstarted service has been started based on the startup status recorded by the first thread. If so, it starts the unstarted service. If not, it traverses the next unstarted service and returns each time it traverses an unstarted service based on the startup status recorded by the first thread until all unstarted services are traversed, wherein the target service is the service on which the unstarted service depends. Since the first thread can determine the startup status of each service by traversing each service, the second thread can determine whether the service on which the service to be started depends has been started based on the startup status of each service determined by the first thread when starting each unstarted service. Furthermore, if the service on which the service to be started depends has been started, the service to be started can be successfully started. If the service on which the service to be started depends has not been started, the next unstarted service can be traversed without the problem of service startup failure due to the fact that the dependent service has not been started, which can greatly improve the startup efficiency of distributed services.

[0168] The communication bus mentioned in the server above can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. This communication bus can be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one thick line is used in the figure, but this does not mean that there is only one bus or only one type of bus.

[0169] The communication interface is used for communication between the above server and other devices.

[0170] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk memory. Alternatively, the memory may be at least one storage device located away from the processor.

[0171] The above-mentioned processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, and discrete hardware components.

[0172] In another embodiment of the present invention, a computer-readable storage medium is provided, which stores a startup program. When the startup program is executed by a server, the steps of the distributed service startup method described in any of the above embodiments are implemented.

[0173] In another embodiment of the present invention, a computer program product including instructions is provided. When the computer program product is run on a computer, the computer executes the method for starting a distributed service described in any one of the above embodiments.

[0174] In the above embodiments, all or part of the embodiments can be implemented by software, hardware, firmware, or any combination thereof. When implemented using software, all or part of the embodiments can be implemented in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or data center that includes one or more available media. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive (SSD)).

[0175] It should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply the existence of any such actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or device comprising the element.

[0176] Each embodiment in this specification is described in a related manner. Similar portions between embodiments can be referenced to each other. Each embodiment focuses on the differences between the other embodiments. In particular, since the system, server, computer-readable storage medium, and computer program product are generally similar to the method embodiments, their descriptions are relatively simplified. For related portions, reference can be made to the descriptions of the method embodiments.

[0177] The above description is only a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present invention are included in the scope of protection of the present invention.

Claims

1. A method for starting a distributed service, characterized in that: A startup program deployed on a master server in a distributed service system, wherein the distributed service system further comprises a plurality of slave servers, each of which has at least one service deployed thereon, wherein the method comprises: When a service start instruction is obtained, the first thread and the second thread are started; The first thread traverses each service, and each time it traverses a service, it determines whether the traversed service has been started. If so, it records the startup status of the service. If not, it traverses the next service and returns to the process of traversing each service to determine whether the traversed service has been started until all services are traversed; The second thread traverses each unstarted service, and each time it traverses an unstarted service, determines whether a target service corresponding to the traversed unstarted service has been started based on the startup status recorded by the first thread; if so, starts the unstarted service; if not, traverses the next unstarted service, and returns to the startup status recorded by the first thread for each traversal of the unstarted service until the traversal of each unstarted service is completed, wherein the target service is a service that the unstarted service depends on; The method further comprises: After the traversal of the unstarted services is completed, the second thread determines whether the services are all started based on the start status recorded by the first thread, and if not, performs a sleep action; After all services are traversed, the first thread determines whether all services are started. If not, the second thread is awakened. The first thread waits for a preset time, traverses all inactive services, and returns to the traversed service one by one to determine whether the traversed service is started, until all services are started. The second thread returns to the traversal of each unstarted service until each service is started.

2. The method according to claim 1, characterized in that The service is a microservice; Determining whether the traversed service has been started includes: A preset service discovery interface is called to obtain feedback results of the service discovery interface for the traversed service, and based on the feedback results, it is determined whether the traversed service has been started.

3. The method according to claim 2, characterized in that The calling of a preset service discovery interface, obtaining a feedback result of the service discovery interface for the traversed service, and determining whether the traversed service has been started based on the feedback result, includes: Call the preset service discovery interface, request the address of the traversed service from the service discovery request, and obtain the feedback result of the service discovery interface; If the feedback result includes the address of the traversed service, it is determined that the traversed service has been started.

4. The method according to claim 1 or 2, characterized in that Before starting the first thread and the second thread, the method further includes: Sending a service startup script to the slave server, so that the slave server installs the service startup script when it is determined that the service startup script does not exist locally, determines whether the received service startup script is the same as the locally stored service startup script when it is determined that the service startup script exists locally, and uses the received service startup script to overwrite the locally stored service startup script if the received service startup script is different from the locally stored service startup script; The starting of the unstarted service includes: The second thread calls a service startup script corresponding to the unstarted service and installed from the server to start the unstarted service.

5. The method according to claim 1 or 2, characterized in that Before starting the first thread and the second thread, the method further includes: In at least one of the following situations, it is determined that the service startup instruction has been obtained: When the deployment of the master server and the slave server in the distributed service system is completed; the master server and / or the slave server in the distributed service system is restarted; and the startup program is updated.

6. A distributed service system, characterized in that: The distributed service system includes a master server and multiple slave servers, wherein the master server is deployed with a startup program, and each slave server is deployed with at least one service, wherein: The startup program is used to start the first thread and the second thread when obtaining the service startup instruction; The first thread is used to traverse each service, and each time it traverses a service, it determines whether the traversed service has been started. If so, it records the startup status of the service. If not, it traverses the next service and returns to the process of traversing each service to determine whether the traversed service has been started until all services are traversed; The second thread is configured to traverse each unstarted service, and each time a unstarted service is traversed, determine whether a target service corresponding to the traversed unstarted service has been started based on the startup status recorded by the first thread; if so, start the unstarted service; if not, traverse the next unstarted service, and return to the startup status recorded by the first thread for each traversal of the unstarted service until all unstarted services are traversed, wherein the target service is a service that the unstarted service depends on; The service is a microservice; The first thread is specifically configured to call a preset service discovery interface, obtain a feedback result of the service discovery interface for the traversed service, and determine whether the traversed service has been started based on the feedback result; The first thread is specifically configured to call a preset service discovery interface, request the address of the traversed service from the service discovery interface, and obtain a feedback result of the service discovery interface; if the feedback result includes the address of the traversed service, determining that the traversed service has been started; The second thread is further configured to determine, after the traversal of all the unstarted services is completed, whether all the services have been started based on the start status recorded by the first thread, and if not, perform a sleep action; The first thread is further configured to determine whether all services have been started after the traversal of all services is completed, and if not, wake up the second thread; The first thread is further configured to, if the first thread determines that all services have not been started, wait for a preset period of time, traverse all unstarted services, and return to each traversed service to determine whether the traversed service has been started, until all services have been started; The second thread is further configured to return to the process of traversing each unstarted service until all services are started.

7. A server, characterized in that: The server is deployed with a startup program, and when the server executes the startup program, the method steps described in any one of claims 1 to 5 are implemented.

8. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a startup program, and when the startup program is executed by the server, the method steps described in any one of claims 1 to 5 are implemented.

Images