Micro-service registration method and related equipment

Abstract

The embodiment of the invention provides a micro-service registration method and related equipment, which are used for improving the reliability and the stability of micro-services. The micro-service registration method comprises the steps that test traffic is acquired, the test traffic is used for detecting the service state of a first micro-service, the first micro-service is a to-be-registered service, and the service state is used for indicating the processing capacity of the first micro-service; the first microservice is detected using the test traffic. And when the service state indicates that the processing capability of the first micro-service is stable, registering the first micro-service.

Description

Technical Field

[0001] This application relates to the field of communications, and in particular, to a microservice registration method and related devices. Background Art

[0002] The microservice architecture disassembles a large application into multiple small services, and each of these multiple small services can be deployed, maintained, and extended independently. Microservice registration and discovery, as an important branch in the microservice architecture, can help services discover and communicate with each other, thereby realizing some or all functions of a large application. In the microservice architecture, how to implement microservice registration is an extremely important issue.

[0003] In a microservice registration method, the availability of a microservice is detected. When the microservice is in an available state, that is, when it is determined that the microservice initialization is completed, the microservice is registered.

[0004] In this method, the microservice is registered as soon as it is determined to be available. However, the availability of a microservice is a basic requirement for the microservice. The availability of a microservice does not mean that the microservice can provide continuous and stable services, and it is easy to report errors for user requests, resulting in a decrease in the reliability of the microservice. Summary of the Invention

[0005] This application provides a microservice registration method and related devices for improving the reliability and stability of microservices.

[0006] The first aspect of this application provides a microservice registration method, including:

[0007] A first microservice to be registered runs on a network device. By detecting the first microservice, it is determined whether to register the first microservice. Specifically, the network device can obtain test traffic, and the test traffic is used to detect the service state of the first microservice, and the service state indicates the processing ability of the first microservice. The processing ability mentioned here not only includes whether the first microservice is in an available state, but also includes the level of the processing ability of the first microservice to process the test traffic. The test traffic includes the characteristics of the request and the response corresponding to the request, and is used to simulate the traffic that the first microservice may use during operation. The first microservice is detected using the first traffic to determine the service state of the first microservice. When the service state indicates that the processing ability of the first microservice is stable, it means that the first microservice is not only available, but also has good performance and can provide reliable services. Therefore, the first microservice can be registered.

[0008] In this application, before registering the first microservice, the service status of the first microservice is detected. Only when the service status indicates that the processing capacity of the first microservice is stable, the first microservice is registered. This not only ensures that the first microservice is in an available state, but also ensures that the first microservice has good processing capacity, ensuring that stable services can be provided after the first microservice is registered, and improving the reliability and stability of the microservice.

[0009] In some alternative embodiments of the first aspect, the network device can determine the service status of the first microservice. Specifically, the network device can detect the response status parameters of the first microservice and determine the service status of the first microservice according to the response status parameters. Among them, the response status parameters include at least one of requests per second (RPS), error rate, or response latency. Generally, the better the service status of the microservice is considered when the RPS tends to be stable, the lower the error rate, or the lower the response latency.

[0010] In this application, there are various possibilities for the response status parameters of the first microservice. The service status of the first microservice can be measured from multiple dimensions, which can be flexibly applied to different requirements, improving the practicability and flexibility of the technical solution of this application.

[0011] In some alternative embodiments of the first aspect, there may be various situations where the network device determines that the service status indicates that the processing capacity of the first microservice is stable according to the response status parameters. Specifically, it may include at least one of the following: the RPS meets the preset conditions, the error rate is less than or equal to the error rate threshold, or the response latency is less than or equal to the latency threshold. Among them, there are various possibilities for the RPS to meet the preset conditions. It may be that the average RPS during the period of detecting the first microservice using test traffic (i.e., the detection period) is within the preset range, or the average RPS is greater than the first RPS threshold. In addition, there may be other situations, such as the minimum value of the RPS during the detection period is greater than the second RPS threshold but less than the third RPS threshold, or the minimum value of the RPS during the detection period is greater than the fourth RPS threshold. Specifically, it is not limited here. The foregoing RPS thresholds can be set according to the actual application requirements, and this application does not limit this.

[0012] In this application, there are various possibilities for the response parameters of the first microservice status. Correspondingly, there are also various possibilities for the service status determined based on the response parameters. There are also different-dimensional criteria to measure whether the processing capacity of the first microservice indicated by the service status is stable. Then, in actual applications, the corresponding criteria can be set according to the requirements, enriching the application scenarios of the technical solution of this application.

[0013] In some alternative embodiments of the first aspect, the test traffic includes the traffic recorded during the operation of the second microservice. That is to say, during the operation of the second microservice, the traffic called and / or called by the second microservice during operation is recorded. Among them, the second microservice is a registered service, and the first microservice is an updated version of the second microservice. In other words, the first microservice and the second microservice include the same services. In addition, the first microservice may also include services that the second microservice does not have or more optimized services.

[0014] In this application, the test traffic is the real traffic used by the registered second microservice during operation. When detecting the first microservice, which is an upgraded version of the second microservice, using this test traffic can simulate the real production application scenario and be close to the real application scenario. It is easier to cover all service branches of the first microservice applied in the actual application, avoiding partial traffic blockage of the first microservice due to some service branches not being covered, that is, avoiding partial service blockage after the first microservice is launched, further improving the comprehensiveness of the technical solution of this application in detecting the first microservice and improving the smoothness of the first microservice.

