Method for realizing automatic service discovery based on xxl-job transformation of service registration center

Abstract

An embodiment of the present application provides a method for realizing automatic service discovery by transforming a service registration center based on xxl‑job, by registering a microservice gateway, a multi-copy xxl‑job‑admin scheduling center, and a microservice scheduled task executor to the service registration center, and the configuration items are centrally stored and managed in the service registration center. At the same time, a microservice gateway is used to provide routing-based access and load balancing for the xxl‑job‑admin scheduling center and the microservice scheduled task executor. The xxl‑job‑admin scheduling center obtains the online microservice scheduled task executor from the service registration center and calls the executor to execute the scheduled task, rather than relying on the executor to actively register. This method solves the problems of high management cost and difficult dynamic expansion that arise when deploying xxl‑job alone, and provides an xxl‑job deployment method that is easy to uniformly manage, highly available, and flexible in configuration, thereby realizing automatic discovery and dynamic scheduling of scheduled tasks in a microservice environment.

Description

Technical Field

[0001] The present application relates to the field of data processing, and specifically to a method for realizing automatic service discovery by transforming a service registration center based on xxl-job. Background Art

[0002] In today's digital age, microservices architecture is becoming the dominant model for building complex distributed systems. Scheduled tasks, as a key component of many business processes, play a vital role in ensuring efficient and stable system operation. Against this backdrop, xxl-job emerged as a lightweight distributed task scheduling platform. Leveraging its significant advantages, it has been widely adopted and promoted in the field of microservices scheduled scheduling.

[0003] xxl-job boasts rapid development. Its concise and clear architectural design and rich, comprehensive interface functionality enable developers to quickly build a task scheduling framework, focusing more on implementing business logic and significantly shortening project development cycles. Furthermore, it's easy to learn, making it easy for developers new to task scheduling to get started. This lowers the technical barrier to entry and reduces learning costs, allowing teams to quickly master and apply it to real-world projects. Furthermore, xxl-job is inherently lightweight, requiring relatively few system resources. It can run efficiently in small and medium-sized microservice architectures without placing an excessive burden on the server. This allows it to demonstrate excellent task scheduling capabilities even in resource-constrained environments, meeting the basic needs of many enterprises.

[0004] However, despite xxl-job's numerous advantages, its standalone deployment model has gradually exposed some management and scalability limitations in real-world applications, particularly in large-scale microservice clusters. In standalone deployments, each executor requires manual configuration of the xxl-job-admin address. This may be manageable in initial, small-scale deployments, but as the business continues to grow and the number of microservice instances rapidly increases, this manual configuration approach will undoubtedly significantly increase management costs. Operations and maintenance personnel must log in to each executor to configure the address, which is not only time-consuming and labor-intensive, but also prone to human error, leading to configuration errors and other issues, potentially jeopardizing system stability.

[0005] The problem becomes even more complex when enterprises want to add more xxl-job-admin instances to improve system availability or achieve load balancing. In addition to configuring each newly added admin instance individually, existing executors must also be updated and adjusted to work with the new admin instance. This process involves extensive manual work and complex configuration changes, significantly limiting the system's dynamic scalability. In a rapidly changing business environment, the inability to flexibly and timely expand task scheduling capabilities can severely impact business development and system performance optimization.

[0006] As the scale of the cluster continues to expand, the problems caused by deploying xxl-job alone have become increasingly prominent. On the one hand, configuration synchronization has become a difficult problem. The configurations on different executors may be inconsistent due to differences in manual operations, resulting in uncertainty in task scheduling behavior and increasing the difficulty of troubleshooting and system maintenance. On the other hand, version control has also become tricky. When xxl-job is upgraded to fix vulnerabilities, add new features, or optimize performance, it is an extremely challenging task to ensure that all executors and admin instances in a large-scale cluster can be smoothly and synchronously upgraded to the target version while maintaining compatibility and stability. The existence of these problems makes it increasingly difficult for xxl-job to meet the needs of enterprises for efficient task scheduling management when dealing with large-scale, high-concurrency, and dynamically changing microservice scenarios. There is an urgent need to solve these pain points through architectural optimization and technological innovation to improve its applicability and competitiveness in complex distributed environments. Summary of the Invention

[0007] In response to the problems in the existing technology, this application provides a method for realizing automatic service discovery by transforming the service registration center based on xxl-job, so as to solve the problems of high management cost and difficult dynamic expansion when deploying xxl-job alone, and realize automatic discovery and dynamic scheduling of scheduled tasks in a microservice environment.

[0008] In order to solve at least one of the above problems, the present application provides the following technical solutions:

[0009] In the first aspect, the present application provides a method for implementing automatic service discovery by transforming a service registration center based on xxl-job, including:

[0010] Register the microservice gateway, multi-copy xxl-job-admin scheduling center, and microservice scheduled task executor to the service registration center; the microservice gateway provides routing-based access to microservices registered to the service registration center; the microservice scheduled task executor contains the service name;

[0011] The client accesses the xxl-job-admin scheduling center to create a scheduling task and specifies the service name, so that the xxl-job-admin scheduling center can query the list of online microservice instances in the service registration center according to the service name, select the target instance according to the load balancing strategy, and obtain the URL of the target microservice scheduled task executor;

[0012] The xxl-job-admin scheduling center sends a request to the URL of the target microservice scheduled task executor, triggering the microservice scheduled task executor to execute the scheduled task and return the execution result to the xxl-job-admin scheduling center.

[0013] Furthermore, the step of registering the microservice gateway, the multi-copy xxl-job-admin scheduling center, and the microservice scheduled task executor with the service registration center includes:

[0014] Microservice scheduled task executor: Add the client dependency corresponding to the service registry; define a unique identifier in its configuration file as the service name in the service registry;

[0015] xxl-job-admin scheduling center: Delete the fixed address configuration of the microservice scheduled task executor and add the client dependency corresponding to the service registration center; By modifying the dynamic routing logic, bind the service name to the scheduling task, so that the service name can be specified when creating a scheduling task in the web interface;

[0016] Microservice Gateway: Add client dependencies corresponding to the service registry; configure the service name and the address of the registry.

[0017] Furthermore, the step of obtaining the URL of the target microservice scheduled task executor includes: obtaining the IP address of the target instance, and obtaining the executor port from the metadata of the target instance, and splicing the IP address and the executor port into a complete URL.

[0018] Furthermore, the step of obtaining the URL of the target microservice scheduled task executor also includes:

[0019] The xxl-job-admin scheduling center periodically pre-generates all URLs and stores them in the local cache. When a task is triggered, the URL in the cache is directly read.

[0020] Deploy the microservice scheduled task executor in the Kubernetes environment and assign it a stable DNS name. When scheduling tasks, the xxl-job-admin scheduling center uses the DNS name to build the URL.

[0021] Furthermore, the method for obtaining the microservice online instance list includes: performing a health check on all service instances registered with the service registration center, maintaining healthy service instances in the microservice online instance list for query and call, and removing unhealthy service instances from the microservice online instance list; the xxl-job-admin scheduling center monitors service change events and perceives changes in service instances in real time.

[0022] Furthermore, the method for realizing automatic service discovery by transforming the service registration center based on xxl-job also includes:

[0023] The multi-copy xxl-job-admin scheduling center achieves load balancing through Nginx reverse proxy;

[0024] Split the database task table of the xxl-job-admin scheduling center by task ID or business line, with the master database handling write operations and the slave database handling read operations;

