A method and apparatus for managing service routing tables

Abstract

This invention discloses a service routing table management method, apparatus, and device. The method includes: constructing a service routing table based on a service table and a service template; and updating the service routing table based on the status of service instances and the estimated load of service instances. Through this invention, service requests of different levels are forwarded according to the next hop of their respective service routes. For service requests of the same level, load balancing is achieved across multiple non-equivalent load-sharing paths, improving resource utilization, meeting diverse user needs, and offering faster response times and simpler deployment. This solves the technical problem of low network and computing resource utilization in related technologies.

Description

Technical Field

[0001] This invention relates to the field of routing technology, and in particular to a service routing table management method and apparatus. Background Technology

[0002] Currently, computing power networks are a new type of network architecture that deeply integrates computing power and networks, enabling the network to schedule computing resources from different locations on demand and in a timely manner, thereby improving the utilization rate of both network and computing resources. Meeting the needs for efficient connection, on-demand allocation, and flexible scheduling of computing resources is an important direction for the development of computing power networks.

[0003] In related technologies, mathematical tools are typically used to model and solve problems related to efficient connection, on-demand allocation, and flexible scheduling of computing resources. However, due to differences in computing power and network metrics, as well as heterogeneous computing power metrics, the way user needs are mapped becomes complex. The premises and assumptions on which the models are created differ from the actual scenarios, and the data involved in the models and solutions are difficult to collect in actual systems.

[0004] These problems result in low utilization rates of network and computing resources. Therefore, a solution to improve the utilization rate of network and computing resources is urgently needed. Summary of the Invention

[0005] This invention provides a service routing table management method and apparatus, which can solve the technical problem of low utilization of network and computing resources in the prior art.

[0006] To achieve the above objectives, the present invention provides the following technical solution:

[0007] In a first aspect, embodiments of the present invention provide a service routing table management method, the method comprising:

[0008] Build a service routing table based on the service table and service template;

[0009] The service routing table is updated based on the status of the service instance and the estimated load of the service instance.

[0010] In a second aspect, embodiments of the present invention provide a service routing table management device, the device comprising:

[0011] The routing table building module is configured to build service routing tables based on service tables and service templates;

[0012] The information update module is configured to update the service routing table based on the status of the service instance and the estimated load of the service instance.

[0013] Thirdly, embodiments of the present invention also provide an electronic device, including: a memory and a processor; the processor is configured to read and execute a computer program stored in the memory to implement the aforementioned service routing table management method.

[0014] Fourthly, embodiments of the present invention also provide a computer storage medium storing computer-executable instructions, which, when executed, implement the aforementioned service routing table management method.

[0015] The beneficial effects of the technical solutions provided by the embodiments of the present invention include:

[0016] A service routing table is built based on the service table and service template to complete the mapping from the service level of the server to the service level of the network, so that the service capabilities and network capabilities are matched. The hierarchical service routing method is easy to operate and maintain, avoids the huge table entry requirements of fine-grained traffic scheduling, meets the needs of users with different service levels, and provides differentiated services.

[0017] Based on the status of service instances and the estimated load of service instances, the service routing table is updated to achieve load balancing among different instances and improve resource utilization.

[0018] Through this invention, service requests of different levels are forwarded according to the next hop of their respective service routes, and service requests of the same level achieve load balancing of traffic among multiple non-equivalent load-sharing paths, thereby improving resource utilization, meeting the differentiated needs of users, and providing faster response speed and simpler deployment. This invention also solves the technical problem of low network and computing resource utilization in related technologies. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a flowchart illustrating an embodiment of the service routing table management method of the present invention;

[0021] Figure 2 This is a service routing representation schematic of an embodiment of the present invention;

[0022] Figure 3 This is a schematic diagram of a service routing network according to an embodiment of the present invention;

[0023] Figure 4 for Figure 1 A detailed flowchart of step S20;

[0024] Figure 5 This is a flowchart illustrating another embodiment of the service routing table management method of the present invention;

[0025] Figure 6 This is a functional module diagram of an embodiment of the service routing table management device of the present invention;

[0026] Figure 7 This is a schematic diagram of the structure of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0027] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0028] To make the objectives, technical solutions, and advantages of the present invention clearer, the embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0029] In a first aspect, embodiments of the present invention provide a service routing table management method.

[0030] In one embodiment, reference is made to Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the service routing table management method of the present invention. Figure 1 As shown, the service routing table management methods include:

[0031] Step S10: Construct a service routing table based on the service table and service template;

[0032] In this embodiment, the service table is formed based on the service instance information configured on the computing power routing egress node. All service instances are initially in an available state. Service instance information includes the computing power service identifier (SID), computing power service level, computing power service instance IP, outgoing interface, next-hop information, and computing power service type.

[0033] The service level in the service route identifier represents the basic optimization goal of the service, including basic computing power service capabilities and network resource constraints. Different service instances of the same service function can provide different service capability levels, and the required network capabilities also differ. Routing nodes connecting services color the service routes according to mapping policies and service level parameter values, representing their network capability requirements. That is, network-side service levels are represented by different colors, while server-side service levels are represented by different levels. Therefore, the first router connecting the service instances needs to deploy corresponding service templates to complete the mapping from Level to Color. The Color converts service level capabilities into network requirements, constructing end-to-end hierarchical service capabilities. When routing nodes calculate service routes, they iterate forwarding paths based on the service route Color to obtain the service routing table. Using a hierarchical service routing approach facilitates operation and maintenance management, avoids the huge table entry requirements of fine-grained traffic scheduling, meets the needs of users with different service levels, and provides differentiated services.

[0034] Reference Figure 2 , Figure 2 This is a schematic representation of service routing according to an embodiment of the present invention. Figure 2 As shown, the service routing table for the same service has its own corresponding next hop for each service level. There are one or more next hops for the same service level, and these next hops form a UCMP (Unequal Cost Multiple Path) path. Service requests of different levels are forwarded according to the next hop of their respective service routes. For service requests of the same level, weighted load balancing is achieved across multiple UCMP paths.

[0035] It should be noted that when deploying service instances, resources are allocated based on service capability requirements such as computing, communication, memory, and storage, and the initial resource level of the service instance is set. The method of service level classification is not limited here. Each type of computing service can have its own service level classification method, which can cover the needs of various users and maintain semantic consistency.

[0036] In some specific embodiments, step S10 includes:

[0037] The service level of the server capability corresponding to each service instance is determined based on the service table.

[0038] The network-side service level corresponding to the service level of each server capability is determined based on the service template.

[0039] The service routing table is obtained by calculating the next hop and iterating the forwarding path for each network-side service level.

[0040] In this embodiment, refer to Figure 3 , Figure 3 This is a schematic diagram of a service routing network according to an embodiment of the present invention. Figure 3 As shown, computing power routing egress node 1 connects to service 1: instance 1 and service 1: instance 2 of the computing power server; computing power routing egress node 2 connects to service 1: instance 3 of the computing power server. Computing power routing egress nodes 1 and 2 obtain the following service table information through configuration distribution from the management system or through protocol interaction with the server: computing power service (computing power service identifier SID, service level), service instance IP, outgoing interface, next-hop information, service type, etc. When a user needs to access service 1, it connects to computing power routing ingress node 1 and computing power routing ingress node 2 via CPE (Customer-premises equipment).

[0041] In this system, both computing power routing ingress node 1 and computing power routing ingress node 2 are second routers, while both computing power routing egress node 1 and computing power routing egress node 2 are first routers. Computing power routing intermediate node 1 is a regular node between computing power routing ingress node 1 and computing power routing egress node 1, and computing power routing intermediate node 2 is a regular node between computing power routing ingress node 2 and computing power routing egress node 2. Computing power routing intermediate nodes 1 and 2 primarily function as information forwarding nodes.

[0042] The hierarchical service routing identifier uses SRv6 segmented routing. The SID includes a Locator (network addressing, including service routing addressing), a Function (service capability), and a Level (service level). The Function represents the provided service capability, while the service level is represented by the parameters of the SRv6 SID, corresponding to the service capability level provided by the computing power service and the network carrying requirements. For the same service, the Locator and Function are the same, but the Level can be different.

[0043] The service table formed based on the service instance information configured for the connection on computing power routing egress node 1 is as follows:

[0044] Service 1, Service Instance 1, IP 1, SID 1 (Locator+Function)+Level 0, Status (Green);

[0045] Service 1, Service Instance 2, IP 2, SID 1 (Locator+Function)+Level 1, Status (Green).

[0046] The service table formed based on the service instance information configured for the connection on computing power routing egress node 2 is as follows:

[0047] Service 1, Service Instance 3, IP 3, SID 1 (Locator+Function)+Level 1, Status (Green).