[0015] In some alternative embodiments of the first aspect, the test traffic includes the first traffic used by the second microservice to communicate with the terminal device; and / or, the second traffic used by the second microservice to communicate with the first service. Among them, the first service provides different services from the second microservice. The first service can also be a microservice. In this case, the first service and the second microservice can be included in a microservice architecture, that is, the first service and the second microservice are different small services of the same large application. Or, the first service and the second microservice can also be included in different microservice architectures, that is, the first service and the second microservice correspond to different applications respectively. The relationship between the first service and the second microservice can be determined according to the actual application scenario, and this application does not limit it. In addition, it should be noted that the first traffic can also be understood as external traffic, including the characteristics of the requests sent by the terminal device when calling the first microservice and the response characteristics of the first microservice to the terminal device. The second traffic can be understood as external traffic, including the characteristics of the requests sent by the second microservice when calling the first service and the response characteristics of the first service to the second microservice.

[0016] In this application, there are various possibilities for the recorded test traffic, including the first traffic of the second microservice communicating with the terminal device and / or the second traffic of the second microservice communicating with the first service, which can be flexibly selected, further enriching the application scenarios of the technical solution of this application.

[0017] In some alternative embodiments of the first aspect, there are multiple possibilities for the test traffic. Correspondingly, there are also multiple solutions for detecting the first microservice using the test traffic. Generally speaking, they include: the network device can simulate the communication between the first microservice and the terminal device through the first traffic; and / or, control the first microservice to communicate with the simulation system through the second traffic, where the simulation system is used to simulate the first service. The former detects the service status of the first microservice from the perspective of the communication between the first microservice and the terminal device, and the latter detects the service status of the first microservice from the perspective of the communication between the first microservice and other microservices.

[0018] In this application, there are also multiple solutions for detecting the first microservice using the test traffic, which further improves the flexibility of the technical solution of this application. In addition, for the solution of detecting the first microservice using the first traffic, what is concerned is the service status of the first microservice facing the terminal device (or facing the user); for the solution of detecting the first microservice using the first traffic, what is concerned is the service status of the first microservice facing other microservices, and the first microservice is detected from different perspectives. Detecting the first microservice using the first traffic and the second traffic makes the detection of the first microservice more comprehensive, and the obtained results are more reliable, which further ensures the reliability and stability of the first microservice after registration.

[0019] In some alternative embodiments of the first aspect, the test traffic carries a test tag, and the test tag is used to indicate the test traffic. This means that the test traffic will not be confused with the traffic used by other microservices, and the process of detecting the first microservice will not affect the normal operation of other microservices in the real environment.

[0020] In this application, the traffic used by the real system is distinguished from the test traffic through the test tag, avoiding the impact of detecting the first microservice on the actual application.

[0021] In the second aspect, this application provides a communication device that can implement the functions of the network device in the method shown in the above first aspect or any possible implementation manner of the first aspect. The device includes corresponding units or modules for executing the above method. The units or modules included in the device can be implemented in software and / or hardware. The device can be, for example, a network device, or a module of a network device (such as a chip), or a logical node, logical module, or software that can implement all or part of the functions of the network device.

[0022] In the third aspect, this application provides a communication device, including a processor and a memory. The processor stores instructions, and when the instructions stored in the memory run on the processor, the method shown in the foregoing first aspect or any possible implementation manner of the first aspect is implemented.

[0023] Fourthly, the present application provides a computer-readable storage medium. Instructions are stored in the computer-readable storage medium, and when the instructions run on a processor, the method shown in the foregoing first aspect or any possible implementation manner of the first aspect is implemented.

[0024] Fifthly, the present application provides a computer program product. When the computer program product is executed on a processor, the method shown in the foregoing first aspect or any possible implementation manner of the first aspect is implemented.

[0025] The beneficial effects shown in any one of the second aspect to the fifth aspect are similar to those of the first aspect or any possible implementation manner of the first aspect, and will not be elaborated here. Description of the Drawings

[0026] Figure 1 It is a schematic diagram of a system architecture provided by an embodiment of the present application;

[0027] Figure 2 It is another schematic diagram of a system architecture provided by an embodiment of the present application;

[0028] Figure 3 It is a schematic flowchart of a microservice registration method provided by an embodiment of the present application;

[0029] Figure 4 It is a schematic diagram provided by an embodiment of the present application;

[0030] Figure 5 It is a schematic diagram provided by an embodiment of the present application;

[0031] Figure 6 It is another schematic flowchart of a microservice registration method provided by an embodiment of the present application;

[0032] Figure 7 It is another schematic flowchart of a microservice registration method adopted by an embodiment of the present application;

[0033] Figure 8 It is a schematic structural diagram of a communication device provided by an embodiment of the present application;

[0034] Figure 9 It is another schematic structural diagram of a communication device provided by an embodiment of the present application. Detailed Embodiments

[0035] Embodiments of the present application provide a microservice registration method and related devices, which are used to improve the reliability and stability of microservices.

[0036] The embodiments of the present application will be described below with reference to the accompanying drawings. As is known to those of ordinary skill in the art, with the development of technology and the emergence of new scenarios, the technical solutions provided by the embodiments of the present application are equally applicable to similar technical problems.

[0037] The terms "first", "second", etc. in the specification, claims and above-mentioned drawings of the present application are used to distinguish similar objects, and do not have to be used to describe a specific order or sequence. It should be understood that such terms can be interchanged under appropriate circumstances, which is only a way of distinguishing when describing objects with the same attributes in the embodiments of the present application. In addition, the terms "comprising" and "having" and any variations thereof are intended to cover non-exclusive inclusion, so that a process, method, system, product or device comprising a series of units does not have to be limited to those units, but may include other units not clearly listed or inherent to these processes, methods, products or devices. In addition, "at least one" means one or more, and "a plurality" means two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships can exist. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone, where A and B can be singular or plural. The character " / " generally means that the associated objects before and after are in an "or" relationship. "At least one (item)" or similar expressions below refer to any combination of these items, including any combination of single item (s) or plural item (s). For example, at least one (item) of a, b, or c can mean: a, b, c, a-b, a-c, b-c, or a-b-c, where a, b, c can be single or multiple.