[0025] A message queue is introduced between the xxl-job-admin scheduling center and the microservice scheduled task executor to asynchronously trigger the task request; the xxl-job-admin scheduling center is only responsible for task scheduling, and the trigger request is distributed by the message queue.

[0026] Furthermore, the method for realizing automatic service discovery by transforming the service registration center based on xxl-job also includes:

[0027] The microservice scheduled task executor uses dynamic thread pool technology to automatically adjust the number of its core threads according to its real-time load situation;

[0028] Deploy the microservice scheduled task executor in the Kubernetes environment, and use the HPA function built into the Kubernetes environment to automatically adjust the number of instances of the microservice scheduled task executor based on indicators such as CPU or memory usage.

[0029] In a second aspect, the present application provides a method and apparatus for realizing automatic service discovery based on xxl-job transformation of a service registration center, including:

[0030] The service registration module is used to register the microservice gateway, the multi-copy xxl-job-admin scheduling center, and the microservice scheduled task executor with the service registration center; the microservice gateway provides routing-based access to the microservices registered with the service registration center; the microservice scheduled task executor contains the service name;

[0031] The task scheduling module is used for the client to access the xxl-job-admin scheduling center to create a scheduling task and specify a service name, so that the xxl-job-admin scheduling center can query the list of online microservice instances in the service registration center according to the service name, select the target instance according to the load balancing strategy, and obtain the URL of the target microservice scheduled task executor;

[0032] The task execution module is used to send a request from the xxl-job-admin scheduling center to the URL of the target microservice scheduled task executor, trigger the microservice scheduled task executor to execute the scheduled task, and return the execution result to the xxl-job-admin scheduling center.

[0033] In the third aspect, the present application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and runnable on the processor. When the processor executes the program, it implements the steps of the method for realizing automatic service discovery based on the xxl-job transformation service registration center.

[0034] In a fourth aspect, the present application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method for realizing automatic service discovery by transforming a service registration center based on xxl-job.

[0035] In a fifth aspect, the present application provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the steps of the method for realizing automatic service discovery based on xxl-job transformation of the service registration center.

[0036] It can be seen from the above technical solution that the present application provides a method for realizing automatic service discovery by transforming the service registration center based on xxl-job, by registering the microservice gateway, multi-copy xxl-job-admin scheduling center and microservice scheduled task executor to the service registration center, and the configuration items are centrally stored and managed in the service registration center. At the same time, the microservice gateway is used to provide routing-based access and load balancing for the xxl-job-admin scheduling center and the microservice scheduled task executor. The xxl-job-admin scheduling center obtains the online microservice scheduled task executor from the service registration center and calls the executor to execute the scheduled task, rather than relying on the executor to actively register. This method solves the problems of high management cost and difficult dynamic expansion when deploying xxl-job alone, and provides an xxl-job deployment method that is easy to manage in a unified manner, highly available, and flexible in configuration, and realizes the automatic discovery and dynamic scheduling of scheduled tasks in a microservice environment. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0038] Figure 1 This is one of the flow charts of the method for realizing automatic service discovery based on xxl-job transformation of the service registration center in an embodiment of the present application;

[0039] Figure 2 This is the second flow chart of the method for realizing automatic service discovery based on xxl-job transformation of the service registration center in an embodiment of the present application;

[0040] Figure 3 This is a structural diagram of a method and apparatus for realizing automatic service discovery based on xxl-job transformation of a service registration center in an embodiment of the present application;

[0041] Figure 4 Schematic diagram of the structure of the electronic device in the embodiment of the present application.

[0042] Reference numerals:

[0043] Electronic device 9600, central processing unit 9100, memory 9140, communication module 9110, input unit 9120, audio processor 9130, display 9160, power supply 9170, buffer memory 9141, application / function storage unit 9142, data storage unit 9143, driver program storage unit 9144, antenna 9111, speaker 9131, microphone 9132. DETAILED DESCRIPTION

[0044] To make the purpose, technical solutions, and advantages of the embodiments of this application more clear, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0045] The acquisition, storage, use, and processing of data in this application's technical solution comply with relevant national laws and regulations.

[0046] Taking into account the problems existing in the prior art, the present application provides a method for realizing automatic service discovery by transforming the service registration center based on xxl-job, by registering the microservice gateway, multi-copy xxl-job-admin scheduling center and microservice scheduled task executor to the service registration center, and the configuration items are centrally stored and managed in the service registration center. At the same time, the microservice gateway is used to provide routing-based access and load balancing for the xxl-job-admin scheduling center and the microservice scheduled task executor. The xxl-job-admin scheduling center obtains the online microservice scheduled task executor from the service registration center and calls the executor to execute the scheduled task, rather than relying on the executor to actively register. This method solves the problems of high management cost and difficult dynamic expansion when deploying xxl-job alone, and provides an xxl-job deployment method that is easy to manage in a unified manner, highly available, and flexible in configuration, and realizes the automatic discovery and dynamic scheduling of scheduled tasks in a microservice environment.

[0047] In order to solve the problems of high management cost and difficult dynamic expansion when deploying xxl-job separately, and realize automatic discovery and dynamic scheduling of scheduled tasks in a microservice environment, this application provides an embodiment of a method for realizing automatic service discovery based on xxl-job transformation of the service registration center. Figure 1-Figure 2 The method of realizing automatic service discovery by transforming the service registration center based on xxl-job specifically includes the following contents:

[0048] Step S101: Register the microservice gateway, multi-copy xxl-job-admin scheduling center and microservice scheduled task executor to the service registration center; the microservice gateway provides routing-based access for the microservices registered to the service registration center; the microservice scheduled task executor contains the service name.

[0049] In this embodiment, the microservice gateway (hereinafter referred to as the gateway) serves as the traffic entry point and is responsible for routing, load balancing (e.g., round-robin, consistent hashing), permission verification (e.g., JWT validation), and rate limiting (e.g., the token bucket algorithm). The multi-replica xxl-job-admin scheduling center (hereinafter referred to as the scheduling center) (e.g., three replicas) is deployed across multiple instances to avoid single points of failure and registers with the service registry (hereinafter referred to as the registration center) for high availability. The microservice scheduled task executor (hereinafter referred to as the executor) is embedded in each microservice and automatically registers with the service registry upon startup, reporting its service name and metadata. This registration provides a unified view of all components through the service registry (e.g., Nacos or Eureka), laying the foundation for dynamic discovery.

[0050] Exemplarily, the registration process includes:

[0051] 1. Start the service registration center

[0052] Deploy the service registry in the server environment. The specific steps are as follows:

[0053] Download the service registry installation package and choose standalone or cluster mode deployment (depending on the enterprise size and business needs).

[0054] Configure parameters such as the database connection of the service registry (optional, for data persistence), cluster node information (in cluster mode), etc.

[0055] Start the service registry service and access the service registry console through a browser to verify whether the service is started normally.

[0056] 2. Registration of microservice scheduled task executors

[0057] 2.1 Introducing service registration dependencies

[0058] For example, if the microservice is based on Spring Cloud, it is necessary to integrate the client dependencies of service registration components (such as Nacos and Eureka). For example, when using Spring Cloud Alibaba Nacos, it is necessary to add the Nacos service discovery dependency package to enable the executor to register with the service registry.

[0059] 2.2 Configuring service registration information

[0060] Define a unique identifier (such as order-service-executor) in the microservice configuration file as the logical service name in the registry, that is, the service name; specify the access address of the service registry (such as 127.0.0.1:8848 for Nacos) as the registry address; metadata, additional executor-specific information, such as the executor port of XXL-JOB (default 9999).

