CN113645259A

CN113645259A - Micro-service elastic expansion method, system and related equipment

Info

Publication number: CN113645259A
Application number: CN202010344991.0A
Authority: CN
Inventors: 李林锋
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huaban Payment Shenzhen Co ltd
Priority date: 2020-04-27
Filing date: 2020-04-27
Publication date: 2021-11-12
Anticipated expiration: 2040-04-27
Also published as: CN113645259B

Abstract

The application discloses a micro-service elastic scaling method, a micro-service elastic scaling system and related equipment. After the micro-service instance which is expanded by elastic expansion and new is started by adopting a lazy loading mechanism, the micro-service instance is registered in a service registration center in an offline state, and the service registration center registers but does not release the micro-service instance. And then the micro-service instance is tested by the test server, and after the completion of the service starting is determined, the state of the micro-service instance in the service registration center is modified into an online state. The service registration center issues the micro-service instance, and the service caller can normally access the service provided by the micro-service instance, thereby improving the call success rate of the newly expanded micro-service instance.

Description

Micro-service elastic expansion method, system and related equipment

Technical Field

The present application relates to the field of communications technologies, and in particular, to a method, a system, and a related device for elastic scaling of micro services.

Background

The micro-service is a software architecture style, and is used as an independent application system in a mode of developing a group of small-sized services, and different services are communicated by adopting a lightweight communication mechanism. These services are built around a specific business and can be deployed independently to a production environment. For example, for a shopping application, small services such as a user registration service, a user login service, a commodity display service, an ordering service and the like can be classified, and the small services can be developed and deployed respectively. These services may be written in different programming languages and may use different data storage technologies. The micro-service has the advantage of easy development and maintenance, one micro-service only focuses on one specific business function, so the business is clear, the code amount is less, and the development and maintenance of a single micro-service are relatively simple.

As shown in fig. 1, a schematic view of a scenario for a service caller to access a microservice provider is shown. Different services of the application system are all deployed in a service server of the micro-service providing terminal in a micro-service instance mode, and a user can access the services provided by the micro-service providing terminal through a mobile phone APP or a webpage as a service calling party. And the micro-service can be elastically scaled according to the requirement, for example, if the user access amount of the service A in the application system is large, several micro-service instances can be created for the service A to provide the service.

Fig. 2 is a schematic diagram illustrating a scenario of elastic scalability of a micro-service in the prior art. If the service a in fig. 2 is a game forum service, a user accesses the game forum service through a mobile phone Application (APP) as an example. As shown in fig. 2 (a), under normal conditions, the maximum number of users accessing the game forum service is 50 ten thousand, the performance of a single game forum service instance can meet 25 universal user online accesses, and the service server can meet the user access requirements only by deploying 2 forum service instances, that is, the micro service instance 1 of the service a and the micro service instance 2 of the service a. As shown in fig. 2 (b), when a post becomes popular, the user access amount is caused to increase sharply, which is twice as much as usual, i.e., 100 ten thousand. Since the current system can only handle 50 ten thousand user requests, half of the users fail to access the game forum service. After the system expands through elastic expansion, 2 game forum service instances, namely a micro-service instance 3 of a newly expanded service A and a micro-service instance 4 of the newly expanded service A, are added. After capacity expansion, the number of game forum service instances is 4, each game forum service instance can process 25 ten thousand user requests, and theoretically 100 universal user concurrent access can be supported.

However, the micro-service instances are all started by adopting a lazy loading mechanism, that is, at the initial stage of starting the micro-service instances, since the instances of the game forum service are just started successfully, a cache, a database resource, a HyperText Transfer Protocol (HTTP) connection pool and the like which are depended by the service need to be initialized for a while, when 25 ten thousand user requests are instantly routed to the micro-service instance 3 of the newly expanded service a or the micro-service instance 4 of the newly expanded service a, the service access requests of the part of users can be failed. Therefore, in the prior art, the call success rate of the micro-service instance newly expanded by elastic expansion is low.

Disclosure of Invention

The application provides a method, a system and related equipment for elastic expansion of micro-service, which are used for improving the call success rate of a micro-service instance newly expanded through elastic expansion.

In a first aspect, an embodiment of the present application provides a micro-service elastic stretching method, which is applied to a micro-service elastic stretching system, where the micro-service elastic stretching system includes: the system comprises an elastic telescopic server, a service registration center, a service server and a test server; the micro-service elastic expansion method comprises the following steps: the elastic expansion server sends a first request for starting a first micro service instance to the business server, wherein the first request carries an offline state parameter; the first micro-service instance is used for providing a first micro-service; the business server starts the first micro service instance according to the first request, and sends a registration request carrying the offline state parameter to the service registration center; the service registration center responds to the registration request and registers but does not issue the first micro-service instance according to the offline state parameter; after receiving the registration information of the first micro-service instance sent by the service server, the elastic telescopic server sends a second request for testing the first micro-service instance to the test server; the test server confirms that the test is successful according to the second request; the service registration center receives a third request sent by the test server or the elastic telescopic server, wherein the third request carries an online state parameter; the service registry responds to the third request and issues the first microservice instance according to the online status parameter.

In the embodiment of the application, the first request sent by the elastic scaling server to the service server carries the offline state parameter. And after the business server starts the first micro service instance according to the first request, the business server also carries the offline state parameter when sending a registration request to the service registration center. Thus, the service registry registers the first microservice instance in a down-line state, but does not publish. And after the elastic telescopic server enables the test server to test the first micro-service instance and determines that the test is successful, sending a third request carrying the online state parameters to the service registration center. The service registry issues the first micro-service instance after receiving the third request, and the service caller can access the first micro-service instance. Therefore, when the service calling party accesses the newly expanded first micro-service instance, the first micro-service instance can directly and normally provide the first micro-service, the condition that the service calling failure rate is high due to a lazy loading mechanism does not occur, and the calling success rate of the elastically expanded newly expanded micro-service instance is greatly improved.

In combination with the first aspect, in some embodiments, the method further comprises: the test server sends the third request to the service registry.

In the above embodiment, the third request is directly sent to the service registration center by the test server, which saves the information sending process and improves the information transmission efficiency.

In combination with the first aspect, in some embodiments, the method further comprises: and after the elastic scaling server receives the test success message sent by the test server, the elastic scaling server sends the third request to the service registration center.

In the above embodiment, the third request is sent to the service registration center by the elastic scaling server, and a complete closed loop for sending the request and receiving the response is maintained, so that the information sending process is more standard.

With reference to some embodiments of the first aspect, in some embodiments, the determining, by the test server, that the test is successful according to the second request specifically includes: responding to the second request, the test server calls the first micro service instance by using a first test case; the first test case is a test case corresponding to the first micro service; the test server receives a calling result of the first micro-service instance sent by the service server; and when the calling result of the first micro service instance is the same as the preset calling result of the first test case, the test server confirms that the test is successful.

In the embodiment, the test server calls the first micro-service instance by using the pre-stored first test case corresponding to the first micro-service, and whether the test is successful is determined by calling whether the returned result is the preset call result of the first test case, so that the efficiency and the accuracy of the micro-service instance test are improved.

With reference to some embodiments of the first aspect, in some embodiments, the second request includes registration information of the first microservice instance, and the registration information of the first microservice instance includes an access address of the first microservice instance.

In the above embodiment, the registration information of the first micro service instance included in the second request includes the access address of the first micro service instance, so that the test server can conveniently test the first micro service instance.

With reference to some embodiments of the first aspect, in some embodiments, the first request includes a microservice identifier for identifying the first microservice; the registration request comprises first instance identification information, and the first instance identification information is used for uniquely identifying the first microservice instance; the second request comprises the registration information of the first micro service instance and the identification information of the first instance; the third request includes the first instance identification information.

In the above embodiment, the first request includes the micro-service identifier of the first micro-service, so that the service server receiving the first request can quickly and definitely determine the micro-service instance that needs to be started, and the efficiency of starting the first micro-service instance is improved. The registration request comprises the first instance identification information, so that the efficiency of registering the first micro-service instance by the service registration center is improved. The second request comprises the first instance identification information, so that the test server can definitely use which test case to test the first micro-service instance; the second request contains the registration information of the first micro service instance, so that the test server can determine the access address of the first micro service instance, and the test efficiency is improved. The third request contains the first instance identification information, so that the efficiency of the service registration center for issuing the first micro service instance is improved.

With reference to some embodiments of the first aspect, in some embodiments, the offline status parameter is a first preset value in a preset field of the request message, and the online status parameter is a second preset value in the preset field of the request message, where the second preset value is different from the first preset value.

With reference to some embodiments of the first aspect, in some embodiments, the offline state parameter is a first preset character string carried in the request message; the on-line state parameter is a second preset character string carried in the request message, and the second preset character string is different from the first preset character string.

In the above embodiment, the first request, the second request, the registration request, and the third request are all one request message, and there are many expression forms in which the offline state parameter and the online state parameter are carried in the request message, which may be carried in the above two carrying manners, or may be carried in other carrying manners, and this is not limited here.