[0038] First, the relevant concepts and proprietary terms that the present application may involve will be described:

[0039] 1. Microservice architecture.

[0040] Different from the overall architecture, the microservice architecture consists of multiple smaller microservices, and the coupling relationship between these multiple microservices is not tight. That is to say, multiple microservices can be deployed independently. At the same time, these multiple microservices can communicate with each other to realize multiple functions of the application program that includes these microservices.

[0041] 2. Traffic preheating.

[0042] It is to dynamically adjust the traffic through the service consumer side (or the terminal) and dynamically allocate the traffic. When a request is initiated to a newly started service instance, compared with other already started service instances, the allocated traffic will be less. For a newly started service, the allocated traffic will increase with time until it is the same as that of other services.

[0043] 3. Traffic recording and playback.

[0044] Traffic recording and playback is a technology used for testing and monitoring applications. It can record the network traffic of an application and save it. The recorded sample can be played back to reproduce the behavior of the application in different environments. Traffic recording and playback can help developers better understand the behavior of the application, discover potential problems, and perform performance optimization. In addition, traffic recording and playback can also be used for security testing, regression testing, full-link scenario testing, etc.

[0045] 4. Just-in-time compilation (JIT).

[0046] JIT is a technology that dynamically compiles program source code or intermediate code into machine code at runtime. Different from traditional static compilation, JIT compiles the code into machine code according to needs during program execution and directly executes it.

[0047] Next, please refer to Figure 1 and Figure 2 , Figure 1 and Figure 2 Both are schematic diagrams of the system architecture provided by the embodiments of this application.

[0048] As Figure 1 shown, the user establishes a communication connection with the network device through the terminal device. There are multiple ways to establish this communication connection. It can be through a wireless network connection or a wired network connection. Specifically, it is not limited here. If it is through a wireless network connection, the specific connection form can be a cellular wireless network, a wireless fidelity (WiFi) network, or other types of wireless networks. Specifically, it is not limited here.

[0049] Figure 1 The architecture shown can also be called a client-server (C / S) architecture. Among them, the server is responsible for data management, and the client is responsible for completing the interaction tasks with the user. Corresponding to the embodiment shown in Figure 1 In the embodiment shown, the terminal device acts as the client, responsible for interacting with the user and transmitting the user's needs to the server. In the embodiments of this application, the network device acts as the server, deploys and manages at least one microservice, and the user uses this at least one microservice through the terminal device.

[0050] It should be noted that the terminal device can also be referred to as a terminal, user equipment (UE), mobile station, mobile terminal, etc. The terminal can be widely applied to various scenarios, such as device-to-device (D2D), vehicle to everything (V2X) communication, machine-type communication (MTC), Internet of Things (IoT), virtual reality, augmented reality, industrial control, autonomous driving, remote medical treatment, smart grid, smart furniture, smart office, smart wearables, smart transportation, smart city, etc. The terminal can be a mobile phone, a tablet computer, a computer with wireless transceiver function, a wearable device, a vehicle, a drone, a helicopter, an airplane, a ship, a robot, a robotic arm, a smart home device, etc. The embodiments of the present application do not limit the device form of the terminal.

[0051] In some alternative embodiments, the microservice registration method provided by the embodiments of the present application can be applied to the cloud computing field, for example, applied in the platform as a service (PaaS) scenario. Optionally, the PaaS scenario can be used to provide a development framework, and developers can develop or customize cloud-based applications based on this framework. For example, the microservices shown in the embodiments of the present application can be developed based on PaaS.

[0052] In some alternative embodiments, the network device provided by the embodiments of the present application may include microservice 1.0 and microservice 1.1 as shown in Figure 2 Each microservice is registered through a registration center and then provided for use by the terminal device. The terminal device uses each microservice by means of service invocation. In this scenario, the terminal device can also be referred to as a service consumer, and the microservice can also be referred to as a service provider.

[0053] As shown in Figure 2 , microservice 1.1 is an upgraded version of microservice 1.0. Before microservice 1.1 is registered, it is necessary to detect the service capabilities of microservice 1.1. Generally speaking, a stress testing engine can be used to perform service invocation on microservice 1.1, and this process simulates the process of the terminal device invoking microservice 1.0. In practical applications, microservice 1.0 can also communicate with other services (such as service 2). Then, when detecting the service capabilities of microservice 1.1, it is also possible to detect the process of microservice 1.1 invoking the simulation system, and this process simulates the communication between microservice 1.0 and other services. Specific implementation details will be described later and will not be elaborated here.

[0054] It should be noted that Figure 2 This is only an example of the application scenario of this application. In actual applications, the network device may also include a greater number of microservices. Microservice 1.0 and Service 2 may be microservices provided by one network device or microservices provided by different network devices, and specific details are not limited here. The registration center, stress testing engine, or simulation system may be hosted on the network device or on other devices that establish a communication connection with the network device, and specific details are not limited here.

[0055] In addition, it should be noted that the microservice registration method provided in the embodiments of this application is not limited to Figure 2 the microservice upgrade scenario shown, and can also be applied to scenarios such as software gray release, rolling upgrade, and service expansion, and specific details are not limited here.