[0061] 2.3 Enabling automatic registration

[0062] Add service discovery annotations (such as @EnableDiscoveryClient) to the microservice startup class to automatically register with the registry at startup. The registry periodically verifies the instance status through the microservice's health check endpoint (such as / actuator / health) and removes abnormal instances.

[0063] 3. Renovation of the xxl-job-admin scheduling center

[0064] 3.1 Remove static configuration

[0065] The original mode of the dispatch center required the dispatch center to manually configure the IP and port of each executor (for example, xxl.job.executor.address=http: / / 192.168.1.10:9999). This implementation removes all fixed address configurations and instead uses dynamic discovery via service name.

[0066] 3.2 Integrating Service Discovery Clients

[0067] In the dispatch center project, add the client dependency corresponding to the service registration center (such as Nacos Client), introduce it as a dependency, and configure the registration center address: specify that the dispatch center itself is registered with the service registration center (optional), or only acts as a client to query the service.

[0068] 3.3 Dynamic Routing Logic Transformation

[0069] Bind the service name to the task. When creating a task in the scheduling center web interface, specify the service name (such as order-service-executor) instead of the specific IP address.

[0070] Set up the service discovery process: Query the instance list: The scheduling center calls the service registration center API to obtain all healthy instances based on the service name; Metadata parsing: Extract the executor port (such as xxl-job-port:9999) from the instance metadata; URL splicing: Combine the instance IP (host) and the executor port into a complete task trigger address (such as http: / / 192.168.1.10:9999 / run).

[0071] Load balancing strategies include: randomly selecting one from the instance list, or using a polling strategy to select different instances in sequence, or routing to a fixed instance based on the hash value of the task parameter. This is suitable for tasks that require idempotence.

[0072] 4. Microservice Gateway Registration