[0048] The service templates configured on computing power routing egress nodes 1 and 2 are as follows:

[0049] Service 1, Level 0, Color X;

[0050] Service 1, Level 1, color Y.

[0051] Based on the service table, the service level of the server capability corresponding to service instance 1 is determined to be Level 0, the service level of the server capability corresponding to service instance 2 is Level 1, and the service level of the server capability corresponding to service instance 3 is Level 1.

[0052] Based on the service template, the network-side service level corresponding to Service 1 Level 0 is determined to be color X, and the network-side service level corresponding to Service 1 Level 1 is determined to be color Y.

[0053] The computing power routing ingress node 1 can learn the service tables advertised by computing power routing egress nodes 1 and 2 through the extended BGP protocol. Based on the network-side service level (color), it calculates a suitable next-hop forwarding path, and prioritizes all next hops with a "Green" status in each service table to add them to the service routing table. Service instances with a service level of Level 0 are iterated to the compliant SRv6-TE Policy according to color X, and service instances with a service level of Level 1 are iterated to the compliant SRv6-TE Policy according to color Y. The resulting service routing table is as follows:

[0054] SID 1 Level 0, next-hop computing power routing egress node 1 IP, service SID_S1, instance IP1;

[0055] SID 1 Level 1, next-hop computing power routing exit node 1 IP, service SID_S1, instance IP2, weight w1;

[0056] SID 1 Level 1, next-hop computing power routing exit node 2 IP, service SID_S2, instance IP3, weight w2.

[0057] In this context, the initial state weights w1 = w2 = 1, and service request packets with a service level of Level 1 are load-balanced between the two instances IP2 and IP3.

[0058] Step S20: Update the service routing table based on the status of the service instance and the estimated load of the service instance.

[0059] In this embodiment, traffic forwarding is performed based on the service routing table constructed in step S10. After running for a period of time, if the status of a service instance is detected as unavailable, the unavailable service instance is deleted from the service routing table. If the traffic of any service instance among the service instances corresponding to the same service capability level increases significantly, and new service requests are still scheduled according to the original equal-cost load sharing method, it may further aggravate the load imbalance. Therefore, it is necessary to update the weight of each service instance in the service routing table to enable load balancing among the service instances.

[0060] In some specific embodiments, reference is made to Figure 4 , Figure 4 for Figure 1 A detailed flowchart of step S20. (See attached diagram.) Figure 4 As shown, step S20 includes:

[0061] Step S201: If it is determined that the status of the service instance is unavailable, then the service instance with the unavailable status is deleted from the service routing table.

[0062] In this embodiment, traffic forwarding is performed based on the service routing table constructed in step S10. The initial service routing table constructed is as follows:

[0063] SID 1 Level 0, next-hop computing power routing egress node 1 IP, service SID_S1, instance IP1;

[0064] SID 1 Level 1, next-hop computing power routing exit node 1 IP, service SID_S1, instance IP2, weight w1;

[0065] SID 1 Level 1, next-hop computing power routing exit node 2 IP, service SID_S2, instance IP3, weight w2.

[0066] After running for a period of time, if the traffic of service instance 3 increases significantly, exceeding its computing capacity, service instance 3 will notify the computing power routing egress node 2 of the real-time calculated λe and load threshold λmax. If the actual load λe of service instance 3 is greater than or equal to λmax and continues for a preset duration T, the status of service instance 3 will change to unavailable (Red). The computing power routing egress node 2 will then notify the computing power routing ingress node 1 and computing power routing ingress node 2 of the current status of service instance 3. The service table currently maintained on the computing power routing egress node 2, which is: Service 1, Service Instance 3, IP3, SID 1 (Locator+Function)+Level 1, Status (Green), will be updated to: Service 1, Service Instance 3, IP3, SID 1 (Locator+Function)+Level 1, Status (Red).

[0067] The computing power routing ingress node 1 learns the service table update announced by the computing power routing egress node 2 through the extended BGP protocol, updates the next hop of the route, and obtains the updated service routing table:

[0068] SID 1 Level 0, next-hop computing power routing egress node 1 IP, service SID_S1, instance IP1;

[0069] SID 1 Level 1, next-hop computing power routing exit node 1 IP, service SID_S1, instance IP2.

[0070] At this point, because service instance 3 is unavailable, it is removed from the next-hop list, and all new Level 1 service requests are routed to service instance 2. Removing service instance 3, which is in an unavailable state, from the service routing table avoids routing new service requests to the unavailable service instance 3.

[0071] Step S202: If, among the service instances corresponding to the same service capability level, there exists a service instance whose absolute value of the difference between the estimated load of the service instance and the estimated load of the service instance at the previous moment is greater than the product of the load of the service instance at the previous moment and the change threshold, then calculate the average load of each service instance corresponding to the same service capability level.

[0072] Step S203: Divide the average load by the load of each service instance, and use the quotient as the weight of each service instance corresponding to the same service capability level in the service routing table.

[0073] In this embodiment, traffic forwarding is performed based on the service routing table constructed in step S10. The initial service routing table constructed is as follows:

[0074] SID 1 Level 0, next-hop computing power routing egress node 1 IP, service SID_S1, instance IP1;

[0075] SID 1 Level 1, next-hop computing power routing exit node 1 IP, service SID_S1, instance IP2, weight w1;

[0076] SID 1 Level 1, next-hop computing power routing exit node 2 IP, service SID_S2, instance IP3, weight w2.

[0077] After running for a period of time, if the traffic scheduled to service instance 2 increases significantly, the weights of each service instance in the service routing table need to be updated to facilitate load balancing among the service instances. Specifically, if the traffic scheduled to service instance 2 increases significantly, i.e., the current service instance 2 satisfies |Li_new-Li_old|>Li_old*X%, then Li_old=Li_new is updated, and the estimated load of the current service instance 2 is notified to the computing power routing entry node 1 so that the computing power routing entry node 1 can detect the significant increase in traffic to service instance 2. The service level of the server capability corresponding to service instance 2 is Level 1. The service instances corresponding to the service level of Level 1 are service instance 2 and service instance 3. Therefore, it is also necessary to obtain the estimated load of the current service instance 3. Since the estimated load of service instance 3 has not been updated, the previous estimated load can be used.

[0078] The computing power routing ingress node 1 learns the estimated load updates of the service instances advertised by computing power routing egress nodes 1 and 2 through the extended BGP protocol, and records the estimated load of the current service instance 2 as L0 and the estimated load of the current service instance 3 as L1. It then calculates the average load L of each service instance corresponding to the service level of Level 1. In the formula, n is the total number of service instances corresponding to the same service capability level, and L... i The estimated load for the i-th service instance.

[0079] Divide the average load by the estimated load of service instance 2, and use the quotient as the weight w1′ of service instance 2 in the service routing table. Divide the average load by the estimated load of service instance 3, and use the quotient as the weight w2′ of service instance 3 in the service routing table.

[0080] The updated service routing table is as follows:

[0081] SID 1 Level 0, next-hop computing power routing egress node 1 IP, service SID_S1, instance IP1;

[0082] SID 1 Level 1, next-hop computing power routing exit node 1 IP, service SID_S1, instance IP2, weight w1′;

[0083] SID 1 Level 1, next-hop computing power routing exit node 2 IP, service SID_S2, instance IP3, weight w2′.

[0084] The new weights w1′ and w2′ are used as the weights for traffic load balancing. When forwarding traffic, the load is distributed according to the new weights. New service requests are less likely to be scheduled to service instance 2 and more likely to be scheduled to service instance 3, which balances the load between different instances and does not rely too much on the status announcements of service instances.

[0085] In this embodiment, a service routing table is constructed based on the service table and service template to map the service level (Level) of the server-side capability to the service level (Color) of the network side. This ensures that service capabilities and network capabilities are matched. The hierarchical service routing approach facilitates operation and maintenance management, avoids the large number of table entries required for fine-grained traffic scheduling, meets the needs of users with different service levels, and provides differentiated services. The service routing table is updated based on the status of service instances and the estimated load of service instances, enabling load balancing among different instances and improving resource utilization. Through this embodiment, service requests of different levels are forwarded according to the next hop of their respective service routes. Service requests of the same level achieve load balancing of traffic across multiple non-equivalent load-sharing paths, improving resource utilization, meeting differentiated user needs, and offering faster response times and simpler deployment. This solves the technical problem of low network and computing resource utilization in related technologies.

[0086] Optionally, in one embodiment, the state of the service instance is determined based on the actual load of the service instance, and the estimated load of the service instance is obtained through a traffic statistics model.

[0087] In this embodiment, the service node's ability to process requests is calculated based on the status of the service instance, which has two states: available and unavailable. An available state indicates that the node can be used to process service requests, while an unavailable state indicates that the node cannot be used to process service requests.

[0088] Select metrics λ1, λ2, λ3…λn that can be used to represent the load level of a service instance, such as the number of supported service connections, available resources, CPU / GPU / NPU performance, and storage capacity. Assign reasonable weight values ​​ω1, ω2, ω3…ωn to each metric, and comprehensively calculate the actual load λe of the service instance, which is defined as the system resource utilization rate. The quantification function of λe is expressed as: λe=ω1λ1+ω2λ2+ω3λ3+…ωnλn, where ω1+ω2+ω3+…+ωn=1. For example, for a compute-intensive service, CPU utilization and memory utilization are selected to characterize the load level, each with a weight of 0.5. The weighted sum of the two represents the system resource utilization rate of the service instance: λe=CPU utilization * 0.5 + memory utilization * 0.5.

[0089] The actual load of a service instance is calculated using metrics that represent its load level and their corresponding weights. This actual load is then compared to the instance's load threshold; based on the comparison result, the service instance's status can be determined.

[0090] Multiple service instances of the same service level can simultaneously provide that service level. Through the UCMP service routing table, traffic can be scheduled according to UCMP weights. Based on the traffic sent to and received from service instances, a traffic statistics model is used to obtain the statistical values ​​of each preset parameter of the service instance and the weight corresponding to each preset parameter statistical value. Then, based on each preset parameter statistical value and its corresponding weight, the estimated load of the service instance can be calculated.

[0091] Optionally, in one embodiment, the step of determining the state of a service instance based on its actual load includes:

[0092] In the initial state, the actual load of the service instance is compared with the load threshold of the service instance to obtain the comparison result;

[0093] If the comparison result shows that the actual load of the service instance is less than the load threshold of the service instance, then the service instance is determined to be available.

[0094] If the comparison result shows that the actual load of the service instance is greater than or equal to the load threshold of the service instance, then the service instance is determined to be unavailable.

[0095] In this embodiment, the actual load λe of the service instance when performance deteriorates is selected as the load threshold value of the service instance. For example, the λe value when the service latency of the service instance cannot meet the requirements, or a preset value is used as the load threshold value of the service instance. The load threshold value of the service instance is used to determine whether the service instance can continue to provide services.

[0096] Initial state: When the actual load λe of the service instance is less than the load threshold λmax of the service instance, the service instance is determined to be available (Green).

[0097] If the actual load λe of a service instance is greater than or equal to λmax, the service instance is determined to be in an unavailable (Red) state.

[0098] Optionally, in one embodiment, the step of obtaining the estimated load of a service instance through a traffic statistics model includes:

[0099] The statistical values ​​of each preset parameter of the service instance are obtained through the traffic statistics model;

[0100] By multiplying the statistical value of each preset parameter of the service instance by the weight corresponding to each preset parameter statistical value, the product corresponding to each preset parameter statistical value is obtained.

[0101] The products corresponding to the statistical values ​​of each preset parameter are accumulated, and the sum is used as the estimated load of the service instance.

[0102] In this embodiment, a traffic statistics approach is used. Through a traffic statistics model, the total number of packets destined for the service instance (ToPackets), the total number of packets originating from the service instance (FromPackets), the number of bytes destined for the service instance (ToBytes), and the number of bytes originating from the service instance (FromBytes) are calculated. The first router can estimate the load Li to a specific service instance based on one of these statistical values ​​or by combining all four statistical values ​​(with different weights wi).

[0103] Li=(w1*ToPackets+w2*FromPackes+w3*ToBytes+w4*FromBytes);

[0104] In the formula, 0 <= wi <= 1 and w1 + w2 + w3 + w4 = 1.

[0105] The weight of each statistic can be configured or adjusted through self-learning. For example, for interactive applications, outbound and inbound traffic can each account for half, while for non-interactive applications, only outbound traffic can be considered. Different applications can count bytes, packets, or a combination of both. Therefore, the selection of this weight value is application-dependent.

[0106] Specifically, taking service instance n as an example, service instance n:

[0107] Service A, Level i, {ToPackets,FromPackes,ToBytes,FromBytes}, {w1,w2,w3,w4}, sampling period: M1, change threshold: X%.

[0108] Detailed calculation process:

[0109] Li is initialized to 0, Li_old = Li;

[0110] The first router collects parameters with non-zero weights in the traffic statistics model according to the sampling period M1, and calculates the estimated load Li_new of the service instance according to the formula Li=(w1*ToPackets+w2*FromPackes+w3*ToBytes+w4*FromBytes).

[0111] Furthermore, if |Li_new-Li_old|<=Li_old*X%, then the first router will not advertise Li_new to the second router;

[0112] When |Li_new - Li_old| > Li_old * X%, the first router announces Li_new to the second router, and the first router updates Li_old = Li_new. Here, Li_old is the estimated load of the service instance at the previous moment.

[0113] Optionally, in one embodiment, reference is made to Figure 5 , Figure 5 This is a flowchart illustrating another embodiment of the service routing table management method of the present invention. Figure 5 As shown, after step S20, the following steps are included:

[0114] Step S30: If the actual load of a service instance that is in an available state is greater than or equal to the load threshold of the service instance, and this continues for a preset duration, then the available state of the service instance will be changed to an unavailable state.

[0115] In this embodiment, the updated service routing table in step S20 is used as the current service routing table, and traffic forwarding is performed based on the current service routing. If the current service routing table is:

[0116] SID 1 Level 0, next-hop computing power routing egress node 1 IP, service SID_S1, instance IP1;

[0117] SID 1 Level 1, next-hop computing power routing exit node 1 IP, service SID_S1, instance IP2, weight w1′;

[0118] SID 1 Level 1, next-hop computing power routing exit node 2 IP, service SID_S2, instance IP3, weight w2′.

[0119] If the actual load λe of service instance 2, which is in an available state, is greater than or equal to the load threshold λmax of the service instance, and this condition persists for a preset duration, then the available state of service instance 2 will be changed to an unavailable state. Then, step S201 will be executed. If it is determined that the state of the service instance is unavailable, then the service instance in an unavailable state will be deleted from the service routing table.

[0120] Optionally, in one embodiment, reference continues to be made to... Figure 5 After step S20, the following is included:

[0121] Step S40: If the actual load of a service instance that is in an unavailable state is less than the load threshold of the service instance and continues for a preset duration, then change the unavailable state of the service instance to an available state.

[0122] Step S50: Add the service instance with the status of available to the service routing table, and reassign the weights of each service instance corresponding to the service capability level to which the service instance belongs.

[0123] In this embodiment, the updated service routing table in step S20 is used as the current service routing table, and traffic forwarding is performed based on the current service routing. If the current service routing table is:

[0124] SID 1 Level 0, next-hop computing power routing egress node 1 IP, service SID_S1, instance IP1;

[0125] SID 1 Level 1, next-hop computing power routing exit node 1 IP, service SID_S1, instance IP2.

[0126] If the actual load λe of service instance 3, which is in an unavailable state, is less than the load threshold λmax of the service instance, and this load remains unavailable for a preset duration T, then the unavailable state of service instance 3 will be changed to an available state.

[0127] Add service instance 3, which is in an available state, to the service routing table, and reallocate the weights of each service instance corresponding to the service capability level to which service instance 3 belongs. That is, reallocate the weights of service instances 2 and 3 corresponding to the service capability service level Level 1 to which service instance 3 belongs. Specifically, if the estimated load of service instances 2 and 3 both satisfy |Li_new-Li_old|<=Li_old*X%, then the weights of service instances 2 and 3 are equal. If the estimated load of service instances 2 and / or the estimated load of service instances 3 satisfy |Li_new-Li_old|>Li_old*X%, then calculate the average load of each service instance (service instance 2 and service instance 3) corresponding to the service capability service level Level 1. Then, divide the average load by the load of service instance 2, and use the quotient as the weight of service instance 2. Divide the average load by the load of service instance 3, and use the quotient as the weight of service instance 3.

[0128] Optionally, in one embodiment, after step S20, the following is included:

[0129] Service requests of different service capability levels are forwarded according to the next hop of their respective service routes based on the updated service routing table.

[0130] Service requests of the same service capability level are forwarded between multiple non-equivalent load-sharing paths based on the updated service routing table.

[0131] In this embodiment, the updated service routing table is as follows:

[0132] SID 1 Level 0, next-hop computing power routing egress node 1 IP, service SID_S1, instance IP1;

[0133] SID 1 Level 1, next-hop computing power routing exit node 1 IP, service SID_S1, instance IP2, weight w1′;

[0134] SID 1 Level 1, next-hop computing power routing exit node 2 IP, service SID_S2, instance IP3, weight w2′.

[0135] For service requests with service capability level of Level 0 and service capability level of Level 1, service requests with service capability level of Level 0 are forwarded according to the instance IP1 corresponding to service capability level of Level 0; service requests with service capability level of Level 1 are forwarded according to the instance IP2 and instance IP3 corresponding to service capability level of Level 1.

[0136] For service requests with a service capability level of Level 1, instance IP2 and instance IP3 corresponding to the service capability level of Level 1 form a UCMP (Unequal Cost Multiple Path) path, and forward traffic according to the weight w1′ corresponding to instance IP2 and the weight w2′ corresponding to instance IP3 to achieve weighted load balancing of traffic.

[0137] Secondly, embodiments of the present invention also provide a service routing table management device.

[0138] In one embodiment, reference is made to Figure 6 , Figure 6 This is a functional module diagram of an embodiment of the service routing table management device of the present invention. Figure 6 As shown, the service routing table management device includes:

[0139] The routing table building module 10 is configured to build service routing tables based on service tables and service templates.

[0140] The information update module 20 is configured to update the service routing table based on the status of the service instance and the estimated load of the service instance.

[0141] Optionally, in one embodiment, the routing table construction module 10 is configured to:

[0142] The service level of the server capability corresponding to each service instance is determined based on the service table.

[0143] The network-side service level corresponding to the service level of each server capability is determined based on the service template.

[0144] The service routing table is obtained by calculating the next hop and iterating the forwarding path for each network-side service level.

[0145] Optionally, in one embodiment, the state of the service instance is determined based on the actual load of the service instance, and the estimated load of the service instance is obtained through a traffic statistics model.

[0146] Optionally, in one embodiment, the service routing table management device further includes an information determination module, configured to:

[0147] In the initial state, the actual load of the service instance is compared with the load threshold of the service instance to obtain the comparison result;

[0148] If the comparison result shows that the actual load of the service instance is less than the load threshold of the service instance, then the service instance is determined to be available.

[0149] If the comparison result shows that the actual load of the service instance is greater than or equal to the load threshold of the service instance, then the service instance is determined to be unavailable.

[0150] Optionally, in one embodiment, the information determination module is further configured to:

[0151] The statistical values ​​of each preset parameter of the service instance are obtained through the traffic statistics model;

[0152] By multiplying the statistical value of each preset parameter of the service instance by the weight corresponding to each preset parameter statistical value, the product corresponding to each preset parameter statistical value is obtained.

[0153] The products corresponding to the statistical values ​​of each preset parameter are accumulated, and the sum is used as the estimated load of the service instance.

[0154] Optionally, in one embodiment, the information update module 20 is configured to:

[0155] If it is determined that the service instance is unavailable, then the service instance with the unavailable status will be removed from the service routing table;

[0156] If, among the service instances corresponding to the same service capability level, there exists a service instance whose estimated load minus its estimated load at the previous moment is greater than the product of the service instance's previous load and the change threshold, then the average load of each service instance corresponding to the same service capability level is calculated.

[0157] The average load is divided by the load of each service instance, and the resulting quotient is used as the weight of each service instance corresponding to the same service capability level in the service routing table.

[0158] Optionally, in one embodiment, the information update module 20 is further configured to:

[0159] If the actual load of a service instance that is in an available state is greater than or equal to the load threshold of the service instance, and this continues for a preset duration, then the available state of the service instance will be changed to an unavailable state.

[0160] Optionally, in one embodiment, the information update module 20 is further configured to:

[0161] If the actual load of a service instance that is in an unavailable state is less than the load threshold of the service instance and continues for a preset duration, then the unavailable state of the service instance will be changed to an available state.

[0162] Add the service instance that is in an available state to the service routing table, and reassign the weights of each service instance corresponding to the service capability level to which the service instance belongs.

[0163] The functions of each module in the above-mentioned service routing table management device correspond to the steps in the above-mentioned service routing table management method embodiment, and their functions and implementation processes will not be described in detail here.

[0164] Thirdly, embodiments of the present invention also provide an electronic device, the structure of which is as follows: Figure 7 As shown, it includes: a memory and a processor, wherein the processor is used to read and execute the computer program stored in the memory to implement the aforementioned service routing table management method.

[0165] Fourthly, embodiments of the present invention also provide a computer storage medium storing computer-executable instructions, which, when executed, implement the aforementioned service routing table management method.

[0166] Fifthly, embodiments of the present invention provide a computer program product, which is stored in a storage medium and executed by at least one processor to implement the various processes of the service routing table management method embodiments described above, and can achieve the same technical effects. To avoid repetition, it will not be described again here.

[0167] Finally, it should be noted that while some processes described in the embodiments of the present invention include multiple operations or steps that appear in a specific order, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of the present invention, or may be executed in parallel. The sequence number of the operation is only used to distinguish different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.

[0168] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A service routing table management method characterized by comprising: The method comprises: determining a service-side capability service level corresponding to each service instance based on a service table; determining a network-side service level corresponding to each service-side capability service level based on a service template; calculating a next hop and iteratively forwarding a path through each network-side service level to obtain a service routing table; if it is determined that the state of the service instance is unavailable, deleting the service instance in an unavailable state from the service routing table; if, among service instances corresponding to a same service capability level, an absolute value of a difference between an estimated load of any service instance and a load of the service instance at a previous time is greater than a product of the load of the service instance at the previous time and a change threshold, calculating a load average of the service instances corresponding to the same service capability level; dividing the load average by the load of each service instance respectively to obtain a quotient as a weight of each service instance corresponding to the same service capability level in the service routing table.

2. The service route table management method according to claim 1, characterized by, The state of the service instance is determined based on an actual load of the service instance, and the estimated load of the service instance is obtained through a traffic statistical model.

3. The service route table management method according to claim 2, characterized by, The step of determining the state of the service instance based on the actual load of the service instance comprises: in an initial state, comparing the actual load of the service instance with a load threshold value of the service instance to obtain a comparison result; if the comparison result is that the actual load of the service instance is less than the load threshold value of the service instance, determining that the state of the service instance is available; if the comparison result is that the actual load of the service instance is greater than or equal to the load threshold value of the service instance, determining that the state of the service instance is unavailable.

4. The service route table management method according to claim 2, characterized by, The step of obtaining the estimated load of the service instance through the traffic statistical model comprises: obtaining each preset parameter statistical value of the service instance through the traffic statistical model; multiplying each preset parameter statistical value of the service instance by a weight corresponding to each preset parameter statistical value to obtain a product corresponding to each preset parameter statistical value; accumulating the products corresponding to each preset parameter statistical value to obtain a sum as the estimated load of the service instance.

5. The service route table management method according to any one of claims 1 to 4, characterized by, After the step of updating the service routing table based on the state of the service instance and the estimated load of the service instance, the method further comprises: if the actual load of the service instance in an available state is greater than or equal to the load threshold value of the service instance and lasts for a preset duration, changing the available state of the service instance to an unavailable state.

6. The service route table management method according to any one of claims 1 to 4, characterized by, After the step of updating the service routing table based on the state of the service instance and the estimated load of the service instance, the method further comprises: if the actual load of the service instance in an unavailable state is less than the load threshold value of the service instance and lasts for a preset duration, changing the unavailable state of the service instance to an available state; adding the service instance in the available state to the service routing table and reassigning weights of each service instance corresponding to a service capability level to which the service instance belongs.

7. The service route table management method of claim 1, wherein, After the step of updating the service routing table based on the state of the service instance and the estimated load of the service instance, the method further comprises: service requests of different service capability levels are forwarded based on the updated service routing table according to next hops of respective service routes. Service requests of the same service capability level are forwarded between multiple non-equal load sharing paths based on the updated service routing table.

8. A service route table management apparatus characterized by comprising: The apparatus comprises: A routing table construction module configured to determine a service capability service level corresponding to each service instance based on a service table; determine a network side service level corresponding to each service capability service level based on a service template; calculate a next hop through each network side service level and iterate a forwarding path to obtain a service routing table; An information update module configured to, if it is determined that a state of a service instance is unavailable, delete the service instance with the state of unavailable from the service routing table; if an absolute value of a difference between an estimated load of any service instance and a load of the service instance at a previous time of the service instance, corresponding to the same service capability level, is greater than a product of the load of the service instance at the previous time and a change threshold, calculate a load average of the service instances corresponding to the same service capability level; and divide the load average by a load of each service instance to obtain a quotient as a weight of each service instance corresponding to the same service capability level in the service routing table.

Images