In a second aspect, an embodiment of the present application provides a method for elastic expansion and contraction of a micro service, including: sending a first request for starting a first micro service instance to a business server, wherein the first request carries an offline state parameter and is used for indicating that the first micro service instance is registered in a service registration center but not issued after being started by the business server; the first micro-service instance is used for providing a first micro-service; receiving registration information of the first micro service instance sent by the business server; and sending a second request for testing the first micro-service instance to the testing server, wherein the first micro-service instance is issued in the service registry after the testing server tests successfully.

In the embodiment of the present application, the first request sent to the service server carries the offline status parameter, which may indicate that the first microservice instance is registered but not published only in the service registry after being started by the service server. After the first micro-service instance is registered, the test server tests the first micro-service instance to enable the first micro-service instance to be issued in the service registration center after the first micro-service instance completes the loading of the service, and the call success rate of the micro-service instance newly expanded through elastic expansion is improved.

In combination with the second aspect, in some embodiments, the method further comprises: receiving a test success message sent by the test server; and responding to the test success message, and sending a third request to the service registry, wherein the third request is used for indicating the issuance of the first micro-service instance.

In the embodiment, the third request is sent to the service registration center after the test success message is received, and the first micro-service instance is instructed to be issued, so that the condition that the service calling failure rate is high due to a lazy loading mechanism is avoided, and the calling success rate of the micro-service instance newly expanded through elastic expansion is greatly improved.

In some embodiments, in combination with some embodiments of the second aspect, before the step of sending the first request to start the first microservice instance to the business server, the method further comprises: monitoring the running state of the micro-service instance in the service server; and determining that the running state of the micro service instance of the first micro service meets the condition of expanding the micro service instance of the new first micro service in the preset elastic scaling rule.

In the embodiment, when the condition that the micro service instance of the first micro service is expanded is monitored, the first request for starting the first micro service instance is sent to the service server, so that the dynamic elastic expansion capability of the first micro service is improved, and the call success rate of the first micro service is improved.

With reference to some embodiments of the second aspect, in some embodiments, the second request includes registration information of the first microservice instance, and the registration information of the first microservice instance includes an access address of the first microservice instance.

In some embodiments in combination with some embodiments of the second aspect, in some embodiments, the first request includes a microservice identifier for identifying the first microservice; the second request comprises registration information of the first micro service instance and first instance identification information, and the first instance identification information is used for uniquely identifying the first micro service instance; the third request includes the first instance identification information.

With reference to some embodiments of the second aspect, in some embodiments, the offline status parameter is a first preset value in a preset field of the request message, and the online status parameter is a second preset value in the preset field of the request message, where the second preset value is different from the first preset value.

With reference to some embodiments of the second aspect, in some embodiments, the offline state parameter is a first preset character string carried in the request message; the on-line state parameter is a second preset character string carried in the request message, and the second preset character string is different from the first preset character string.

In a third aspect, an embodiment of the present application provides a method for elastic expansion and contraction of a micro service, including: receiving a registration request for registering a first micro-service instance sent by a business server, wherein the registration request carries an offline state parameter and is used for registering but not issuing the first micro-service instance; the first micro-service instance is used for providing a first micro-service; responding to the registration request, and registering but not issuing the first micro service instance according to the offline state parameter; returning the registration information of the first micro service instance to the business server; receiving a third request carrying an online state parameter; responding to the third request and issuing the first micro service instance according to the online state parameter.

In the embodiment of the application, when a registration request carrying the offline state parameters is received, the first micro-service instance is registered but not issued, and when a third request carrying the online state parameters is received, the first micro-service instance is issued according to the online state parameters in the third request, so that the condition that the service call failure rate is high due to a lazy loading mechanism is avoided. After a third request carrying the on-line state parameter is received, the first micro-service instance is issued according to the on-line state parameter, and the call success rate of the micro-service instance newly expanded through elastic expansion is greatly improved.

With reference to the third aspect, in some embodiments, the receiving a third request carrying an online status parameter specifically includes: and receiving the third request sent by the test server.

With reference to the third aspect, in some embodiments, the receiving a third request carrying an online status parameter specifically includes: and receiving the third request sent by the elastic scaling server.

With reference to some embodiments of the third aspect, in some embodiments, the offline status parameter is a first preset value in a preset field of the request message, and the online status parameter is a second preset value in the preset field of the request message, where the second preset value is different from the first preset value.

With reference to some embodiments of the third aspect, in some embodiments, the offline state parameter is a first preset character string carried in the request message; the on-line state parameter is a second preset character string carried in the request message, and the second preset character string is different from the first preset character string.

In a fourth aspect, an embodiment of the present application provides a method for elastic expansion and contraction of a micro service, including: receiving a first request for starting a first micro service instance sent by an elastic telescopic server, wherein the first request carries an offline state parameter; the first micro-service instance is used for providing a first micro-service; starting the first micro-service instance according to the first request; sending a registration request carrying an offline state parameter to a service registration center for registering in the service registration center but not issuing the first micro-service instance; and sending the registration information of the first micro service instance to the elastic scaling server, wherein the registration information is used for issuing the first micro service instance in a service registration center after the elastic scaling server requests the test server to test the first micro service instance successfully.

In the embodiment of the application, if the received first request carries the offline state parameter, after the first micro-service instance is started, the registration request sent to the service registration center carries the offline state parameter, so that the service registration center registers but does not issue the first micro-service instance, and the condition that the service calling failure rate is high due to a lazy loading mechanism is avoided. After the first micro-service instance is registered, the registration information of the first micro-service instance is sent to the elastic telescopic server, so that the first micro-service instance is issued in the service registration center only after the elastic telescopic server requests to test the first micro-service instance successfully, and the call success rate of the micro-service instance newly expanded through elastic telescopic is improved.

In combination with the fourth aspect, in some embodiments, the method further comprises: receiving the call of the first micro service instance by the test server by using a first test case, and completing service loading for the first micro service instance, wherein the first test case is a test case corresponding to the first micro service; and sending the calling result of the first micro service instance to the test server so that the test server can confirm that the test is successful.

In some embodiments, in combination with some embodiments of the fourth aspect, the registration information of the first microservice instance includes an access address of the first microservice instance.

With reference to some embodiments of the fourth aspect, in some embodiments, the offline status parameter is a first preset value in a preset field of the request message.

With reference to some embodiments of the fourth aspect, in some embodiments, the offline status parameter is a first preset character string carried in the request message.

In a fifth aspect, an embodiment of the present application provides a microservice elastic expansion system, including: the system comprises an elastic telescopic server, a service registration center, a service server and a test server; the elastic expansion server is used for sending a first request for starting a first micro service instance to the business server, wherein the first request carries an offline state parameter; the first micro-service instance is used for providing a first micro-service; after receiving the registration information of the first micro service instance sent by the business server, sending a second request for testing the first micro service instance to the testing server; the business server is used for starting the first micro service instance according to the first request and sending a registration request carrying the offline state parameter to the service registration center; the service registration center is used for responding to the registration request and registering but not issuing the first micro service instance according to the offline state parameter; after receiving a third request carrying an online state parameter sent by the test server or the elastic telescopic server, responding to the third request and issuing the first micro service instance according to the online state parameter; the test server is used for confirming that the test is successful according to the second request.

With reference to the fifth aspect, in some embodiments, the test server is further configured to send the third request to the elastic scaling server after confirming that the test is successful.

With reference to the fifth aspect, in some embodiments, the test server is further configured to send a test success message to the elastic scaling server after confirming that the test is successful; the flexible scaling server is further configured to send the third request to the service registration center after receiving the test success message sent by the test server.

With reference to the fifth aspect, in some embodiments, the test server is specifically configured to, in response to the second request, invoke the first microservice instance using a first test case; the first test case is a test case corresponding to the first micro service; receiving a calling result of the first micro-service instance sent by the business server; and when the calling result of the first micro service instance is the same as the preset calling result of the first test case, the test is confirmed to be successful.

With reference to some embodiments of the fifth aspect, in some embodiments, the second request includes registration information of the first microservice instance, and the registration information of the first microservice instance includes an access address of the first microservice instance.

In some embodiments in combination with some embodiments of the fifth aspect, in some embodiments, the first request includes a microservice identifier for identifying the first microservice; the registration request comprises first instance identification information, and the first instance identification information is used for uniquely identifying the first microservice instance; the second request comprises the registration information of the first micro service instance and the identification information of the first instance; the third request includes the first instance identification information.

With reference to some embodiments of the fifth aspect, in some embodiments, the offline status parameter is a first preset value in a preset field of the request message, and the online status parameter is a second preset value in the preset field of the request message, where the second preset value is different from the first preset value.

With reference to some embodiments of the fifth aspect, in some embodiments, the offline state parameter is a first preset character string carried in the request message; the on-line state parameter is a second preset character string carried in the request message, and the second preset character string is different from the first preset character string.

In a sixth aspect, an embodiment of the present application provides an elastic scaling server, including: one or more processors and memory; the memory coupled with the one or more processors, the memory for storing computer program code, the computer program code including computer instructions, the one or more processors invoking the computer instructions to cause the elastic scaling server to perform: sending a first request for starting a first micro service instance to a business server, wherein the first request carries an offline state parameter and is used for indicating that the first micro service instance is registered in a service registration center but not issued after being started by the business server; the first micro-service instance is used for providing a first micro-service; receiving registration information of the first micro service instance sent by the business server; and sending a second request for testing the first micro-service instance to the testing server, wherein the first micro-service instance is issued in the service registry after the testing server tests successfully.