[0073] If the gateway serves solely as a request entry point (without exposing its own API), it doesn't need to register with the service registry. It simply acts as a client, pulling other microservice instances from the registry. Scenarios where registration is necessary include: Gateway high availability: Multiple replica gateway instances must be discovered by a load balancer (such as a Kubernetes Service); Internal calls: Other internal services call the gateway; Health checks: The gateway's own status must be monitored (such as by the registry's active detection).

[0074] Taking Spring Cloud Gateway + Nacos as an example, if you need to register the gateway itself:

[0075] (1) Add service registration dependency: introduce Nacos service discovery client in the pom.xml of the gateway project;

[0076] (2) Configure service registration information: define the service name and registration center address in application.yml;

[0077] (3) Enable service discovery: Add the annotation @EnableDiscoveryClient to the gateway startup class;

[0078] (4) Verify the registration result: Access the Nacos console (http: / / localhost:8848 / nacos) and view the api-gateway instance in the service list.

[0079] In addition, the typical configuration of the gateway as a service consumer is as follows:

[0080] (1) Configure routing rules: Define dynamic routing in application.yml to route requests based on service names;

[0081] (2) Dynamic service discovery process: Requests enter the gateway: External requests access the gateway's / api / orders / 123 path; Route matching: The gateway matches the order-service routing rule based on the path; Service discovery: The gateway queries Nacos for a list of instances of the service name order-service; Load balancing: The gateway (through Ribbon or Spring CloudLoadBalancer) selects an instance (such as 192.168.1.10:8080); Request forwarding: The gateway forwards the request to http: / / 192.168.1.10:8080 / api / orders / 123; Response processing: After receiving the response from the microservice, the gateway can perform: Data conversion: such as XML to JSON, field filtering; Error handling: Unified encapsulation of error codes and message formats; Cache: Cache responses to frequently requested requests (such as product details); Return to client: Return the processed response to the client to complete the request life cycle.

[0082] 5. Registration and Discovery Process

[0083] Executor registration: Microservice starts → sends a registration request to the registration center (with service name, IP, port, metadata); the registration center stores the instance information in the service list (such as Nacos's service_order-service-executor).

[0084] The scheduling center discovers: The scheduling center triggers the task → queries the registration center for the instance list corresponding to the service name → obtains information about all healthy instances.

[0085] Example: Take the "order service log cleanup task" as an example:

[0086] (1) Executor registration: The order service is started and registered to Nacos with the service name order-service-executor. The metadata includes xxl-job-port=9999.

[0087] (2) Task definition: Create a task in the xxl-job-admin interface and specify the service name as order-service-executor.

[0088] (3) Task triggering: The dispatch center queries Nacos for a list of order-service-executor instances and obtains two instances:

[0089] Instance A: IP=192.168.1.10, metadata port=9999

[0090] Instance B: IP=192.168.1.11, metadata port=9999

[0091] The scheduling center randomly selects instance A, concatenates the URL to http: / / 192.168.1.10:9999 / run, and sends a task request.

[0092] (4) Task execution: The executor in the order service receives the request, executes the log cleaning logic, and returns the result to the scheduling center.

[0093] In this embodiment, to improve the performance of the registration center, a registration center (such as Nacos / Eureka) cluster can be deployed, multiple nodes can be used to share the load (such as a 3-node Nacos cluster), and the database can be configured for high availability (such as MySQL master-slave synchronization + sharding).

[0094] Taking Nacos as an example, build a multi-node cluster (at least three nodes are recommended), with each node maintaining data synchronization. Specify the addresses of other nodes in the cluster in the configuration file to enable communication and data synchronization. Similarly, for Eureka, you can deploy multiple instances and configure the addresses of cluster peer nodes to achieve mutual registration and data replication, sharing the load of service registration and discovery requests and preventing single points of failure from causing service registration and discovery failures.

[0095] Nacos / Eureka's data storage architecture can also be changed from a single database to a multi-database architecture. For example, using MySQL, a master-slave synchronization mechanism is employed, with one master and two slaves. The master database is responsible for write operations, while the slave database is responsible for read operations. Furthermore, a sharding strategy can be implemented. If the master database fails, the slave database can quickly switch to the master database, ensuring high-availability storage of data such as service registration information and ensuring that the registration center can continue to provide stable services.

[0096] Optionally, you can also extend the scheduling center (xxl-job-admin), such as:

[0097] 1. Multiple copies and load balancing

[0098] Horizontal Scaling: Deploy multiple replicas of the scheduling center (e.g., 5 nodes) and implement load balancing through Nginx reverse proxy. Specifically, based on business load forecasts, deploy multiple xxl-job-admin scheduling center instances (e.g., 5 nodes), ensuring that each instance has the same configuration, including database connections and cluster communication parameters. Using Nginx as a reverse proxy server, external requests are evenly distributed to each scheduling center instance. Nginx configuration uses load balancing algorithms such as round-robin, least connections, or weighted strategies to enable each instance to fully utilize computing resources and improve the concurrent processing capabilities of the entire scheduling system.

[0099] Database optimization: sharding: split the task table by task ID or business line; read-write separation: the master database handles write operations, and the slave database handles read operations. Specifically, the task table is split according to the hash value of the task ID or the business line. For example, it is divided into multiple sub-tables according to the modulus of the task ID, and each sub-table stores task data in a specific range. At the same time, establish corresponding routing rules and aggregate query mechanisms to ensure that the addition, deletion, modification and query operations of tasks can be accurately located in the corresponding sub-tables, thereby improving the read and write efficiency of the database. For read-write separation, configure the database master-slave replication architecture, with the master database specifically handling write operations (such as task creation, status update, etc.), and the slave database taking on read operations (such as task query, statistical analysis, etc.). Use read-write separation middleware (such as MyCat) to automatically distribute read and write requests to different database instances, balance the database load, and improve the performance and availability of the database.

[0100] Asynchronous task queues: RabbitMQ / Kafka is introduced to asynchronously trigger task requests, balancing peak and valley traffic. The dispatch center is solely responsible for task orchestration, with trigger requests distributed by message queues. Specifically, a RabbitMQ or Kafka message queue is introduced between the dispatch center and the executors. The dispatch center encapsulates task trigger requests as messages and publishes them to the message queue. Multiple executor instances subscribe to this message queue, asynchronously consuming task messages and executing them. This buffers task trigger requests and balances peak traffic, avoiding network congestion and system overload caused by the dispatch center's direct simultaneous communication with a large number of executors during peak traffic periods. For example, during major e-commerce promotions, when a large number of tasks are triggered simultaneously, the message queue can smoothly handle the sudden traffic flow and ensure the orderly distribution and execution of tasks.

[0101] 2. Task Sharding and Distributed Locking

[0102] Task sharding: Split large tasks into multiple subtasks (e.g., by data range) and distribute them to different executors for parallel processing. For example, a log cleaning task is sharded by date, with each instance processing one day's data. Specifically, for large-scale data processing tasks (such as log cleaning and data statistics), tasks are split into multiple subtasks according to specific rules. For example, log cleaning tasks are sharded based on the date range of the log files, with each subtask responsible for cleaning log data for a specific date. During task scheduling, the scheduling center assigns subtasks to different executor instances according to the sharding rules, allowing for concurrent execution. This significantly reduces overall task execution time and improves task processing efficiency.

[0103] Distributed locks: Use Redis / ZooKeeper to implement distributed locks to prevent multiple scheduling centers from repeatedly triggering the same task. Specifically, distributed locks are implemented using Redis's Setnx (Set if Not Exists) command or ZooKeeper's temporary sequence node creation function. In a multi-replica scheduling center environment, when a scheduling center instance is about to trigger a task, it first attempts to acquire a distributed lock. If the acquisition is successful, the task is triggered normally; if not, the lock is released before retrying. This ensures that the same task is triggered by only one scheduling center instance at a time, avoiding data inconsistencies or other business issues caused by repeated task execution.

[0104] Optionally, the actuator can also be optimized:

[0105] 1. High-performance task processing

[0106] Thread pool tuning: Dynamic thread pools (such as the Hystrix thread pool) automatically adjust the number of core threads based on load. Specifically, dynamic thread pool technologies like the Hystrix thread pool automatically adjust the number of core threads based on the real-time load of the executor. For example, as the number of task requests increases, the thread pool dynamically increases the number of core threads to meet processing needs; as the number of requests decreases, the number of idle threads is gradually reduced to optimize system resource utilization. Furthermore, a reasonable maximum number of threads is set to prevent excessive thread expansion from exhausting system resources.

[0107] Rejection policy: Reject new tasks when the task queue is full to avoid Out-of-Memory (OOM) errors. Specifically, when the task queue is full and can no longer accept new tasks, a rejection policy (such as AbortPolicy or CallerRunsPolicy) is enabled. AbortPolicy directly throws an exception to reject new tasks, making it suitable for scenarios sensitive to task loss. CallerRunsPolicy, which delegates task execution to the caller thread, is suitable for scenarios with short task execution times and the desire to process all tasks as quickly as possible. Using a reasonable rejection policy can prevent serious executor failures such as Out-of-Memory (OOM) errors caused by task backlogs.

[0108] Asynchronous and non-blocking: Use Netty or WebFlux to implement asynchronous processing and improve throughput. Specifically, use asynchronous programming frameworks such as Netty or WebFlux to achieve asynchronous and non-blocking task processing. When processing HTTP requests, Netty's event-driven and callback-based mechanism avoids the thread waiting issues of traditional synchronous I / O blocking, enabling a single thread to handle multiple requests simultaneously, significantly improving system throughput.

[0109] 2. Elastic Scaling

[0110] Kubernetes autoscaling: Automatically scales executor instances based on CPU and memory metrics (e.g., HPA configuration). Example: Automatically scales to 10 replicas when CPU utilization exceeds 70%. Specifically, in a Kubernetes environment, deploy the executor as a pod and configure horizontal autoscaling (HPA). Based on CPU utilization, when CPU utilization exceeds 70%, HPA automatically increases the number of replicas of the executor pod to 10; when CPU utilization falls below 30%, the number of replicas is gradually reduced to an appropriate level. The HPA's automatic scaling feature ensures that the executor can quickly expand or contract resources when business load fluctuates, ensuring efficient task execution and avoiding resource waste.

[0111] Warm-up mechanism: New instances are added to the load balancing pool after startup to avoid cold start performance bottlenecks. Specifically, a warm-up period (e.g., 30 seconds) is set before newly started executor instances are added to the load balancing pool. During this period, the instance initializes resources, warms up the thread pool, and connects to dependent services, allowing the instance's performance to gradually reach a stable state. After the warm-up period is complete, the instance is added to the load balancing pool and participates in task distribution, preventing the impact of low initial performance on overall task execution efficiency.

[0112] 3. Resource Isolation and Circuit Breaker

[0113] Dedicated thread groups: Critical tasks (such as payment reconciliation) are allocated independent thread pools to prevent them from being blocked by common tasks. Specifically, critical tasks (such as payment reconciliation and order timeout processing) are assigned to separate, dedicated thread groups. These thread groups have higher priorities and independent resource allocation, and are isolated from other common task thread groups. This way, even if common tasks encounter thread blockage or resource exhaustion, the normal execution of critical tasks will not be affected, ensuring the stable operation of core business.

[0114] Circuit Breaker and Degradation: Sentinel integration triggers circuit breaking when the task failure rate exceeds a threshold, enabling rapid failure and downgrade processing. Specifically, Sentinel and other circuit breaking components are integrated into the executor, and task circuit breaking rules are configured. For example, when a task failure rate exceeds 50% and lasts for more than one minute, the circuit breaker mechanism is triggered, rapidly failing subsequent task requests and initiating downgrade processing. Downgrade processing can include returning to default values ​​or invoking backup services, ensuring that the system can still provide basic service capabilities in the event of task anomalies, preventing the failure from escalating and impacting the entire business system.

[0115] Optionally, you can also optimize task distribution and URL concatenation:

[0116] 1. Client load balancing

[0117] Ribbon / Spring Cloud LoadBalancer: The scheduling center integrates client-side load balancing, directly selecting instances based on the local service list, reducing registration center queries. Strategy: Weighted response time (preferring low-latency instances). Specifically, the scheduling center integrates client-side load balancing components such as SpringCloud LoadBalancer or Ribbon, and adopts a weighted response time strategy. This strategy dynamically assigns weights based on the historical response times of executor instances, prioritizing task requests to instances with shorter response times, thereby improving overall task execution efficiency. For example, if the average response time of instance A is 100 milliseconds and the average response time of instance B is 200 milliseconds, instance A will receive a higher weight, gaining more opportunities to distribute task requests, and achieving intelligent scheduling of task requests.

[0118] 2. Pre-generated URL Cache

[0119] URL local caching: The dispatch center periodically pregenerates all executor URLs and stores them in a local cache (e.g., Caffeine). When a task is triggered, the cache can be directly read, reducing real-time splicing overhead. Specifically, the dispatch center periodically (e.g., every 30 seconds) obtains the IP address, port number, and other information of all executor instances from the service registry, pregenerates the task execution URL corresponding to each executor, and stores these URLs in a local cache (e.g., using the Caffeine caching framework). When a task is triggered, the URL is directly read from the local cache, avoiding the network query and string manipulation overhead required for real-time URL splicing and accelerating task dispatch.

[0120] 3. Domain Name and Dynamic DNS

[0121] Kubernetes Service: The executor is deployed as a K8s Service and is accessed through a DNS name (such as executor-service) instead of IP splicing. Example: The URL is simplified to http: / / executor-service:9999 / run, which is automatically routed by K8s. Specifically, for example, when deploying an executor in a Kubernetes cluster, create a corresponding Service resource object and configure it with a stable DNS name (such as executor-service). When scheduling tasks, the scheduling center sends requests through the DNS name, and the Kubernetes service routing mechanism automatically forwards the requests to the specific executor Pod instance on the backend. This method avoids directly using the Pod's IP address for communication, simplifies URL management, and does not require modifying the URL configuration of the scheduling center when scaling or migrating Pod instances, thereby improving the flexibility and maintainability of the system.

[0122] Step S102: The client accesses the xxl-job-admin scheduling center to create a scheduling task and specifies the service name, so that the xxl-job-admin scheduling center can query the list of online microservice instances in the service registration center according to the service name, select the target instance according to the load balancing strategy, and obtain the URL of the target microservice scheduled task executor.

[0123] For example, the xxl-job-admin project integrates the Nacos Client, imports the Nacos Client dependency, configures relevant parameters (such as the Nacos server address), and develops the ServiceDiscoveryClient class to encapsulate the service discovery logic. This includes writing the getInstances(String serviceName) method, which calls the Nacos Client API to query the list of instances for a specified service name and returns a collection of objects containing information such as the instance IP address, port number, and status. Before a task is triggered, the dispatch center calls this method to dynamically obtain a list of executor instances, replacing the original logic that reads executor addresses from the database to ensure that the latest available executor instances are obtained.

[0124] Alternatively, you can implement a load balancing strategy in xxl-job-admin by developing a round-robin strategy class, RoundRobinStrategy, which internally uses a ConcurrentHashMap to store the mapping between service names and counters. When selecting an instance, the counter value is modulo the instance list size, and instances are selected in a round-robin fashion to ensure a relatively balanced distribution of tasks across them. Alternatively, you can develop a random strategy class, RandomStrategy, which, after obtaining the instance list, uses a random algorithm to select an instance to execute a task. You can also extend other strategies (such as weighted random and minimum number of connections) based on business needs, and provide strategy selection parameters in the system configuration to facilitate flexible switching among operations and maintenance personnel.

[0125] Task triggering: The dispatch center constructs an HTTP call request based on the selected executor instance information. This request URL is formed by concatenating the executor instance's IP address and port number (e.g., http: / / instance-ip:port / xxl-job-executor / run). Request parameters are set, including the task ID, task parameters, and other necessary information. A POST request is sent to the executor using an HTTP client (e.g., ApacheHttpClient or Spring's RestTemplate), triggering task execution.

[0126] Optionally, in this embodiment, health checks are performed on all service instances registered with the service registration center, and healthy service instances are maintained in the microservice online instance list for query and call, and unhealthy service instances are removed from the microservice online instance list; the xxl-job-admin scheduling center monitors service change events and perceives changes in service instances in real time.

[0127] For example, the executor checks its health status through heartbeat detection: it sends heartbeat packets to the registration center regularly, and marks it as unhealthy if it times out. It also proactively checks for liveness: the registration center proactively calls the executor's health check interface (such as / actuator / health) to verify the service status. Abnormal instances are removed from the available list. The registration center can inform consumers (such as gateways and scheduling centers) of instance list changes through event notifications (such as Nacos's NamingEvent). The scheduling center receives the Nacos notification and updates the locally cached order-service-executor instance list.