[0056] In addition, it should be noted that "sending information to... (such as a network device)" in this application can be understood as the destination of the information being the network device. It may include directly or indirectly sending information to the network device. "Receiving information from... (such as a network device)" can be understood as the source of the information being the network device, and it may include directly or indirectly receiving information from the network device. The information may be subject to necessary processing, such as format change, etc., between the source and destination of the information transmission, but the destination can be understood as the valid information from the source. Similar expressions in this application can be understood similarly, and will not be elaborated here.

[0057] Next, please refer to Figure 3 , Figure 3 which is a schematic flowchart of the microservice registration method provided in the embodiments of this application.

[0058] 301. Obtain test traffic, where the test traffic is used to detect the service status of the first microservice. The first microservice is the service to be registered, and the service status is used to indicate the processing capacity of the first microservice.

[0059] In the embodiments of this application, there are various possibilities for the test traffic. It may be preset traffic or traffic collected or recorded from a real production environment, and specific details are not limited here.

[0060] In some alternative embodiments, the test traffic includes the traffic recorded when the second microservice is running. The second microservice is a registered service, and the first microservice is an updated version of the second microservice. The so-called traffic recorded when the second microservice is running means the traffic generated during the actual application of the second microservice, including the traffic called and / or called by the second microservice during operation. These traffic are real traffic, that is, traffic generated based on the actual application requirements of users. Among them, the first microservice being the updated version of the second microservice can also be understood as the first microservice being the upgraded version of the second microservice. That is to say, the first microservice is the service after optimizing some or all service branches of the second microservice, and the first microservice and the second microservice include the same service branches.

[0061] In some alternative embodiments, considering that in actual applications, the second microservice can not only respond to requests from terminal devices and provide the services it includes to the terminal devices, but also interact with other microservices and call other microservices. Therefore, when the network device performs traffic recording, it can record the first traffic when the second microservice communicates with the terminal device, or record the second traffic when the second microservice communicates with other services (such as the first service). That is to say, the test traffic includes the first traffic used by the second microservice to communicate with the terminal device; and / or, the second traffic used by the second microservice to communicate with the first service. The first traffic can also be understood as external traffic, including the characteristics of the requests sent by the terminal device when calling the first microservice, and the response characteristics of the first microservice to the terminal device. The second traffic can be understood as external traffic, including the characteristics of the requests sent by the second microservice when calling the first service, and the response characteristics of the first service to the second microservice.

[0062] It should be noted that the foregoing uses the first service as an example only to indicate a service other than the first microservice and the second microservice. The first service provides different services from the second microservice. The first service can be a microservice or not, and no specific limitation is made here. When the first service is a microservice, the first service and the second microservice can be included in a microservice architecture. That is to say, the first service and the second microservice are different small services of the same large application. Or, the first service and the second microservice can also be included in different microservice architectures, that is, the first service and the second microservice correspond to different applications respectively. The relationship between the first service and the second microservice can be determined according to the actual application scenario, and the present application does not make any limitation thereto.

[0063] In addition, in the embodiments of the present application, the duration, time period, or data volume of the recorded traffic is not limited. It can be understood that the longer the recording time, or the larger the number of users corresponding to the recording time period, or the larger the amount of data recorded, the easier it is to approximate the user's usage habits, and the easier it is for the recorded traffic to cover more service branches of the second microservice.

[0064] It should also be noted that the device for recording the traffic used in the running process of the second microservice can be a network device or other devices that establish communication with the network device, and specific details are not limited here. That is to say, the method for the network device to obtain the test traffic can be self-recording or obtaining the traffic sent by other devices, and specific details are not limited here.

[0065] In the embodiments of the present application, the test traffic is the real traffic used by the second microservice that has been registered during operation. When detecting the first microservice, which is an upgraded version of the second microservice, using this test traffic can simulate the real production application scenario and approximate the real application scenario. It is also easier to cover all the service branches of the first microservice that are applied in the actual application, avoiding the blockage of some traffic of the first microservice due to some service branches not being covered, that is, avoiding partial service blockage after the first microservice is launched, further improving the comprehensiveness of the technical solution of the present application for detecting the first microservice and the smoothness of the first microservice. In addition, there are various possibilities for the recorded test traffic, including the first traffic of the communication between the second microservice and the terminal device, and / or the second traffic of the communication between the second microservice and the first service, which can be flexibly selected, further enriching the application scenarios of the technical solution of the present application.

[0066] 302. Detect the first microservice using the test traffic.

[0067] The detection process of the first microservice can be understood as simulating the operating environment of the first microservice and detecting the service status of the first microservice in this operating environment.

[0068] In some alternative embodiments, the test traffic includes the first traffic and / or the second traffic. Then, detecting the first microservice using the test traffic includes simulating the communication between the first microservice and the terminal device through the first traffic; and / or controlling the first microservice to communicate with the simulation system through the second traffic. Among them, the simulation system is used to simulate the first service.

[0069] Among them, the communication between the first microservice and the terminal device is simulated through the first traffic. Specifically, a first call request is sent to the first microservice, and the request characteristics included in the first traffic are carried in the first call request, and the response of the first microservice to the first call request is detected. And the characteristics of the response are compared with the response characteristics corresponding to the first call request in the first traffic. The following is further illustrated with examples. For example, assume that the correspondence between the request characteristics and the response characteristics in the first traffic is shown in Table 1 below:

[0070] Table 1

[0071] Requested feature Response feature A1 B1 A2 B2 …… …… An Bn

[0072] As shown in Table 1, the first traffic includes n pairs of characteristics, and each pair of characteristics includes a request characteristic and a response characteristic. For example, the request characteristic A1 corresponds to the same characteristic B1. Exemplarily, during the operation of the second microservice, after the second microservice receives a call request carrying the request characteristic A1, the response returned carries the response characteristic B1.