In combination with the sixth aspect, in some embodiments, the one or more processors are further configured to invoke the computer instructions to cause the elastic scaling server to perform: receiving a test success message sent by the test server; and responding to the test success message, and sending a third request to the service registry, wherein the third request is used for indicating the issuance of the first micro-service instance.

In some embodiments in combination with some embodiments of the sixth aspect, the one or more processors are further configured to invoke the computer instructions to cause the elastic scaling server to perform: monitoring the running state of the micro-service instance in the service server; and determining that the running state of the micro service instance of the first micro service meets the condition of expanding the micro service instance of the new first micro service in the preset elastic scaling rule.

With reference to some embodiments of the sixth aspect, in some embodiments, the second request includes registration information of the first microservice instance, and the registration information of the first microservice instance includes an access address of the first microservice instance.

In some embodiments, in combination with some embodiments of the sixth aspect, the first request includes a microservice identifier for identifying the first microservice; the second request comprises registration information of the first micro service instance and first instance identification information, and the first instance identification information is used for uniquely identifying the first micro service instance; the third request includes the first instance identification information.

With reference to some embodiments of the sixth aspect, in some embodiments, the offline status parameter is a first preset value in a preset field of the request message, and the online status parameter is a second preset value in the preset field of the request message, where the second preset value is different from the first preset value.

With reference to some embodiments of the sixth aspect, in some embodiments, the offline state parameter is a first preset character string carried in the request message; the on-line state parameter is a second preset character string carried in the request message, and the second preset character string is different from the first preset character string.

In a seventh aspect, an embodiment of the present application provides a service registry, where the service registry includes: one or more processors and memory; the memory coupled with the one or more processors, the memory for storing computer program code, the computer program code including computer instructions, the one or more processors invoking the computer instructions to cause the service registry to perform: receiving a registration request for registering a first micro-service instance sent by a business server, wherein the registration request carries an offline state parameter and is used for registering but not issuing the first micro-service instance; the first micro-service instance is used for providing a first micro-service; responding to the registration request, and registering but not issuing the first micro service instance according to the offline state parameter; returning the registration information of the first micro service instance to the business server; receiving a third request carrying an online state parameter; responding to the third request and issuing the first micro service instance according to the online state parameter.

With reference to the seventh aspect, in some embodiments, the one or more processors are specifically configured to invoke the computer instructions to cause the service registry to perform: and receiving the third request sent by the test server.

With reference to the seventh aspect, in some embodiments, the one or more processors are specifically configured to invoke the computer instructions to cause the service registry to perform: and receiving the third request sent by the elastic scaling server.

With reference to some embodiments of the seventh aspect, in some embodiments, the registration request includes first instance identification information, and the first instance identification information is used to uniquely identify the first microservice instance; the third request includes the first instance identification information.

With reference to some embodiments of the seventh aspect, in some embodiments, the offline status parameter is a first preset value in a preset field of the request message, and the online status parameter is a second preset value in the preset field of the request message, where the second preset value is different from the first preset value.

With reference to some embodiments of the seventh aspect, in some embodiments, the offline state parameter is a first preset character string carried in the request message; the on-line state parameter is a second preset character string carried in the request message, and the second preset character string is different from the first preset character string.

In an eighth aspect, an embodiment of the present application provides a service server, where the service server includes: one or more processors and memory; the memory coupled with the one or more processors, the memory for storing computer program code, the computer program code including computer instructions, the one or more processors invoking the computer instructions to cause the service registry to perform: receiving a first request for starting a first micro service instance sent by an elastic telescopic server, wherein the first request carries an offline state parameter; the first micro-service instance is used for providing a first micro-service; starting the first micro-service instance according to the first request; sending a registration request carrying an offline state parameter to a service registration center for registering in the service registration center but not issuing the first micro-service instance; and sending the registration information of the first micro service instance to the elastic scaling server, wherein the registration information is used for issuing the first micro service instance in a service registration center after the elastic scaling server requests the test server to test the first micro service instance successfully.

In combination with the eighth aspect, in some embodiments, the one or more processors are further configured to invoke the computer instructions to cause the service server to perform: receiving the call of the first micro service instance by the test server by using a first test case, and completing service loading for the first micro service instance, wherein the first test case is a test case corresponding to the first micro service; and sending the calling result of the first micro service instance to the test server so that the test server can confirm that the test is successful.

With reference to some embodiments of the eighth aspect, in some embodiments, the registration information of the first microservice instance includes an access address of the first microservice instance.

In some embodiments, in combination with some embodiments of the eighth aspect, the first request includes a microservice identifier for identifying the first microservice; the registration request includes first instance identification information, and the first instance identification information is used for uniquely identifying the first microservice instance.

With reference to some embodiments of the eighth aspect, in some embodiments, the offline status parameter is a first preset value in a preset field of the request message.

With reference to some embodiments of the eighth aspect, in some embodiments, the offline status parameter is a first preset character string carried in the request message.

In a ninth aspect, the present application provides a chip system, which is applied to an elastic scaling server, and the chip system includes one or more processors, and the processors are configured to invoke computer instructions to cause the elastic scaling server to execute the micro-service elastic scaling method as provided in any one of the possible implementations of the second aspect or the second aspect.

In a tenth aspect, embodiments of the present application provide a computer program product containing instructions that, when run on a resilient scaling server, cause the resilient scaling server to perform a microservice resilient scaling method as provided in the second aspect or any one of the possible implementations of the second aspect.

In an eleventh aspect, embodiments of the present application provide a computer-readable storage medium, which includes instructions that, when executed on an elastic scaling server, cause the elastic scaling server to perform a microservice elastic scaling method as provided in the second aspect or any one of the possible implementations of the second aspect.

It will be appreciated that the resilient scaling server provided by the sixth aspect, the chip system provided by the ninth aspect, the computer program product provided by the tenth aspect and the computer storage medium provided by the eleventh aspect are all adapted to perform the method provided by any of the possible implementations of the second aspect or the second aspect. Therefore, the beneficial effects achieved by the method can refer to the beneficial effects in the corresponding method, and are not described herein again.

In a twelfth aspect, the present application provides a chip system, where the chip system is applied to a service registry, and the chip system includes one or more processors, where the processors are configured to invoke computer instructions to cause the service registry to perform the micro-service flexible scaling method as provided in any one of the possible implementations of the third aspect or the third aspect.

In a thirteenth aspect, the present application provides a computer program product containing instructions that, when run on a service registry, cause the service registry to perform a microservice elastic scaling method as provided in any one of the possible implementations of the third aspect or the third aspect.

In a fourteenth aspect, an embodiment of the present application provides a computer-readable storage medium, which includes instructions that, when executed on a service registry, cause the service registry to perform a microservice elastic scaling method as provided in any one of the possible implementations of the third aspect or the third aspect.

It is to be understood that the server registry provided in the seventh aspect, the chip system provided in the twelfth aspect, the computer program product provided in the thirteenth aspect, and the computer storage medium provided in the fourteenth aspect are all configured to perform the method provided in any one of the possible implementations of the third aspect or the third aspect. Therefore, the beneficial effects achieved by the method can refer to the beneficial effects in the corresponding method, and are not described herein again.

In a fifteenth aspect, the present application provides a chip system, which is applied to a service server, and the chip system includes one or more processors, where the processors are configured to invoke computer instructions to cause the service server to execute the micro-service elastic scaling method as provided in any one of the possible implementations of the fourth aspect or the fourth aspect.

In a sixteenth aspect, the present application provides a computer program product containing instructions, which when run on a service server, causes the service server to execute the microservice elastic scaling method as provided in any one of the possible implementations of the fourth aspect or the fourth aspect.

In a seventeenth aspect, an embodiment of the present application provides a computer-readable storage medium, which includes instructions that, when executed on a service server, cause the service server to perform the micro-service elastic scaling method as provided in any one of the possible implementations of the fourth aspect or the fourth aspect.

It is to be understood that the service server provided by the above-mentioned eighth aspect, the chip system provided by the fifteenth aspect, the computer program product provided by the sixteenth aspect, and the computer storage medium provided by the seventeenth aspect are all used to execute the method provided by any one of the possible implementations of the fourth aspect or the fourth aspect. Therefore, the beneficial effects achieved by the method can refer to the beneficial effects in the corresponding method, and are not described herein again.

Drawings

FIG. 1 is a schematic diagram of a scenario in which a service caller accesses a microservice provider;

FIG. 2 is a diagram illustrating a scenario of elastic scalability of micro-services in the prior art;

FIG. 3 is a schematic diagram of information interaction between a service registry and a microserver in an embodiment of the present application;

FIG. 4 is a schematic diagram of an exemplary microservice architecture;

FIGS. 5(a) -5 (c) are schematic views of a scenario of the microservice elastic expansion method in the embodiment of the present application;

FIG. 6 is a schematic diagram of the interaction of components in a prior art microservice elastic telescoping system;

FIG. 7 is a schematic diagram of the architecture of the micro-service elastic telescoping system in the embodiment of the present application;