[0128] In this embodiment, the URL is obtained by splicing to meet the needs of dynamic service discovery, multi-port isolation and flexible expansion. Specifically:

[0129] (1) Multi-port isolation of service instances

[0130] Business port vs. executor port: The business port handles regular HTTP requests (such as user orders and product inquiries) and is usually listened to by the microservice main application (such as 8080); while the executor port is dedicated to task scheduling communication (such as XXL-JOB's RPC port 9999) and is isolated from the business logic.

[0131] Registry storage content: The service registry records the microservice's business port (such as 8080) by default, not the executor port. For metadata extension, the executor port must be additionally declared through metadata (such as xxl-job-port=9999).

[0132] (2) Dynamic service discovery

[0133] In cloud-native environments (such as Kubernetes), instance IPs and ports are dynamically assigned (for example, the IP changes after a Pod restart). Hardcoding the IP or port can cause service unavailability. Therefore, we retrieve the latest instance IP from the registry and extract the executor port from metadata to dynamically concatenate the URL.

[0134] (3) Path flexibility

[0135] The task trigger endpoint may be different, and the executor task trigger path may be different for different frameworks (for example, XXL-JOB defaults to / run, while other frameworks may use / invoke). Dynamic splicing allows you to freely define the path according to the framework protocol without modifying the registration information.

[0136] For example, a complete executor URL can be composed of the following three parts: http: / / {instance IP}:{executor port} / {task trigger endpoint}. Specifically, the instance IP is the instance host address (e.g., 192.168.1.10) retrieved from the service registry. This IP address is dynamic; instances may scale up, down, or migrate, and the IP address may change accordingly. The executor port is extracted from the service instance metadata (e.g., xxl-job-port=9999). It is isolated and separate from the service port to avoid resource conflicts. The task trigger endpoint is defined by the task scheduling protocol (e.g., the default endpoint for XXL-JOB is / run). It is configurable, and the path can be customized as needed (e.g., / api / job / trigger).

[0137] Scenario example: Scheduled order closing task of order service

[0138] 1. Service registration: The order service is started and registered with Nacos.

[0139] yaml

[0140] spring.application.name: order-service

[0141] spring.cloud.nacos.discovery.metadata.xxl-job-port: 9999

[0142] 2. Scheduling center query: Get the instance list based on the service name order-service:

[0143] json [

[0145] {"host": "192.168.1.10", "metadata": {"xxl-job-port": 9999}},

[0146] {"host": "192.168.1.11", "metadata": {"xxl-job-port": 9999}} ]

[0148] 3. Concatenate the URLs: Select the instance 192.168.1.10, extract the port 9999, and concatenate the path / run → http: / / 192.168.1.10:9999 / run.

[0149] 4. Trigger task: The dispatch center sends an HTTP request to the URL to trigger the closing task.

[0150] In this embodiment, dynamic adaptation can be achieved by splicing URLs. When the IP or port changes, the URL is automatically updated without manual intervention. It supports multiple protocols such as HTTP, HTTPS, and gRPC. Only the path and port need to be modified, and resource isolation is achieved. The executor is isolated from the business API to avoid mutual influence. New metadata fields (such as version number and environment identifier) ​​do not affect the existing logic, and the scalability is better.

[0151] Step S103: The xxl-job-admin scheduling center sends a request to the URL of the target microservice scheduled task executor, triggering the microservice scheduled task executor to execute the scheduled task, and returns the execution result to the xxl-job-admin scheduling center.

[0152] Optionally, the selected executor instance receives the scheduling request and executes specific business logic (such as generating reports or clearing caches). The executor must implement the XXL-JOB JobHandler interface to process task parameters and context. It also returns the execution results (success / failure, logs) to the scheduling center via HTTP callbacks or RPC. The scheduling center then logs and triggers alerts (such as retrying in case of failure and notifying operations and maintenance).

[0153] For example, after receiving a task instruction, the microservice executor uses the annotation-driven mechanism provided by xxl-job to match the task execution method corresponding to the task ID. The task execution method is then called to run the business logic code. During execution, health checks can be performed using the Spring Boot Actuator endpoint / actuator / health. Custom health indicators (such as the number of active threads in the thread pool and the task queue length) can be used to monitor the executor's status and ensure stable task execution. If an exception occurs during task execution, the exception information is captured and logged, providing a basis for subsequent troubleshooting and retry attempts.

[0154] After the task is completed, the executor reports the results to the dispatch center: a response object is constructed containing the execution status (success / failure), execution log, output results, and other information. The results are sent back to the xxl-job-admin dispatch center via HTTP responses or active callbacks. After receiving the results, the dispatch center stores the task execution history, updates the task status, and displays the results in the console for easy monitoring and querying.

[0155] When a task fails, the service retrieves the latest instance list from the service registry (possibly due to new instances being added or previous instances being removed due to failures). Based on the pre-set retry strategy (e.g., immediate retry, interval retry, etc.), the load balancing strategy is invoked to select an instance and initiate a task retry request. The number of retries and the results are recorded. If the retry limit is reached without success, an alarm is triggered, notifying operations and maintenance personnel to intervene.

[0156] The method provided in this application is to realize automatic service discovery by transforming the service registration center based on xxl-job. By registering the microservice gateway, multi-copy xxl-job-admin scheduling center and microservice scheduled task executor to the service registration center, the configuration items are centrally stored and managed in the service registration center. At the same time, the microservice gateway is used to provide routing-based access and load balancing for the xxl-job-admin scheduling center and the microservice scheduled task executor. The xxl-job-admin scheduling center obtains the online microservice scheduled task executor from the service registration center and calls the executor to execute the scheduled task, rather than relying on the executor to actively register. This method solves the problems of high management cost and difficult dynamic expansion when deploying xxl-job alone, and provides an xxl-job deployment method that is easy to manage in a unified manner, highly available, and flexible in configuration, which realizes the automatic discovery and dynamic scheduling of scheduled tasks in a microservice environment.

[0157] In order to solve the problems of high management cost and difficult dynamic expansion when deploying xxl-job separately, and realize automatic discovery and dynamic scheduling of scheduled tasks in a microservice environment, this application provides an embodiment of a method and device for realizing automatic service discovery based on xxl-job transformation service registration center, see Figure 3 The method and device for realizing automatic service discovery based on xxl-job transformation of the service registration center specifically includes the following contents:

[0158] The service registration module 10 is used to register the microservice gateway, the multi-copy xxl-job-admin scheduling center, and the microservice scheduled task executor with the service registration center; the microservice gateway provides routing-based access to the microservices registered with the service registration center; the microservice scheduled task executor contains the service name;

[0159] The task scheduling module 20 is used for the client to access the xxl-job-admin scheduling center to create a scheduling task and specify a service name, so that the xxl-job-admin scheduling center can query the list of online microservice instances in the service registration center according to the service name, select the target instance according to the load balancing strategy, and obtain the URL of the target microservice scheduled task executor;

[0160] The task execution module 30 is used for the xxl-job-admin scheduling center to send a request to the URL of the target microservice scheduled task executor, triggering the microservice scheduled task executor to execute the scheduled task, and returning the execution result to the xxl-job-admin scheduling center.

[0161] From the above description, it can be seen that the embodiment of the present application provides a method and device for realizing automatic service discovery based on the xxl-job transformation service registration center, by registering the microservice gateway, multi-copy xxl-job-admin scheduling center and microservice scheduled task executor to the service registration center, and the configuration items are centrally stored and managed in the service registration center. At the same time, the microservice gateway is used to provide routing-based access and load balancing for the xxl-job-admin scheduling center and the microservice scheduled task executor. The xxl-job-admin scheduling center obtains the online microservice scheduled task executor from the service registration center and calls the executor to execute the scheduled task, rather than relying on the executor to actively register. This method solves the problems of high management cost and difficult dynamic expansion when deploying xxl-job alone, and provides a xxl-job deployment method that is easy to manage in a unified manner, highly available, and flexible in configuration, and realizes the automatic discovery and dynamic scheduling of scheduled tasks in a microservice environment.

[0162] From a hardware perspective, in order to solve the problems of high management costs and difficulty in dynamic expansion that arise from deploying xxl-job alone, and to achieve automatic discovery and dynamic scheduling of scheduled tasks in a microservice environment, this application provides an embodiment of an electronic device for implementing all or part of the method for implementing automatic service discovery based on xxl-job transformation of a service registration center. The electronic device specifically includes the following contents:

[0163] A processor, a memory, a communications interface, and a bus; wherein the processor, the memory, and the communications interface communicate with each other via the bus; the communications interface is used to implement information transmission between a method and apparatus for implementing automatic service discovery based on the xxl-job transformation service registration center and related devices such as core business systems, user terminals, and related databases; the logic controller can be a desktop computer, a tablet computer, a mobile terminal, etc., but this embodiment is not limited thereto. In this embodiment, the logic controller can be implemented with reference to the embodiment of the method for implementing automatic service discovery based on the xxl-job transformation service registration center and the embodiment of the method and apparatus for implementing automatic service discovery based on the xxl-job transformation service registration center in the embodiment, the contents of which are incorporated herein and repeated parts are not repeated.

[0164] It is understandable that the user terminal may include a smart phone, a tablet electronic device, a network set-top box, a portable computer, a desktop computer, a personal digital assistant (PDA), a vehicle-mounted device, a smart wearable device, etc. Among them, the smart wearable device may include smart glasses, a smart watch, a smart bracelet, etc.

[0165] In actual applications, part of the method for realizing automatic service discovery based on the xxl-job transformation service registration center can be performed on the electronic device side as described above, or all operations can be completed in the client device. The specific selection can be based on the processing capability of the client device and the limitations of the user's usage scenario. This application does not limit this. If all operations are completed in the client device, the client device may also include a processor.

[0166] The aforementioned client device may include a communication module (i.e., a communication unit) capable of establishing a communication connection with a remote server to facilitate data transmission with the server. The server may include a server at the task scheduling center or, in other implementation scenarios, a server on an intermediate platform, such as a server on a third-party server platform that is communicatively linked to the task scheduling center server. The server may comprise a single computer device, a server cluster consisting of multiple servers, or a distributed server configuration.

[0167] Figure 4 Schematic block diagram of the system structure of the electronic device 9600 according to an embodiment of the present application. Figure 4 As shown, the electronic device 9600 may include a central processing unit 9100 and a memory 9140; the memory 9140 is coupled to the central processing unit 9100. It is worth noting that the Figure 4is exemplary; other types of structures may also be used to supplement or replace this structure to implement telecommunication functions or other functions.

[0168] In one embodiment, the method and function of realizing automatic service discovery based on the xxl-job transformation service registration center can be integrated into the central processing unit 9100. The central processing unit 9100 can be configured to perform the following control:

[0169] Step S101: register the microservice gateway, the multi-copy xxl-job-admin scheduling center, and the microservice scheduled task executor with the service registration center; the microservice gateway provides routing-based access for the microservices registered with the service registration center; the microservice scheduled task executor contains the service name;

[0170] Step S102: The client accesses the xxl-job-admin scheduling center to create a scheduling task and specifies a service name, so that the xxl-job-admin scheduling center can query the list of online microservice instances in the service registration center according to the service name, select the target instance according to the load balancing strategy, and obtain the URL of the target microservice scheduled task executor. The client accesses the xxl-job-admin scheduling center to create a scheduling task and specifies a service name, so that the xxl-job-admin scheduling center can query the list of online microservice instances in the service registration center according to the service name, select the target instance according to the load balancing strategy, and obtain the URL of the target microservice scheduled task executor.

[0171] Step S103: The xxl-job-admin scheduling center sends a request to the URL of the target microservice scheduled task executor, triggering the microservice scheduled task executor to execute the scheduled task, and returns the execution result to the xxl-job-admin scheduling center.

[0172] As can be seen from the above description, the electronic device provided by the embodiment of the present application registers the microservice gateway, the multi-copy xxl-job-admin scheduling center and the microservice scheduled task executor to the service registration center, and the configuration items are centrally stored and managed in the service registration center. At the same time, the microservice gateway is used to provide routing-based access and load balancing for the xxl-job-admin scheduling center and the microservice scheduled task executor. The xxl-job-admin scheduling center obtains the online microservice scheduled task executor from the service registration center and calls the executor to execute the scheduled task, rather than relying on the executor to actively register. This method solves the problems of high management cost and difficult dynamic expansion when deploying xxl-job alone, and provides an xxl-job deployment method that is easy to manage in a unified manner, highly available, and flexible in configuration, and realizes the automatic discovery and dynamic scheduling of scheduled tasks in a microservice environment.

[0173] In another embodiment, the method device for realizing automatic service discovery based on the xxl-job transformation service registration center can be configured separately from the central processing unit 9100. For example, the method device for realizing automatic service discovery based on the xxl-job transformation service registration center can be configured as a chip connected to the central processing unit 9100, and the method function for realizing automatic service discovery based on the xxl-job transformation service registration center can be realized through the control of the central processing unit.

[0174] like Figure 4 As shown, the electronic device 9600 may further include: a communication module 9110, an input unit 9120, an audio processor 9130, a display 9160, and a power supply 9170. It is worth noting that the electronic device 9600 does not necessarily have to include Figure 4 In addition, the electronic device 9600 may also include all components shown in Figure 4 For components not shown, reference may be made to the prior art.

[0175] like Figure 4 As shown, the central processing unit 9100 is sometimes also referred to as a controller or operation control, and may include a microprocessor or other processor device and / or logic device. The central processing unit 9100 receives input and controls the operation of various components of the electronic device 9600.

[0176] Memory 9140 can be, for example, one or more of a cache, flash memory, hard drive, removable media, volatile memory, non-volatile memory, or other suitable devices. It can store the aforementioned failure-related information and also store programs that execute the relevant information. The CPU 9100 can execute the programs stored in memory 9140 to implement information storage or processing.

[0177] The input unit 9120 provides input to the central processing unit 9100. The input unit 9120 may be, for example, a keypad or touch input device. The power supply 9170 is used to provide power to the electronic device 9600. The display 9160 is used to display objects such as images and text. The display may be, for example, an LCD display, but is not limited thereto.

[0178] The memory 9140 may be a solid-state memory, such as a read-only memory (ROM), random access memory (RAM), or SIM card. Alternatively, it may be a memory that retains information even when power is off, can be selectively erased, and is capable of storing additional data. Examples of such memory are sometimes referred to as EPROMs. The memory 9140 may also be some other type of device. The memory 9140 includes a buffer memory 9141 (sometimes referred to as a buffer). The memory 9140 may include an application / function storage unit 9142 for storing application programs and function programs, or processes used by the central processing unit 9100 to execute operations of the electronic device 9600.

[0179] The memory 9140 may also include a data storage unit 9143 for storing data, such as contacts, digital data, images, sounds, and / or any other data used by the electronic device. The driver storage unit 9144 of the memory 9140 may include various driver programs for communication functions of the electronic device and / or for executing other functions of the electronic device (such as messaging applications, address book applications, etc.).

[0180] The communication module 9110 is a transmitter / receiver that transmits and receives signals via the antenna 9111. The communication module 9110 (transmitter / receiver) is coupled to the central processor 9100 to provide input signals and receive output signals, which may be the same as the case of a conventional mobile communication terminal.

[0181] Based on different communication technologies, multiple communication modules 9110 may be provided in the same electronic device, such as cellular network modules, Bluetooth modules, and / or wireless local area network modules. The communication module 9110 (transmitter / receiver) is also coupled to a speaker 9131 and a microphone 9132 via an audio processor 9130, providing audio output via the speaker 9131 and receiving audio input from the microphone 9132, thereby implementing common telecommunication functions. The audio processor 9130 may include any suitable buffer, decoder, amplifier, etc. Furthermore, the audio processor 9130 is coupled to the central processing unit 9100, enabling local recording via the microphone 9132 and playback of stored audio via the speaker 9131.

[0182] Embodiments of the present application also provide a computer-readable storage medium capable of implementing all steps of the method for implementing automatic service discovery based on the xxl-job transformation service registration center in the above embodiment, where the execution subject is a server or a client. The computer-readable storage medium stores a computer program, which, when executed by a processor, implements all steps of the method for implementing automatic service discovery based on the xxl-job transformation service registration center in the above embodiment, where the execution subject is a server or a client. For example, when the processor executes the computer program, the following steps are implemented:

[0183] Step S101: register the microservice gateway, the multi-copy xxl-job-admin scheduling center, and the microservice scheduled task executor with the service registration center; the microservice gateway provides routing-based access for the microservices registered with the service registration center; the microservice scheduled task executor contains the service name;

[0184] Step S102: The client accesses the xxl-job-admin scheduling center to create a scheduling task and specifies a service name, so that the xxl-job-admin scheduling center can query the list of online microservice instances in the service registration center according to the service name, select the target instance according to the load balancing strategy, and obtain the URL of the target microservice scheduled task executor. The client accesses the xxl-job-admin scheduling center to create a scheduling task and specifies a service name, so that the xxl-job-admin scheduling center can query the list of online microservice instances in the service registration center according to the service name, select the target instance according to the load balancing strategy, and obtain the URL of the target microservice scheduled task executor.

[0185] Step S103: The xxl-job-admin scheduling center sends a request to the URL of the target microservice scheduled task executor, triggering the microservice scheduled task executor to execute the scheduled task, and returns the execution result to the xxl-job-admin scheduling center.

[0186] As can be seen from the above description, the computer-readable storage medium provided in the embodiment of the present application registers the microservice gateway, the multi-copy xxl-job-admin scheduling center and the microservice scheduled task executor to the service registration center, and the configuration items are centrally stored and managed in the service registration center. At the same time, the microservice gateway is used to provide routing-based access and load balancing for the xxl-job-admin scheduling center and the microservice scheduled task executor. The xxl-job-admin scheduling center obtains the online microservice scheduled task executor from the service registration center and calls the executor to execute the scheduled task, rather than relying on the executor to actively register. This method solves the problems of high management cost and difficult dynamic expansion when deploying xxl-job alone, and provides a xxl-job deployment method that is easy to manage in a unified manner, highly available, and flexible in configuration, and realizes the automatic discovery and dynamic scheduling of scheduled tasks in a microservice environment.

[0187] Embodiments of the present application also provide a computer program product capable of implementing all steps of the method for implementing automatic service discovery based on the xxl-job transformation service registry center in the above embodiment, where the execution subject is a server or a client. When the computer program / instructions are executed by a processor, the steps of the method for implementing automatic service discovery based on the xxl-job transformation service registry center are implemented. For example, the computer program / instructions implement the following steps:

[0188] Step S101: register the microservice gateway, the multi-copy xxl-job-admin scheduling center, and the microservice scheduled task executor with the service registration center; the microservice gateway provides routing-based access for the microservices registered with the service registration center; the microservice scheduled task executor contains the service name;

[0189] Step S102: The client accesses the xxl-job-admin scheduling center to create a scheduling task and specifies a service name, so that the xxl-job-admin scheduling center can query the list of online microservice instances in the service registration center according to the service name, select the target instance according to the load balancing strategy, and obtain the URL of the target microservice scheduled task executor. The client accesses the xxl-job-admin scheduling center to create a scheduling task and specifies a service name, so that the xxl-job-admin scheduling center can query the list of online microservice instances in the service registration center according to the service name, select the target instance according to the load balancing strategy, and obtain the URL of the target microservice scheduled task executor.

[0190] Step S103: The xxl-job-admin scheduling center sends a request to the URL of the target microservice scheduled task executor, triggering the microservice scheduled task executor to execute the scheduled task, and returns the execution result to the xxl-job-admin scheduling center.

[0191] As can be seen from the above description, the computer program product provided by the embodiment of the present application registers the microservice gateway, the multi-copy xxl-job-admin scheduling center and the microservice scheduled task executor to the service registration center, and the configuration items are centrally stored and managed in the service registration center. At the same time, the microservice gateway is used to provide routing-based access and load balancing for the xxl-job-admin scheduling center and the microservice scheduled task executor. The xxl-job-admin scheduling center obtains the online microservice scheduled task executor from the service registration center and calls the executor to execute the scheduled task, rather than relying on the executor to actively register. This method solves the problems of high management cost and difficult dynamic expansion when deploying xxl-job alone, and provides a xxl-job deployment method that is easy to manage in a unified manner, highly available, and flexible in configuration, and realizes the automatic discovery and dynamic scheduling of scheduled tasks in a microservice environment.

[0192] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods, apparatuses, or computer program products. Thus, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROMs, optical storage, etc.) containing computer-usable program code.