[0073] Exemplarily, assume that during the process of detecting the first microservice using the first traffic, a first call request carrying the request characteristic A2 is sent to the first microservice, and the response received for the first call request carries the response characteristic B2. This situation matches the aforementioned Table 1, so it can be determined that the response of the first microservice to the first call request is correct, and the test traffic covers the service branch called by the first call request in the first microservice.

[0074] Exemplarily, assume that during the process of detecting the first microservice using the first traffic, a first call request carrying the request characteristic A2 is sent to the first microservice, and the response received for the first call request does not carry the response characteristic B2. This situation does not match the aforementioned Table 1, so it can be determined that the response of the first microservice to the call request is incorrect, and further detection is required.

[0075] Exemplarily, assume that during the process of detecting the first microservice using the first traffic, a first call request carrying the request characteristic A2 is sent to the first microservice, and no response to the first call request is received within the preset duration. Then it can also be determined that the response of the first microservice to the call request is incorrect, and further detection is required. Among them, the specific value of the preset duration can be determined according to the needs of actual applications, and it is not specifically limited here.

[0076] It should be noted that Table 1 is only an example of the mapping relationship between the request features and response features included in the first traffic. In actual applications, there may be other situations for the mapping relationship. For example, one request feature may correspond to multiple response features, etc. This application does not limit the mapping relationship between the request features and response features included in the first traffic, nor does it limit the number of request features and response features included in the first traffic. In addition, this application does not limit the format of the request features and their positions in the request message, nor does it limit the format of the response features and their positions in the response message, which can all be set according to the needs of actual applications.

[0077] Among them, controlling the first microservice to communicate with the simulation system through the second traffic specifically means controlling the first microservice to send a second call request to the simulation system. The second call request carries the request features included in the second traffic, and detecting the response of the simulation system to the second call request. Then compare the features of this response with the response features corresponding to this call request in the first traffic, so as to determine whether the communication between the first microservice and the simulation system is normal. This process is similar to the relevant examples in Table 1 above and will not be elaborated here.

[0078] The simulation system mentioned here is used to simulate the first service that communicates with the second microservice. That is to say, the simulation system is used to simulate the external system of the first microservice to be detected to ensure the normal communication between the first microservice and the external system. It should be noted that the architecture adopted by the simulation system can be set according to the needs of actual applications, including the microservices that communicate with the second microservice in the real application environment, and provides the services provided by the microservices that communicate with the second microservice in the real application environment. Optionally, a MOCK system can be used as the simulation system. In addition, the simulation system can run either on the network device or on other devices that establish a communication connection with the network device, and the specific details are not limited here.

[0079] In summary, simulating the communication between the first microservice and the terminal device through the first traffic is to detect the service status of the first microservice from the perspective of the communication between the first microservice and the terminal device. Controlling the first microservice to communicate with the simulation system through the second traffic is to detect the service status of the first microservice from the perspective of the communication between the first microservice and other microservices.

[0080] In this application, there are also multiple solutions for using test traffic to detect the first microservice, which further improves the flexibility of the technical solution of this application. In addition, for the solution of using the first traffic to detect the first microservice, what is concerned is the service status of the first microservice facing the terminal device (or facing the user); for the solution of using the first traffic to detect the first microservice, what is concerned is the service status of the first microservice facing other microservices, and the first microservice is detected from different perspectives. Detecting the first microservice using the first traffic and the second traffic makes the detection of the first microservice more comprehensive, and the obtained results are more reliable, further ensuring the reliability and stability of the first microservice after registration.

[0081] 303. When the service status indicates that the processing capacity of the first microservice is stable, register the first microservice.

[0082] After the detection is completed, it is determined whether to perform service registration on the first microservice according to the service status of the first microservice. Among them, there are multiple possible determination criteria for the completion of the detection. It can be that the detection duration reaches the duration threshold, or the data volume of the traffic actually used for detection reaches the data volume threshold. In addition, there can also be other situations, such as the detection traffic being exhausted, etc., which can be set according to the actual application needs and are not specifically limited here.

[0083] The network device can determine the service status of the first microservice according to the response status parameters of the first microservice. Among them, the response status parameters include at least one of RPS, error rate, or response delay. That the service status indicates that the processing capacity of the first microservice is stable includes at least one of the following: RPS meets the preset conditions, the error rate is less than or equal to the error rate threshold, or the response delay is less than or equal to the delay threshold. Among them, the error rate threshold and the delay threshold can be determined according to the actual application situation and are not specifically limited here. It can be understood that the lower the error rate threshold or the lower the delay threshold, the higher the performance requirements for the first microservice.

[0084] It can be understood that generally, when RPS tends to be stable, or the error rate is lower, or the response delay is lower, it can be determined that the service status of the first microservice is better. In addition, there are multiple possibilities for RPS to meet the preset conditions. It can be that the average RPS during the period of using test traffic to detect the first microservice (i.e., the detection period) is within the preset range, or the average RPS is greater than the first RPS threshold. In addition, there may be other situations, such as the lowest value of RPS during the detection period is greater than the second RPS threshold but less than the third RPS threshold, or the lowest value of RPS during the detection period is greater than the fourth RPS threshold, which are not specifically limited here. The foregoing RPS thresholds can be set according to the actual application requirements, and this application does not limit this.

[0085] Exemplarily, the error rate threshold can be set to 0%. This is considered because error responses will have a huge adverse impact on users, and for microservices that are registered and on the line, accurate responses are a basic requirement.