FIG. 8 is a flowchart illustrating a method for elastic micro-service scaling in an embodiment of the present application;

fig. 9 is a schematic hardware configuration diagram of a server in the embodiment of the present application.

Detailed Description

The terminology used in the following embodiments of the present application is for the purpose of describing particular embodiments only and is not intended to be limiting of the present application. As used in the specification of the present application and the appended claims, the singular forms "a", "an", "the" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the listed items.

In the following, the terms "first", "second" are used for descriptive purposes only and are not to be understood as implying or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of embodiments of the application, unless stated otherwise, "plurality" means two or more.

Since the embodiments of the present application relate to the application of microservice and elastic expansion technology, for the convenience of understanding, the related terms and concepts related to the embodiments of the present application will be described below.

(1) Micro-service:

before the advent of microservices, it was generally a monolithic software application. A software application will often develop and package all the functions of the application together. However, such a method has disadvantages such as poor fault tolerance, difficulty in scaling, and difficulty in development and cooperation.

The micro-service software architecture style splits a single software application into a group of small services which can be developed and deployed respectively.

A typical microservice has the following features:

1. single duty. One micro-service solves one business problem.

2. Service oriented. The method encapsulates the business capability of the micro-service and provides services to the outside, and one micro-service can use the capability of other micro-services.

In order to solve the problem of service management after micro-servicing of an application program, a micro-service architecture is provided.

The first problem encountered after application microservices is the service discovery problem. How does one microservice discover other microservices? The simplest way is to configure the addresses of other micro-services in each micro-service, but when the number of micro-services is large, it is obviously unrealistic to do so. It is therefore necessary to use one of the most important components into the microservice architecture: and the service registry registers all services to the service registry, and can acquire a current available service list from the service registry. Fig. 3 is a schematic diagram illustrating information interaction between the service registry and the microserver. By registering at the service registry, different microservices: the service A, the service B and the service C can mutually discover and call the service.

After solving the service discovery problem, it is then necessary to solve the second problem caused by distributed deployment of microservices: problem of service configuration management. When the number of the micro-services exceeds a certain degree, if the configuration file of each micro-service needs to be maintained in each micro-service, the workload is too large. Then, the second important component in the microservice architecture is needed: a configuration center from which all microservices get/refresh the configuration.

In addition, there may be multiple microservice instances for the same microservice, more microservice instances for different microservices, different addresses for different microservice instances, how do the service caller call the microservices? In this case, the service gateway is required to provide a uniform service entrance, and finally, a typical micro-service framework is formed. FIG. 4 is a diagram of a typical microservice architecture.

(2) Example (c):

examples are commonly used terms in computer languages. A "class" is called an "instance" after instantiation. Classes are static and do not occupy process memory, while instances have dynamic memory. In the database, a collection of programs is represented.

In the embodiment of the present application, a micro-service instance may refer to a virtual machine that provides a micro-service. According to actual needs, one micro service can have a plurality of micro service instances, and the micro service instances all provide the functions of the micro service.

(3) The lazy loading mechanism:

the lazy loading mechanism is a system initialization strategy for delaying the loading of software resources. After the system is started, the resource initialization and the service call are not performed immediately. But the relevant resources and services are initialized and called when the external first request message is received subsequently and needs to be used, thereby reducing the consumption of time and memory in the starting process.

Because one micro service may have a relationship with many micro services, third-party service systems, or other network elements, if initialization and service invocation of all relevant resources are directly performed after the system is started without a request, a great waste of time and resources is caused, and the purpose of implementing the service cannot be achieved. Therefore, at present, the micro-service generally uses a lazy loading mechanism for starting.

(4) Elastic expansion (Auto Scaling):

elastic scaling is a management service that automatically adjusts its elastic computing resources according to business needs and policies. When the service requirement is increased, automatically increasing the operation examples; the running instances are automatically reduced when the business demand decreases. Thereby more efficiently achieving the utilization of computing resources.

(5) Micro-service identification:

the microservice identifier is used to uniquely identify a microservice, thereby distinguishing between different microservices that make up a software application.

For example, if a software application consists of three different microservices: service A, service B, and service C. The three different microservices have different microservice identities. A microservice may be provided by a number of microservice instances together, for example there may be 3 microservice instances of service a each providing service a.

(6) Example identification information:

the instance identification information is information which is obtained when the micro service instance is started and is used for uniquely identifying the micro service instance. The instance identification information may include: micro-service identification, micro-service instance identification number (ID), micro-service instance start time, micro-service instance version information, IP of micro-service instance, service monitoring port, etc.

(7) Example registration information:

the instance registration information is information which is obtained when the service registration center registers the micro-service instance and represents the access address of the micro-service instance. The instance registration information may include: a Uniform Resource Locator (URL) address of the microservice instance, information of the room where the microservice instance is deployed, and the like.

In the prior art, a micro-service instance newly expanded through elastic expansion is started by adopting a lazy loading mechanism, and is issued to a service caller after being registered in a service registration center. When a service calling party accesses for the first time, the micro-service instance needs to load related resource starting service. During which service access requests of a large number of users fail, resulting in a low call success rate.

In the method for elastic expansion and contraction of micro-service provided by the embodiment of the application, after a micro-service instance newly expanded through elastic expansion is started by adopting a lazy loading mechanism, the micro-service instance is registered in a service registration center in an offline state, and the service registration center registers but does not issue the micro-service instance. And then the micro-service instance is tested by the test server, and after the completion of the service starting is determined, the state of the micro-service instance in the service registration center is modified into an online state. The service registration center issues the micro-service instance, and the service caller can normally access the service provided by the micro-service instance, thereby improving the call success rate of the newly expanded micro-service instance.

Fig. 5(a) to 5(c) are schematic views of a scenario of the microservice elastic scaling method in the embodiment of the present application. If the service a in fig. 5(a) to 5(c) is a game forum service, taking the example that the user accesses the game forum service through the mobile phone APP:

as shown in fig. 5(a), under normal conditions, the maximum number of users accessing the game forum service is 50 ten thousand, the performance of a single game forum service instance can meet 25 universal user online accesses, and the service server can meet the user access requirements only by deploying 2 forum service instances, that is, the micro service instance 1 of the service a and the micro service instance 2 of the service a. The access traffic of the service invoker to browse the game forum service is split equally to the micro-service instances of the two services a.

As shown in fig. 5(b), when a post becomes hot, resulting in a rapid increase of user access volume, the system determines that the service a reaches the flexible expansion condition, and newly expands two micro-service instances for the service a: micro-service instance 3 of newly expanded service a and micro-service instance 4 of newly expanded service a. After the two newly expanded micro-service instances are started, the micro-service registration is carried out in the service registration center in the offline state, and the service registration center only registers but does not issue the two newly started micro-service instances. The two newly started micro-service instances carry out service test through the test server, the test server accesses the two micro-service instances through the test cases of the test server, service starting in the two micro-service instances is triggered, and when the service can be normally accessed, the test success is determined.

As shown in fig. 5(c), after the test server feeds back that the two newly-expanded micro service instances are successfully tested, the two newly-expanded micro service instances modify the registration state in the service registry to be the online state, and the service registry issues the two newly-expanded micro service instances. At this time, 4 forum service instances are deployed in the service server to meet the user access requirement, that is, micro service instance 1 of service a, micro service instance 2 of service a, micro service instance 3 of newly expanded service a, and micro service instance 4 of newly expanded service a. The access flow of the service caller browsing the game forum service is uniformly distributed into the 4 micro-service instances of the service A, each micro-service instance can process 25 ten thousand user requests, the maximum number of users accessing the game forum service is increased to 100 ten thousand, the calling success rate is high, and the condition that the newly expanded micro-service instance fails to be called for the first time is reduced.

Fig. 6 is a schematic diagram illustrating interaction among components in a microservice elastic expansion and contraction system in the prior art:

s601, based on the elastic expansion rule, when determining that a new micro-service instance needs to be started, the elastic expansion server sends a starting instruction to the service server;

s602, after receiving the starting instruction, the service server starts a new micro-service instance to obtain instance identification information of the micro-service instance;

s603, the service server sends the registration request carrying the instance identification information to a service registration center, and registers for the newly started micro-service instance in the service registration center;

s604, after receiving the registration request, the service registration center registers and releases the newly started micro-service instance;

s605, the service registration center returns instance registration information to the service server;

s606, the service server returns the instance identification information and the instance registration information to the elastic expansion server;

s607, the service register center broadcasts the service on-line state information of the newly started micro-service instance to the service caller;

s608, the service caller distributes the request message to the micro-service instance in the service server, wherein the micro-service instance comprises the newly started micro-service instance.

Compared with the micro-service elastic telescopic system in the prior art, the micro-service elastic telescopic system in the embodiment of the application further comprises a test server, and the specific functions of the servers in the micro-service elastic telescopic system are different from those in the prior art. Fig. 7 is a schematic diagram of the architecture of the microservice elastic expansion and contraction system 700 according to the embodiment of the present application. The micro-service elastic scaling system 700 comprises a service registration center 701, an elastic scaling server 702, a service server 703 and a test server 704.