[0193] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (apparatus), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowcharts and / or block diagrams. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0194] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0195] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0196] Specific embodiments are used in the present invention to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the method of the present invention and its core ideas. At the same time, for those skilled in the art, according to the ideas of the present invention, there may be changes in the specific implementation methods and application scopes. In summary, the contents of this specification should not be understood as limiting the present invention.

Claims

1. A method for realizing automatic service discovery by transforming the service registration center based on xxl-job, characterized in that: The method comprises: Register the microservice gateway, multi-copy xxl-job-admin scheduling center, and microservice scheduled task executor to the service registration center; the microservice gateway provides routing-based access to microservices registered to the service registration center; the microservice scheduled task executor contains the service name; The client accesses the xxl-job-admin scheduling center to create a scheduling task and specifies the service name, so that the xxl-job-admin scheduling center can query the list of online microservice instances in the service registration center according to the service name, select the target instance according to the load balancing strategy, and obtain the URL of the target microservice scheduled task executor; The xxl-job-admin scheduling center sends a request to the URL of the target microservice scheduled task executor, triggering the microservice scheduled task executor to execute the scheduled task and return the execution result to the xxl-job-admin scheduling center.

2. The method for realizing automatic service discovery based on xxl-job transformation service registration center according to claim 1 is characterized in that: The steps of registering the microservice gateway, the multi-copy xxl-job-admin scheduling center, and the microservice scheduled task executor with the service registration center include: Microservice scheduled task executor: Add the client dependency corresponding to the service registry; define a unique identifier in its configuration file as the service name in the service registry; xxl-job-admin scheduling center: Delete the fixed address configuration of the microservice scheduled task executor and add the client dependency corresponding to the service registration center; By modifying the dynamic routing logic, bind the service name to the scheduling task, so that the service name can be specified when creating a scheduling task in the web interface; Microservice Gateway: Add client dependencies corresponding to the service registry; configure the service name and the address of the registry.

