CN112449005A - Request distribution method and device, electronic equipment and readable storage medium - Google Patents

Request distribution method and device, electronic equipment and readable storage medium Download PDF

Info

Publication number
CN112449005A
CN112449005A CN202011256720.6A CN202011256720A CN112449005A CN 112449005 A CN112449005 A CN 112449005A CN 202011256720 A CN202011256720 A CN 202011256720A CN 112449005 A CN112449005 A CN 112449005A
Authority
CN
China
Prior art keywords
instance
service
target service
preheating
weight value
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202011256720.6A
Other languages
Chinese (zh)
Other versions
CN112449005B (en
Inventor
周世伟
史海洋
杨茗凯
夏露
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Absolute Health Ltd
Original Assignee
Beijing Absolute Health Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Absolute Health Ltd filed Critical Beijing Absolute Health Ltd
Priority to CN202011256720.6A priority Critical patent/CN112449005B/en
Publication of CN112449005A publication Critical patent/CN112449005A/en
Application granted granted Critical
Publication of CN112449005B publication Critical patent/CN112449005B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/60Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63Routing a service request depending on the request content or context
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/60Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/62Establishing a time schedule for servicing the requests

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Stored Programmes (AREA)

Abstract

The invention discloses a request distribution method, a request distribution device, electronic equipment and a readable storage medium, and relates to the technical field of Internet. The method comprises the following steps: acquiring a preheating parameter of a target service to be started; monitoring a service interface, recording the starting time of a target service instance, wherein the target service instance is any one of a plurality of service instances and is registered in the service interface after the starting is finished; when the preheating parameter indicates to preheat the target service instance, determining the current time, and calculating an instance weight value according to the preheating period, the current time and the starting time; and distributing the received user request to the target service instance according to the instance weight value.

Description

Request distribution method and device, electronic equipment and readable storage medium
Technical Field
The present invention relates to the field of internet technologies, and in particular, to a request distribution method and apparatus, an electronic device, and a readable storage medium.
Background
With the rapid development of internet technology, user demands change frequently, and micro-services are produced in order to meet the demands of users in the aspects of design, development, maintenance and the like. The micro-service is a high-cohesion low-coupling system architecture, and the application is divided into a group of micro-services with single functions and independent deployment, and the micro-services are cooperatively matched with each other through a lightweight communication mechanism to realize agile development and deployment. At present, integrated management is usually implemented on a micro service construction service grid, in the service grid, some service instances of the micro service need to enter a complete service state asymptotically according to service starting time after being started, and for such service instances, when a request of a user is allocated to the service instances, asymptotically increasing and gradually reaching a full state are also needed.
In the related art, when a request of a user is allocated to a service instance, the service grid assigns the same access weight to all available service instances by default, the access weight usually takes a value of 1, and the access weight may vary. The service grid will distribute requests for service instances as indicated by the access weights until it is determined that the service instances enter a full service state based on the access weights.
However, the inventors have recognized that at least the following technical problems exist in the related art described above:
the access weights given by the service grid to all available service instances are the same, but the service capacity of each service instance is different, so that it is very likely that when the service grid determines that the service instance enters the full service state according to the access weights, the service instance does not really enter the full service state, the load of the service instance is too heavy, the stability of the service instance is affected, and the user request has the risk of processing failure.
Disclosure of Invention
In view of this, the present application provides a request distribution method, an apparatus, an electronic device and a readable storage medium, and mainly aims to solve the problems that the current service instance is overloaded, the stability of the service instance is affected, and the user request has a risk of processing failure.
According to a first aspect of the present invention, there is provided a request allocation method, the method comprising:
acquiring a preheating parameter of a target service to be started, wherein the preheating parameter indicates whether a plurality of service instances included in the target service are preheated or not and a preheating period and a preheating step length of the target service;
monitoring a service interface, recording the starting time of a target service instance, wherein the target service instance is any one of the plurality of service instances and is registered in the service interface after the starting is finished;
when the preheating parameter indicates to preheat the target service instance, determining the current time, and calculating an instance weight value according to the preheating period, the current time and the starting time;
and distributing the received user request according to the example weight value.
In another embodiment, after the listening service interface records the start time of the target service instance, the method further includes:
when the preheating parameter does not indicate preheating of the target service instance, determining standard request flow;
and distributing the received user request to the target service instance according to the standard request flow.
In another embodiment, said calculating an instance weight value based on said warm-up period, said current time, and said start-up time comprises:
calculating a difference value between the current time and the starting time, and generating a value group comprising the difference value and the preheating period;
determining a target value as the instance weight value among the set of values, the target value being the smallest of the difference and the warm-up period.
In another embodiment, after the allocating the received user request to the target service instance according to the instance weight value, the method further includes:
reading a plurality of instance weight values corresponding to the plurality of service instances;
when detecting that a first designated instance weight value smaller than the preheating period exists in the plurality of instance weight values, determining a first designated service instance corresponding to the first designated instance weight value;
setting a timing task according to the preheating step length;
according to the timing task, recalculating an instance weight value for the first specified service instance based on the current time, the preheating period and the starting time of the first specified service instance at regular time, and allocating a user request to the first specified service instance according to the recalculated instance weight value.
In another embodiment, the method further comprises:
and when the calculated instance weight value of the first appointed service instance is larger than or equal to the preheating period, determining that the first appointed service instance is completely preheated, and stopping the timing task.
In another embodiment, after the setting of the timing task according to the preheating step, the method further includes:
updating the last starting time of the target service to be the starting time of the target service instance;
associating the last start time with the timed task;
and continuously monitoring the service interface, and updating the last starting time by adopting the starting time of other service instances and associating the last starting time with the timing task when monitoring that other service instances are registered in the service interface.
In another embodiment, the method further comprises:
when detecting that a second specified instance weight value smaller than the preheating period exists in a plurality of instance weight values of the plurality of service instances, reading the last starting time, and determining an actual last starting time in the plurality of starting times of the plurality of service instances, wherein the time interval between the actual last starting time and the current time is smaller than the time interval between the other starting times except the actual last starting time and the current time in the plurality of starting times;
and if the time interval between the value of the last starting time and the current time is larger than the time interval between the actual last starting time and the current time, determining that the timing task is triggered, and periodically recalculating an instance weight value for a second designated service instance corresponding to the second designated instance weight value based on the timing task.
According to a second aspect of the present invention, there is provided a request distribution apparatus, comprising:
the system comprises an acquisition module, a pre-heating module and a control module, wherein the acquisition module is used for acquiring a pre-heating parameter of a target service to be started, and the pre-heating parameter indicates whether a plurality of service instances included in the target service are pre-heated or not and a pre-heating period and a pre-heating step length of the target service;
the monitoring module is used for monitoring a service interface and recording the starting time of a target service instance, wherein the target service instance is any one of the plurality of service instances and is registered in the service interface after the starting is finished;
the calculation module is used for determining the current time when the preheating parameter indicates that the target service instance is preheated, and calculating an instance weight value according to the preheating period, the current time and the starting time;
and the distribution module is used for distributing the received user request to the target service instance according to the instance weight value.
In another embodiment, the apparatus further comprises:
a first determining module, configured to determine a standard request traffic when the warming parameter does not indicate warming of the target service instance;
the distribution module is further configured to distribute the received user request to the target service instance according to the standard request traffic.
In another embodiment, the calculating module is configured to calculate a difference between the current time and the starting time, and generate a set of values including the difference and the preheating period; determining a target value as the instance weight value among the set of values, the target value being the smallest of the difference and the warm-up period.
In another embodiment, the apparatus further comprises:
the reading module is used for reading a plurality of instance weight values corresponding to the plurality of service instances;
a second determining module, configured to determine, when it is detected that a first specified instance weight value smaller than the warm-up period exists in the plurality of instance weight values, a first specified service instance corresponding to the first specified instance weight value;
the setting module is used for setting a timing task according to the preheating step length;
the allocation module is configured to, according to the timing task, periodically recalculate an instance weight value for the first specified service instance based on the current time, the preheating period, and the start time of the first specified service instance, and allocate a user request to the first specified service instance according to the recalculated instance weight value.
In another embodiment, the apparatus further comprises:
and the stopping module is used for determining that the first appointed service instance is completely preheated when the calculated instance weight value of the first appointed service instance is larger than or equal to the preheating period, and stopping the timing task.
In another embodiment, the apparatus further comprises:
the updating module is used for updating the last starting time of the target service into the starting time of the target service instance;
an association module for associating the last start time with the timed task;
and the updating module is further configured to continuously monitor the service interface, and when it is monitored that other service instances are registered in the service interface, update the last start time by using the start times of the other service instances and associate the last start time with the timed task.
In another embodiment, the reading module is further configured to read the last start time when detecting that a second specified instance weight value smaller than the pre-heating period exists in a plurality of instance weight values of the plurality of service instances, determine an actual last start time among the plurality of start times of the plurality of service instances, where a time interval between the actual last start time and a current time is smaller than a time interval between other start times except the actual last start time and the current time among the plurality of start times;
the allocation module is further configured to determine that the timing task is triggered if a time interval between the last start time and the current time is greater than a time interval between the actual last start time and the current time, and periodically recalculate an instance weight value for a second specified service instance corresponding to the second specified instance weight value based on the timing task.
According to a third aspect of the present invention, there is provided an electronic device comprising a memory and a processor, the memory storing a computer program, the processor implementing the steps of the method of the first aspect when executing the computer program.
According to a fourth aspect of the present invention, there is provided a readable storage medium having stored thereon a computer program which, when executed by a processor, carries out the steps of the method of the first aspect as set forth above.
By means of the technical scheme, according to the starting time of the successfully started target service instance and the preheating parameters including whether the plurality of service instances are preheated and the preheating period and the preheating step length of the target service, which are set by the target service where the target service instance is located, the instance weight value of the target service instance is dynamically calculated, the request of the user is distributed to the service instance according to the dynamically set instance weight, so that the service instance can gradually enter the full-scale working state through the buffer period, overload of the service instance is avoided, the request of the user to the service can be effectively responded and processed, and the robustness and the stability of the service are improved.
The foregoing description is only an overview of the technical solutions of the present application, and in order to make the technical means of the present application more clearly understood, the technical solutions of the present invention can be implemented according to the content of the description, and in order to make the above and other objects, features, and advantages of the present application more clearly understood, the technical solutions of the present invention are further described in detail below with reference to the accompanying drawings and examples.
Drawings
Various other advantages and benefits will become apparent to those of ordinary skill in the art upon reading the following detailed description of the preferred embodiments. The drawings are only for purposes of illustrating the preferred embodiments and are not to be construed as limiting the application. Also, like reference numerals are used to refer to like parts throughout the drawings. In the drawings:
fig. 1 is a schematic flowchart illustrating a request distribution method according to an embodiment of the present application;
fig. 2A is a schematic flowchart illustrating a request distribution method according to an embodiment of the present application;
fig. 2B is a schematic flowchart illustrating a request distribution method according to an embodiment of the present application;
fig. 3A is a schematic structural diagram illustrating a request distribution apparatus according to an embodiment of the present application;
fig. 3B is a schematic structural diagram illustrating a request distribution apparatus according to an embodiment of the present application;
fig. 3C is a schematic structural diagram illustrating a request distribution apparatus according to an embodiment of the present application;
fig. 3D is a schematic structural diagram illustrating a request distribution apparatus according to an embodiment of the present application;
fig. 3E shows a schematic structural diagram of a request distribution device according to an embodiment of the present application.
Detailed Description
Various exemplary embodiments of the present invention will now be described in detail with reference to the accompanying drawings. It should be noted that: the relative arrangement of the components and steps, the numerical expressions and numerical values set forth in these embodiments do not limit the scope of the present invention unless specifically stated otherwise.
An embodiment of the present invention provides a request allocation method, as shown in fig. 1, the method includes:
101. the method comprises the steps of obtaining a preheating parameter of a target service to be started, wherein the preheating parameter indicates whether a plurality of service instances included in the target service are preheated or not, and a preheating period and a preheating step length of the target service.
102. And monitoring the service interface, and recording the starting time of the target service instance, wherein the target service instance is any one of the plurality of service instances and is registered in the service interface after the starting is completed.
103. When the preheating parameter indicates to preheat the target service instance, determining the current time, and calculating an instance weight value according to the preheating period, the current time and the starting time.
104. And distributing the received user request to the target service instance according to the instance weight value.
The method provided by the embodiment of the invention dynamically calculates the instance weight value of the target service instance according to the starting time of the successfully started target service instance and the preheating parameters which are set by the target service where the target service instance is located and comprise the preheating period and the preheating step length of the target service and whether the plurality of service instances are preheated or not, and the preheating period and the preheating step length of the target service, and distributes the user request to the service instance according to the dynamically set instance weight, so that the service instance can gradually enter the full working state through the buffer period, the overload of the service instance is avoided, the user request for the service can be effectively responded and processed, and the robustness and the stability of the service are improved.
An embodiment of the present invention provides a task issuing method, as shown in fig. 2A, the method includes:
201. and acquiring the preheating parameters of the target service to be started.
In recent years, a service grid constructed for micro services is generally an isotope (service grid constructed for micro services) service grid, in a micro service cluster environment based on the isotope service grid, after a service instance of some micro services is started, a complete service state needs to be gradually entered according to service starting time, for such a service instance, when a user requests to be allocated, the service instance also needs to be gradually increased progressively and gradually reach a full state, which is also a process of preheating the service. Currently, when the service grid provides the warm-up operation, all available service instances are given the same access weight by default, the access weight is usually 1, and the access weight may be changed. The service grid will distribute requests to the service instances as indicated by the access weights until it is determined that the service instances enter a full service state based on the access weights. However, the inventor recognizes that the access weights given by the service grid to all available service instances are the same, but the service capabilities of each service instance are different, and it is very likely that when the service grid determines that the service instance enters the full service state according to the access weights, the service instance does not really enter the full service state, which may cause the overload of the service instance, affect the stability of the service instance, and risk the processing failure of the task. Moreover, the service instance has strong capability, and if the service instance is limited, a large number of user requests may fail within a period of time after the service instance is started, which affects the stability of the service. Therefore, the invention provides a request distribution method, which dynamically calculates the instance weight value of the target service instance according to the starting time of the successfully started target service instance and the preheating parameters which are set by the target service where the target service instance is located and comprise whether the plurality of service instances are preheated and the preheating period and the preheating step length of the target service, realizes the gradual dynamic weighting of the service instance, and further distributes the request to the service instance according to the dynamically set instance weight, so that the service instance can gradually enter the full working state through the buffer period, the request of the user to the service can be ensured to be effectively responded and processed, and the robustness and the stability of the service are improved.
In order to implement the request allocation method of the present invention, first, a preheating parameter of a target service to be started needs to be acquired. The warm-up parameter indicates whether a plurality of service instances included in the target service are warmed up and a warm-up period and a warm-up step size of the target service. The general preheating period is default to 90 seconds, the preheating step length is default to 5 seconds, the content included by the preheating parameters can be changed along with different preheating scenes, different services, different user amounts and the like, and even the preheating parameters of each service can be dynamically adjusted according to historical statistical data of each service in the service cluster, so that the overall service and service elasticity of the service cluster is improved. The specific contents of the preheating parameters are not limited in the present invention. After obtaining the preheating parameter of the target service, the service grid can execute the preheating operation of the service instance in the target service according to the indication of the preheating parameter. In addition, a warm-up procedure may be provided in the service grid to support control at the service granularity as to whether warm-up is to be initiated for a particular service or service instance.
202. Monitoring a service interface, recording the starting time of a target service instance, and executing the following processes from step 203 to step 206 when a preheating parameter indicates that the target service instance is preheated; when the warm-up parameter does not indicate warm-up of the target service instance, the process in step 207, described below, is performed.
In the embodiment of the present invention, after the service instances in the service are started, the start state of the service instances is registered in the service interface, and the service interface may specifically be a K8S API Server (an interface service), so that the service grid may monitor the service interface to determine which service instances have been started, further preheat the service instances with preheating requirements, and dynamically calculate instance weight values for the service instances. Specifically, the service grid listens to the service interface and records the start time of a target service instance, which is any one of the plurality of service instances and is registered in the service interface after the start is completed. That is, when the target service instance is found by the service grid to be a newly started service instance, the service grid records the target service instance and also records the starting time of the target service instance. The service grid then queries the obtained warm-up parameters for the need to warm up the target service instance. When the preheating parameter indicates to preheat the target service instance, it is determined that the target service instance needs to be preheated, and the instance weight needs to be dynamically calculated for the target service instance, that is, the following processes in steps 203 to 207 are performed. When the preheating parameter does not indicate to preheat the target service instance, it is determined that the target service instance does not need to be preheated, and the user request is directly allocated to the target service instance according to the normal standard, that is, the following process in step 207 is executed.
203. When the preheating parameter indicates to preheat the target service instance, determining the current time, and calculating an instance weight value according to the preheating period, the current time and the starting time.
In the embodiment of the present invention, when the preheating parameter indicates to preheat the target service instance, it is determined that the target service instance needs to be preheated, and the instance weight needs to be dynamically calculated for the target service instance, and calculating the instance weight of the target service instance at the current time needs to depend on the current time, the preheating period, and the starting time, so that the service grid determines the current time, and calculates the instance weight value according to the preheating period, the current time, and the starting time, where a process of specifically calculating the instance weight value is as follows:
first, the difference between the current time and the start-up time is calculated, and a value group including the difference and the preheating period is generated. Then, a target value, which is the smallest one of the difference and the warm-up period, is determined as an example weight value among the group of values. That is, the difference between the current time and the start time is calculated, the difference and the minimum value in the preheating period are used as example weight values, the calculation process can be specifically represented by formula 1, and "min" in formula 1 is used to determine the difference and the minimum value in the preheating period:
equation 1: example weight value min (current time-start time, preheat cycle)
204. And distributing the received user request to the target service instance according to the instance weight value.
In the embodiment of the present invention, when the calculation of the instance weight value is completed, the received user request may be initially distributed to the target service instance. Specifically, in the actual application process, the service grid will issue the target service instance and the instance weight value together to all the issue-Proxy (Proxy service of grid) agents in the cluster, and at this time, each agent will distribute the request traffic among the service instances according to the instance weight value. It should be noted that, it is very likely that the service grid will detect that a plurality of target service instances are started at the same time and calculate the instance weight values of the plurality of target service instances at the same time, and then the service grid may issue all target service instances and the instance weight values corresponding to the target service instances to the issue-Proxy.
205. Reading a plurality of instance weight values corresponding to a plurality of service instances, determining a first designated service instance corresponding to a first designated instance weight value when a first designated instance weight value smaller than a preheating period exists in the plurality of instance weight values, setting a timing task according to a preheating step length, recalculating the instance weight value for the first designated service instance according to the timing task and timing based on the current time, the preheating period and the starting time of the first designated service instance, and allocating a user request to the first designated service instance according to the recalculated instance weight value.
In the embodiment of the present invention, since the instance weight value of each service instance is dynamically calculated, the start time is different, and the change of the current time will result in the change of the instance weight value, and if the instance weight values of some service instances reach the preheating period set in the preheating parameter, it indicates that the preheating process of the service instance has ended. Therefore, the service grid reads a plurality of instance weight values corresponding to a plurality of service instances, and inquires whether a first specified instance weight value smaller than the preheating period exists in the plurality of instance weight values. And when detecting that a first designated instance weight value smaller than the preheating period exists in the plurality of instance weight values, indicating that the first designated service instance corresponding to the first designated instance weight value is still in the preheating state and needs to be dynamically calculated for the instance weight value, therefore, the service grid sets a timing task according to the preheating step length, calculates the instance weight value for the first designated service instance according to the timing task based on the current time, the preheating period and the starting time of the first designated service instance, and allocates a user request to the first designated service instance according to the recalculated instance weight value until the instance weight value of the first designated service instance reaches the preheating period.
206. And when the calculated instance weight value of the first appointed service instance is larger than or equal to the preheating period, determining that the first appointed service instance is completely preheated, and stopping the timing task.
In the embodiment of the present invention, the step 205 calculates the instance weight value for the first specified service instance based on the timing task. And when the calculated instance weight value of the first specified service instance is larger than or equal to the preheating period, the first specified service instance can be determined to be completely preheated, and the timing task is stopped.
In addition, when a service contains multiple service instances and these service instances enter the startup state in succession in a short time (which usually occurs in the service deployment phase), the same service is caused to frequently calculate and issue instance weight values due to the variation of multiple service instances. For example, for a service containing 30 service instances, a warm-up period of 90s, a start-up period of 5s step size, and in the extreme case up to 30 × (90 ÷ 5) × 540 calculations and deliveries may be made within 90 s. Therefore, in the embodiment of the present application, after a certain service instance is started, the service grid will synchronously update the last start time of the service where the service instance is located, and update the last start time of the target service to the start time of the target service instance. The service grid then associates the last start time with the timed task. Further, the service grid will continuously monitor the service interface, and when it is monitored that there are other service instances registered in the service interface, the last start time is updated by using the start times of the other service instances and associated with the timing task, thereby ensuring that the last start time is the largest one of the start times of the service instances.
Thus, after the association between the timing task and the last start time is completed, the service grid checks the last start time associated with the current timing task before customizing the new timing task and calculating the service weight whenever the timing task needs to be established. That is, when the service grid detects that a second specified instance weight value smaller than the preheating period exists in the instance weight values of the service instances, it is determined that the timed task needs to be executed, and therefore, the last start time is read, and the actual last start time is determined in the start times of the service instances, and the time interval between the actual last start time and the current time is smaller than the time interval between the other start times except the actual last start time in the start times and the current time, that is, the latest start time. And if the time interval between the value of the last starting time and the current time is larger than the time interval between the actual last starting time and the current time, namely the last service starting time is earlier than the actual last service starting time, determining that the timing task is triggered, and based on the timing task, recalculating the instance weight value for the second designated service instance corresponding to the second designated instance weight value at the timing, and canceling the customization of the current new timing task. By the method, the instance weight value is uniformly sent at the same time for the same service no matter how many service instances are changed in the instance weight value, and the sending interval is not less than the preset step length. Redundant calculation and issuing can be eliminated under the operation, and calculation and communication expenses caused by frequent calculation and configuration issuing are reduced.
207. And when the preheating parameter does not indicate that the target service instance is preheated, determining standard request flow, and distributing the received user request to the target service instance according to the standard request flow.
In the embodiment of the invention, when the preheating parameter does not indicate to preheat the target service instance, the target service instance is determined not to be preheated, and the task is directly issued to the target service instance and the flow is distributed according to the normal standard. Thus, the service grid determines a standard request traffic and distributes the received user request to the target service instance according to the standard request traffic.
In summary, the whole request allocation process in the embodiment of the present invention is as follows:
referring to fig. 2B, B1, B2, and B3 are service instances, and after booting, B1, B2, and B3 register their boot states in the K8S API Server. The service grid Istio monitors the K8S API Server, periodically calculates an instance weight value for the started service instance, simultaneously issues the service instance and the instance weight value to an Istio-Proxy agent, and distributes a user request for the service instance by the Proxy agent according to the instance weight value.
The method provided by the embodiment of the invention dynamically calculates the instance weight value of the target service instance according to the starting time of the successfully started target service instance and the preheating parameters which are set by the target service where the target service instance is located and comprise the preheating period and the preheating step length of the target service and whether the plurality of service instances are preheated or not, and the preheating period and the preheating step length of the target service, and distributes the user request to the service instance according to the dynamically set instance weight, so that the service instance can gradually enter the full working state through the buffer period, the overload of the service instance is avoided, the user request for the service can be effectively responded and processed, and the robustness and the stability of the service are improved.
Further, as a specific implementation of the method shown in fig. 1, an embodiment of the present application provides a request distribution apparatus, as shown in fig. 3A, the apparatus includes: an acquisition module 301, a monitoring module 302, a calculation module 303 and a distribution module 304.
The obtaining module 301 is configured to obtain a preheating parameter of a target service to be started, where the preheating parameter indicates whether a plurality of service instances included in the target service are preheated, and a preheating period and a preheating step length of the target service;
the monitoring module 302 is configured to monitor a service interface, and record start time of a target service instance, where the target service instance is any one of the plurality of service instances and is registered in the service interface after the start is completed;
the calculating module 303 is configured to determine a current time when the preheating parameter indicates that the target service instance is preheated, and calculate an instance weight value according to the preheating period, the current time, and the starting time;
the allocating module 304 is configured to allocate the received user request to the target service instance according to the instance weight value.
In a specific application scenario, as shown in fig. 3B, the apparatus further includes: a first determination module 305.
The first determining module 305 is configured to determine a standard request traffic when the warming parameter does not indicate warming of the target service instance;
the issuing module 304 is further configured to allocate the received user request to the target service instance according to the standard request traffic.
In a specific application scenario, the calculating module 303 is configured to calculate a difference between the current time and the starting time, and generate a value group including the difference and the preheating period; determining a target value as the instance weight value among the set of values, the target value being the smallest of the difference and the warm-up period.
In a specific application scenario, as shown in fig. 3C, the apparatus further includes: a reading module 306, a second determining module 307 and a setting module 308.
The reading module 306 is configured to read a plurality of instance weight values corresponding to the plurality of service instances;
the second determining module 307 is configured to, when it is detected that a first specified instance weight value smaller than the warm-up period exists in the plurality of instance weight values, determine a first specified service instance corresponding to the first specified instance weight value;
the setting module 308 is configured to set a timing task according to the preheating step length;
the allocating module 304 is configured to, according to the timing task, periodically calculate an instance weight value for the first specified service instance based on the current time, the preheating period, and the starting time of the first specified service instance, and allocate the user request to the first specified service instance according to the recalculated instance weight value.
In a specific application scenario, as shown in fig. 3D, the apparatus further includes: the module 309 is stopped.
The stopping module 309 is configured to, when the calculated instance weight value of the first specified service instance is greater than or equal to the preheating period, determine that the first specified service instance is completely preheated, and stop the timing task.
In a specific application scenario, as shown in fig. 3E, the apparatus further includes: an update module 310 and an association module 311.
The updating module 310 is configured to update the last start time of the target service to the start time of the target service instance;
the associating module 311 is configured to associate the last start time with the timing task;
the updating module 310 is further configured to continuously monitor the service interface, and when it is monitored that there is another service instance registered in the service interface, update the last start time by using the start time of the another service instance and associate the last start time with the timing task.
In a specific application scenario, the reading module 305 is further configured to, when it is detected that a second specified instance weight value smaller than the pre-heating period exists in a plurality of instance weight values of the plurality of service instances, read the last start time, and determine an actual last start time among the plurality of start times of the plurality of service instances, where a time interval between the actual last start time and a current time is smaller than a time interval between other start times except the actual last start time and the current time among the plurality of start times;
the allocating module 304 is further configured to determine that the timing task is triggered if a time interval between the last start time and the current time is greater than a time interval between the actual last start time and the current time, and periodically recalculate an instance weight value for a second specified service instance corresponding to the second specified instance weight value based on the timing task.
The device provided by the embodiment of the invention dynamically calculates the instance weight value of the target service instance according to the starting time of the successfully started target service instance and the preheating parameters which are set by the target service where the target service instance is located and comprise the preheating period and the preheating step length of the target service and whether the plurality of service instances are preheated or not, and the preheating period and the preheating step length of the target service, and distributes the user request to the service instance according to the dynamically set instance weight, so that the service instance can gradually enter the full working state through the buffer period, the overload of the service instance is avoided, the user request for the service can be effectively responded and processed, and the robustness and the stability of the service are improved.
Meanwhile, it should be understood that the sizes of the respective portions shown in the drawings are not drawn in an actual proportional relationship for the convenience of description.
The following description of at least one exemplary embodiment is merely illustrative in nature and is in no way intended to limit the invention, its application, or uses.
Techniques, methods, and apparatus known to those of ordinary skill in the relevant art may not be discussed in detail but are intended to be part of the specification where appropriate.
It should be noted that: like reference numbers and letters refer to like items in the following figures, and thus, once an item is defined in one figure, further discussion thereof is not required in subsequent figures.
Embodiments of the invention are operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well known computing systems, environments, and/or configurations that may be suitable for use with the computer system/server include, but are not limited to: personal computer systems, server computer systems, thin clients, thick clients, hand-held or laptop devices, microprocessor-based systems, set-top boxes, programmable consumer electronics, networked personal computers, minicomputer systems, mainframe computer systems, distributed cloud computing environments that include any of the above, and the like.
The computer system/server may be described in the general context of computer system-executable instructions, such as program modules, being executed by a computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, etc. that perform particular tasks or implement particular abstract data types. The computer system/server may be practiced in distributed cloud computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed cloud computing environment, program modules may be located in both local and remote computer system storage media including memory storage devices.
In the present specification, the embodiments are described in a progressive manner, each embodiment focuses on differences from other embodiments, and the same or similar parts in the embodiments are referred to each other. For the system embodiment, since it basically corresponds to the method embodiment, the description is relatively simple, and for the relevant points, reference may be made to the partial description of the method embodiment.
The method and system of the present invention may be implemented in a number of ways. For example, the methods and systems of the present invention may be implemented in software, hardware, firmware, or any combination of software, hardware, and firmware. The above-described order for the steps of the method is for illustrative purposes only, and the steps of the method of the present invention are not limited to the order specifically described above unless specifically indicated otherwise. Furthermore, in some embodiments, the present invention may also be embodied as a program recorded in a recording medium, the program including machine-readable instructions for implementing a method according to the present invention. Thus, the present invention also covers a recording medium storing a program for executing the method according to the present invention.
The description of the present invention has been presented for purposes of illustration and description, and is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to practitioners skilled in this art. The embodiment was chosen and described in order to best explain the principles of the invention and the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.

Claims (10)

1. A method for request distribution, comprising:
acquiring a preheating parameter of a target service to be started, wherein the preheating parameter indicates whether a plurality of service instances included in the target service are preheated or not and a preheating period and a preheating step length of the target service;
monitoring a service interface, recording the starting time of a target service instance, wherein the target service instance is any one of the plurality of service instances and is registered in the service interface after the starting is finished;
when the preheating parameter indicates to preheat the target service instance, determining the current time, and calculating an instance weight value according to the preheating period, the current time and the starting time;
and distributing the received user request to the target service instance according to the instance weight value.
2. The method of claim 1, wherein the listening service interface records a start time of a target service instance, and wherein the method further comprises:
when the preheating parameter does not indicate preheating of the target service instance, determining standard request flow;
and distributing the received user request to the target service instance according to the standard request flow.
3. The method of claim 1, wherein said calculating an instance weight value based on said preheat cycle, said current time, and said start time comprises:
calculating a difference value between the current time and the starting time, and generating a value group comprising the difference value and the preheating period;
determining a target value as the instance weight value among the set of values, the target value being the smallest of the difference and the warm-up period.
4. The method of claim 1, wherein after assigning the received user request to the target service instance according to the instance weight value, the method further comprises:
reading a plurality of instance weight values corresponding to the plurality of service instances;
when detecting that a first designated instance weight value smaller than the preheating period exists in the plurality of instance weight values, determining a first designated service instance corresponding to the first designated instance weight value;
setting a timing task according to the preheating step length;
according to the timing task, recalculating an instance weight value for the first specified service instance based on the current time, the preheating period and the starting time of the first specified service instance at regular time, and allocating a user request to the first specified service instance according to the recalculated instance weight value.
5. The method of claim 4, further comprising:
and when the calculated instance weight value of the first appointed service instance is larger than or equal to the preheating period, determining that the first appointed service instance is completely preheated, and stopping the timing task.
6. The method of claim 4, wherein after the setting of the timing task according to the warm-up step size, the method further comprises:
updating the last starting time of the target service to be the starting time of the target service instance;
associating the last start time with the timed task;
and continuously monitoring the service interface, and updating the last starting time by adopting the starting time of other service instances and associating the last starting time with the timing task when monitoring that other service instances are registered in the service interface.
7. The method of claim 6, further comprising:
when detecting that a second specified instance weight value smaller than the preheating period exists in a plurality of instance weight values of the plurality of service instances, reading the last starting time, and determining an actual last starting time in the plurality of starting times of the plurality of service instances, wherein the time interval between the actual last starting time and the current time is smaller than the time interval between the other starting times except the actual last starting time and the current time in the plurality of starting times;
and if the time interval between the value of the last starting time and the current time is larger than the time interval between the actual last starting time and the current time, determining that the timing task is triggered, and periodically recalculating an instance weight value for a second designated service instance corresponding to the second designated instance weight value based on the timing task.
8. A request distribution apparatus, comprising:
the system comprises an acquisition module, a pre-heating module and a control module, wherein the acquisition module is used for acquiring a pre-heating parameter of a target service to be started, and the pre-heating parameter indicates whether a plurality of service instances included in the target service are pre-heated or not and a pre-heating period and a pre-heating step length of the target service;
the monitoring module is used for monitoring a service interface and recording the starting time of a target service instance, wherein the target service instance is any one of the plurality of service instances and is registered in the service interface after the starting is finished;
the calculation module is used for determining the current time when the preheating parameter indicates that the target service instance is preheated, and calculating an instance weight value according to the preheating period, the current time and the starting time;
and the distribution module is used for distributing the received user request to the target service instance according to the instance weight value.
9. An electronic device comprising a memory and a processor, the memory storing a computer program, wherein the processor implements the steps of the method of any one of claims 1 to 7 when executing the computer program.
10. A readable storage medium, on which a computer program is stored, which, when being executed by a processor, carries out the steps of the method according to any one of claims 1 to 7.
CN202011256720.6A 2020-11-11 2020-11-11 Request distribution method, request distribution device, electronic equipment and readable storage medium Active CN112449005B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202011256720.6A CN112449005B (en) 2020-11-11 2020-11-11 Request distribution method, request distribution device, electronic equipment and readable storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011256720.6A CN112449005B (en) 2020-11-11 2020-11-11 Request distribution method, request distribution device, electronic equipment and readable storage medium

Publications (2)

Publication Number Publication Date
CN112449005A true CN112449005A (en) 2021-03-05
CN112449005B CN112449005B (en) 2023-11-17

Family

ID=74735777

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011256720.6A Active CN112449005B (en) 2020-11-11 2020-11-11 Request distribution method, request distribution device, electronic equipment and readable storage medium

Country Status (1)

Country Link
CN (1) CN112449005B (en)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114138357A (en) * 2021-10-29 2022-03-04 北京达佳互联信息技术有限公司 Request processing method and device, electronic equipment, storage medium and product
CN114244898A (en) * 2021-11-16 2022-03-25 阿里巴巴(中国)有限公司 Service grid-based workload preheating method and device
CN117097621A (en) * 2023-10-18 2023-11-21 易方信息科技股份有限公司 Method, system, device and storage medium for discovering dynamic weights based on services

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108134766A (en) * 2016-12-01 2018-06-08 阿里巴巴集团控股有限公司 A kind of method, apparatus, system, server and client for servicing publication
CN108845876A (en) * 2018-04-09 2018-11-20 阿里巴巴集团控股有限公司 A kind of method and device of traffic assignments
US20190068699A1 (en) * 2017-08-31 2019-02-28 Genesys Telecommunications Laboratories, Inc. Systems and methods for load balancing across media server instances
CN111464592A (en) * 2020-03-09 2020-07-28 平安科技(深圳)有限公司 Load balancing method, device, equipment and storage medium based on microservice
CN111597048A (en) * 2020-05-15 2020-08-28 上海交通大学 Micro-service scheduling method and system based on service quality and electronic equipment
CN111832453A (en) * 2020-06-30 2020-10-27 杭州电子科技大学 Unmanned scene real-time semantic segmentation method based on double-path deep neural network

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108134766A (en) * 2016-12-01 2018-06-08 阿里巴巴集团控股有限公司 A kind of method, apparatus, system, server and client for servicing publication
US20190068699A1 (en) * 2017-08-31 2019-02-28 Genesys Telecommunications Laboratories, Inc. Systems and methods for load balancing across media server instances
CN108845876A (en) * 2018-04-09 2018-11-20 阿里巴巴集团控股有限公司 A kind of method and device of traffic assignments
CN111464592A (en) * 2020-03-09 2020-07-28 平安科技(深圳)有限公司 Load balancing method, device, equipment and storage medium based on microservice
CN111597048A (en) * 2020-05-15 2020-08-28 上海交通大学 Micro-service scheduling method and system based on service quality and electronic equipment
CN111832453A (en) * 2020-06-30 2020-10-27 杭州电子科技大学 Unmanned scene real-time semantic segmentation method based on double-path deep neural network

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
郝庭毅;吴恒;吴国全;张文博;: "面向微服务架构的容器级弹性资源供给方法", 计算机研究与发展, no. 03 *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114138357A (en) * 2021-10-29 2022-03-04 北京达佳互联信息技术有限公司 Request processing method and device, electronic equipment, storage medium and product
CN114244898A (en) * 2021-11-16 2022-03-25 阿里巴巴(中国)有限公司 Service grid-based workload preheating method and device
CN117097621A (en) * 2023-10-18 2023-11-21 易方信息科技股份有限公司 Method, system, device and storage medium for discovering dynamic weights based on services
CN117097621B (en) * 2023-10-18 2024-03-19 易方信息科技股份有限公司 Method, system, device and storage medium for discovering dynamic weights based on services

Also Published As

Publication number Publication date
CN112449005B (en) 2023-11-17

Similar Documents

Publication Publication Date Title
CN112449005A (en) Request distribution method and device, electronic equipment and readable storage medium
CN109376155B (en) ID generation method and device, storage medium and electronic device
JP7127010B2 (en) Resource allocation methods, apparatus, electronic equipment, computer readable media and computer programs
WO2020177533A1 (en) Electronic invoice identifier allocation method, and electronic ticket generating method, device and system
EP3469478B1 (en) Server computer management system for supporting highly available virtual desktops of multiple different tenants
US20190155655A1 (en) Resource allocation method and resource manager
JP6089783B2 (en) Control device, resource control program, and resource control method
US11496413B2 (en) Allocating cloud computing resources in a cloud computing environment based on user predictability
WO2017088393A1 (en) Bandwidth allocation method and system
CN110310198B (en) Enterprise quota information management method, device, equipment and readable storage medium
CN109587220B (en) Load balancing method and device, computer equipment and storage medium
CN112231108A (en) Task processing method and device, computer readable storage medium and server
CN110008029B (en) ceph metadata cluster directory distribution method, system, device and readable storage medium
CN114116173A (en) Method, device and system for dynamically adjusting task allocation
US6728895B1 (en) System and method for resource recovery in a distributed system
CN105338037A (en) Dynamic scheduling method and system
CN110569114B (en) Service processing method, device, equipment and storage medium
WO2023169106A1 (en) Method and apparatus for scheduling content delivery network domain name
CN109005071B (en) Decision deployment method and scheduling equipment
JP6957194B2 (en) Service system, its control method, and its program
CN111831503A (en) Monitoring method based on monitoring agent and monitoring agent device
CN106131187B (en) Authorization control method and device
CN116010019A (en) Memory resource allocation method, related device and equipment
CN113760940A (en) Quota management method, device, equipment and medium applied to distributed system
CN112860442A (en) Resource quota adjusting method and device, computer equipment and storage medium

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
CB02 Change of applicant information
CB02 Change of applicant information

Address after: 100102 201 / F, block C, 2 lizezhong 2nd Road, Chaoyang District, Beijing

Applicant after: Beijing Shuidi Technology Group Co.,Ltd.

Address before: 100102 201, 2 / F, block C, No.2 lizezhong 2nd Road, Chaoyang District, Beijing

Applicant before: Beijing Health Home Technology Co.,Ltd.

GR01 Patent grant
GR01 Patent grant