The service registry 701 is configured to register a microservice instance, manage the up-down state of the microservice instance, and issue the microservice instance. Compared with the service registry in the prior art shown in fig. 6, the service registry 701 in the embodiment of the present application supports a service status field when registering a microservice instance, where the service status field has two selectable status parameters: the system is divided into an offline state (offline) and an online state (online).

The service registration interface of the service registration center 701 supports optional status parameters, and may specify whether the microservice instance is registered in a down-line status or an on-line status:

if the micro-service instance is registered in the offline mode, the service registration center 701 does not send a notification message to the service caller 705, and the service caller 705 cannot sense that the new micro-service instance is registered online. Thus, the request message of the service invoker 705 is not routed to the microservice instance;

if the microservice instance is registered in an online mode, the service registry 701 sends a service online broadcast message to the service caller 705. After obtaining the service address information of the newly registered online microservice instance, the service caller 705 adds the service address information to the local routing table. The request message of the subsequent service invoker 705 can be automatically sent to these online microservice instances.

In addition to the optional state parameters that may be selected for the service state field of a microservice instance at registration, the service registry 701 also provides an interface for modifying the optional state parameters of the service state field of a registered microservice instance based on the instance identification information and the instance registration information of the registered microservice instance. If the service registration center 701 receives a request message carrying the instance identification information, the instance registration information, and the on-line status parameter, the service registration center 701 modifies the service status field of the microservice instance corresponding to the instance identification information and the instance registration information to the on-line status. And sends a service online broadcast message to the service invoker 705. After obtaining the service address information of the newly online micro-service instance, the service caller 705 adds the service address information to the local routing table. The request message of the subsequent service invoker 705 can be automatically sent to these online microservice instances.

The elastic scaling server 702 is used to start a new micro-service instance or delete a micro-service instance in the service server 603 according to the elastic scaling rule. Compared with the elastic scaling server in the prior art shown in fig. 6, the elastic scaling server 702 in the embodiment of the present application has the following different functions:

1. support is given for starting a new microservice instance in the traffic server 603 in a different mode by carrying different optional state parameters.

For example, the elastic scaling server 702 may send a start instruction carrying the offline state parameter to the service server 703, and after the service server 703 starts the micro-service instance according to the start instruction, the newly started micro-service instance may be registered with the service registration center 701 by carrying the offline state parameter.

For example, the elastic scaling server 702 may send a start instruction carrying the online status parameter to the service server 703, and then the service server 703 starts the micro-service instance according to the start instruction, and registers the newly started micro-service instance with the service registration center 701 by carrying the online status parameter.

2. And the method supports the initiation of the test of the started micro-service instance and carries out corresponding processing on the micro-service instance according to the test result.

For example, the elastic scaling server 702 may carry the instance identification information and the instance registration information of the started micro service instance in the test request and send the test request to the test server 704, so that the test server 704 tests the micro service instance.

If the elastic scaling server 702 receives the test passing message returned by the test server 704, the elastic scaling server 702 may send a request message for modifying the state to the online state to the service registration center 701, and modify the state of the micro-service instance to the online state.

If elastic scaling server 702 receives the test failure message returned by test server 704, elastic scaling server 702 may send a restart instruction to service server 703 to restart the micro-service instance.

The service server 703 is configured to start, delete, or restart the micro service instance according to an instruction of the elastic scaling server 702. Compared with the service server in the prior art shown in fig. 6, after the service server 703 in the embodiment of the present application receives the start instruction carrying the offline state parameter sent by the elastic scaling server 702 and starts a new micro service instance, the instance identification information of the micro service instance is carried in the registration request and sent to the micro service registration center 701, and the registration request carries the offline state parameter.

The test server 704 is configured to use a corresponding test case to test a corresponding micro-service instance according to the test request sent by the elastic scaling server 702.

It can be understood that the test server 704 stores in advance a test case corresponding to a micro service instance that can be started in the service server, and tests the micro service instance using the test case, that is, it is equivalent to simulating a user to call the micro service provided by the micro service instance. The test server 704 may continue to preset the call duration for testing the micro-service instance, and if the call is successful within the preset call duration, a test success message may be returned to the elastic scaling server 702. If the call cannot be successfully made within the set call duration, a test failure message may be returned to the elastic scaling server 702.

The micro-service elastic scaling method in the embodiment of the present application is specifically described below with reference to the micro-service elastic scaling system 700 shown in fig. 7.

Please refer to fig. 8, which is a flowchart illustrating a method for elastic expansion and contraction of microservice in an embodiment of the present application:

s801, the elastic scaling server 702 sends a first request carrying the offline state parameter to the service server 703;

it can be understood that the elastic scaling server 702 may monitor the state of the micro service instance running in the service server 703, and send a first request to the service server 703 according to a preset elastic scaling rule, where the first request carries the offline state parameter. The first request may be a launch instruction to instruct to launch the first microservice instance. The first micro service instance is used for providing a first micro service, the first micro service is a micro service which needs to be expanded according to a preset elastic expansion rule, and the first request may also carry a micro service identifier of the first micro service.

For example, if the preset elastic scaling rule indicates that when the operation load of the micro service instance corresponding to a certain micro service is higher than 80% and the duration exceeds the preset load duration, a new micro service instance needs to be started for the micro service. If the elastic scaling server monitors that the operation load of the micro-service instance corresponding to the service a in the service server 703 is higher than 80% and the duration exceeds the preset load duration, the elastic scaling server 702 sends a start instruction carrying the offline state parameter to the service server 703 according to the preset elastic scaling rule, where the start instruction also carries the micro-service identifier of the service a.

For another example, if the preset elastic scaling rule indicates that when the increase rate of the operation load of the micro-service instance corresponding to a certain micro-service exceeds 100% and the duration exceeds the preset increase, a new micro-service instance needs to be started for the micro-service. If the elastic scaling server monitors that the increase rate of the operation load of the micro-service instance corresponding to the service B in the service server 703 exceeds 100% and the duration exceeds the preset increase duration, the elastic scaling server 702 sends a start instruction carrying the offline state parameter to the service server 703 according to the preset elastic scaling rule, where the start instruction also carries the micro-service identifier of the service B.

It is to be understood that the above is only an exemplary description of the preset elastic stretch rule, and does not constitute a limitation on the preset elastic stretch rule. In practical application, the preset elastic expansion rule may be set according to a practical application scenario, and may be a single rule or a composite rule composed of a plurality of rules, which is not limited herein.

It can be understood that there are many ways for the online status parameter and the offline status parameter in the embodiment of the present application to be carried in the request message. For example, a value of a certain field in the request message may be used to indicate that, for example, there may be an optional status parameter field in the request message, if the value of the optional status parameter field is 1, it indicates that the request message carries an online status parameter, and if the value of the optional status parameter field is 0, it indicates that the request message carries an offline status parameter. For another example, the request message may be represented by carrying a specific character string, for example, if the request message carries an offline character string, it may represent that the request message carries an offline status parameter, and if the request message carries an online character string, it may represent that the request message carries an online status parameter, and the like. There may be many different ways to carry the online status parameter and the offline status parameter in the request message, which is not limited herein.

S802, the service server 703 starts a first micro service instance according to the first request to obtain first instance identification information;

it can be understood that, since the first request includes the micro-service identifier of the first micro-service, the first micro-service instance initiated by the service server 703 is used to provide the first micro-service.

The obtained first instance identification information is used for uniquely identifying the first microservice instance. The first instance identification information may specifically include: the first micro-service identification, the first micro-service instance identification number, the first micro-service instance starting time, the first micro-service instance version information and the like.

S803, the service server 703 sends a registration request carrying the offline state parameter to the service registration center 701;

it should be noted that, after the micro service instance is started, only one system supporting providing the micro service is started, but the other parties do not know the access address of the micro service instance. Therefore, the micro-service instance needs to be registered in the service registration center 701 to acquire information indicating the access address of the micro-service instance.

After the service server 703 obtains the first instance identification information, since the first request for starting the first micro service instance carries the offline state parameter, the registration request sent by the service server 703 to the service registration center 701 also carries the offline state parameter, so that the service registration center 701 registers the first micro service instance in the following line state. It is understood that the registration request is used to request that the first microservice instance be registered in the service registry 701, and therefore, the registration request further includes the first instance identification information.

S804, after the service registration center 701 receives the registration request carrying the offline state parameters, the first micro-service instance is registered but not released;

it is understood that the service registration center 701 can register the first micro-service instance because the registration request also contains the first instance identification information. Since the registration request carries the offline status parameter, the service registry 701 registers the first microservice instance in the following linear status mode: the first microservice instance is registered, but not published.

After the service registry 701 registers the first microservice instance, first instance registration information is obtained, where the first instance registration information is used to indicate an access address of the first microservice instance. The first instance registration information may specifically include: the URL address of the first micro-service instance, the machine room information deployed by the first micro-service instance, and the like.

S805, the service registration center 701 returns the first instance registration information to the service server 703;

it is understood that, since the service server sends the registration request to the service registration center 701, after the registration is completed, the service registration center 701 returns the first instance registration information to the service server 703, which indicates that the first microservice instance has been successfully registered.

S806, the service server 703 returns the first instance identification information and the first instance registration information to the elastic scaling server 702;

