A traffic management method under a service publishing platform

Abstract

The application discloses a traffic management method under a service publishing platform and belongs to the technical field of cloud computing and micro services. The method comprises the following steps: based on the Kubernetes, the Endpoint resource is used to listen to the Pod readiness state, and the HTTP gateway route is dynamically updated; the health check and traffic control interface are exposed through the traffic management SDK, the traffic control metadata in the Nacos registration center is maintained and updated; the message middleware consumer information is acquired through the traffic management SDK, and the traffic suspension and recovery interface is exposed; the mapping relationship is maintained through the metadata configuration center, the service discovery request is intercepted and rewritten through the proxy SDK, and the request is forwarded to the target Nacos cluster. The application realizes the lossless traffic management of the whole service life cycle, the accurate traffic suspension in the running time and the cross-cluster calling.

Description

Technical Field

[0001] This invention relates to the fields of cloud computing and microservices technology, and specifically to a traffic management method for a service publishing platform. Background Technology

[0002] With the increasing adoption of microservice architectures, more and more enterprises are using containerized deployments and unified release platforms to manage the service lifecycle. Throughout the entire process of service release, operation, update, and decommissioning, lossless traffic management has become crucial for ensuring business stability. However, existing technologies still present numerous challenges in traffic management.

[0003] A unified publishing platform supporting service deployment needs to possess the following traffic management capabilities: HTTP traffic should be accessible normally after service deployment; traffic should be lossless after the service is automatically registered with the registry center; traffic should be lossless during service version updates; remote procedure calls across registry center clusters should achieve traffic distribution; and traffic should be controllable during service operation. Specifically, during Java service startup, the RPC interface is registered with the Nacos registry center. The consumer service obtains the provider's IP address and port and makes the call. However, due to provider startup failure or improper maxSurge parameter or health check configuration during Kubernetes deployment, the call traffic continuously reports errors. Similarly, when a service goes offline, the node registered on Nacos does not immediately go offline. Due to Nacos's characteristics, it waits approximately 30 seconds without receiving a heartbeat before removing the node. This results in consumers still holding the IP address and port of the offline node during this period, leading to continuous call errors. Furthermore, during service operation, it may be necessary to pause certain traffic, such as suspending RPC services or message consumption from RocketMQ and Kafka, to troubleshoot online issues. When deploying multiple Pods of the same service in a Kubernetes environment, how to expose the service through an HTTP gateway and achieve unified traffic access and management is also an unsolved problem. At the same time, Nacos, as a widely used dynamic service discovery platform, only supports calls between services within the same namespace via native RPC calls. In daily development, different namespaces are often used to isolate business lines or different environments, but business scenarios may require cross-namespace calls, or different services deployed on different Nacos clusters may also require cross-cluster service calls.

[0004] To address the aforementioned issues, some existing technologies offer solutions. For traffic errors during service startup and shutdown, current technologies typically require developers to implement graceful shutdown code internally. However, such solutions suffer from high code invasiveness, lack of unified maintenance, and inability to handle startup failures. For traffic pauses during service operation, existing technologies can handle RPC traffic pauses through the native management console of the registry center, but cannot handle traffic pauses from message brokers like RocketMQ and Kafka. For HTTP traffic exposure, existing technologies use NodePort to expose services, but NodePort is limited by the number of available server ports, resulting in low scalability. For cross-Nacos cluster calls, the official solution provides data synchronization between different clusters, but this method suffers from data consistency issues, potentially leading to service call errors. Furthermore, no official solution is provided for cross-namespace calls.

[0005] In summary, existing technologies have the following main drawbacks: Firstly, the platform cannot uniformly address the lossless nature of RPC traffic during service startup and shutdown, requiring developers to handle graceful shutdown manually, while the traffic loss issue during startup remains unresolved. Secondly, during service operation, a unified platform capability cannot be used to pause traffic to message middleware such as RocketMQ and Kafka, nor can other middleware be stopped based on pause signals. Thirdly, when troubleshooting online issues, it is impossible to precisely pause a specific portion of traffic, leading to the identification of traffic interference issues from other channels. Fourthly, HTTP traffic exposure methods have limitations on the number of ports or cannot dynamically remove traffic from individual Pods, resulting in insufficient scalability and flexibility. Fifthly, cross-Nacos cluster calls rely on data synchronization, leading to data consistency issues, and cross-namespace calls lack official solutions. Summary of the Invention

[0006] The purpose of this invention is to provide a traffic management method for a service publishing platform, so as to solve the problem of imperfect traffic management throughout the entire service lifecycle in the prior art.

[0007] To achieve the above objectives, the technical solution adopted by the present invention is as follows: A traffic governance method for a service publishing platform includes the following steps: S1. Dynamic HTTP Traffic Management: Based on Kubernetes Endpoints resources, it monitors the readiness status of Pods under the target service in real time, dynamically updates the traffic routing and upstream configuration of the HTTP gateway, and determines the IP addresses and ports to be added and removed. S2. Lossless Traffic Addition and Drop: A health check interface and a traffic control interface are exposed through a traffic governance SDK integrated into the target service, and the traffic control metadata of the target service is maintained in the Nacos registry. When a new IP address and port are identified, the traffic governance SDK responds to the service publishing platform by calling a call to update the traffic control metadata corresponding to that IP to an enabled state; when a removed IP address and port are identified, the traffic governance SDK responds to the service publishing platform by calling a call to update the traffic control metadata corresponding to that IP to a disabled state. S3. Runtime Traffic Pause: Obtain consumer information of the message middleware in the current service instance through the traffic governance SDK integrated in the target service, and expose traffic pause and resume interfaces; S4. Cross-Registry Center Call: Maintain the mapping relationship between namespaces and Nacos clusters, as well as the mapping relationship between interfaces and namespaces, through the metadata configuration center; intercept service discovery requests sent by the target service to the Nacos registry center through the proxy SDK, rewrite the request parameters according to the information in the metadata configuration center, and forward them to the target Nacos cluster.

[0008] Furthermore, S1 includes: By using the Watch service and Kubernetes' ListAndWatch mechanism, we can monitor changes to the Endpoints resource under the Service resource corresponding to the target service, obtain the IP address and port of all ready Pods after each change, and use them as a set of ready Pod addresses. Get the IP addresses and ports currently bound to the HTTP gateway, and use them as the gateway binding address set; The set of ready Pod addresses is compared with the set of gateway bound addresses to determine the newly added IP addresses and ports and the removed IP addresses and ports. The newly added IP addresses and ports are those that exist in the set of ready Pod addresses but not in the set of gateway bound addresses, and the removed IP addresses and ports are those that do not exist in the set of ready Pod addresses but exist in the set of gateway bound addresses. For newly added IP addresses and ports, call the HTTP gateway's interface to upload the IP address and port to the HTTP gateway's upstream configuration, so that traffic can be directly routed to the corresponding Pod through the HTTP gateway; For the removed IP address and port, call the HTTP gateway's interface to remove the IP address and port from the HTTP gateway's upstream configuration.

[0009] Furthermore, S2 includes: when the target service starts, the traffic governance SDK exposes health check interfaces, current status query interfaces, traffic online interfaces, and traffic offline interfaces; and registers the traffic control status to the Nacos registry in the form of metadata.

[0010] Furthermore, S2 also includes: When the target service starts, the traffic governance SDK sets the traffic control metadata to the off state and registers it with the Nacos registry. Once a Pod of the target service is confirmed to be fully started via the health check interface, the Pod's IP address and port are added to the Endpoints resource. When a new IP address and port are identified by comparing the set of ready Pod addresses with the set of gateway bound addresses, the traffic access interface corresponding to that IP address and port is called; the traffic governance SDK responds to the corresponding traffic access interface and updates the traffic control metadata of all interfaces of the target service in the Nacos registry to the enabled state; When consumers obtain a list of service instances through the Nacos registry, the service instances with traffic control metadata set to "off" are filtered out from the returned results, so that consumers only obtain service instances with traffic control metadata set to "on". When the set of ready Pod addresses is compared with the set of gateway bound addresses and it is determined that there are IP addresses and ports to be removed, the traffic offline interface corresponding to the IP address and port is called; the traffic governance SDK responds to the corresponding traffic offline interface and updates the traffic control metadata of all interfaces of the target service in the Nacos registry to the closed state; When consumers obtain a list of service instances through the Nacos registry, the returned results are filtered out for service instances whose traffic control metadata is disabled, preventing consumers from obtaining service instances with disabled traffic control metadata.

[0011] Furthermore, S3 includes: The traffic governance SDK obtains all RocketMQ consumer groups in the current service instance through reflection, calls the native suspend() method to pause consumption, and calls the resume() method to resume consumption.

[0012] Furthermore, S3 includes: The traffic governance SDK obtains all Kafka MessageListenerContainers in the current service instance through the native API, calls the native pause() method to pause consumption, and calls the resume() method to resume consumption.

[0013] Furthermore, S3 includes: The traffic governance SDK stores the traffic pause status locally in the form of key-value pairs. The value of the key-value pair serves as a traffic pause signal, which is read by other middlewares besides the message middleware through the Java SPI mechanism. Other middlewares decide whether to pause scheduling or execute tasks based on the read traffic pause signal value.

[0014] Furthermore, S4 includes: The metadata configuration center obtains all namespace information from each Nacos cluster and stores the mapping relationship between namespaces and Nacos clusters; When the target service starts, the proxy SDK intercepts the registration request and reports the mapping relationship between the interface and the namespace to the metadata configuration center; When the target service performs service discovery, the proxy SDK intercepts the service discovery request and parses the dependent interface names in the service discovery request; The proxy SDK queries the mapping relationship between the interface and the namespace based on the dependent interface name, and obtains the namespace ID where the dependent interface is located; The proxy SDK queries the mapping relationship between the namespace and the Nacos cluster based on the namespace ID where the dependent interface is located, and obtains the Nacos cluster address where the dependent interface is located. The proxy SDK modifies the target address of the service discovery request to the Nacos cluster address, and modifies the namespace ID in the service discovery request to the namespace ID of the dependent interface. It then forwards the request to the target Nacos cluster, retrieves the list of service instances of the dependent interface, and returns it to the target service.

[0015] Furthermore, in S4, the target service modifies the original Nacos cluster address to the address of the proxy SDK, so that all requests sent to the Nacos registry center are intercepted and processed by the proxy SDK.

[0016] Furthermore, it also includes HTTP proactive flow control: The service publishing platform calls the HTTP gateway's interface to temporarily set the traffic weight of the IP address and port of the target service's Pod to zero, thereby temporarily removing HTTP traffic from the Pod to facilitate online troubleshooting. After the troubleshooting is completed, the service publishing platform calls the HTTP gateway's interface to restore the traffic weight of the IP address and port to the preset value.

[0017] Compared with the prior art, the present invention has the following beneficial effects: 1. This invention solves the problem of traffic loss throughout the entire process of service startup, deployment, update, and shutdown by implementing dynamic HTTP traffic management and lossless traffic uploading and unloading. Specifically, during service startup, the Pod's IP is added to Endpoints only after the health check interface confirms that the service is fully started, and the metadata is updated to an enabled state via the traffic uploading interface, ensuring that consumers only obtain healthy service instances. During service shutdown, the metadata is updated to a disabled state via the traffic shutdown interface, preventing consumers from obtaining the service instance again. This mechanism completely solves the traffic error problems caused by service startup failures or unreasonable health check configurations in existing technologies, as well as the traffic error problems caused by the registry center's failure to remove nodes in a timely manner when a service is shut down. It achieves lossless traffic access and removal, ensuring business continuity.

[0018] 2. This invention achieves precise control over traffic to message middleware such as RocketMQ and Kafka by pausing traffic at runtime. The traffic governance SDK obtains consumer group information through reflection, calls native methods to pause or resume consumption, and exposes an HTTP interface for platform use. Simultaneously, through key-value pair storage and the Java SPI mechanism, other middleware such as XXL-Job can read the traffic pause signal and stop scheduling or executing tasks as needed. This mechanism allows operations personnel to precisely pause specific channel traffic for a service instance when troubleshooting online issues, preventing other traffic from interfering with problem localization, improving the efficiency and security of fault diagnosis, and simultaneously resolving the problem of service crashes caused by premature traffic influx during service startup.

[0019] 3. This invention utilizes dynamic HTTP traffic management, leveraging Kubernetes Endpoints resources to monitor Pod readiness status in real time and dynamically update HTTP gateway traffic routing and upstream configurations. Compared to the existing NodePort approach, this invention is not limited by the number of ports; compared to using fixed IPs exposed via service resources, this invention can dynamically remove and restore traffic to individual Pods. By comparing the set of ready Pod addresses with the gateway's bound address set through the Watch service, it can automatically bring new IPs online, take removed IPs offline, or reset their weights to zero, allowing traffic to be directly routed to Pods through the gateway. This provides strong scalability and high flexibility.

[0020] 4. This invention utilizes cross-registry center calls, leveraging a metadata configuration center to maintain the mapping relationship between namespaces and Nacos clusters, as well as the mapping relationship between interfaces and namespaces. A proxy SDK intercepts service discovery requests from the target service destined for the Nacos registry, rewrites the request parameters based on information from the metadata configuration center, and forwards them to the target Nacos cluster. This solution overcomes the limitation of Nacos natively supporting only services within the same namespace, and addresses the data consistency issues present in the official cross-cluster data synchronization solution. It achieves completely transparent cross-namespace and cross-Nacos cluster service discovery and invocation to the application layer, breaking down architectural barriers caused by environment isolation or business line isolation, and promoting service reuse and integration.

[0021] 5. This invention consolidates all traffic management capabilities onto the platform side, including dynamic HTTP traffic management, lossless traffic shutdown and restart, runtime traffic pause, and cross-registration center calls. Each business application only needs to integrate the traffic management SDK according to the specifications to obtain complete traffic management capabilities. Compared to existing technologies that require developers to implement graceful shutdown code and traffic pause logic within each service, this invention avoids redundant development, reduces development costs and maintenance complexity, and achieves unified, standardized, and platform-based traffic management capabilities.

[0022] 6. This invention achieves unified management and control of traffic from multiple channels, including RPC, RocketMQ, Kafka, and HTTP. Specifically, it enables lossless online / offline control of RPC traffic through a traffic control interface that ensures seamless online / offline operation; it allows for precise pausing and resuming of RocketMQ and Kafka message middleware traffic through runtime traffic pausing; and it provides dynamic management and proactive control of HTTP traffic through dynamic HTTP traffic management. The platform can pause or resume traffic on specified channels for any service instance as needed. Traffic control for each channel is independent and does not interfere with each other, providing operations and maintenance personnel with a comprehensive traffic management toolkit. Attached Figure Description

[0023] Figure 1 This is a flowchart of the method of the present invention.

[0024] Figure 2 This is a flowchart of the dynamic traffic management process of S1 in this invention.

[0025] Figure 3 This is a flowchart of the lossless online / offline process of S2 in this invention.

[0026] Figure 4 This is a flowchart of the cross-registration center call process in S4 of the present invention. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this invention, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0028] like Figure 1 As shown, this invention provides a traffic governance method for a service publishing platform, used to achieve lossless access and dynamic management of HTTP traffic during service publishing. It includes the following steps: S1. Based on Kubernetes Endpoints resources, monitor the readiness status of Pods under the target service in real time, dynamically update the traffic routing and upstream configuration of the HTTP gateway, and determine the IP addresses and ports to be added and removed. S2. Expose health check and traffic control interfaces through the traffic governance SDK integrated into the target service, and maintain the traffic control metadata of the target service in the Nacos registry; when a new IP address and port are identified, the traffic governance SDK responds to the platform call to update the traffic control metadata corresponding to the IP to the enabled state; when a removed IP address and port are identified, the traffic governance SDK responds to the platform call to update the traffic control metadata corresponding to the IP to the disabled state. S3. Obtain consumer information of the message middleware in the current service instance through the traffic governance SDK integrated in the target service, and expose traffic pause and resume interfaces; S4. Maintain the mapping relationship between namespaces and Nacos clusters, as well as the mapping relationship between interfaces and namespaces, through the metadata configuration center; intercept service discovery requests sent by the target service to the Nacos registry center through the proxy SDK, rewrite the request parameters according to the information in the metadata configuration center, and forward them to the target Nacos cluster.

[0029] Through the four steps described above, this invention constructs a complete traffic governance system for a service publishing platform. S1 implements dynamic automatic governance of HTTP traffic; S2 implements lossless traffic uploading and unloading; S3 implements runtime traffic pause for message middleware and other middleware; and S4 enables service calls across Nacos clusters and namespaces. These steps cooperate and work together to achieve unified control over traffic from multiple channels such as HTTP, RPC, RocketMQ, and Kafka, covering various traffic governance scenarios throughout the service lifecycle. This significantly improves the stability and efficiency of service publishing and reduces operational complexity.

[0030] In one specific embodiment of the present invention, such as Figure 2As shown, S1 includes: The Watch service leverages Kubernetes' ListAndWatch mechanism to monitor changes to the Endpoints resource under the Service resource corresponding to the target service. The Endpoints resource records the IP addresses and ports of all Pods in the Ready state under this Service. When the Endpoints resource changes (e.g., a Pod is added or removed), the Watch service obtains the IP addresses and ports of all currently ready Pods after each change, and uses this as a set of ready Pod addresses.

[0031] Meanwhile, the Watch service obtains the IP addresses and ports currently bound to the HTTP gateway, which serve as the gateway binding address set. The HTTP gateway can be a cloud-native gateway such as APISIX, Nginx, Spring Cloud Gateway, or a self-developed gateway, used to uniformly access HTTP traffic and route it to the backend Pods.

[0032] The Watch service compares the set of ready Pod addresses with the set of gateway bound addresses to determine newly added and removed IP addresses and ports. Newly added IP addresses and ports are those that exist in the set of ready Pod addresses but not in the set of gateway bound addresses, while removed IP addresses and ports are those that do not exist in the set of ready Pod addresses but do exist in the set of gateway bound addresses.

[0033] For newly added IP addresses and ports, the Watch service calls the HTTP gateway's interface to upload the IP address and port to the HTTP gateway's upstream configuration. After the upload is complete, the HTTP gateway adds the newly added Pod to the upstream service list, enabling subsequent HTTP traffic to be directly routed to the newly ready Pod through the gateway, thus achieving traffic access for the new service.

[0034] For the removed IP address and port, the Watch service calls the HTTP gateway's interface to remove the IP address and port from the HTTP gateway's upstream configuration. After the removal is complete, the HTTP gateway removes the Pod from the upstream service list and no longer routes traffic to that Pod, thus removing traffic from the old service.

[0035] Through the above dynamic online and offline operations, the HTTP gateway always maintains a list of upstream services that is consistent with the ready Pods in the Kubernetes cluster, enabling traffic to be directly routed to the correct Pod through the HTTP gateway without secondary forwarding through the Service, thus achieving dynamic and efficient management of HTTP traffic.

[0036] In one specific embodiment of the present invention, S2 includes: The traffic governance SDK integrated into the target service exposes four fixed HTTP endpoint paths upon service startup: a health check interface, a current status query interface, a traffic uplink interface, and a traffic downlink interface, used for health checks and traffic control. For example, the HTTP endpoint path for the health check interface could be ` / health / depends`, the current status query interface could be ` / flowcontrol / status`, the traffic uplink interface could be ` / flowcontrol / online`, and the traffic downlink interface could be ` / flowcontrol / offline`. The health check interface is used by Kubernetes probes to detect the target service's readiness; the current status query interface, traffic uplink interface, and traffic downlink interface are exposed as HTTP interfaces for platform calls.

[0037] Meanwhile, the traffic governance SDK registers the traffic control status with the Nacos registry center in the form of metadata. Specifically, the traffic governance SDK can mark the traffic control status as off at startup by adding custom metadata, such as setting `dubbo.application.parameters.flow-control=off` in the Dubbo framework or `spring.cloud.nacos.discovery.metadata.flow-control=off` in the Spring Cloud framework, indicating that the service instance initially does not receive traffic.

[0038] Through the above methods, this invention provides the interface and metadata foundation for subsequent lossless traffic uploading and unloading.

[0039] In one specific embodiment of the present invention, such as Figure 3 As shown, S2 also includes lossless traffic uplink and downlink, as detailed below: When the target service starts, the traffic governance SDK sets the traffic control metadata to the off state (flow-control=off) and registers it with the Nacos registry. Kubernetes configures the health check path to the HTTP endpoint path corresponding to the health check interface, i.e., / health / depends (the check logic can also be implemented in this path). After confirming that a Pod of the target service has started completely through this interface, the IP address and port of the Pod are automatically added to the Endpoints resource.

[0040] When a new IP address and port are identified by comparing the set of ready Pod addresses with the set of gateway-bound addresses, the Watch service calls the traffic uploading interface ` / flowcontrol / online` corresponding to that IP address and port. The traffic governance SDK responds to this traffic uploading interface, retrieves all registered interfaces within the service, and updates them to the enabled state (`flow-control=on`) in the Nacos registry's metadata. At this point, when consumers retrieve the service instance list through the Nacos registry, the returned results filter out service instances with `flow-control` metadata set to disabled, ensuring that consumers only obtain service instances with `flow-control` metadata set to enabled, thus achieving lossless traffic uploading.

[0041] When the set of ready Pod addresses is compared with the set of gateway-bound addresses, and a removed IP address and port are identified, the Watch service calls the traffic offline interface ` / flowcontrol / offline` corresponding to that IP address and port. The traffic governance SDK responds to this interface by updating the flow control metadata of all interfaces for the target service in the Nacos registry to the off state (`flow-control=off`). When consumers retrieve the service instance list through the Nacos registry, the returned results filter out service instances with flow control metadata in the off state, preventing consumers from obtaining such instances and thus achieving lossless traffic offline.

[0042] By filtering consumers in the above manner, ensuring that they only obtain service instances in the "on" state, lossless online / offline processing of RPC traffic is achieved. This solves the problems of traffic errors caused by service startup failures, unreasonable health check configurations, and the failure of the registry center to remove nodes in a timely manner when services are taken offline.

[0043] S3 and S2 share the same traffic management SDK. This traffic management SDK is integrated into the target service, providing both lossless traffic uploading and unloading capabilities and runtime traffic pause capabilities.

[0044] In one specific embodiment of the present invention, the RocketMQ traffic pause in S3 is as follows: When the traffic governance SDK starts, it uses Java reflection to obtain all RocketMQ consumer groups in the current service instance and exposes an HTTP interface for the platform to call. When the platform calls this interface to trigger a pause operation, the traffic governance SDK iterates through all consumer groups and calls the native suspend() method to pause message consumption; when the platform calls this interface to trigger a resume operation, the traffic governance SDK calls the native resume() method to resume message consumption.

[0045] The above methods enable precise pausing and resuming of RocketMQ traffic, allowing operations and maintenance personnel to pause message consumption when troubleshooting online issues and avoid message interference in problem localization.

[0046] In one specific embodiment of the present invention, the Kafka traffic pause in S3 is as follows: When the traffic governance SDK starts, it retrieves all Kafka MessageListenerContainers in the current service instance through the Kafka native API and exposes an HTTP interface for the platform to call. When the platform calls this interface to trigger a pause operation, the traffic governance SDK iterates through all MessageListenerContainers and calls the native pause() method to pause message consumption; when the platform calls this interface to trigger a resume operation, the traffic governance SDK calls the native start() method to resume message consumption.

[0047] The above methods enable precise pausing and resumption of Kafka traffic, allowing operations and maintenance personnel to pause message consumption when troubleshooting online issues and avoid message interference in problem localization.

[0048] In one specific embodiment of the present invention, the flow pause signal extension mechanism in S3 is as follows: The traffic governance SDK stores the traffic pause status in local memory as key-value pairs (e.g., `flow-pause=true` indicates pause, `flow-pause=false` indicates resumption). The value of this key-value pair is the traffic pause signal. The traffic governance SDK exposes this signal through the Java SPI mechanism. Other middleware (such as the XXL-Job scheduled task scheduler) can read this signal value through SPI and determine whether to pause scheduling or execute tasks based on the read signal value. For example, when the signal value is true, XXL-Job stops scheduling tasks for that service instance; when the signal value is false, scheduling resumes.

[0049] By using the above method, the ability to pause traffic is extended to other middleware besides message middleware, thus achieving broader traffic control coverage.

[0050] In one specific embodiment of the present invention, the cross-registration center call of S4 is independent of S1-S3, and is used to solve the service call problem between different Nacos clusters and different namespaces. For example... Figure 4 As shown, its specific implementation includes: First, build the metadata configuration center. The metadata configuration center is a service component used to store and manage mapping relationships. Its construction method is as follows: First, the metadata configuration center retrieves all namespace information for each Nacos cluster by calling the management API of each Nacos cluster (the unique ID of a namespace is a string of characters that will not be repeated).

[0051] Then, the metadata configuration center stores the obtained namespace and its corresponding Nacos cluster as a [namespace → Nacos cluster] mapping relationship.

[0052] In addition, the metadata configuration center also maintains the mapping relationship between interfaces and namespaces. This mapping relationship originates from the reports submitted by the proxy SDK: when a target service starts and registers with Nacos, the proxy SDK intercepts the registration request, extracts the interface name, and combines it with the namespace ID of the target service to form a mapping relationship, which is then reported to the metadata configuration center for storage.

[0053] In this way, the metadata configuration center maintains two core mapping tables, providing a query basis for subsequent cross-namespace and cross-cluster calls.

[0054] When the target service performs service discovery, the proxy SDK intercepts the service discovery request and parses the dependent interface name in the service discovery request URL. For example, when the target service s1 needs to call the dependent service s2, it will send a service discovery request with the request path / nacos / v1 / ns / instance / list?serviceName=s2&namespaceId=namespace-1, where serviceName=s2 is the dependent interface name and namespaceId=namespace-1 is the namespace ID of the target service.

[0055] The proxy SDK queries the [interface → namespace] mapping relationship based on the dependent interface name to obtain the namespace ID of the dependent interface. For example, querying the metadata configuration center using serviceName=s2, it finds that the namespace ID of the dependent service s2 is namespace-2.

[0056] Then, the proxy SDK uses the namespace ID to query the mapping relationship between the namespace and the Nacos cluster, and obtains the Nacos cluster address where the dependent interface is located. For example, querying the metadata configuration center based on namespace-2, it obtains the Nacos cluster address corresponding to this namespace as nacos1.xx.cn.

[0057] The proxy SDK modifies the target address of the service discovery request to the Nacos cluster address, and modifies the namespace ID in the service discovery request to the namespace ID of the dependent interface. It then forwards the request to the target Nacos cluster, retrieves the list of service instances of the dependent interface, and returns it to the target service.

[0058] For example, target service s1 needs to call dependent service s2. The proxy SDK intercepts the service discovery request, parses it to obtain the dependent interface name s2, queries the metadata configuration center to obtain the namespace ID of s2 as namespace-2, and then queries the corresponding Nacos cluster address nacos1.xx.cn based on namespace-2. The proxy SDK rewrites the service discovery request to http: / / nacos1.xx.cn / nacos / v1 / ns / instance / list?serviceName=s2&namespaceId=namespace-2, forwards it to this Nacos cluster (the target Nacos cluster), obtains the IP address and port of s2, and returns them to s1. Subsequently, s1 directly requests s2 based on the obtained IP address and port, achieving cross-namespace calls. When the dependent service is located in different Nacos clusters (for example, s3 is located in another Nacos cluster), the processing flow is exactly the same, only the cluster address obtained is different.

[0059] The above approach enables service discovery and invocation across namespaces and Nacos clusters that are completely transparent to the application layer. This solves the limitation that Nacos natively only supports service invocation within the same namespace, as well as the data consistency issues present in the official cross-cluster data synchronization solution.

[0060] In one specific embodiment of the present invention, the proxy SDK address in S4 is configured as follows: To implement the interception and forwarding functions, the target service needs to change the original Nacos cluster address to the address of the proxy SDK. Specifically, the original Nacos IP address and port (address1) should be changed to the IP address and port exposed by the proxy SDK (address2), for example, 127.0.0.1:port.

[0061] After the modification, all requests sent to the Nacos registry (such as service discovery requests and registration requests) will be intercepted and processed by the proxy SDK, which will then rewrite and forward them based on the information in the metadata configuration center.

[0062] The above method enables non-intrusive proxy configuration at the application layer, allowing cross-registration center calls without modifying business code.

[0063] In one specific embodiment of the present invention, HTTP active traffic control is also included as a supplement to S1, for maintenance personnel to manually control HTTP traffic.

[0064] The platform calls the HTTP gateway's interface to temporarily set the traffic weight of the IP address and port of the target service's Pod to zero, thereby temporarily removing the Pod's HTTP traffic to facilitate online troubleshooting. After the troubleshooting is completed, the platform calls the HTTP gateway's interface to restore the traffic weight of the IP address and port to the preset value (e.g., 100).

[0065] Through the above methods, active control of HTTP traffic is achieved, complementing S1 and providing operators with flexible manual traffic control capabilities.

[0066] Finally, it should be noted that the above embodiments are merely preferred embodiments of the present invention used to illustrate the technical solutions of the present invention, and are not intended to limit the invention, nor are they intended to limit the patent scope of the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. These modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention. That is to say, any changes or refinements made to the main design concept and spirit of the present invention that are not of substantial significance, but whose technical problems are still consistent with the present invention, should be included within the protection scope of the present invention. In addition, the direct or indirect application of the technical solutions of the present invention to other related technical fields are similarly included within the patent protection scope of the present invention.

Claims

1. A traffic management method for a service publishing platform, characterized in that, Includes the following steps: S1. Based on Kubernetes Endpoints resources, monitor the readiness status of Pods under the target service in real time, dynamically update the traffic routing and upstream configuration of the HTTP gateway, and determine the IP addresses and ports to be added and removed. S2. Expose health check and traffic control interfaces through the traffic governance SDK integrated into the target service, and maintain the traffic control metadata of the target service in the Nacos registry; when a new IP address and port are identified, the traffic governance SDK responds to the service publishing platform by calling to update the traffic control metadata corresponding to the IP to the enabled state; when a removed IP address and port are identified, the traffic governance SDK responds to the service publishing platform by calling to update the traffic control metadata corresponding to the IP to the disabled state. S3. Obtain consumer information of the message middleware in the current service instance through the traffic governance SDK integrated in the target service, and expose traffic pause and resume interfaces; S4. Maintain the mapping relationship between namespaces and Nacos clusters, as well as the mapping relationship between interfaces and namespaces, through the metadata configuration center; intercept service discovery requests sent by the target service to the Nacos registry center through the proxy SDK, rewrite the request parameters according to the information in the metadata configuration center, and forward them to the target Nacos cluster.

2. The traffic management method under a service publishing platform according to claim 1, characterized in that, S1 includes: By using the Watch service and Kubernetes' ListAndWatch mechanism, we can monitor changes to the Endpoints resource under the Service resource corresponding to the target service, obtain the IP address and port of all ready Pods after each change, and use them as a set of ready Pod addresses. Get the IP addresses and ports currently bound to the HTTP gateway, and use them as the gateway binding address set; The set of ready Pod addresses is compared with the set of gateway bound addresses to determine the newly added IP addresses and ports and the removed IP addresses and ports. The newly added IP addresses and ports are those that exist in the set of ready Pod addresses but not in the set of gateway bound addresses, and the removed IP addresses and ports are those that do not exist in the set of ready Pod addresses but exist in the set of gateway bound addresses. For newly added IP addresses and ports, call the HTTP gateway's interface to upload the IP address and port to the HTTP gateway's upstream configuration, so that traffic can be directly routed to the corresponding Pod through the HTTP gateway; For the removed IP address and port, call the HTTP gateway's interface to remove the IP address and port from the HTTP gateway's upstream configuration.

3. The traffic management method under a service publishing platform according to claim 2, characterized in that, S2 includes: When the traffic governance SDK starts the target service, it exposes health check interfaces, current status query interfaces, traffic online interfaces, and traffic offline interfaces; and registers the traffic control status to the Nacos registry in the form of metadata.

4. The traffic management method under a service publishing platform according to claim 3, characterized in that, S2 also includes: When the target service starts, the traffic governance SDK sets the traffic control metadata to the off state and registers it with the Nacos registry. Once a Pod of the target service is confirmed to be fully started via the health check interface, the Pod's IP address and port are added to the Endpoints resource. When a new IP address and port are identified by comparing the set of ready Pod addresses with the set of gateway bound addresses, the traffic access interface corresponding to that IP address and port is called; the traffic governance SDK responds to the corresponding traffic access interface and updates the traffic control metadata of all interfaces of the target service in the Nacos registry to the enabled state; When consumers obtain a list of service instances through the Nacos registry, the service instances with traffic control metadata set to "off" are filtered out from the returned results, so that consumers only obtain service instances with traffic control metadata set to "on". When the set of ready Pod addresses is compared with the set of gateway bound addresses and it is determined that there are IP addresses and ports to be removed, the traffic offline interface corresponding to the IP address and port is called; the traffic governance SDK responds to the corresponding traffic offline interface and updates the traffic control metadata of all interfaces of the target service in the Nacos registry to the closed state; When consumers obtain a list of service instances through the Nacos registry, the returned results are filtered out for service instances whose traffic control metadata is disabled, preventing consumers from obtaining service instances with disabled traffic control metadata.

5. The traffic management method under a service publishing platform according to claim 1, characterized in that, S3 includes: The traffic governance SDK obtains all RocketMQ consumer groups in the current service instance through reflection, calls the native suspend() method to pause consumption, and calls the resume() method to resume consumption.

6. The traffic management method under a service publishing platform according to claim 1, characterized in that, S3 includes: The traffic governance SDK obtains all Kafka MessageListenerContainers in the current service instance through the native API, calls the native pause() method to pause consumption, and calls the resume() method to resume consumption.

7. The traffic management method under a service publishing platform according to claim 1, characterized in that, S3 includes: The traffic governance SDK stores the traffic pause status locally in the form of key-value pairs. The value of the key-value pair serves as a traffic pause signal, which is read by other middleware except message middleware through the Java SPI mechanism. Other middleware decides whether to pause scheduling or execute tasks based on the read traffic pause signal value.

8. The traffic management method under a service publishing platform according to claim 1, characterized in that, S4 include: The metadata configuration center obtains all namespace information from each Nacos cluster and stores the mapping relationship between namespaces and Nacos clusters; When the target service starts, the proxy SDK intercepts the registration request and reports the mapping relationship between the interface and the namespace to the metadata configuration center; When the target service performs service discovery, the proxy SDK intercepts the service discovery request and parses the dependent interface names in the service discovery request; The proxy SDK queries the mapping relationship between the interface and the namespace based on the dependent interface name, and obtains the namespace ID where the dependent interface is located; The proxy SDK queries the mapping relationship between the namespace and the Nacos cluster based on the namespace ID where the dependent interface is located, and obtains the Nacos cluster address where the dependent interface is located. The proxy SDK modifies the target address of the service discovery request to the Nacos cluster address, and modifies the namespace ID in the service discovery request to the namespace ID of the dependent interface. It then forwards the request to the target Nacos cluster, retrieves the list of service instances of the dependent interface, and returns it to the target service.

9. A traffic management method for a service publishing platform according to claim 8, characterized in that, In S4, the target service modifies the original Nacos cluster address to the address of the proxy SDK, so that all requests sent to the Nacos registry center are intercepted and processed by the proxy SDK.

10. The method according to claim 1, characterized in that, It also includes HTTP active flow control: The service publishing platform calls the HTTP gateway's interface to temporarily set the traffic weight of the IP address and port of the Pod under the target service to zero, so as to temporarily remove the HTTP traffic of the Pod and facilitate online problem troubleshooting. After the investigation is completed, the service publishing platform calls the HTTP gateway's interface to restore the traffic weight of the IP address and port to the preset value.

Images