3. The method for realizing automatic service discovery based on xxl-job transformation service registration center according to claim 1 is characterized in that: The step of obtaining the URL of the target microservice scheduled task executor includes: obtaining the IP address of the target instance, obtaining the executor port from the metadata of the target instance, and splicing the IP address and the executor port into a complete URL.

4. The method for realizing automatic service discovery based on xxl-job transformation service registration center according to claim 3 is characterized in that: The step of obtaining the URL of the target microservice scheduled task executor also includes: The xxl-job-admin scheduling center periodically pre-generates all URLs and stores them in the local cache. When a task is triggered, the URL in the cache is directly read. Deploy the microservice scheduled task executor in the Kubernetes environment and assign it a stable DNS name. When scheduling tasks, the xxl-job-admin scheduling center uses the DNS name to build the URL.

5. The method for realizing automatic service discovery based on xxl-job transformation service registration center according to claim 1 is characterized in that: The method for obtaining the microservice online instance list includes: performing a health check on all service instances registered with the service registration center, maintaining healthy service instances in the microservice online instance list for query and call, and removing unhealthy service instances from the microservice online instance list; the xxl-job-admin scheduling center monitors service change events and perceives changes in service instances in real time.

6. The method for realizing automatic service discovery based on xxl-job transformation service registration center according to claim 1 is characterized in that: Also includes: The multi-copy xxl-job-admin scheduling center achieves load balancing through Nginx reverse proxy; Split the database task table of the xxl-job-admin scheduling center by task ID or business line, with the master database handling write operations and the slave database handling read operations; A message queue is introduced between the xxl-job-admin scheduling center and the microservice scheduled task executor to asynchronously trigger the task request; the xxl-job-admin scheduling center is only responsible for task scheduling, and the trigger request is distributed by the message queue.

7. The method for realizing automatic service discovery based on xxl-job transformation service registration center according to claim 1 is characterized in that: Also includes: The microservice scheduled task executor uses dynamic thread pool technology to automatically adjust the number of its core threads according to its real-time load situation; Deploy the microservice scheduled task executor in the Kubernetes environment, and use the HPA function built into the Kubernetes environment to automatically adjust the number of instances of the microservice scheduled task executor based on CPU or memory usage indicators.

8. A method and device for realizing automatic service discovery by transforming the service registration center based on xxl-job, characterized in that: The device comprises: The service registration module is used to register the microservice gateway, the multi-copy xxl-job-admin scheduling center, and the microservice scheduled task executor with the service registration center; the microservice gateway provides routing-based access to the microservices registered with the service registration center; the microservice scheduled task executor contains the service name; The task scheduling module is used for the client to access the xxl-job-admin scheduling center to create a scheduling task and specify a service name, so that the xxl-job-admin scheduling center can query the list of online microservice instances in the service registration center according to the service name, select the target instance according to the load balancing strategy, and obtain the URL of the target microservice scheduled task executor; The task execution module is used to send a request from the xxl-job-admin scheduling center to the URL of the target microservice scheduled task executor, trigger the microservice scheduled task executor to execute the scheduled task, and return the execution result to the xxl-job-admin scheduling center.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the program, the steps of the method for realizing automatic service discovery based on xxl-job transformation of the service registration center are implemented as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method for realizing automatic service discovery based on xxl-job transformation of the service registration center are implemented as described in any one of claims 1 to 7.

Images