[0086] In the embodiments of the present application, the response status parameters of the first microservice have multiple possibilities, and the service status of the first microservice can be measured from multiple dimensions, which can be flexibly applied to different requirements, improving the practicability and flexibility of the technical solution of the present application. In addition, there are multiple possibilities for the response parameters of the first microservice status. Correspondingly, there are also multiple possibilities for the service status determined based on the response parameters, and there are different-dimensional criteria for measuring whether the processing ability of the first microservice indicated by the service status is stable. Then, in actual applications, corresponding criteria can be set according to requirements, enriching the application scenarios of the technical solution of the present application.

[0087] In some optional embodiment manners, the test traffic carries a test flag, and the test flag is used to indicate the test traffic. Exemplarily, the test flag can be carried in the header of the traffic packet, and specifically which field it is in can be set according to the packet type or the requirements of the actual application, and specific details are not limited here.

[0088] Exemplarily, please refer to Figures 4 to 6 , Figures 4 to 6 which is a schematic diagram provided for the implementation of the present application. Among them, Figure 4 takes microservice 1.1 as the first microservice and the MOCK system as the simulation system as an example.

[0089] As Figure 4 shown, the network device includes a traffic control module for distinguishing test traffic and the traffic required for the real operating environment according to the test flag. In Figure 4 the shown embodiment, the pseudocode "header: 'x-test=true'" means that the "x-test" field is carried in the header of the traffic packet, indicating that the packet corresponds to test traffic. For the traffic packets of the terminal device that actually calls the service, the "x-test" field will not be carried in the packet header.

[0090] Exemplarily, the operation logic of the traffic control module can be as Figure 4As shown, when it is detected that the message header carries the "x-test" field, it is determined that the traffic is test traffic, and the traffic is sent to microservice 1.1 or the MOCK system. The specific transmission path of this traffic (that is, whether it is transmitted to microservice 1.1 or the MOCK system) can be determined according to the request characteristics or response characteristics of the traffic. Similar to the first traffic and the second traffic introduced above, it will not be elaborated here. When the message header does not carry the "x-test" field, it is determined that the message is not test traffic, and the traffic is transmitted to other services. The other services mentioned here are services that have been registered and are running in the real environment. It can be a microservice or not, and it is not specifically limited here.

[0091] It should be noted that Figure 4 This is only an example of the operation logic of the traffic control module, and does not constitute a limitation on the test identifier and traffic differentiation. Exemplarily, it can also be set that the pseudo-code "header: 'x-test=true'" means that the message header of the traffic carries the "x-test" field, and when the value of this field is "true", it means that the message corresponds to test traffic. Then, when the traffic control module detects that the message header carries the "x-test" field, it also needs to further determine the value of this field. When the value of this field is "true", it is determined that the message corresponds to test traffic. If the value of this field is not "true", it is determined that the traffic corresponding to the message is not test traffic.

[0092] In addition, in the embodiments of the present application, there are many possible specific implementation manners of the traffic control module.

[0093] Exemplarily, as Figure 5 shown in Figure (a) of [reference], the traffic control module can identify test marks and distinguish test traffic and other traffic in the first microservice by means of a software development kit (SDK) and invade the service code.

[0094] Exemplarily, as Figure 5 shown in Figure (b) of [reference], in the Java scenario, JavaAgent (without invading the service code) can also be used to perform bytecode enhancement to identify test marks and control the traffic direction. Different from the example in Figure (a) of [reference], Figure 5 the method shown in Figure (b) of [reference] is actually mounted on the relevant program of the first microservice, and the code of this module will not be written into the relevant program of the first microservice. Figure 5

[0095] ​In the implementation of this application, the test traffic carries a test flag. When the network device obtains the traffic carrying this test flag, this part of the traffic will be regarded as the test traffic for detecting the first microservice, and this part of the traffic will not be used to call the registered services. In other words, if the traffic obtained by the network device does not carry a test flag, it means that this traffic is generated by real applications. The network device will not use this traffic to test the service status of the first microservice, but will transmit this traffic to the corresponding service based on traffic characteristics (such as request characteristics and / or response characteristics). That is to say, in the embodiments of this application, the traffic used by the real system and the test traffic are distinguished by the test flag, so as to avoid the detection of the first microservice from affecting the actual application.

[0096] In some alternative embodiments, after the first microservice is registered, the first microservice can be taken offline to reduce the maintenance cost of the network device.

[0097] In some alternative embodiments, if the service status of the first microservice detected using the test traffic indicates that the processing ability of the first microservice is unstable, then the first microservice can be continuously detected, or the first microservice can be subjected to fault inspection and other processing, which is not specifically limited here.

[0098] The foregoing has described the microservice registration method provided by the embodiments of this application with the network device as the execution entity. Next, a further description will be made from the perspective of the system.

[0099] Please refer to Figure 6 , Figure 6 which is a schematic flowchart of the microservice registration method provided by the embodiments of this application.

[0100] As Figure 6 shown, the stress testing engine sends 1. test traffic to the first microservice, and this test traffic is used to detect the service status of the first microservice. In addition, the first microservice may also obtain real traffic in the real production environment, and the traffic control module will distinguish between the real traffic and the test traffic, so that the test traffic is transmitted to the first microservice or the simulation system. During the process of detecting the first microservice using the first test traffic, the test traffic can be transmitted between the stress testing engine and the first microservice to simulate the communication process between the terminal device and the second microservice. It can also initiate 2. service calls to the simulation system through the traffic control module to simulate the communication process between the second microservice and the first service. When the service status of the detected first microservice indicates that the processing ability of the first microservice is stable, the service registration module performs 3. service registration, specifically initiating service registration to the registration center, so that the first microservice can be discovered and used by the terminal device.

