A service process running method, system, device and readable storage medium
By disabling and controlling the external traffic interfaces of service processes in a microservice environment, and automatically or manually managing traffic based on service status, the problem of abnormal network requests during service deployment and shutdown is solved, resulting in more stable service operation.
Patent Information
- Application Number
- CN202310288407.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2023-03-15
- Publication Date
- 2026-01-30
- Estimated Expiration
- 2043-03-15
AI Technical Summary
In a microservices environment, network request anomalies can easily occur when services are published or stopped. Existing network request middleware or frameworks cannot fully meet the needs of service maintenance or machine downtime scenarios in an enterprise environment, resulting in abnormal traffic access.
By disabling external traffic interfaces when a service process startup request is received, and automatically or manually calling the internal traffic management interface to enable or disable traffic based on the instance status after detecting the service process status, business code execution errors caused by accessing traffic can be avoided when the application starts or shuts down.
Effective control over traffic uplink and downlink avoids business code execution errors caused by service anomalies, increases awareness of the underlying device health status, automatically makes traffic operation decisions, and reduces the occurrence of anomalies.
Smart Images

Figure CN116346895B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of computer technology, and more specifically to a service process running method, system, device, and readable storage medium. Background Technology
[0002] In a microservices environment, service deployments are relatively frequent. Service deployments and shutdowns can cause some anomalies related to request traffic. For example, during deployment, the service provider may not be fully started and may be called by consumer applications. Or, during service shutdown, the service consumer may not be aware that the provider has shut down the service in time, resulting in request anomalies.
[0003] Directly starting or stopping a process can easily lead to network request anomalies. While existing network request middleware or frameworks can perform some service discovery functions, they cannot fully meet the needs of service maintenance, machine downtime, configuration changes, and other scenarios in an enterprise environment. Summary of the Invention
[0004] Based on this, embodiments of this application provide a service process running method, system, device, and readable storage medium, which uses an internally provided service interface for managing traffic to flexibly go online, avoiding errors in business code execution caused by access traffic due to application startup or shutdown failures.
[0005] To achieve the above objectives, the embodiments of this application provide the following technical solutions:
[0006] According to a first aspect of the embodiments of this application, a method for running a service process is provided, the method comprising:
[0007] When a service process startup request for the current microservice is received, the target application service process is started, and the interface for external traffic is disabled.
[0008] Disable service traffic threads when starting the application;
[0009] After the application service process has started, check whether the application service process started normally.
[0010] If normal, the service instance status will determine whether to manually or automatically call the service's internal traffic management interface to bring service traffic online.
[0011] Re-enable the interface that provides the outbound traffic.
[0012] Optionally, the step of determining whether to manually judge or automatically call the in-process interface to bring service traffic online based on the status of the service instance includes:
[0013] If the service instance is in use, automatically call the in-process interface to bring service traffic online;
[0014] If the service instance is in the maintenance state, it is necessary to manually determine whether to call the in-process interface to bring the service traffic online.
[0015] Optionally, it also includes:
[0016] Upon receiving a request to shut down the current microservice's service process, the service's internal traffic management interface is invoked to close external traffic;
[0017] The process will be suspended until it has finished processing the current traffic and is completely shut down.
[0018] Optionally, it also includes:
[0019] Upon receiving a service maintenance request for the current microservice, manually invoke the service's internal traffic management interface to close external traffic;
[0020] The process will be shut down once it has finished processing the existing traffic.
[0021] Optionally, it also includes:
[0022] Upon receiving a configuration change request for the current microservice, manually invoke the service's internal traffic management interface to close external traffic;
[0023] The process will be shut down once it has finished processing the existing traffic.
[0024] Optionally, the service internal traffic management interface includes RPC and HTTP interfaces;
[0025] The disabled service traffic initiated by the application includes RPC traffic based on the Dubbo framework, as well as HTTP traffic.
[0026] According to a second aspect of the embodiments of this application, a service process running system is provided, the system comprising:
[0027] The service process startup module is used to start the target application service process when a service process startup request for the current microservice is received, while disabling the interface for external traffic.
[0028] The service traffic disable module is used to disable service traffic threads when the application starts.
[0029] The detection module is used to detect whether the application service process has started normally after it has finished starting.
[0030] The service traffic deployment module is used to determine, based on the status of the service instance, whether to manually judge or automatically call the service's internal traffic management interface to deploy service traffic if the situation is normal.
[0031] The external traffic interface recovery module is used to restore the interface that enables external traffic.
[0032] Optionally, the service traffic online module is specifically used for:
[0033] If the service instance is in use, automatically call the in-process interface to bring service traffic online;
[0034] If the service instance is in the maintenance state, it is necessary to manually determine whether to call the in-process interface to bring the service traffic online.
[0035] Optionally, it also includes:
[0036] The service shutdown module is used to call the internal traffic management interface of the service to shut down external traffic when it receives a service process shutdown request for the current microservice; and to stop the process until the process has finished processing the existing traffic business and then shuts down completely.
[0037] Optionally, it also includes:
[0038] The service maintenance module is used to manually call the internal traffic management interface of the service when a service maintenance request for the current microservice is received, and shut down the external traffic; the process is shut down after the process has finished processing the existing traffic business.
[0039] Optionally, it also includes:
[0040] The service configuration change module is used to manually call the internal traffic management interface of the service to shut down external traffic when a configuration change request for the current microservice is received; the process will be shut down after the process has finished processing the existing traffic business.
[0041] Optionally, the service internal traffic management interface includes RPC and HTTP interfaces; the disabled service traffic when the application starts includes RPC traffic based on the Dubbo framework and HTTP traffic.
[0042] According to a third aspect of the present application, an electronic device is provided, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method described in the first aspect above.
[0043] According to a fourth aspect of the embodiments of this application, a computer-readable storage medium is provided having computer-readable instructions stored thereon, the computer-readable instructions being executable by a processor to implement the method described in the first aspect above.
[0044] In summary, this application provides a service process running method, system, device, and readable storage medium. Upon receiving a service process startup request for the current microservice, the method starts the target application service process while simultaneously disabling the external traffic interface. The application startup disables the service traffic thread. After the application service process starts, it checks whether the process started normally. If normal, based on the service instance's status, it determines whether to manually or automatically call the service's internal traffic management interface to enable service traffic. The external traffic interface is then re-enabled. This flexible deployment using the internally provided traffic management service interface avoids errors in business code execution caused by incoming traffic due to application startup or shutdown failures. Attached Figure Description
[0045] To more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are merely exemplary, and those skilled in the art can derive other embodiments based on the provided drawings without creative effort.
[0046] The structures, proportions, sizes, etc. illustrated in this specification are only for the purpose of assisting those skilled in the art in understanding and reading the content disclosed herein, and are not intended to limit the conditions under which the present invention can be implemented. Therefore, they have no substantial technical significance. Any modifications to the structure, changes in the proportions, or adjustments to the size, without affecting the effects and objectives that the present invention can produce, should still fall within the scope of the technical content disclosed in the present invention.
[0047] Figure 1 This is a normal service access process provided for the embodiments of this application;
[0048] Figure 2 A diagram illustrating a network request exception that occurred during the service startup process provided in this embodiment of the application.
[0049] Figure 3 This is a diagram illustrating the network requests that occur when a service is shut down, as provided in an embodiment of this application.
[0050] Figure 4 This is an overall flowchart of the online service provided in the embodiments of this application;
[0051] Figure 5 This application provides a schematic flowchart of a service process execution method.
[0052] Figure 6 This is a schematic diagram illustrating the service publishing startup process provided in the embodiments of this application.
[0053] Figure 7This is a schematic diagram illustrating the process of closing the startup process of a service provided in an embodiment of this application.
[0054] Figure 8 This is a schematic diagram illustrating service maintenance or downtime situations provided in the embodiments of this application;
[0055] Figure 9 A block diagram of the service process running system provided in the embodiments of this application;
[0056] Figure 10 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application;
[0057] Figure 11 This is a schematic diagram of a computer-readable storage medium provided in an embodiment of this application. Detailed Implementation
[0058] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.
[0059] It is understood that the terms “first,” “second,” etc., used in this application may be used herein to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish one element from another.
[0060] The following specific embodiments illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0061] Figure 1 The normal service access process is shown, and it can be seen that under normal circumstances, a service process can receive external network requests after it starts.
[0062] Figure 2 This shows a network request exception that occurred when starting the service. When the service is starting up or the service process has failed, it is easy for external network requests to access the service process to fail.
[0063] Figure 3 The diagram shows the network requests that occurred when the service was shut down. When a service is shut down voluntarily or involuntarily (such as when a physical machine crashes), and the service stops abnormally, requests are likely to fail if there is still traffic.
[0064] Existing microservice frameworks typically implement service online / offline notification functionality. For example, load balancers generally use heartbeats; if network access differs, subsequent requests will not access processes on that machine. Alternatively, RPC frameworks usually initiate online / offline notifications through a service registry. Figure 4 As shown, when a service is launched, the service process starts successfully, notifying the service registry and remote service center that the consumer service is online and can be called; when a service is taken offline, the service consumer is first notified that the service is preparing to close and that no further requests should be sent. However, the sources of traffic that trigger code execution will be more diverse, such as external HTTP requests, TCP requests, etc.
[0065] However, some new problems may arise. If maintenance or configuration modifications are required on the current machine, the process may still exist at times. In such cases, the existing framework will only perform service online notifications or offline traffic shutdown operations when the process is closed. If operations are performed while the process is still running, it may affect changes to the production line.
[0066] As you can see, we encountered several common problems: 1. Network request exceptions during service deployment. 2. Network request exceptions during process shutdown. 3. Network request exceptions during maintenance or system downtime.
[0067] Figure 5 This application illustrates a service process execution method provided by an embodiment of the present application, the method comprising:
[0068] Step 501: Upon receiving a request to start the service process of the current microservice, start the target application service process and disable the interface for external traffic.
[0069] Step 502: Disable service traffic threads when starting the application;
[0070] Step 503: After the application service process has started, check whether the application service process has started normally;
[0071] Step 504: If normal, determine whether to manually check or automatically call the service's internal traffic management interface to bring service traffic online based on the service instance's status;
[0072] Step 505: Re-enable the interface for external traffic.
[0073] In one possible implementation, step 504, which involves determining whether to manually or automatically invoke an in-process interface to bring service traffic online based on the status of the service instance, includes:
[0074] If the service instance is in use, automatically call the in-process interface to bring service traffic online;
[0075] If the service instance is in the maintenance state, it is necessary to manually determine whether to call the in-process interface to bring the service traffic online.
[0076] Compared to traditional microservice deployment mechanisms, the external traffic deployment mechanism provided in this application embodiment offers better control over traffic. Before deployment, the first step is to ensure the service is available through a health check of the application service. The second step is to determine whether to automatically enable service traffic based on the service instance status. Service instance status can be divided into "in use" or "under maintenance." The "in use" status allows for automatic deployment of traffic, while the "under maintenance" status generally indicates that there may be other faults in other parts of the machine. In this case, automatic deployment is not possible and manual judgment is required. By using the maintenance status, the application can indirectly perceive the health status of the underlying machine, thus avoiding service call failures after deployment.
[0077] In one possible implementation, it also includes:
[0078] Upon receiving a request to shut down the current microservice's service process, the internal traffic management interface of the service is invoked to shut down external traffic; the process is then stopped until it has finished processing the existing traffic and is completely shut down.
[0079] In one possible implementation, it also includes:
[0080] Upon receiving a service maintenance request for the current microservice, the internal traffic management interface of the service is manually invoked to shut down external traffic; the process is then shut down after it has finished processing the existing traffic.
[0081] In one possible implementation, it also includes:
[0082] Upon receiving a configuration change request for the current microservice, the internal traffic management interface of the service is manually invoked to shut down external traffic; the process is then shut down after it has finished processing the existing traffic.
[0083] The operation during a crash or configuration modification is roughly the same as the offline operation process. The difference is that during maintenance or configuration changes, the process may not necessarily be shut down. For traditional microservices, if the process is not shut down, disabling external traffic requires manually disabling the service bit by bit. However, in the embodiments of this application, the traffic management of a single process is all done through the interface exposed inside the process. It is only necessary to call the traffic disabling interface inside the service.
[0084] In one possible implementation, the service internal traffic management interface includes RPC and HTTP interfaces; the disabled service traffic initiated by the application includes RPC traffic based on the Dubbo framework, as well as HTTP traffic.
[0085] The service process running method provided in this application embodiment flexibly adds and removes traffic by using an internally provided traffic management service interface to avoid errors in business code execution caused by access traffic due to application startup or shutdown failures; adds a maintenance status to allow the application to indirectly perceive the health status of the underlying device and automatically decide whether to add or remove traffic; and avoids abnormalities caused by access traffic when process shutdown is time-consuming and the process needs to be forcibly killed.
[0086] The service process operation method provided in the embodiments of this application will be described in detail below with reference to the accompanying drawings.
[0087] Figure 6 This application provides a solution to avoid network request anomalies when launching traffic during the service publishing process, as illustrated in an embodiment of this application. The solution includes the following steps:
[0088] Step 1: Start the service process and provide an interface to disable / enable outbound traffic;
[0089] Step 2: By default, the application disables service traffic, such as RPC traffic (Dubbo framework) and HTTP (Nginx, Citrix).
[0090] Step 3: Service process starts up and health check passes. The health check will check whether the service starts up normally.
[0091] Step 4: Enable service traffic by calling the in-process interface. The online traffic script determines whether the user should manually or automatically call the in-process interface to enable service traffic, such as internal service traffic like RPC and HTTP interfaces, depending on the application scenario.
[0092] As you can see, starting the application here is different from traditional microservice traffic deployment. Traditional microservices deploy all traffic directly through service discovery. In this embodiment, service traffic is disabled by default. The process is started successfully first, and then traffic is deployed automatically or manually depending on the actual scenario.
[0093] Compared to traditional microservice deployment mechanisms, the external traffic deployment mechanism provided in this application embodiment offers better control over traffic. Before deployment, the first step is to ensure the service is available through a health check of the application service. The second step is to determine whether to automatically enable service traffic based on the service instance status. Service instance status can be divided into "in use" or "under maintenance." The "in use" status allows for automatic deployment of traffic, while the "under maintenance" status generally indicates that there may be other faults in other parts of the machine. In this case, automatic deployment is not possible and manual judgment is required. By using the maintenance status, the application can indirectly perceive the health status of the underlying machine, thus avoiding service call failures after deployment.
[0094] Figure 7 This application provides a solution for preventing network request anomalies when a service shuts down its startup process, stops traffic, or is interrupted, including the following steps:
[0095] Step 1: Call the service's internal traffic management interface to shut down external traffic such as RPC and HTTP;
[0096] Step 2: Close the process;
[0097] Step 3: After the process finishes processing the existing traffic, it stops and waits until the process no longer exists.
[0098] When handling traffic offline, the operation to shut down a process involves first closing the entry point, and then closing the process after the internal logic is completed.
[0099] Figure 8 This application provides a solution for avoiding abnormal network requests during service maintenance or downtime, as illustrated in its embodiments. The steps involved in maintenance or configuration changes include:
[0100] Step 1: Machine maintenance or configuration change;
[0101] Step 2: Manually call the service's internal traffic management interface to shut down external traffic;
[0102] Step 3: Close the process; the process no longer exists.
[0103] The operation during a crash or configuration modification is roughly the same as the offline operation process. The difference is that during maintenance or configuration changes, the process may not necessarily be shut down. For traditional microservices, if the process is not shut down, disabling external traffic requires manually disabling the service bit by bit. However, in the embodiments of this application, the traffic management of a single process is all done through the interface exposed inside the process. It is only necessary to call the traffic disabling interface inside the service.
[0104] This application embodiment also provides a service process running method, the method including:
[0105] Step 1: If a service process startup request for the current microservice is received, start the target application service process, and disable the interface for external traffic. The application startup disables the service traffic thread.
[0106] Step 2: After the application service process has started, check whether the application service process has started normally;
[0107] Step 3: If normal, determine whether to manually or automatically call the service's internal traffic management interface to bring service traffic online based on the service instance's status; if the service instance is in use, automatically call the in-process interface to bring service traffic online; if the service instance is under maintenance, manual determination is required to call the in-process interface to bring service traffic online. Re-enable the interface for external traffic.
[0108] Step 4: If a service process shutdown request for the current microservice is received, call the internal traffic management interface of the service to shut down external traffic; stop the process until the process has finished processing the existing traffic and then shuts down completely.
[0109] Step 5: If a service maintenance request for the current microservice is received, manually call the internal traffic management interface of the service to shut down external traffic; shut down the process after the process has finished processing the existing traffic business.
[0110] Step 6: If a configuration change request for the current microservice is received, manually call the internal traffic management interface of the service to shut down external traffic; shut down the process after the process has finished processing the existing traffic business.
[0111] The method provided in this application embodiment uses an internally provided traffic management service interface to flexibly add and remove traffic, avoiding errors in business code execution caused by access traffic due to application startup or shutdown failures; it adds a maintenance status so that the application can indirectly perceive the health status of the underlying device and automatically decide whether to add or remove traffic; and it avoids abnormalities caused by access traffic when there is a time-consuming process shutdown that requires forced killing of the process.
[0112] In summary, this application provides a service process execution method. Upon receiving a service process startup request for the current microservice, the method starts the target application service process while simultaneously disabling the external traffic interface. The application startup disables the service traffic thread. After the application service process starts, it checks whether the process started normally. If normal, based on the service instance's status, it determines whether to manually or automatically call the service's internal traffic management interface to enable service traffic. Finally, it re-enables the external traffic interface. Using the internally provided traffic management service interface allows for flexible deployment, avoiding errors in business code execution caused by incoming traffic due to application startup or shutdown failures.
[0113] Based on the same technical concept, embodiments of this application also provide a service process running system, such as... Figure 9 As shown, the system includes:
[0114] The service process startup module 901 is used to start the target application service process when it receives a service process startup request for the current microservice, and at the same time disable the interface for external traffic.
[0115] Service traffic disabling module 902 is used to disable service traffic threads when an application starts.
[0116] The detection module 903 is used to detect whether the application service process has started normally after the application service process has finished starting.
[0117] The Service Traffic Launch Module 904 is used to determine, if normal, whether to manually judge or automatically call the service's internal traffic management interface to launch service traffic based on the status of the service instance.
[0118] The external traffic interface recovery module 905 is used to restore the interface that enables external traffic.
[0119] In one possible implementation, the service traffic online module 904 is specifically used for:
[0120] If the service instance is in use, the in-process interface will be automatically called to bring the service traffic online; if the service instance is under maintenance, manual judgment is required to determine whether to call the in-process interface to bring the service traffic online.
[0121] Compared to traditional microservice deployment mechanisms, the external traffic deployment mechanism provided in this application embodiment offers better control over traffic. Before deployment, the first step is to ensure the service is available through a health check of the application service. The second step is to determine whether to automatically enable service traffic based on the service instance status. Service instance status can be divided into "in use" or "under maintenance." The "in use" status allows for automatic deployment of traffic, while the "under maintenance" status generally indicates that there may be other faults in other parts of the machine. In this case, automatic deployment is not possible and manual judgment is required. By using the maintenance status, the application can indirectly perceive the health status of the underlying machine, thus avoiding service call failures after deployment.
[0122] In one possible implementation, it further includes: a service shutdown module, which, upon receiving a service process shutdown request for the current microservice, calls the service's internal traffic management interface to shut down external traffic; and disables the process until it has finished processing the existing traffic and is completely shut down.
[0123] In one possible implementation, it further includes: a service maintenance module, which is used to manually call the internal traffic management interface of the service to shut down external traffic when a service maintenance request for the current microservice is received; and to shut down the process after the process has finished processing the existing traffic business.
[0124] In one possible implementation, it further includes: a service configuration change module, which is used to manually call the internal traffic management interface of the service to shut down external traffic when a configuration change request for the current microservice is received; and to shut down the process after the process has finished processing the existing traffic business.
[0125] The operation during a crash or configuration modification is roughly the same as the offline operation process. The difference is that during maintenance or configuration changes, the process may not necessarily be shut down. For traditional microservices, if the process is not shut down, disabling external traffic requires manually disabling the service bit by bit. However, in the embodiments of this application, the traffic management of a single process is all done through the interface exposed inside the process. It is only necessary to call the traffic disabling interface inside the service.
[0126] In one possible implementation, the service internal traffic management interface includes RPC and HTTP interfaces; the disabled service traffic initiated by the application includes RPC traffic based on the Dubbo framework, as well as HTTP traffic.
[0127] The service process running system provided in this application embodiment flexibly adds and removes traffic by using an internal service interface that manages traffic, avoiding errors in business code execution caused by access traffic due to application startup or shutdown failures; it adds a maintenance status so that the application can indirectly perceive the health status of the underlying device and automatically decide whether to add or remove traffic; and it avoids abnormalities caused by access traffic when a process shutdown is time-consuming and requires forced killing.
[0128] This application also provides an electronic device corresponding to the method provided in the foregoing embodiments. Please refer to... Figure 10 The diagram illustrates an electronic device provided by some embodiments of this application. The electronic device 20 may include: a processor 200, a memory 201, a bus 202, and a communication interface 203, wherein the processor 200, the communication interface 203, and the memory 201 are connected via the bus 202; the memory 201 stores a computer program that can run on the processor 200, and when the processor 200 runs the computer program, it executes the method provided by any of the foregoing embodiments of this application.
[0129] The memory 201 may include high-speed random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one physical port 203 (which can be wired or wireless), such as the Internet, wide area network, local area network, or metropolitan area network.
[0130] Bus 202 can be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. The memory 201 is used to store programs. After receiving an execution instruction, the processor 200 executes the program. The method disclosed in any of the foregoing embodiments of this application can be applied to the processor 200, or implemented by the processor 200.
[0131] The processor 200 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of the processor 200 or by instructions in software form. The processor 200 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), an off-the-shelf programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules may reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 201. The processor 200 reads the information in memory 201 and, in conjunction with its hardware, completes the steps of the above method.
[0132] The electronic devices and methods provided in the embodiments of this application are based on the same inventive concept and have the same beneficial effects as the methods they employ, operate, or implement.
[0133] This application also provides a computer-readable storage medium corresponding to the method provided in the foregoing embodiments. Please refer to... Figure 11 The computer-readable storage medium shown is an optical disc 30, on which a computer program (i.e., a program product) is stored, which, when run by a processor, executes the methods provided in any of the foregoing embodiments.
[0134] It should be noted that examples of the computer-readable storage medium may also include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other optical and magnetic storage media, which will not be elaborated here.
[0135] The computer-readable storage medium provided in the above embodiments of this application and the method provided in the embodiments of this application are based on the same inventive concept and have the same beneficial effects as the methods adopted, run or implemented by the applications stored therein.
[0136] It should be noted that:
[0137] The algorithms and displays provided herein are not inherently related to any particular computer, virtual device, or other equipment. Various general-purpose devices can also be used in conjunction with the teachings herein. The required structure for constructing such devices is apparent from the above description. Furthermore, this application is not directed to any particular programming language. It should be understood that the content of this application described herein can be implemented using various programming languages, and the above description of specific languages is for the purpose of disclosing the best mode of implementation of this application.
[0138] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of this application may be practiced without these specific details. In some instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification.
[0139] Similarly, it should be understood that, in order to simplify this application and aid in understanding one or more of the various inventive aspects, in the above description of exemplary embodiments of this application, various features of this application are sometimes grouped together into a single embodiment, figure, or description thereof. However, this method of disclosure should not be construed as reflecting an intention that the claimed application requires more features than are expressly recited in each claim. Rather, as reflected in the following claims, inventive aspects lie in fewer than all features of a single foregoing disclosed embodiment. Therefore, the claims following the detailed description are hereby expressly incorporated into that detailed description, wherein each claim itself is a separate embodiment of this application.
[0140] Those skilled in the art will understand that modules in the device of the embodiments can be adaptively changed and placed in one or more devices different from that embodiment. Modules, units, or components in the embodiments can be combined into a single module, unit, or component, and further, they can be divided into multiple sub-modules, sub-units, or sub-components. Except where at least some of such features and / or processes or units are mutually exclusive, any combination can be used to combine all features disclosed in this specification (including the accompanying claims, abstract, and drawings) and all processes or units of any method or device so disclosed. Unless expressly stated otherwise, each feature disclosed in this specification (including the accompanying claims, abstract, and drawings) may be replaced by an alternative feature that serves the same, equivalent, or similar purpose.
[0141] Furthermore, those skilled in the art will understand that although some embodiments described herein include certain features but not others included in other embodiments, combinations of features from different embodiments are intended to be within the scope of this application and form different embodiments. For example, in the following claims, any of the claimed embodiments can be used in any combination.
[0142] The various component embodiments of this application can be implemented in hardware, or as software modules running on one or more processors, or a combination thereof. Those skilled in the art will understand that microprocessors or digital signal processors (DSPs) can be used in practice to implement some or all of the functions of some or all of the components in the virtual machine creation apparatus according to embodiments of this application. This application can also be implemented as a device or apparatus program (e.g., a computer program and computer program product) for performing part or all of the methods described herein. Such an implementation of this application can be stored on a computer-readable medium, or can be in the form of one or more signals. Such signals can be downloaded from an Internet website, provided on a carrier signal, or provided in any other form.
[0143] It should be noted that the above embodiments are illustrative of this application and not restrictive, and that those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. This application can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names.
[0144] The above description is merely a preferred embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of protection of the claims. Those skilled in the art can understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when the program is executed, it can include the processes of the embodiments of the above methods. The aforementioned storage medium can be a non-volatile storage medium such as a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM).
[0145] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.
[0146] The embodiments described above are merely illustrative of several implementations of the present invention, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these modifications and improvements all fall within the scope of protection of the present invention. Therefore, the scope of protection of this patent should be determined by the appended claims.
Claims
1. A service process running method, characterized by, The method comprises: when a service process startup request of a current microservice is received, starting a target application service process while disabling an interface for external traffic; applying a startup disabled service traffic thread; after the application service process startup is completed, detecting whether the application service process is started normally; if normal, determining manual judgment or automatic calling of a service internal traffic management interface according to a state of a service instance to bring online service traffic; resuming the interface for external traffic; when a service process shutdown request of the current microservice is received, calling the service internal traffic management interface to close external traffic; stopping the process until the process completely shuts down after processing existing traffic business. The method further comprises:
2. The method of claim 1, wherein, when a service maintenance request of the current microservice is received, manually calling the service internal traffic management interface to close external traffic; until the process is completely shut down after processing existing traffic business. The method further comprises:
3. The method of claim 1, wherein, when a configuration change request of the current microservice is received, manually calling the service internal traffic management interface to close external traffic; until the process is completely shut down after processing existing traffic business. The service internal traffic management interface comprises an RPC and an HTTP interface.
4. The method of claim 1, wherein, The application startup disabled service traffic comprises RPC traffic and HTTP traffic based on a Dubbo framework. The system comprises:
5. A service process running system characterized by comprising: a service process startup module configured to, when a service process startup request of a current microservice is received, start a target application service process while disabling an interface for external traffic; a service traffic disabling module configured to apply a startup disabled service traffic thread, and further configured to, when a service process shutdown request of the current microservice is received, call the service internal traffic management interface to close external traffic, and stop the process until the process completely shuts down after processing existing traffic business; a detection module configured to, after the application service process startup is completed, detect whether the application service process is started normally; a service traffic online module configured to, if normal, determine manual judgment or automatic calling of a service internal traffic management interface according to a state of a service instance to bring online service traffic, and specifically configured to, if the state of the service instance is in use, automatically call a process internal interface to bring online service traffic, and if the state of the service instance is in maintenance, manually judge whether to call the process internal interface to bring online service traffic; an external traffic interface resuming module configured to resume the interface for external traffic. A memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor executes the computer program to implement the method of any one of claims 1-4.
6. An electronic device comprising: 7. A computer readable storage medium characterized by having computer readable instructions stored thereon that are executable by a processor to implement the method of any of claims 1-4.
Citation Information
Patent Citations
Application control method and robot
CN111152215A