CN110912972B - Service processing method, system, electronic equipment and readable storage medium - Google Patents
Service processing method, system, electronic equipment and readable storage medium Download PDFInfo
- Publication number
- CN110912972B CN110912972B CN201911083305.2A CN201911083305A CN110912972B CN 110912972 B CN110912972 B CN 110912972B CN 201911083305 A CN201911083305 A CN 201911083305A CN 110912972 B CN110912972 B CN 110912972B
- Authority
- CN
- China
- Prior art keywords
- pod
- service
- available
- list
- processed
- 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.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1004—Server selection for load balancing
- H04L67/1008—Server selection for load balancing based on parameters of servers, e.g. available memory or workload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
Abstract
The application discloses a Service processing method, which is different from the architecture of Ingress + Service + Pod in the prior art, and provides a new architecture of new Ingress + Pod, wherein a custom controller is additionally added in the new Ingress, so that not only can passive monitoring on the operating state of the Pod at the lower layer be realized, but also active health check can be realized through a load tool, and when incoming Service to be processed is received, the current available Pod can be determined in time and issued. Because the Service layer in the traditional scheme is removed, the defects of the traditional scheme are not existed any more. In other words, by simplifying and integrating unnecessary layers, the defect of a Service layer in the traditional scheme is overcome, the efficiency of Service registration discovery is improved, and the Service interruption phenomenon caused by untimely Pod state update can be effectively prevented. The application also discloses a service processing system, an electronic device and a readable storage medium, which have the beneficial effects.
Description
Technical Field
The present application relates to the field of kubernets technology, and in particular, to a service processing method and system applied to an Ingress layer, an electronic device, and a readable storage medium.
Background
With the development of information technology, cloud computing has gradually become a development hotspot in the industry, and the cloud computing technology is also gradually applied to multiple fields of education, science, culture, public security, government, sanitation, high-performance computing, electronic commerce, internet of things and the like, and accordingly, the usage amount and the activity of cloud computing service platforms are increasing day by day. With the development of cloud computing, cloud computing clusters are increasingly large and complex, and how to utilize cluster resources well meets service requirements, saves energy, reduces emission, and improves resource utilization rate is a difficult problem that technical workers must deal with.
Kubernetes itself provides a set of service registration discovery solutions: ingress + Service, namely Kubernet, loads a plurality of copies of pod Service through the Service, and realizes load balance through a polling mode and the like. The schematic architecture of this scheme can be seen in fig. 1. The Service is used as a lower layer of Ingress, is used as an upper layer of each Pod, is positioned in the middle layer, and is designed to realize load balance by using the Service as a master agent of each Pod. But the Service design has the disadvantages which are difficult to solve: the abnormality of the Pod application cannot be sensed actively, and only by passively monitoring the Pod state and passively receiving the abnormality notification of the Pod application, when the node is down (Pod is built on the node), kubernets usually exceed 5 minutes to identify the node as the abnormal state, and before that, Service still allocates load to the Pod. However, the Pod cannot process the load and is in an unavailable state, so that the subsequent service depending on the Pod cannot be processed without processing the service, and the service is interrupted.
In the service registration discovery scheme, the 5-minute departure time can meet the current requirement at the beginning of use, and the departure time cannot meet the current requirement with the development of information technology and the gradual increase of the requirement. Therefore, how to provide a better service registration discovery scheme, improve service registration discovery efficiency, prevent service interruption, and the like is a problem to be solved urgently by those skilled in the art.
Disclosure of Invention
The application aims to provide a business processing method, a business processing system, an electronic device and a readable storage medium, and aims to improve service registration discovery efficiency and prevent business interruption.
In order to achieve the above object, the present application provides a service processing method applied to an Ingress layer in kubernets, where the method includes:
receiving an incoming service to be processed;
acquiring an available Pod list through a custom controller according to the service to be processed; the user-defined controller is preset in the Ingress layer, a data connection is established between the user-defined controller and each Pod, an available Pod in each Pod can be determined through an active health check mechanism, and the identity information of each available Pod is recorded in the available Pod list;
selecting a target Pod from the available Pod list according to a preset load balancing strategy;
and sending the service to be processed to the target Pod.
Optionally, obtaining, by a custom controller, an available Pod list according to the service to be processed includes:
determining the target resource type of the service to be processed; setting corresponding resource types for each service to be processed in advance;
determining an initial Pod list corresponding to the target resource type; the initial Pod list comprises identity information of all pods which are allocated with processing resource types as the target resource types;
controlling the custom controller to completely refresh the identity information in the initial Pod list into Nginx;
controlling the Nginx to execute health check operation on each Pod to obtain each available Pod;
and generating the available Pod list according to the identity information of each available Pod.
Optionally, the service processing method further includes:
controlling the custom controller to monitor the running state information of each Pod;
and controlling the custom controller to update the latest information into the Nginx according to the running state information.
Optionally, selecting a target Pod from the available Pod list according to a preset load balancing policy, including:
acquiring the current load of each available Pod in the available Pod list;
and comparing the current loads, and selecting the available Pod corresponding to the minimum current load as the target Pod.
Optionally, to achieve the above object, the present application further provides a service processing system, which is applied to an Ingress layer in kubernets, and the system includes:
a to-be-processed service receiving unit, configured to receive an incoming to-be-processed service;
an available Pod list obtaining unit, configured to obtain an available Pod list through a custom controller according to the service to be processed; the user-defined controller is preset in the Ingress layer, a data connection is established between the user-defined controller and each Pod, an available Pod in each Pod can be determined through an active health check mechanism, and the identity information of each available Pod is recorded in the available Pod list;
a target Pod selecting unit, configured to select a target Pod from the available Pod list according to a preset load balancing policy;
and the to-be-processed service issuing unit is used for issuing the to-be-processed service to the target Pod.
Optionally, the available Pod list obtaining unit includes:
a target resource type determining subunit, configured to determine a target resource type of the service to be processed; wherein, a corresponding resource type is preset for each service to be processed;
an initial Pod list determining subunit, configured to determine an initial Pod list corresponding to the target resource type; wherein, the initial Pod list includes identity information of all pods allocated with processing resource types as the target resource types;
the information is refreshed to a Nginx subunit, and the information is used for controlling the custom controller to refresh all the identity information in the initial Pod list to the Nginx subunit;
an active health check operation execution subunit, configured to control the Nginx to execute a health check operation on each Pod, so as to obtain each available Pod;
an available Pod list generating subunit, configured to generate the available Pod list according to the identity information of each available Pod.
Optionally, the service processing system further includes:
the running state information passive monitoring unit is used for controlling the custom controller to monitor the running state information of each Pod;
and the information updating unit is used for controlling the custom controller to update the latest information into the Nginx according to the running state information.
Optionally, the target Pod selecting unit includes:
a current load obtaining subunit, configured to obtain a current load of each available Pod in the available Pod list;
and the load comparison and selection subunit is used for comparing each current load and selecting the available Pod corresponding to the minimum current load as the target Pod.
To achieve the above object, the present application also provides an electronic device, including:
a memory for storing a computer program;
and a processor, configured to implement, when executing the computer program, the steps of the service processing method applied to the Ingress layer in kubernets as described above.
In order to achieve the above object, the present application further provides a readable storage medium, which stores thereon a computer program, and when the computer program is called by a processor and executed, the computer program can implement the steps of the service processing method applied to the Ingress layer in kubernets as described above.
The application provides a service processing method applied to an Ingress layer in Kubernets, which comprises the following steps: receiving an incoming service to be processed; acquiring an available Pod list through a custom controller according to the service to be processed; the user-defined controller is preset in the Ingress layer, a data connection is established between the user-defined controller and each Pod, an available Pod in each Pod can be determined through an active health check mechanism, and the identity information of each available Pod is recorded in the available Pod list; selecting a target Pod from the available Pod list according to a preset load balancing strategy; and sending the service to be processed to the target Pod.
According to the Service processing method provided by the application, the method is different from the architecture of Ingress + Service + Pod in the prior art, the new architecture of Ingress + Pod is provided, the new Ingress is additionally provided with the custom controller, not only can passive monitoring on the running state of the Pod at the lower layer be realized, but also active health check can be realized through proper processing, so that when the new Ingress layer receives the transmitted Service to be processed, the current available Pod can be timely determined and issued to the available Pod, and the untimely problem caused by the defects of the traditional Service scheme layer can be avoided. In other words, the defects of a Service layer in the traditional scheme are overcome through simplification and integration of unnecessary layers, the efficiency of Service registration discovery is improved, and the phenomenon of Service interruption caused by untimely Pod state updating is effectively prevented from reoccurring.
The application also provides a service processing system, an electronic device and a readable storage medium, which have the beneficial effects and are not described herein again.
Drawings
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly introduced below, it is obvious that the drawings in the following description are only embodiments of the present application, and for those skilled in the art, other drawings can be obtained according to the provided drawings without creative efforts.
Fig. 1 is a schematic structural diagram of a kubernets service registration discovery scheme used in the prior art;
fig. 2 is a flowchart of a service processing method according to an embodiment of the present application;
fig. 3 is a schematic structural diagram of a kubernets novel service registration discovery scheme corresponding to the scheme shown in fig. 2 according to an embodiment of the present application;
fig. 4 is a flowchart of a method for acquiring an available Pod list based on Nginx according to this embodiment;
FIG. 5 is a diagram of an actual code operation provided in this embodiment;
fig. 6 is a flowchart of a passive monitoring scheme of a custom controller according to an embodiment of the present application;
FIG. 7 is a specific timing diagram corresponding to the scheme in FIG. 4 provided in the embodiments of the present application;
FIG. 8 is a specific timing diagram corresponding to the scheme in FIG. 6 according to an embodiment of the present application;
fig. 9 is a schematic diagram of an operation principle and effect of an Nginx according to an embodiment of the present application;
FIG. 10 is a schematic diagram of another Nginx operating principle and effect provided by an embodiment of the present application;
fig. 11 is a flowchart of a method for selecting a target Pod based on a minimum load according to an embodiment of the present application;
fig. 12 is a block diagram of a service processing system according to an embodiment of the present application.
Detailed Description
The application aims to provide a business processing method, a business processing system, an electronic device and a readable storage medium, and aims to improve service registration discovery efficiency and prevent business interruption.
In order to make the objects, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are some embodiments of the present application, but not all embodiments. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments in the present application without making any creative effort belong to the protection scope of the present application.
Referring to fig. 2, fig. 2 is a flowchart of a service processing method provided in an embodiment of the present application, and it should be noted that an execution main body of each step in fig. 2 is an Ingress layer in kubernets, that is, the following steps are distinguished from an Ingress layer in a conventional scheme by describing how the Ingress layer in the present application processes a service to be processed, and include the following steps:
s101: receiving an incoming service to be processed;
the service to be processed comes from the upper layer of the cluster, and the service to be processed at least includes information describing relevant parameters of the service to be processed, which may include the type of the service to be processed, processing requirements, the size of the service to be processed, and other special information required according to an actual application scenario, and is not limited specifically here.
S102: acquiring an available Pod list through a custom controller according to a service to be processed;
the user-defined controller is preset in the Ingress layer, data connection is established between the user-defined controller and each Pod, available pods in each Pod can be determined through an active health check mechanism, and the identity information of each available Pod is recorded in the available Pod list. In which, the active health check mechanism can be generally implemented by Nginx, apache, traffic and other load tools that can achieve similar effects.
The user-defined controller is newly set in the Ingress layer, which is different from Ingress in a conventional scheme, can better complete the work of Pod state confirmation and load balancing on the basis of removing the Service layer by linking with the load tool, and meanwhile, because the redundant Service layer in the traditional scheme is removed, the steps are simplified, and the efficiency is improved.
On the basis of S101, in this step, the new Ingress layer is linked with load tools such as Nginx through a custom controller newly added in the layer, and under the condition that the original Service layer is removed and data connection is directly established between the new Ingress layer and each Pod (see the novel architecture diagram shown in fig. 3), not only the original function of the original Service layer is not lost, but also better performance can be achieved in Pod status confirmation and load balancing strategies (brought by the expansibility of load tools such as Nginx) so as to obtain an available Pod list responsible for processing the Service to be processed. Due to the fact that the controller and the load tool such as the Nginx are customized, all the Pods recorded in the formed available Pod list are currently available, and therefore the situation that the load task is issued to the Pod with the exception and the unavailable Pod cannot occur.
To facilitate understanding of the specific implementation process of this step, the present application also takes an Nginx load tool as an example, and provides a specific implementation scheme as shown in the flowchart of fig. 4, which includes the following steps:
s201: determining a target resource type of a service to be processed;
s202: controlling a custom controller to determine an initial Pod list corresponding to the target resource type;
due to the complexity of the cluster, different resource types are also set for different to-be-processed services in advance in the specific scheme, and corresponding Pod groups (including multiple pods) are allocated to the different resource types, so that the different pods only need to be responsible for processing the to-be-processed services of the corresponding resource types.
The custom resource type may be PIngress, and the corresponding relationship may be implemented by designating a corresponding agent Pod in a selector manner.
The initial Pod list includes identity information of all pods allocated processing resource types as target resource types.
A custom controller (controller) directs the Pod list corresponding to the resource type described in the tag (i.e., the initial Pod list) according to the resource type tag provided by PIngress. See the actual code execution diagram shown in fig. 5.
S203: controlling a custom controller to completely refresh the identity information in the initial Pod list into Nginx;
on the basis of S202, the custom controller automatically comforts each Pod in the initial Pod list to Nginx, so that the Nginx performs active operation status confirmation on each Pod refreshed therein.
S204: controlling Nginx to execute health check operation on each Pod to obtain each available Pod;
on the basis of S203, Nginx performs an active health check operation on each Pod refreshed into it, so as to determine which pods are currently available pods according to the result of the health check operation.
The health check operation may be implemented in various ways, such as, for example, the Pod sending a handshake packet, a test packet, or sending a custom, recognizable name, etc., for the purpose of enabling the Pod to respond to an inquiry signal issued by Nginx to enable the Nginx to determine whether it is in a usable state.
S205: and generating an available Pod list according to the identity information of each available Pod.
On the basis of S204, this step is intended to generate an available Pod list according to the identity information of each available Pod.
Furthermore, the custom controller can monitor the Pod addition/deletion and adjustment events from the upper layer, so as to adjust the information in the initial Pod list, and meanwhile, the passive monitoring function of the original Service layer can be kept, and the feedback information from each Pod is passively received, so that the information in the initial Pod list is automatically adjusted according to the feedback information, and the operation amount required to be executed by the active health mechanism is reduced as much as possible.
One implementation, including but not limited to, may be seen in the flow chart shown in fig. 6:
s301: controlling a custom controller to monitor the running state information of each Pod;
s302: and controlling the custom controller to update the latest information into Nginx according to the running state information.
A more specific implementation process including the scheme shown in fig. 4 and fig. 6 can be seen from the timing chart shown in fig. 7 and fig. 8, which details how the parts implement this process interactively, and for the load tool of Nginx, the present application also provides a description of the working principle and effect of fig. 9 and fig. 10.
S103: selecting a target Pod from the available Pod list according to a preset load balancing strategy;
on the basis of S102, this step is intended to select an appropriate available Pod from the available Pod list as a target Pod according to a preset load balancing policy. Unlike the traditional unique polling load balancing strategy brought by the Service layer, the load tool such as Nginx can support more various load balancing strategies due to the expansibility and diversity thereof, such as a load minimum strategy (the current load in a plurality of Pod is selected to be the minimum), a grouping strategy, a data size strategy, a request response time strategy, an importance strategy and the like.
For ease of understanding, a specific implementation is given by taking the load minimization strategy as an example, please refer to the flowchart shown in fig. 11, which includes the following steps:
s401: acquiring the current load of each available Pod in the available Pod list;
s402: and comparing the current loads, and selecting the available Pod corresponding to the minimum current load as the target Pod.
S104: and sending the service to be processed to the target Pod.
On the basis that the target Pod is determined in S103, the step aims to issue the service to be processed to the target Pod by the new Ingress layer.
Based on the Service processing method provided by this embodiment, it can be known that, unlike the architecture of Ingress + Service + Pod in the prior art, the present application provides a new architecture of new Ingress + Pod, and a custom controller is additionally added in the new Ingress, which not only can realize passive monitoring of the operating state of the Pod on the lower layer, but also can realize active health check through proper processing, so that when the new Ingress receives a Service to be processed, the current available Pod can be determined in time and issued to the available Pod, and the problem of untimely time caused by the defects of the traditional Service scheme layer can not occur. In other words, due to the simplification and integration of unnecessary layers, the defect of a Service layer in the traditional scheme is overcome, the efficiency of Service registration discovery is improved, and the phenomenon of Service interruption caused by untimely Pod state update is effectively prevented from reoccurring.
Because the situation is complex and cannot be illustrated by one list, those skilled in the art can realize that there are many examples according to the basic method principle provided by the present application and the practical situation, and the protection scope of the present application should be covered without enough inventive work.
Referring to fig. 12, fig. 12 is a block diagram of a service processing system according to an embodiment of the present application, where the service processing system may include:
a pending service receiving unit 100, configured to receive an incoming pending service;
an available Pod list obtaining unit 200, configured to obtain an available Pod list through a custom controller according to a service to be processed; the user-defined controller is preset in the Ingress layer, data connection is established between the user-defined controller and each Pod, available pods in each Pod can be determined through an active health check mechanism, and the identity information of each available Pod is recorded in an available Pod list;
a target Pod selecting unit 300, configured to select a target Pod from the available Pod list according to a preset load balancing policy;
and the pending service issuing unit 400 is configured to issue the pending service to the target Pod.
The available Pod list obtaining unit 200 may include:
the target resource type determining subunit is used for determining the target resource type of the service to be processed; wherein, a corresponding resource type is preset for each service to be processed;
an initial Pod list determining subunit, configured to determine an initial Pod list corresponding to the target resource type; the initial Pod list comprises identity information of all pods which are allocated with processing resource types as target resource types;
the information refreshing to Nginx subunit is used for controlling the user-defined controller to refresh all the identity information in the initial Pod list to Nginx;
the active health check operation execution subunit is used for controlling Nginx to execute health check operation on each Pod to obtain each available Pod;
and the available Pod list generating subunit is used for generating an available Pod list according to the identity information of each available Pod.
Further, the service processing system may further include:
the running state information passive monitoring unit is used for controlling the custom controller to monitor the running state information of each Pod;
and the information updating unit is used for controlling the custom controller to update the latest information into Nginx according to the running state information.
The target Pod selecting unit 300 may include:
a current load obtaining subunit, configured to obtain a current load of each available Pod in the available Pod list;
and the load comparison and selection subunit is used for comparing each current load and selecting the available Pod corresponding to the minimum current load as the target Pod.
The present embodiment exists as a system embodiment corresponding to the above method embodiment, and has all the advantages of the method embodiment, and details are not described herein again.
Based on the foregoing embodiments, the present application further provides an electronic device, which may include a memory and a processor, where the memory stores a computer program, and the processor may implement the steps provided by the foregoing embodiments when calling the computer program in the memory. Of course, the electronic device may also include various necessary network interfaces, power supplies, other components, and the like.
The present application further provides a readable storage medium, on which a computer program is stored, and the computer program, when executed by an execution terminal or a processor, can implement the steps provided by the above embodiments. The storage medium may include: various media capable of storing program codes, such as a usb disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk, or an optical disk.
The embodiments are described in a progressive mode in the specification, the emphasis of each embodiment is on the difference from the other embodiments, and the same and similar parts among the embodiments can be referred to each other. The device disclosed by the embodiment corresponds to the method disclosed by the embodiment, so that the description is simple, and the relevant points can be referred to the method part for description.
Those of skill would further appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both, and that the various illustrative components and steps have been described above generally in terms of their functionality in order to clearly illustrate this interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.
The principles and embodiments of the present application are explained herein using specific examples, which are provided only to help understand the method and the core idea of the present application. It will be apparent to those skilled in the art that various changes and modifications can be made in the present invention without departing from the principles of the invention, and these changes and modifications also fall within the scope of the claims of the present application.
It should also be noted that, in this specification, relational terms such as first and second, and the like are used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.
Claims (9)
1. A service processing method is characterized in that the service processing method is applied to an Ingress layer in Kubernets and comprises the following steps:
receiving an incoming service to be processed;
acquiring an available Pod list through a custom controller according to the service to be processed; the user-defined controller is preset in the Ingress layer, data connection is established between the user-defined controller and each Pod, an available Pod in each Pod can be determined through an active health check mechanism, and the identity information of each available Pod is recorded in an available Pod list;
selecting a target Pod from the available Pod list according to a preset load balancing strategy;
sending the service to be processed to the target Pod;
acquiring an available Pod list through a custom controller according to the service to be processed, wherein the acquiring comprises the following steps:
determining the target resource type of the service to be processed; setting corresponding resource types for each service to be processed in advance;
determining an initial Pod list corresponding to the target resource type; the initial Pod list comprises identity information of all pods which are allocated with processing resource types as the target resource types;
controlling the custom controller to completely refresh the identity information in the initial Pod list into Nginx;
controlling the Nginx to execute health check operation on each Pod to obtain each available Pod;
and generating the available Pod list according to the identity information of each available Pod.
2. The traffic processing method according to claim 1, further comprising:
controlling the custom controller to monitor the running state information of each Pod;
and controlling the custom controller to update the latest information into the Nginx according to the running state information.
3. The traffic processing method according to any one of claims 1 or 2, wherein selecting a target Pod from the list of available pods according to a preset load balancing policy comprises:
acquiring the current load of each available Pod in the available Pod list;
and comparing the current loads, and selecting the available Pod corresponding to the minimum current load as the target Pod.
4. A service processing system is characterized in that the service processing system is applied to an Ingress layer in Kubernets and comprises the following components:
a to-be-processed service receiving unit, configured to receive an incoming to-be-processed service;
an available Pod list obtaining unit, configured to obtain an available Pod list through a custom controller according to the service to be processed; the user-defined controller is preset in the Ingress layer, data connection is established between the user-defined controller and each Pod, an available Pod in each Pod can be determined through an active health check mechanism, and the identity information of each available Pod is recorded in an available Pod list;
the target Pod selecting unit is used for selecting a target Pod from the available Pod list according to a preset load balancing strategy;
a to-be-processed service issuing unit, configured to issue the to-be-processed service to the target Pod;
acquiring an available Pod list through a custom controller according to the service to be processed, wherein the acquiring comprises the following steps:
determining the target resource type of the service to be processed; setting corresponding resource types for each service to be processed in advance;
determining an initial Pod list corresponding to the target resource type; the initial Pod list comprises identity information of all pods which are allocated with processing resource types as the target resource types;
controlling the custom controller to completely refresh the identity information in the initial Pod list into Nginx;
controlling the Nginx to execute health check operation on each Pod to obtain each available Pod;
and generating the available Pod list according to the identity information of each available Pod.
5. The service processing system according to claim 4, wherein the available Pod list obtaining unit includes:
a target resource type determining subunit, configured to determine a target resource type of the service to be processed; wherein, a corresponding resource type is preset for each service to be processed;
an initial Pod list determining subunit, configured to determine an initial Pod list corresponding to the target resource type; wherein, the initial Pod list includes identity information of all pods allocated with processing resource types as the target resource types;
the information is refreshed to a Nginx subunit, and the information is used for controlling the custom controller to refresh all the identity information in the initial Pod list to the Nginx subunit;
an active health check operation execution subunit, configured to control the Nginx to execute a health check operation on each Pod, so as to obtain each available Pod;
an available Pod list generating subunit, configured to generate the available Pod list according to the identity information of each available Pod.
6. The traffic processing system of claim 5, further comprising:
the running state information passive monitoring unit is used for controlling the custom controller to monitor the running state information of each Pod;
and the information updating unit is used for controlling the custom controller to update the latest information into the Nginx according to the running state information.
7. The transaction system according to any of claims 4 to 6, wherein the target Pod selecting unit comprises:
a current load obtaining subunit, configured to obtain a current load of each available Pod in the available Pod list;
and the load comparison and selection subunit is used for comparing each current load and selecting the available Pod corresponding to the minimum current load as the target Pod.
8. An electronic device, comprising:
a memory for storing a computer program;
a processor adapted to implement the steps of the traffic processing method according to any of claims 1 to 3 when executing said computer program.
9. A readable storage medium, characterized in that it stores a computer program which, when invoked and executed by a processor, implements the steps of the business processing method of any one of claims 1 to 3.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911083305.2A CN110912972B (en) | 2019-11-07 | 2019-11-07 | Service processing method, system, electronic equipment and readable storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911083305.2A CN110912972B (en) | 2019-11-07 | 2019-11-07 | Service processing method, system, electronic equipment and readable storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN110912972A CN110912972A (en) | 2020-03-24 |
| CN110912972B true CN110912972B (en) | 2022-08-19 |
Family
ID=69816835
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201911083305.2A Active CN110912972B (en) | 2019-11-07 | 2019-11-07 | Service processing method, system, electronic equipment and readable storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110912972B (en) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111625349A (en) * | 2020-04-14 | 2020-09-04 | 金蝶软件（中国）有限公司 | Pod isolation method, device, equipment and storage medium in container scheduling platform |
| CN112256437A (en) * | 2020-11-10 | 2021-01-22 | 网易（杭州）网络有限公司 | Task distribution method and device |
| CN112702441B (en) * | 2021-01-05 | 2023-06-30 | 南京领行科技股份有限公司 | Container-based access data processing method, device, system and storage medium |
| CN113010385B (en) * | 2021-03-18 | 2022-10-28 | 山东英信计算机技术有限公司 | Task state updating method, device, equipment and medium |
| CN116503385B (en) * | 2023-06-25 | 2023-09-01 | 吉林大学 | Sugar mesh bottom image grading method and equipment based on virtual global agent |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106888254A (en) * | 2017-01-20 | 2017-06-23 | 华南理工大学 | A kind of exchange method between container cloud framework based on Kubernetes and its each module |
| CN109885389A (en) * | 2019-02-19 | 2019-06-14 | 山东浪潮云信息技术有限公司 | A kind of parallel deep learning scheduling training method and system based on container |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8544651B2 (en) * | 2012-01-20 | 2013-10-01 | Taiwan Semiconductor Manufacturing Company, Ltd. | Wafer transfer pod for reducing wafer particulate contamination |
| CN108418854A (en) * | 2018-01-22 | 2018-08-17 | 郑州云海信息技术有限公司 | A kind of dependence implementation method based on kubernetes |
| CN108810125B (en) * | 2018-06-01 | 2021-04-23 | 云家园网络技术有限公司 | Service discovery method and system for physical node |
| CN109934361B (en) * | 2019-02-25 | 2022-03-11 | 江苏电力信息技术有限公司 | Automatic operation and maintenance platform model based on container and big data |
| CN110134455A (en) * | 2019-04-12 | 2019-08-16 | 平安医疗健康管理股份有限公司 | A kind of application management system and method |
-
2019
- 2019-11-07 CN CN201911083305.2A patent/CN110912972B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106888254A (en) * | 2017-01-20 | 2017-06-23 | 华南理工大学 | A kind of exchange method between container cloud framework based on Kubernetes and its each module |
| CN109885389A (en) * | 2019-02-19 | 2019-06-14 | 山东浪潮云信息技术有限公司 | A kind of parallel deep learning scheduling training method and system based on container |
Also Published As
| Publication number | Publication date |
|---|---|
| CN110912972A (en) | 2020-03-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110912972B (en) | Service processing method, system, electronic equipment and readable storage medium | |
| EP3335120B1 (en) | Method and system for resource scheduling | |
| CN111818159B (en) | Management method, device, equipment and storage medium of data processing node | |
| CN108881512B (en) | CTDB virtual IP balance distribution method, device, equipment and medium | |
| CN111880936B (en) | Resource scheduling method, device, container cluster, computer equipment and storage medium | |
| WO2019210580A1 (en) | Access request processing method, apparatus, computer device, and storage medium | |
| CN106716385A (en) | Application centric distributed storage system and method | |
| CN110166524B (en) | Data center switching method, device, equipment and storage medium | |
| CN109802986B (en) | Equipment management method, system, device and server | |
| CN110719311B (en) | Distributed coordination service method, system and computer readable storage medium | |
| US10802896B2 (en) | Rest gateway for messaging | |
| CN106936925A (en) | Load-balancing method and system | |
| CN101167307A (en) | Dynamically self-adaptive distributed resource management system and method | |
| CN107508700B (en) | Disaster recovery method, device, equipment and storage medium | |
| CN113032431B (en) | High-availability client load balancing method based on database middleware cluster | |
| US10044838B2 (en) | Method of automatically setting protocol in programmable logic controller system | |
| EP3672203A1 (en) | Distribution method for distributed data computing, device, server and storage medium | |
| CN104410511A (en) | Server management method and system | |
| CN112559461A (en) | File transmission method and device, storage medium and electronic equipment | |
| JP2016177324A (en) | Information processing apparatus, information processing system, information processing method, and program | |
| CN111913784A (en) | Task scheduling method and device, network element and storage medium | |
| CN111556126A (en) | Model management method, system, computer device and storage medium | |
| CN113873052B (en) | Domain name resolution method, device and equipment of Kubernetes cluster | |
| CN110944051B (en) | Method and device for realizing load balance, electronic equipment and storage medium | |
| CN114938375B (en) | Container group updating equipment and container group updating method |
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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |