Multi-cluster service orchestration method and terminal

Abstract

The present application relates to the technical field of new energy management system, and more particularly to a multi-cluster service orchestration method and a terminal. The method comprises: a configuration server creating a first namespace and a second namespace, and configuring states of switch items in the first namespace and the second namespace, the switch items being used to control the start or stop of tasks on a business server; the business server reading the states of the switch items from a corresponding namespace according to a business cluster type to which the business server belongs, the namespace being one of the first namespace and the second namespace; the business server running the tasks according to the states of the switch items; and the configuration server modifying the states of the switch items in the namespace after receiving a failure signal of the business server of the first business cluster type, and routing all task requests to the business server of the second business cluster type. The present application improves system stability and resource utilization efficiency.

Description

Technical Field

[0001] This invention relates to the field of new energy management system technology, and in particular to a multi-cluster service orchestration method and terminal. Background Technology

[0002] As the scale of new energy vehicle charging stations continues to expand, charging station management systems need to simultaneously handle user charging, station operation, and equipment maintenance, leading to increasingly higher requirements for the stability of user charging services. Current common practices for improving stability mainly fall into two categories.

[0003] One approach is to globally add service nodes to the management system. Since charging and non-charging services are deeply coupled within the system, simply adding nodes cannot effectively isolate these services and offers very limited stability improvements. Furthermore, running multiple nodes in parallel can lead to duplicate execution of scheduled tasks and repeated consumption of messages in the Message Queue, resulting in significant server resource consumption and waste. Another approach is to separate the charging and non-charging service code and deploy them as independent microservices. While this physical separation achieves business isolation, it requires deep refactoring of existing code, resulting in a massive workload and a lengthy process. The microservice architecture also significantly increases the difficulty of maintaining the code later on.

[0004] This leads to a dilemma for the existing system: global expansion of nodes fails to effectively improve stability due to business coupling and severely wastes computing resources; while code splitting and microservices bring excessively high transformation costs and maintenance complexity. The system cannot achieve a balance between resource consumption, architecture maintenance, and business isolation. The underlying reason is that the existing architecture lacks a mechanism for fine-grained service orchestration and resource isolation based on different business characteristics, making it impossible to achieve on-demand scheduling and independent high-availability operation of charging services without disrupting the original architecture. Summary of the Invention

[0005] The technical problem to be solved by this invention is to provide a multi-cluster service orchestration method to improve system stability and resource utilization efficiency.

[0006] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: A multi-cluster service orchestration method is applied to a configuration server. The method includes: the configuration server creating a first namespace and a second namespace, configuring the state of switch items in the first and second namespaces respectively, the switch items being used to control the enabling or stopping of tasks on the business servers; the business servers reading the state of the switch items from the corresponding namespace according to their respective business cluster types, the namespace being either the first or the second namespace; the business servers running tasks according to the state of the switch items; after receiving a fault signal from a business server with a business cluster type of the first business cluster, the configuration server modifying the state of the switch items in the namespace and routing all task requests to the business server with a business cluster type of the second business cluster.

[0007] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: A multi-cluster service orchestration terminal includes a memory, a processor, and a computer program stored in the memory and running on the processor. When the processor executes the computer program, it performs the following steps: The configuration server creates a first namespace and a second namespace, and configures the status of switch items in the first and second namespaces respectively. The switch items are used to control the start or stop of tasks on the business server. The business server reads the status of the switch items from the corresponding namespace according to its business cluster type. The namespace can be either the first namespace or the second namespace. The business server runs tasks according to the status of the switch items. After receiving a fault signal from a business server with a business cluster type of the first business cluster, the configuration server modifies the status of the switch items in the namespace and routes all task requests to the business server with a business cluster type of the second business cluster.

[0008] The beneficial effects of this invention are as follows: By creating a first namespace and a second namespace and configuring switches to control task start and stop in each, the invention reads the status of the switches from the corresponding namespace based on the business cluster type to which the business server belongs. During failover, the second business cluster can take over all services of the first business cluster simply by modifying the status of the switches in the namespace, thus improving failover efficiency and enhancing system stability. It also reduces server resource consumption and waste, requiring only configuration modifications and lowering transformation costs. Attached Figure Description

[0009] Figure 1 A flowchart illustrating the steps of a multi-cluster service orchestration method provided in this embodiment of the invention; Figure 2 This is a schematic diagram of the structure of a multi-cluster service orchestration terminal provided in an embodiment of the present invention; Figure 3This is a system schematic diagram of a multi-cluster service orchestration method provided in an embodiment of the present invention; Detailed Implementation Definitions:

[0010] To explain in detail the technical content, objectives, and effects of the present invention, the following description is provided in conjunction with the embodiments and accompanying drawings.

[0011] In existing technologies, the current architecture lacks a mechanism for fine-grained service orchestration and resource isolation for different business characteristics, and cannot achieve on-demand scheduling and independent high-availability operation of charging services without disrupting the original architecture.

[0012] To at least address the aforementioned issues, this invention creates multiple namespaces in the configuration server and dynamically controls the start and stop status of tasks in each service cluster through switches, thereby achieving resource isolation and automatic fault switching. In this way, the charging service can be operated independently and with high availability without disrupting the original architecture, improving system stability while avoiding resource waste.

[0013] The following describes in detail a multi-cluster service orchestration method of the present invention, with reference to the appendix. Figure 1 ,include: Step 101: The configuration server creates a first namespace and a second namespace. The status of switches is configured in both namespaces to control the enabling or disabling of tasks on the business servers. The configuration server refers to the microservice configuration center, used to store and manage microservice configuration items. The first namespace includes a charging service namespace, used to store configuration items for the charging service cluster. The second namespace includes a non-charging service namespace, used to store configuration items for the non-charging service cluster. Switches include scheduled task switches and message queue consumer switches, used to control the start / stop status of scheduled tasks and message queue consumers, respectively. Business servers include charging service servers and non-charging service servers, used to run microservice applications. Tasks include scheduled tasks and message queue consumer tasks.

[0014] Step 102: The business server reads the status of the switch item from the corresponding namespace according to the business cluster type to which it belongs. The namespace is either the first namespace or the second namespace. The business cluster type includes charging business clusters and non-charging business clusters.

[0015] Step 103: The business server runs the task according to the status of the switch item; Step 104: After receiving a fault signal from a business server in the first business cluster, the configuration server modifies the state of the switch item in the namespace and routes all task requests to the business server in the second business cluster. The first business cluster refers to the charging business cluster. The fault signal refers to the signal generated when a business server fails. The second business cluster refers to the non-charging business cluster. Task requests refer to access requests initiated by user clients, the operations backend, and the maintenance backend. Routing refers to directing access requests to a specific business server via Nginx.

[0016] As described above, by configuring the states of switch items in the first and second namespaces respectively, independent control over the start and stop of tasks on the business servers is achieved. When a business server in the first business cluster fails, the configuration server only needs to modify the state of the switch items in the namespace and route all task requests to the second business cluster. Through configuration server settings, physical isolation combined with logical isolation ensures high isolation, and by controlling the configuration via the configuration server to transfer faults, fault transfer efficiency is improved.

[0017] In one embodiment of the present invention, in step 102, the service server reads the status of the switch item from the corresponding namespace according to the type of service cluster it belongs to, including: Step 201: The service server obtains the cluster identifier, which indicates the type of service cluster to which the service server belongs; the cluster identifier is used to indicate whether the service server belongs to a charging service cluster or a non-charging service cluster.

[0018] Step 202: If the cluster identifier indicates that the service server belongs to the first service cluster, the service server reads the status of the switch item from the first namespace. Step 203: If the cluster identifier indicates that the business server belongs to the second business cluster, the business server reads the status of the switch item from the second namespace. As described above, the business server determines its own business cluster type based on the cluster identifier and reads the status of the switch items only from the corresponding namespace. This isolates the switch item configurations of different business clusters, avoiding configuration interference across namespaces.

[0019] In one embodiment of the present invention, it further includes: Step 301: Configure the server to set the default state of all switches related to the first type of task in the first namespace to enabled, and set the default state of all switches related to the second type of task in the first namespace to disabled; where the first type of task refers to charging tasks, and the second type of task refers to non-charging tasks. By default, the charging namespace only enables the switches for charging-related tasks; the non-charging namespace only enables the switches for non-charging-related tasks. Step 302: The configuration server sets the default state of all switches related to the first type of task in the second namespace to disabled, and sets the default state of all switches related to the second type of task in the second namespace to enabled. As described above, by setting the switch items corresponding to different types of tasks to opposite default states in two namespaces, the isolation configuration between tasks and namespaces is achieved.

[0020] In one embodiment of the present invention, it further includes: Step 401: After the configuration server receives a fault signal from the business server of the first business cluster, it modifies the status of all switch items in the first namespace to the disabled state and modifies the status of all switch items in the second namespace to the enabled state. In the event of a fault, the default state of the charging namespace disables all switch items, and the default state of the non-charging namespace enables all switch items. As described above, after receiving a fault signal from the first service cluster, the configuration server quickly switches the service server's on / off state by disabling all switches in the first namespace and enabling all switches in the second namespace. This avoids the need for manual adjustment of switches one by one, thus improving fault response speed.

[0021] In one embodiment of the present invention, step 101, configuring the state of the switch item in the first namespace and the second namespace respectively, includes: Step 501: Configure the server to store task switch items and consumer switch items in key-value pair structures in the first and second namespaces, respectively. The key of the task switch item is the task identifier, and the value is the enabled or stopped state. The key of the consumer switch item is the consumer identifier, and the value is the enabled or stopped state. The key-value pair structure refers to the configuration item structure in JSON format. The task switch item specifies the task configuration JOB_SCHEDULED_ENABLED, used to control the start and stop status of the scheduled task. The consumer switch item refers to the message queue consumer configuration MQ_CONSUMER_ENABLED, used to control the start and stop status of the message queue consumer. The task identifier specifies the task class name. The consumer identifier refers to the message queue consumer class name. The scheduled task configuration items and consumer configuration items for charging and non-charging services are consistent, only the enabled and disabled state settings differ.

[0022] As described above, by storing task and consumer switch items in key-value pair structures in the first and second namespaces respectively, independent configuration and management of task and consumer switch states are achieved. This allows the server to directly query or update the switch state of a specific task or consumer based on key-value pairs, improving the accuracy of switch item configuration and operational efficiency.

[0023] In one embodiment of the present invention, in step 102, the service server reads the status of the switch item from the corresponding namespace according to the type of service cluster it belongs to, including: Step 601: The business server searches for the key corresponding to the target task identifier in the switch items stored in the namespace corresponding to the configuration server in a key-value pair structure; where the target task identifier refers to the name of the scheduled task class or message queue consumer class that needs to be determined whether to start.

[0024] Step 602: Obtain the value corresponding to the key, which serves as the state of the switch item corresponding to the target task identifier; As described above, the business server can directly read the status of the switch item by looking up the key corresponding to the target task identifier in the namespace of the configuration server and retrieving the value corresponding to that key. This method decouples the status of the switch item from the business logic.

[0025] In one embodiment of the present invention, in step 102, the service server reads the status of the switch item from the corresponding namespace according to the type of service cluster it belongs to, including: Step 701: The business server reads the status of the switch item corresponding to the current task from the namespace corresponding to the configuration server according to the business cluster type it belongs to; where the current task refers to the scheduled task or message queue consumer task that is currently determining whether to start.

[0026] Step 702: The business server starts the current task when the status is enabled, and prevents the current task from starting when the status is disabled. As described above, the business server can read the status of the switch items from the namespace corresponding to the configuration server based on the type of business cluster it belongs to. This status is used to control the start or stop of the current task. This process requires no manual intervention, improving the automation level of task management.

[0027] In one embodiment of the present invention, it further includes: Step 801: If the business server belongs to the first business cluster, then the first microservice is run; where the first microservice refers to the charging business microservice, including charging service, recharge service, user service, authentication service, and gateway service.

[0028] Step 802: If the business server belongs to the second business cluster, it runs the first microservice and the second microservice; the second microservice refers to the non-charging business microservice, including operation and maintenance service, statistical analysis service, reporting service and equipment management service.

[0029] Step 803: Configure the server to send the service registration list to the gateway, so that the gateway can route requests corresponding to the first microservice to the first business cluster and requests for the second microservice to the second business cluster using the service registration list. Here, the service registration list refers to the routing configuration information sent by the microservice configuration center to the gateway. The gateway refers to the Nginx router, used to direct access traffic to specific business servers. Requests corresponding to the first microservice refer to access traffic initiated by user clients. Requests for the second microservice refer to access traffic initiated by the operations backend and maintenance backend. In the event of a failure in the first business cluster, the gateway will route requests corresponding to the first microservice to the second business cluster using the service registration list.

[0030] As described above, by configuring the server to send the service registration list to the gateway, the gateway can route requests for the first microservice to the first business cluster and requests for the second microservice to the second business cluster, based on the business cluster affiliation. Business servers then run the corresponding microservices according to their respective clusters, improving service deployment efficiency and request processing accuracy within the business cluster.

[0031] The multi-cluster service orchestration method and terminal of the present invention can be applied to the multi-cluster service orchestration of charging stations, and will be described below through specific embodiments.

[0032] See Figure 3As shown, the client layer includes user clients and an operations / maintenance backend. The client layer communicates with the traffic ingress layer. The traffic ingress layer communicates with the business layer, which includes charging service server clusters and non-charging service server clusters. The configuration center communicates with both the charging service server clusters and the non-charging service server clusters to distribute configuration information to each server cluster.

[0033] The software architecture mainly involves the configuration structure of the microservice configuration center (such as Nacos) and the conditional control components in the microservice application code.

[0034] Two independent namespaces are defined in the microservice configuration center: a charging service namespace and a non-charging service namespace. Scheduled task on / off switches and message queue (MQ) consumer on / off switches are configured in these namespaces, respectively. These on / off switches use key-value pairs to identify the start / stop status of specific tasks / consumers.

[0035] It should be noted that a charging service can have multiple business jobs, such as scheduled order processing and scheduled payment deductions. The format of the scheduled task configuration JOB_SCHEDULED_ENABLED can be, for example: { "job1": true, "job2": false, "jobn": true } In this context, true indicates that the function is enabled, and false indicates that it is disabled.

[0036] The format for configuring MQ consumer with MQ_CONSUMER_ENABLED can be, for example: { "consumer1": true, "consumer2": false, "consumern": true } In addition, add corresponding condition control logic to the microservice code.

[0037] Write the JobScheduledEnabledCondition condition for the scheduled task. Based on the server where the current program is running, such as the charging service server, read the JOB_SCHEDULED_ENABLED configuration item of the charging service namespace in the Nacos configuration center. Based on the passed scheduled task class name, such as job1, return the configuration value, such as true. Write the MQ message consumer condition MqConsumerEnabledCondition. Depending on the server on which the current program is running, such as the charging service server, read the MQ_CONSUMER_ENABLED configuration item of the charging service namespace in the Nacos configuration center. Based on the passed MQ consumer class name, such as consumer1, return the configuration value, such as true. Furthermore, add the annotation `@Conditional(JobScheduledEnabledCondition.class)` to all scheduled task classes in the microservice code. This annotation is used to call the `JobScheduledEnabledCondition` condition class for matching when the Spring container in the server cluster module creates the bean during startup. When the condition class returns `true`, the scheduled task bean is created and started; when it returns `false`, the bean is not created, and therefore the scheduled task will not start.

[0038] Add the annotation `@Conditional(MqConsumerEnabledCondition.class)` to all MQ consumer classes in the microservice code. This annotation is used to call the `MqConsumerEnabledCondition` condition class for matching when the Spring container of the server cluster module creates the bean during startup. When the condition class returns `true`, the MQ consumer bean is created and starts consuming; when it returns `false`, the bean is not created, and therefore the MQ consumer will not start consuming.

[0039] This allows for dynamic control of component loading and startup / shutdown through a configuration center without code intrusion.

[0040] After introducing the system architecture and software architecture, the method of this invention will be described in detail below in conjunction with the above architecture. This includes: Step A: Add configuration in the configuration center.

[0041] Create two independent namespaces in the microservice configuration center: a charging service namespace and a non-charging service namespace; and configure a scheduled task switch and a message queue consumer switch in each namespace. This corresponds to step 101 above.

[0042] Step B: Code Development and Configuration.

[0043] Write the JobScheduledEnabledCondition condition for scheduled tasks and the MqConsumerEnabledCondition condition for MQ message consumers; and configure the annotation @Conditional(JobScheduledEnabledCondition.class) in all scheduled task classes and @Conditional(MqConsumerEnabledCondition.class) in all MQ consumer classes.

[0044] Step C: System startup.

[0045] Based on actual business operations, identify which microservices need to be activated for charging and non-charging operations. Optionally, charging operations only require charging service, recharge service, user service, authentication service, and gateway service; non-charging operations require services such as operation and maintenance, statistical analysis, reporting, and device management.

[0046] Start the core charging microservice on the charging service server cluster, and start all microservices on non-charging service server clusters. When the program is running, a custom Condition will be automatically triggered based on the server type: if the current server is a charging service server, the switch configuration of the charging service namespace will be read; corresponding to step 102 above.

[0047] If the current server is not a charging service server, then read the switch configuration of the non-charging service namespace and determine the start / stop of the scheduled task and MQ consumer based on the switch status. This corresponds to step 103 above.

[0048] Step D: Configure traffic routing.

[0049] Configure traffic routing in the Nginx instance running on the server. Use Nginx to route user client traffic to the charging service server cluster, and route traffic from the operations and maintenance backend to the non-charging service server cluster.

[0050] Step E, Cluster Fault Handling. This corresponds to step 104 above.

[0051] When the charging service server cluster fails, the following failover procedure should be followed to ensure the availability of the charging service: Step E1: Modify the charging service cluster configuration: Under the Nacos charging service namespace, Change all jobs under JOB_SCHEDULED_ENABLED to false. Change all consumers under MQ_CONSUMER_ENABLED to false; Step E2: Modify the non-charging service cluster configuration: Under the Nacos non-charging service namespace, Change all jobs under JOB_SCHEDULED_ENABLED to true. Change all consumers under MQ_CONSUMER_ENABLED to true; Step E3, Traffic Switching: Modify the Nginx configuration to switch all traffic to the non-charging service server cluster.

[0052] Please refer to Figure 2 The present invention also provides a multi-cluster service orchestration terminal 210, including a memory 211, a processor 212, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the various steps of a multi-cluster service orchestration method as described above.

[0053] The beneficial effects of the terminal of the present invention are the same as those of the method described above, and will not be repeated here.

[0054] In summary, this invention creates a first namespace and a second namespace through a configuration center, and configures switch items in each. Based on the business cluster type of the business server, the status of the switch items is read from the corresponding namespace to control the start and stop of tasks. In response to failover commands, the status of the switch items is modified to allow the second business cluster to take over all services of the first business cluster. Compared to existing technologies that globally add service nodes, leading to business coupling, repeated execution of scheduled tasks, and redundant consumption of message queues resulting in resource waste, or that code splitting and microservices bring high transformation costs and maintenance complexity, this invention achieves service orchestration and resource isolation between different business clusters using only the namespaces and switch items in the configuration center. Specifically, by allocating independent namespaces to different business clusters and configuring switch items within them, fine-grained differentiation of business characteristics is achieved. By reading the switch item status from the corresponding namespace based on the cluster identifier to control the start and stop of tasks on the business server, server resource consumption is reduced. By modifying the switch item status during failover, the second business cluster takes over all services of the first business cluster, resulting in fast failover speed and enabling on-demand scheduling and independent high-availability operation of charging services. Physical isolation combined with logical isolation is achieved through an independent configuration center, reducing transformation costs and maintenance complexity.

[0055] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A multi-cluster service orchestration method, characterized in that, include: Configure the server to create a first namespace and a second namespace, and configure the status of switch items in the first namespace and the second namespace respectively. The switch items are used to control the enabling or stopping of tasks on the business server. The business server reads the status of the switch item from the corresponding namespace according to the business cluster type to which it belongs. The namespace is one of the first namespace and the second namespace. The service server runs the task according to the state of the switch item; After receiving a fault signal from the service server whose service cluster type is the first service cluster, the configuration server modifies the state of the switch item in the namespace and routes all task requests to the service server whose service cluster type is the second service cluster.

2. The method according to claim 1, characterized in that, The service server reads the status of the switch item from the corresponding namespace according to the type of service cluster it belongs to, including: The service server obtains a cluster identifier, which indicates the type of service cluster to which the service server belongs; If the cluster identifier indicates that the service server belongs to the first service cluster, then the service server reads the status of the switch item from the first namespace; If the cluster identifier indicates that the service server belongs to the second service cluster, then the service server reads the status of the switch item from the second namespace.

3. The method according to claim 1, characterized in that, Also includes: The configuration server sets the default state of all switches related to the first type of task in the first namespace to enabled, and sets the default state of all switches related to the second type of task in the first namespace to disabled. The configuration server sets the default state of all switches related to the first type of task in the second namespace to disabled, and sets the default state of all switches related to the second type of task in the second namespace to enabled.

4. The method according to claim 3, characterized in that, Also includes: After receiving a fault signal from the service server whose service cluster type is the first service cluster, the configuration server modifies the status of all switch items in the first namespace to the disabled state and modifies the status of all switch items in the second namespace to the enabled state.

5. The method according to claim 1, characterized in that, The configuration of the switch item status in the first namespace and the second namespace respectively includes: The configuration server stores task switch items and consumer switch items in key-value pair structures in the first namespace and the second namespace, respectively. The key of the task switch item is the task identifier, and the value of the task switch item is either enabled or stopped. The key of the consumer switch item is the consumer identifier, and the value of the consumer switch item is either enabled or stopped.

6. The method according to claim 5, characterized in that, The service server reads the status of the switch item from the corresponding namespace according to the type of service cluster it belongs to, including: The business server searches for the key corresponding to the target task identifier from the switch items stored in the namespace corresponding to the configuration server in a key-value pair structure. Obtain the value corresponding to the key, and use it as the state of the switch item corresponding to the target task identifier.

7. The method according to claim 1, characterized in that, The service server reads the status of the switch item from the corresponding namespace according to the type of service cluster it belongs to, including: The business server reads the status of the switch item corresponding to the current task from the namespace corresponding to the configuration server, based on the business cluster type to which it belongs; The service server starts the current task when the state is enabled, and prevents the current task from starting when the state is disabled.

8. The method according to claim 1, characterized in that, Also includes: If the business server belongs to the first business cluster, it runs the first microservice; If the business server belongs to the second business cluster, it runs the first microservice and the second microservice. The configuration server sends a service registration list to the gateway, so that the gateway can route requests corresponding to the first microservice to the first business cluster and requests corresponding to the second microservice to the second business cluster through the service registration list.

9. The method according to claim 8, characterized in that, The first microservice is a charging service, and the second microservice is a non-charging service.

10. A multi-cluster service orchestration terminal, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the multi-cluster service orchestration method as described in any one of claims 1 to 9.

Images