[0101] In some alternative embodiments, the test traffic may be the traffic recorded during the operation of the second microservice in a real production environment. The second microservice is a registered service, and the first microservice to be registered is an updated version of the second microservice. The traffic recording module may record the real traffic of the terminal device calling the second microservice and send this recorded traffic to the stress testing engine. The traffic recording module may also record the real traffic of the second microservice calling the first service and send this recorded traffic to the simulation system.

[0102] The specific implementation process of the foregoing method has been described in the embodiments shown above and will not be elaborated here. It should be noted that, Figures 3 to 5 similar to Figure 5 the traffic recording module may have various possible specific implementation manners. It may be implemented in an SDK manner to invade the code of the second microservice, or it may not invade, for example, be mounted on the relevant program of the second microservice. The specific implementation is not limited here.

[0103] The related devices provided in the embodiments of the present application will be described below. Please refer to Figures 7 to 9 , Figures 7 to 9 which are schematic structural diagrams of the communication devices provided in the embodiments of the present application.

[0104] Generally speaking, the communication device includes corresponding units or modules for executing the foregoing method. The units or modules included in the communication device may be implemented in software and / or hardware. The communication device may be, for example, a network device, or a module of a network device (such as a chip), or a logical node, logical module, or software that can implement all or part of the functions of a network device.

[0105] As Figure 7 shown, the communication device 700 includes a traffic control module 701 and a service registration module 702.

[0106] The traffic control module 701 is used to obtain the test traffic and detect the service capabilities of the first microservice based on the test traffic. In the solution where the test traffic carries a test flag, the traffic control module 701 is also used to distinguish the test traffic from other traffic and transfer the external dependencies required by the first microservice to the simulation system, that is, to transmit the traffic required for the first microservice to call other services to the simulation system.

[0107] The service registration module 702 is used to register the first microservice when the service status of the first microservice indicates that the processing capabilities of the first microservice are stable. Specifically, it may request to register the first microservice with the registration center.

[0108] In some alternative embodiments, the communication device 700 further includes a traffic recording module 703 for recording the real traffic in the production environment, including the first traffic used in the communication process between the terminal device and the second microservice, and / or the second traffic used in the communication process between the first microservice and the first service. The recorded real traffic can be used as the test traffic source for the stress service call to the service instance to be launched.

[0109] In some alternative embodiments, the communication device 700 further includes a stress testing engine module 704 for simulating the terminal device in the real production environment to initiate a service call to the first microservice. It can also be used to obtain the test traffic from the traffic recording module 703, or obtain the preset test traffic, and initiate the detection of the first microservice based on the test traffic.

[0110] In some alternative embodiments, at least one of the following may also run on the communication device 700: a registration center, an emulation system, other services, which are not specifically limited here.

[0111] The communication device 700 is used to perform the operations executed by the network device in the foregoing embodiments to implement the microservice registration method provided in the embodiments of the present application, which will not be elaborated here.

[0112] As Figure 8 shown, the communication device 800 includes an acquisition unit 801 and a processing unit 802.

[0113] In some alternative embodiments, the acquisition unit 801 is used to obtain test traffic for detecting the service status of the first microservice. The first microservice is the service to be registered, and the service status is used to indicate the processing capacity of the first microservice.

[0114] The processing unit 802 is used to detect the first microservice using the test traffic. When the service status indicates that the processing capacity of the first microservice is stable, register the first microservice.

[0115] In some alternative embodiments, the processing unit 802 is further used to determine the service status of the first microservice according to the response status parameters of the first microservice. The response status parameters include at least one of the number of requests per second, the error rate, or the response delay.

[0116] In some alternative embodiments, the service status indicating that the processing capacity of the first microservice is stable includes at least one of the following: the number of requests per second meets the preset conditions, the error rate is less than or equal to the error rate threshold, or the response delay is less than or equal to the delay threshold.

[0117] In some alternative embodiments, the test traffic includes the traffic recorded when the second microservice is running. The second microservice is a registered service, and the first microservice is an updated version of the second microservice.

[0118] In some alternative embodiments, the test traffic includes: the first traffic used by the second microservice to communicate with the terminal device; and / or, the second traffic used by the second microservice to communicate with the first service.

[0119] In some alternative embodiments, the processing unit 802 is specifically configured to: simulate the communication between the first microservice and the terminal device through the first traffic; and / or, control the first microservice to communicate with the simulation system through the second traffic, where the simulation system is used to simulate the first service.

[0120] In some alternative embodiments, the test traffic carries a test tag, and the test tag is used to indicate the test traffic.

[0121] The communication device 800 is configured to perform the operations performed by the network device in the foregoing embodiments to implement the microservice registration method provided in the embodiments of the present application, which will not be elaborated here.

[0122] Please refer to Figure 9 , Figure 9 which is a schematic structural diagram of a communication device provided in an embodiment of the present application. The communication device 900 includes a processor 901, a memory 902, a communication interface 903, and a bus 904. Among them, the processor 901, the memory 902, and the communication interface 903 communicate through the bus 904, and can also implement communication through other means such as wireless transmission. The memory 902 stores program code, and the processor 901 can call the program code stored in the memory 902 to perform the operations performed by the network device in the foregoing Figures 1 to 6 illustrated embodiments, which will not be elaborated here.

[0123] It should be understood that in the embodiments of the present application, the processor 901 may be a CPU, and the processor 901 may also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc.

[0124] The memory 902 may include a read-only memory and a random access memory, and provide instructions and data to the processor 901. The memory 902 may also include a non-volatile random access memory. For example, the memory 902 may also store information about the device type.