it can be understood that, since the elastic scaling server sends the first request for starting the first micro service instance to the service server, after the first micro service instance is started and registered, the service server 703 returns the first instance identification information obtained by starting the first micro service instance and the first instance registration information obtained by registering the first micro service instance to the elastic scaling server 702.

S807, the elastic expansion server 702 sends a second request for testing the first micro service instance to the test server 704;

in this embodiment, after the elastic scaling server 702 receives the first instance identification information and the first instance registration information returned by the service server 703, it may be determined that the first micro-service instance has been started and the registration in the following linear mode is completed. At this point, a second request to test the first microservice instance may be sent to the test server 704.

The second request may carry first instance identification information and first instance registration information, where the first instance identification information is carried to enable the test server 704 to determine a test case corresponding to the first micro service provided by the first micro service instance, and the first instance registration information is carried to enable the test server 704 to obtain an access address for accessing the first micro service instance.

S808, the test server 704 calls a first micro-service instance by using the first test case;

after receiving the second request for testing the first microservice instance sent by the elastic scaling server 702, the test server 704 uses the first test case to call the first microservice instance. The first test case is used for simulating the operation of calling the first micro service by the user.

It should be noted that the test server 704 stores many test cases, and each test case corresponds to a different microservice that the service server 703 can provide. The first instance identification information includes a first micro-service identification, so that the test server 704 can determine a first test case corresponding to the first instance identification information according to the first instance identification information included in the received second request.

As shown in table 1 below, which is an example of the corresponding relationship between the test case stored in the test server 704 and the micro service identifier:

micro-service identification	Test case
		First micro-service identifier	First test case
Second micro-service identifier	Second test case
		Third micro-service identification	Third test case

TABLE 1

It should be understood that this is only one example of the correspondence between the test cases and the microservice identifier, and in practical applications, the correspondence may also have many other expressions and storage manners, such as using arrays, functions, and the like, which is not limited herein.

It can be appreciated that since the micro-service instances in the business server all employ a lazy loading mechanism, the operation of the test server 704 to invoke the first micro-service instance using the first test case lasts for a period of time. The first time the test server 704 calls the first micro-service instance using the first test case triggers the loading of the service in the first micro-service instance, and the first micro-service instance cannot be called successfully directly. If the call is not successful, the test server 704 will use the first test case to make a retry call within a preset call duration. Until the first micro-service instance is successfully invoked using the first test case after the first micro-service instance completes the service loading, the test server 704 may confirm that the test was successful. If the calling cannot be successfully called within the preset calling duration, the calling failure can be determined. The test server 704 may feed back a test failure message to the elastic scaling server 702, so that the elastic scaling server 702 sends a restart instruction to the service server 703, and restarts the first micro-service instance to re-execute the above steps.

S809, the first micro service instance in the service server 703 completes service loading according to the call of the first test instance;

the calling of the first test case to the first micro-service instance triggers the first micro-service instance to complete the service loading for providing the first micro-service. After the service loading is completed, the call result is returned to the test server 704.

S810, the test server 704 confirms that the calling is successful;

it is to be appreciated that after the first micro-service instance completes the service load and returns the call result to the test server 704, the test server 704 may confirm that the call was successful.

Specifically, the test server 704 stores test cases of different microservices that can be provided by the corresponding service servers 703, and may also store preset calling results of the test cases. The test server 704 calls the micro-service instance by using a certain test case, and after receiving the call result sent by the service server, the call result can be compared with the preset call result of the used test case. If the calling result is the same as the preset calling result, the test server 704 may confirm that the test is successful; if the calling result is different from the preset calling result, the test server 704 may confirm that the test failed.

It is understood that the preset call result may be a value range, and the test server 704 may confirm that the test is successful as long as the call result returned by the service server is within the range of the preset call result, which is not limited herein.

For example, the test server 704 may store a preset calling result range of a first test case, and after the test server 704 uses the first test case to call the first micro service instance, the service server 703 may send a calling result of the first micro service instance. The test server 704 may compare the invocation result of the first micro service instance with the preset invocation result range of the first test case, and when it is determined that the invocation result of the first micro service instance is within the preset invocation result range of the first test case, the test server 704 may determine that the test on the first micro service instance is successful.

S811, the test server 704 feeds back a test success message to the elastic expansion server 702;

it can be understood that, since the elastic scaling server sends the second request for testing the first micro-service instance to the test server 704, after the test server 704 determines that the first micro-service instance corresponding to the second request is successfully invoked, a test success message is fed back to the elastic scaling server 702 to inform that the elastic scaling server 702 has successfully tested the micro-service instance.

S812, the elastic expansion server 702 sends a third request carrying the online state parameter to the service registration center 701;

after receiving the test success message fed back by the test server 704, the elastic scaling server 702 indicates that the first micro-service instance has been successfully tested, and can provide the first micro-service. Therefore, the elastic scaling server 702 sends a third request carrying the online status parameter to the service registry 701. The third request may be a state modification request for requesting modification of the state of the first microservice instance to an online state. It is to be understood that the third request may further include the first instance identification information.

Optionally, as another embodiment of the microservice elastic scaling method in the embodiment of the present application, in the above steps S811-S812, after confirming that the call is successful, the test server 704 sends a test success message to the elastic scaling server 702, and then the elastic scaling server 702 sends a third request to the service registration center 701. In practical applications, in some scenarios, after the test server 704 confirms that the call is successful, the test server may directly send a third request to the service registry 701, so as to modify the state of the first microservice instance to be an online state. And is not limited herein.

S813, broadcasting service online state information of the first micro service instance to the service caller 705 by the service registration center 701;

after receiving the third request carrying the online status parameter, the service registry 701 issues the first microservice instance in response to the third request. Specifically, the service hosting center 701 may broadcast the service presence status information of the first microservice instance to the service invoker 705. The service on-line status information of the first micro service instance may include a micro service identifier of the first micro service and first instance registration information.

The microservice identification of the first microservice is used to allow the service invoker 705 to determine the microservice provided by the first microservice instance. The first instance registration information is used to enable the service caller 705 to determine the access address of the first microservice instance.

S814, the service caller 705 distributes the request message to the micro service instance.

After receiving the service on-line status information of the first microservice instance, the service caller 705 updates the access address of the first microservice instance to the local routing table, and then sends a message to the first microservice instance according to the routing policy when the first microservice needs to be called.

In this embodiment, the first request sent by the flexible server 702 to the service server 703 carries the offline state parameter. After the service server 703 starts the first microservice instance according to the first request, the offline status parameter is also carried when the registration request is sent to the service registration center 701. Thus, the service registry 701 will register the first microservice instance in the down-line state, but not publish. After the flexible telescopic server 702 allows the test server 704 to test the first micro-service instance and determines that the test is successful, a third request carrying the online status parameter is sent to the service registration center 701. The service registry 701 will issue the first micro service instance after receiving the third request, and broadcast the service online status information of the first micro service instance to the service caller 705, so that the service caller 705 can access the first micro service instance. Therefore, when the service invoker 705 accesses the newly expanded first micro-service instance, the first micro-service instance can directly and normally provide the first micro-service, the situation that the service invocation failure rate is high due to a lazy loading mechanism does not occur any more, and the invocation success rate of the newly expanded micro-service instance through elastic expansion is greatly improved.

Compared with the prior art shown in fig. 6, in the method for elastic scaling of micro-service according to the embodiment of the present application, the first request for starting the first micro-service instance carries an offline state parameter. The offline state parameter is used for indicating that the micro-service instance is started in the following line state, the micro-service instance is subsequently on-line after the test, and the middle of the micro-service instance lasts for a period of time. Therefore, the timing of triggering the first request by the elastic scaling server 702 according to the preset elastic scaling rule in the embodiment of the present application may be earlier than the timing of triggering the start instruction in the prior art. That is, the preset elastic expansion rule used by the elastic expansion server 702 in the embodiment of the present application may be different from the preset elastic expansion rule used by the elastic expansion server in the prior art. In addition, in this embodiment, since the first request carries the offline status parameter, the registration request sent by the service server 703 to the service registration center 701 also carries the offline status parameter, so that the service registration center 701 may only register without issuing the first micro-service instance. Thus, after the first microservice instance is registered, the service caller 705 does not know that the first microservice instance providing the first microservice has started and does not access the first microservice instance. However, after receiving the registration request, the service registration center in the prior art directly registers and issues the micro-service instance, so that the service is accessed by the service caller when the service is not completely started, and the call success rate is low. In the embodiment of the present application, the first microservice instance is issued only after the service registration center 701 receives the third request carrying the online status parameter. And the third request is issued after the test server 704 successfully tests the first micro-service instance. Thus, the service in the first microservice instance published at this time is fully ready. After the micro-service instance is released, the micro-service instance can be directly and successfully accessed by a service calling party, and compared with the prior art, the calling success rate of the micro-service instance newly expanded through elastic expansion is greatly improved.

In the following, with reference to the micro-service elastic scaling method shown in fig. 8, taking an actual application scenario as an example, an exemplary description is performed on the micro-service elastic scaling method in the embodiment of the present application:

taking a game information application as an example, the game information application is composed of 3 micro-services:

user management for managing registration and login of users;

the news exhibition is used for providing latest game news for the user;

and the forum service is used for providing forum discussion service for the user.

During daily operation, the 3 microservices are respectively deployed with 1 microservice instance in the service server. The micro-service instance 1 in which the forum service is deployed can provide up to 10 ten thousand people simultaneously accessing the forum service online.

On a certain day, a new game is opened and the new game is exploded, more and more users inquire the strategy of the new game in forums and discuss the playing method of the new game with other users.

The elastic scaling server 701 monitors the operation status of the micro service instances in the service server. If the preset elastic expansion rules in the elastic expansion server 701 include: and if the load of the micro-service instance corresponding to a certain micro-service is higher than 70% and lasts for more than 30 minutes, starting a new micro-service instance for the micro-service.

If the elastic telescopic server 701 detects that the load of the micro-service instance 1 corresponding to the forum service is higher than 70% and lasts for more than 30 minutes, that is, more than 7 general users use the device to access the forum service for more than 30 minutes, the elastic telescopic rule is satisfied, and a new micro-service instance needs to be started for the forum service. Then, according to step S801 shown in fig. 8, the elastic scaling server 701 sends a first request carrying an offline state (offline) parameter and a forum service identifier to the service server 703.

According to step S802 shown in fig. 8, the service server 703 starts a new micro-service instance of the forum service according to the forum service identifier in the first request: microservice instance 2. And obtaining the instance identification information of the micro-service instance 2 of the forum service: forum service identification (forum service), identification number of micro service instance 2, IP of micro service instance 2, service listening port, version number of service (e.g. version 2.0), other service description information.

According to step S803 shown in fig. 8, since the first request carries the offline parameter, the service server 703 sends a registration request carrying the offline parameter and the instance identification information of the micro service instance 2 to the service registration center 701.

According to step S804 shown in fig. 8, after receiving the registration request carrying the offline parameter and the instance identification information of the microservice instance 2, the service registration center 701 registers the microservice instance 2 according to the instance identification information of the microservice instance 2 to obtain the instance registration information of the microservice instance 2: access address, interface number, response format, etc. of microservice instance 2. And since the registration request carries the offline parameter, the service registration center 701 does not publish the micro service instance 2 after registering the micro service instance 2 of the forum service.

According to step S805 shown in fig. 8, the service registration center 701 returns the instance registration information of the microservice instance 2 to the service server 703 to inform that the service area 703 has completed registration for the microservice instance 2.

According to step S806 shown in fig. 8, the service server has started the micro service instance 2 completing the forum service according to the first request of the flexible scaling server 702, and has completed the micro service instance 2 with the following status registration. Therefore, the service server 703 returns the instance identification information and the instance registration information of the microservice instance 2 to the elastic scaling server 702 to inform the elastic scaling server that the related matters have been completed.

According to step S807 shown in fig. 8, after determining that the micro service instance 2 of the forum service that needs to be expanded is started and registered in the offline state, the elastic scaling server 702 sends a second request carrying the instance identification information and the instance registration information of the micro service instance 2 to the test server 704 to test the micro service instance 2, so that the micro service instance 2 can normally provide the forum service.

According to step S808 shown in fig. 8, the test server 704 stores test cases for testing three microservices, namely, user management, news exhibition, and forum service. After receiving the third request, according to the instance identification information of the micro service instance 2 carried in the third request, the test server 704 may determine the test instance that needs to use the forum service in the test. According to the instance registration information carried in the third request, the test server 704 may determine the access address of the micro service instance 2 that needs to be tested this time. The test server 704 calls the micro service instance 2 by using the determined test case of the forum service and the access address of the micro service instance 2.

According to step S809 shown in fig. 8, the micro service instance 2 in the service server 703 loads resources and services related to the forum service according to the call of the test case of the forum service, and completes service loading, so as to normally provide the forum service.

According to step S810 shown in fig. 8, the test server 704 uses the test case calling micro-service instance 2 of the forum service to obtain the expected forum access feedback, and then confirms that the calling is successful.

According to step S811 shown in fig. 8, the test server 704 feeds back a test success message to the elastic scaling server 702, where the test success message may include the instance identification information of the micro service instance 2 to notify the elastic scaling server 702 that the test for the micro service instance 2 is successful.

According to step S812 shown in fig. 8, after the elastic scaling server 702 receives the test success message, it can confirm that the micro service instance 2 can normally provide forum services. Therefore, a third request carrying the online status parameter is sent to the service registry 701, and the third request further includes the instance identification information of the micro service instance 2, so that the service registry 701 can locate the micro service instance 2.

According to step S813 shown in fig. 8, the service registration center 701 broadcasts, to the service call 705, service presence status information of the micro service instance 2 of the forum service, where the service presence status information includes a forum service identifier (forum service) and instance registration information of the micro service instance 2.

According to step S814 shown in fig. 8, after receiving the service on-line status information of the micro service instance 2, the service caller 705 updates the access address information of the micro service instance 2 into the local routing table, and parallels the access address of the micro service instance 1 as a path for accessing the forum service. When the forum service needs to be accessed, the access message can be sent to the micro-service instance 2 according to the routing policy.

At this time, 2 micro-service instances are deployed in the service server 703: micro service instance 1 and micro service instance 2 to provide forum services. Up to 20 ten thousand people can be provided with simultaneous online access to the forum service. And the access request distributed to the newly expanded micro-service instance 2 can be normally accessed, and the problem of high service call failure rate caused by a lazy loading mechanism can be avoided.

The following describes an exemplary hardware structure of the service registration center 701, the elastic scaling server 702, the service server 703 and the test server 704 in the micro-service elastic scaling system:

fig. 9 is a schematic diagram of a hardware structure of a server 900 in the embodiment of the present application:

an input device 901, an output device 902, a processor 903 and a memory 904 (wherein the number of the processors 903 in the server 900 may be one or more, and one processor 903 is taken as an example in fig. 9). In some embodiments of the present application, the input device 901, the output device 902, the processor 903 and the memory 904 may be connected by a bus or other means, wherein the connection by the bus is exemplified in fig. 9. The processor 903 is configured to execute the micro-service elastic scaling method in the foregoing embodiment by calling the operation instruction stored in the memory 904.

It is understood that the hardware structures of the service registration center 701, the elastic scaling server 702, the service server 703 and the test server 704 in the micro-service elastic scaling system in the embodiment of the present application may be respectively the same as the hardware structure of the server 900.

Optionally, in this embodiment of the present application, the service registration center 701, the elastic scaling server 702, the service server 703, and the test server 704 may be obtained by combining a plurality of servers 900, may be deployed in different servers 900, or may be deployed in one or more servers 900 by combining with each other, which is not limited herein.

The above embodiments are only used for illustrating the technical solutions of the present application, and not for limiting the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; and the modifications or the substitutions do not make the essence of the corresponding technical solutions depart from the scope of the technical solutions of the embodiments of the present application.

As used in the above embodiments, the term "when …" may be interpreted to mean "if …" or "after …" or "in response to a determination of …" or "in response to a detection of …", depending on the context. Similarly, depending on the context, the phrase "at the time of determination …" or "if (a stated condition or event) is detected" may be interpreted to mean "if the determination …" or "in response to the determination …" or "upon detection (a stated condition or event)" or "in response to detection (a stated condition or event)".

In the above embodiments, the implementation may be wholly or partially realized by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When loaded and executed on a computer, cause the processes or functions described in accordance with the embodiments of the application to occur, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device. The computer instructions may be stored in a computer readable storage medium or transmitted from one computer readable storage medium to another, for example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by wire (e.g., coaxial cable, fiber optic, digital subscriber line) or wirelessly (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device, such as a server, a data center, etc., that incorporates one or more of the available media. The usable medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk), among others.

One of ordinary skill in the art will appreciate that all or part of the processes in the methods of the above embodiments may be implemented by hardware related to instructions of a computer program, which may be stored in a computer-readable storage medium, and when executed, may include the processes of the above method embodiments. And the aforementioned storage medium includes: various media capable of storing program codes, such as ROM or RAM, magnetic or optical disks, etc.

Claims

1. A micro-service elastic stretching method is applied to a micro-service elastic stretching system, and is characterized in that the micro-service elastic stretching system comprises: the system comprises an elastic telescopic server, a service registration center, a service server and a test server; the microservice elastic expansion method comprises the following steps:

the elastic expansion server sends a first request for starting a first micro service instance to the service server, wherein the first request carries offline state parameters; the first micro-service instance is used for providing a first micro-service;

the business server starts the first micro service instance according to the first request and sends a registration request carrying the offline state parameter to the service registration center;

the service registration center responds to the registration request and registers but does not issue the first micro service instance according to the offline state parameter;

after receiving the registration information of the first micro service instance sent by the service server, the elastic telescopic server sends a second request for testing the first micro service instance to the test server;

the test server confirms that the test is successful according to the second request;

the service registration center receives a third request sent by the test server or the elastic telescopic server, wherein the third request carries an online state parameter;

and the service registration center responds to the third request and issues the first micro service instance according to the online state parameter.

2. The method of claim 1, further comprising:

the test server sends the third request to the service registry.

3. The method of claim 1, further comprising:

and after the elastic scaling server receives a test success message sent by the test server, the elastic scaling server sends the third request to the service registration center.

4. The method according to any one of claims 1 to 3, wherein the step of the test server confirming the success of the test according to the second request specifically comprises:

in response to the second request, the test server calls the first microservice instance using a first test case; the first test case is a test case corresponding to the first micro service;

the test server receives a calling result of a first micro-service instance sent by the business server;

and when the calling result of the first micro service instance is the same as the preset calling result of the first test case, the test server confirms that the test is successful.

5. The method according to any one of claims 1 to 4, wherein the second request includes registration information of the first microservice instance, and the registration information of the first microservice instance includes an access address of the first microservice instance.

6. The method according to any one of claims 1 to 5, wherein the offline status parameter is a first preset value in a preset field of the request message, and the online status parameter is a second preset value in the preset field of the request message, and the second preset value is different from the first preset value.

7. The method according to any one of claims 1 to 5, wherein the offline state parameter is a first preset character string carried in the request message; the online state parameter is a second preset character string carried in the request message, and the second preset character string is different from the first preset character string.

8. A method for elastic expansion and contraction of micro-service is characterized by comprising the following steps:

sending a first request for starting a first micro service instance to a business server, wherein the first request carries an offline state parameter and is used for indicating that the first micro service instance is registered in a service registration center but not issued after being started by the business server; the first micro-service instance is used for providing a first micro-service;

receiving registration information of the first micro service instance sent by the business server;

and sending a second request for testing the first micro-service instance to a testing server, wherein the first micro-service instance is issued in a service registry after the testing server tests successfully.

9. The method of claim 8, further comprising:

receiving a test success message sent by the test server;

and responding to the test success message, and sending a third request to the service registry, wherein the third request is used for indicating the issuance of the first micro-service instance.

10. The method of claim 8 or 9, wherein prior to the step of sending the first request to initiate the first microservice instance to the traffic server, the method further comprises:

monitoring the running state of the micro-service instance in the service server;

and determining that the running state of the micro service instance of the first micro service meets the condition of expanding the micro service instance of the new first micro service in a preset elastic scaling rule.

11. The method according to any one of claims 8 to 10, wherein the second request includes registration information of the first microservice instance, and the registration information of the first microservice instance includes an access address of the first microservice instance.

12. The method according to any one of claims 8 to 11, wherein the offline status parameter is a first preset value in a preset field of the request message, and the online status parameter is a second preset value in the preset field of the request message, and the second preset value is different from the first preset value.

13. The method according to any one of claims 8 to 11, wherein the offline status parameter is a first preset character string carried in the request message; the online state parameter is a second preset character string carried in the request message, and the second preset character string is different from the first preset character string.

14. A method for elastic expansion and contraction of micro-service is characterized by comprising the following steps:

receiving a registration request for registering a first micro-service instance sent by a business server, wherein the registration request carries an offline state parameter and is used for registering but not issuing the first micro-service instance; the first micro-service instance is used for providing a first micro-service;

responding the registration request, and registering but not issuing the first micro service instance according to the offline state parameter;

returning the registration information of the first micro service instance to the business server;

receiving a third request carrying an online state parameter;

responding to the third request, and issuing the first micro service instance according to the online state parameter.

15. The method according to claim 14, wherein the receiving of the third request carrying the uplink state parameter specifically includes:

and receiving the third request sent by the test server.

16. The method according to claim 14, wherein the receiving of the third request carrying the uplink state parameter specifically includes:

and receiving the third request sent by the elastic scaling server.

17. The method according to any one of claims 14 to 16, wherein the offline status parameter is a first preset value in a preset field of the request message, and the online status parameter is a second preset value in the preset field of the request message, and the second preset value is different from the first preset value.

18. The method according to any one of claims 14 to 16, wherein the offline status parameter is a first preset character string carried in the request message; the online state parameter is a second preset character string carried in the request message, and the second preset character string is different from the first preset character string.

19. A method for elastic expansion and contraction of micro-service is characterized by comprising the following steps:

receiving a first request for starting a first micro service instance sent by an elastic telescopic server, wherein the first request carries offline state parameters; the first micro-service instance is used for providing a first micro-service;

starting the first micro service instance according to the first request;

sending a registration request carrying an offline state parameter to a service registration center for registering in the service registration center but not issuing the first micro-service instance;

and sending the registration information of the first micro service instance to the elastic scaling server, wherein the registration information is used for issuing the first micro service instance in a service registration center after the elastic scaling server requests the test server to test the first micro service instance successfully.

20. The method of claim 19, further comprising:

receiving a call of the test server to the first micro-service instance by using a first test case, and completing service loading for the first micro-service instance, wherein the first test case is a test case corresponding to a first micro-service;

and sending the calling result of the first micro service instance to the test server so that the test server can confirm that the test is successful.

21. The method of claim 19 or 20, wherein the registration information of the first microservice instance comprises an access address of the first microservice instance.

22. The method according to any of claims 19 to 21, wherein the down status parameter is a first preset value in a preset field of a request message.

23. The method according to any one of claims 19 to 21, wherein the down status parameter is a first predetermined string carried in the request message.

24. A microservice elastic telescoping system, comprising:

the system comprises an elastic telescopic server, a service registration center, a service server and a test server;

the elastic telescopic server is used for sending a first request for starting a first micro-service instance to the service server, wherein the first request carries offline state parameters; the first micro-service instance is used for providing a first micro-service; after receiving the registration information of the first micro service instance sent by the business server, sending a second request for testing the first micro service instance to the test server;

the business server is used for starting the first micro service instance according to the first request and sending a registration request carrying the offline state parameter to the service registration center;

the service registration center is used for responding to the registration request and registering but not issuing the first micro service instance according to the offline state parameter; after receiving a third request carrying an online state parameter sent by the test server or the elastic telescopic server, responding to the third request, and issuing the first micro service instance according to the online state parameter;

and the test server is used for confirming the success of the test according to the second request.

25. The microservice elastic scaling system of claim 24, wherein the test server is further configured to send the third request to the elastic scaling server upon confirmation of successful testing.

26. The microservice elastic scaling system of claim 24, wherein the test server is further configured to send a test success message to the elastic scaling server upon confirmation of a successful test;

the flexible telescopic server is further configured to send the third request to the service registration center after receiving the test success message sent by the test server.

27. The microservice elastic scaling system according to any of the claims 24 to 26, wherein the test server is specifically configured to invoke the first microservice instance using a first test case in response to the second request; the first test case is a test case corresponding to the first micro service; receiving a calling result of a first micro-service instance sent by the business server; and when the calling result of the first micro service instance is the same as the preset calling result of the first test case, confirming that the test is successful.

28. The microservice elastic scaling system according to any of the claims 24 to 27, wherein the second request comprises registration information of the first microservice instance, and the registration information of the first microservice instance comprises an access address of the first microservice instance.

29. The microservice elastic telescopic system according to any of the claims 24 to 28, wherein the down status parameter is a first preset value in a preset field of the request message and the up status parameter is a second preset value in a preset field of the request message, the second preset value being different from the first preset value.

30. The microservice elastic telescopic system according to any one of claims 24 to 28, wherein the offline status parameter is a first predetermined string carried in a request message; the online state parameter is a second preset character string carried in the request message, and the second preset character string is different from the first preset character string.

31. An elastic scaling server, characterized in that the elastic scaling server comprises:

one or more processors and memory;

the memory coupled with the one or more processors, the memory for storing computer program code, the computer program code comprising computer instructions, the one or more processors invoking the computer instructions to cause the elastic scaling server to perform the method of any of claims 8-13.

32. A service registry, the service registry comprising:

one or more processors and memory;

the memory coupled with the one or more processors, the memory for storing computer program code, the computer program code comprising computer instructions, which the one or more processors invoke to cause the service registry to perform the method of any of claims 14-18.

33. A service server, characterized in that the service server comprises:

one or more processors and memory;

the memory coupled with the one or more processors, the memory for storing computer program code, the computer program code comprising computer instructions, which the one or more processors invoke to cause the service registry to perform the method of any of claims 19-23.

34. A chip system applied to a resilient scaling server, the chip system comprising one or more processors for invoking computer instructions to cause the resilient scaling server to perform the method of any one of claims 8-13.

35. A computer program product comprising instructions for causing a resilient scaling server to perform the method according to any one of claims 8-13 when the computer program product is run on the resilient scaling server.

36. A computer-readable storage medium comprising instructions that, when executed on a resilient scaling server, cause the resilient scaling server to perform the method of any of claims 8-13.

37. A chip system for application in a service registry, the chip system comprising one or more processors for invoking computer instructions to cause the service registry to perform the method of any of claims 14-18.

38. A computer program product comprising instructions for causing a service registry to perform the method of any one of claims 14-18 when the computer program product is run on the service registry.

39. A computer-readable storage medium comprising instructions that, when executed on a service registry, cause the service registry to perform the method of any one of claims 14-18.

40. A chip system for application to a business server, the chip system comprising one or more processors for invoking computer instructions to cause the business server to perform the method of any one of claims 19-23.

41. A computer program product comprising instructions for causing a service server to perform the method according to any one of claims 19-23 when the computer program product is run on the service server.

42. A computer-readable storage medium comprising instructions that, when executed on a service server, cause the service server to perform the method of any of claims 19-23.