[0125] The memory 902 can be a volatile memory, a non-volatile memory, or can include both volatile and non-volatile memories. Among them, the non-volatile memory can be a read-only memory (ROM), a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), or a flash memory. The volatile memory can be a random access memory (RAM), which is used as an external cache. By way of example but not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchlink DRAM (SLDRAM), and direct rambus RAM (DR RAM).

[0126] In addition to including a data bus, the bus 904 can also include a power bus, a control bus, a status signal bus, etc. However, for the sake of clarity, all kinds of buses are labeled as bus 904 in the figure. The bus 940 can be a Peripheral Component Interconnect Express (PCIe) bus, or an extended industry standard architecture (EISA) bus, a unified bus (Ubus or UB), a compute express link (CXL), a cache coherent interconnect for accelerators (CCIX), etc. The bus 940 can be divided into an address bus, a data bus, a control bus, etc.

[0127] The communication device 900 can also include one or more communication interfaces, one or more operating systems, such as Windows Server TM , Mac OS X TM , UnixTM , Linux TM , FreeBSD TM etc.

[0128] Those skilled in the art can clearly understand that for the convenience and conciseness of description, the specific working processes of the systems, devices, and units described above can refer to the corresponding processes in the foregoing method embodiments and will not be elaborated herein.

[0129] In several embodiments provided in the present application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the units is only a logical function division, and there can be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed couplings or direct couplings or communication connections to each other can be through some interfaces, and the indirect couplings or communication connections of the devices or units can be in electrical, mechanical, or other forms.

[0130] The units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they can be located in one place or distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0131] In addition, the functional units in each embodiment of the present application can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above-mentioned integrated units can be implemented in the form of hardware or in the form of software functional units.

[0132] If the above-mentioned integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, in essence, or the part that contributes to the prior art, or all or part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in each embodiment of the present application. The foregoing storage medium includes: various media such as USB flash drives, mobile hard disks, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical discs that can store program codes.

Claims

1. A microservice registration method, characterized in that: include: Acquire test traffic, where the test traffic is used to detect a service state of a first microservice, where the first microservice is a service to be registered, and the service state is used to indicate a processing capability of the first microservice; Using the test traffic, detecting the first microservice; When the service status indicates that the processing capacity of the first microservice is stable, register the first microservice.

2. The method according to claim 1, characterized in that The method further comprises: The service status of the first microservice is determined according to a response status parameter of the first microservice, where the response status parameter includes at least one of a number of requests per second, an error rate, or a response delay.

3. The method according to claim 2, characterized in that The service status indicates that the processing capacity of the first microservice is stable, including at least one of the following: The number of requests per second meets a preset condition, the error rate is less than or equal to an error rate threshold, or the response delay is less than or equal to a delay threshold.

4. The method according to any one of claims 1 to 3, characterized in that The test traffic includes traffic recorded when a second microservice is running, the second microservice is a registered service, and the first microservice is an updated version of the second microservice.

5. The method according to claim 4, characterized in that The test traffic includes: A first flow rate used by the second microservice to communicate with the terminal device; and / or, The second traffic used by the second microservice to communicate with the first service.

6. The method according to claim 5, characterized in that The using the test traffic to detect the first microservice includes: Simulating the communication between the first microservice and the terminal device through the first traffic; and / or, The first microservice is controlled to communicate with a simulation system through the second traffic, where the simulation system is used to simulate the first service.

7. The method according to any one of claims 1 to 6, characterized in that The test traffic carries a test tag, and the test tag is used to indicate the test traffic.

8. A communication device, characterized in that: include: an acquisition unit, configured to acquire test traffic, wherein the test traffic is used to detect a service state of a first microservice, wherein the first microservice is a service to be registered, and the service state is used to indicate a processing capability of the first microservice; A processing unit, configured to detect the first microservice using the test traffic; The processing unit is further configured to register the first microservice when the service status indicates that the processing capacity of the first microservice is stable.

9. The communication device according to claim 8, characterized in that: The processing unit is further used for: The service status of the first microservice is determined according to a response status parameter of the first microservice, where the response status parameter includes at least one of a number of requests per second, an error rate, or a response delay.

10. The communication device according to claim 9, characterized in that: The service status indicates that the processing capacity of the first microservice is stable, including at least one of the following: The number of requests per second meets a preset condition, the error rate is less than or equal to an error rate threshold, or the response delay is less than or equal to a delay threshold.

11. The communication device according to any one of claims 8 to 10, characterized in that: The test traffic includes traffic recorded when a second microservice is running, the second microservice is a registered service, and the first microservice is an updated version of the second microservice.

12. The communication device according to claim 11, characterized in that: The test traffic includes: A first flow rate used by the second microservice to communicate with the terminal device; and / or, The second traffic used by the second microservice to communicate with the first service.

13. The communication device according to claim 12, characterized in that: The processing unit is specifically used for: Simulating the communication between the first microservice and the terminal device through the first traffic; and / or, The first microservice is controlled to communicate with a simulation system through the second traffic, where the simulation system is used to simulate the first service.

14. The communication device according to any one of claims 8 to 13, characterized in that: The test traffic carries a test tag, and the test tag is used to indicate the test traffic.

15. A communication device, characterized in that: comprising a processor coupled to a memory; Instructions are stored in the memory, and when the instructions are executed on the processor, the communication device implements the method according to any one of claims 1 to 7.

16. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores instructions, and when the instructions are executed on a processor, the method according to any one of claims 1 to 7 is implemented.

17. A computer program product, characterized in that When the computer program product is executed on a computer, the method according to any one of claims 1 to 7 is implemented.

Images