A multi-heterogeneous web service series scheduling method based on Nginx custom module

Abstract

The application discloses a kind of based on Nginx custom module's multi-heterogeneous web service series connection scheduling method, for the high coupling degree of existing multi-heterogeneous web service series connection scheme, poor compatibility, fault tolerance is insufficient, the problem of high resource occupation, six custom function modules are deployed in Nginx process, realize the unified registration of multi-heterogeneous web service, regular series connection, protocol format automatic adaptation, fault tolerance fusing scheduling and full-link tracking;Through service series connection special state machine control scheduling whole life cycle, using double storage mechanism maintains call context, realizes link level intelligent traffic distribution.The application does not need additional deployment middleware, greatly reduces system coupling degree and resource occupation, improves heterogeneous service compatibility and system availability, adapts to various scale enterprise web service cluster scene.

Description

Technical Field

[0001] This invention belongs to the field of deployment and scheduling optimization technology of Web service clusters, and particularly relates to a method for serial scheduling of multiple heterogeneous Web services based on a custom Nginx module. Background Technology

[0002] With the rapid development of microservice architecture and distributed systems, enterprise application systems are typically composed of multiple independent web services working together. Nginx, as a high-performance HTTP and reverse proxy server, has become the mainstream choice for service gateways and traffic entry points due to its high concurrency processing capabilities and modular expansion mechanism. Developing custom Nginx modules to implement specific business logic processing has become a common technical approach in the industry.

[0003] In the field of web service scheduling, existing technologies have implemented basic functions such as load balancing, traffic distribution, and protocol proxying based on Nginx. For example, existing technologies have disclosed solutions for handling single-backend service calls by forwarding requests at the Nginx level, or for routing different services through API gateway systems. Regarding heterogeneous service integration, existing technologies have also proposed some protocol conversion solutions for specific scenarios, such as the conversion between REST and SOAP protocols, and the conversion between JSON and XML formats.

[0004] However, in the process of implementing the above-mentioned technology, the applicant discovered that the prior art has at least the following shortcomings: First, there is a lack of deep support for orchestrating multiple web services. Existing Nginx extension solutions are mainly designed for single web service invocation scenarios. When a business request needs to call multiple independent web services sequentially to complete, the invocation logic usually needs to be implemented through business code at the upper application layer. This results in Nginx only undertaking simple forwarding functions, failing to fully utilize its high-performance processing capabilities, and also greatly increasing the development complexity of upper-layer applications and the coupling between systems.

[0005] Secondly, there is a lack of a generalized heterogeneous service adaptation layer. Most existing integration solutions are designed for specific business scenarios. When it is necessary to integrate web services developed based on different technology stacks such as Java, Python, and Node.js, it is often necessary to develop dedicated adaptation logic for each service. This makes it impossible to automatically identify and adapt to protocol types, data formats, and calling methods, resulting in high development costs and poor scalability.

[0006] Third, there is a lack of effective transaction consistency guarantees and fault tolerance mechanisms. In scenarios involving multiple services being called in sequence, if a response delay or failure occurs in any link of the call chain, existing technologies struggle to detect intermediate states and cannot automatically roll back and compensate for the states of the called services, which can easily lead to system data inconsistencies and a cascading failure effect.

[0007] Fourth, it lacks the ability to intelligently optimize the call path. The scheduling strategy of the existing solution is relatively static and cannot dynamically adjust the service execution order or weight according to the running status of the entire path or historical call data, making it difficult to cope with performance fluctuations under high load conditions.

[0008] Existing technologies struggle to achieve an ideal balance between "low coupling," "high availability," and "general-purpose orchestration" when handling dynamic scheduling in heterogeneous environments with multiple technology stacks. This is particularly true in scenarios requiring awareness of the entire link's status and precise logic-level control, where a deeply customized mechanism is lacking. Therefore, there is an urgent need to develop a scheduling scheme based on a high-performance Nginx custom module to achieve efficient interconnection of multiple heterogeneous web services, automatic protocol adaptation, and intelligent transaction management, thereby addressing core issues in existing technologies such as rigid architecture, fault propagation, and data inconsistency. Summary of the Invention

[0009] The purpose of this invention is to provide a method for scheduling multiple heterogeneous web services in series based on a custom Nginx module. This method aims to solve technical problems in existing technologies, such as high system coupling, complex adaptation of heterogeneous technology stacks, lack of end-to-end state control, and transaction inconsistencies and avalanche effects caused by local service failures during the series of multiple microservices. This invention achieves loosely coupled access and dynamic hot loading of service configurations by building a custom registration module within Nginx. It utilizes a generalized adaptation layer to shield protocol and data format differences in multi-language environments and introduces a state machine-based service series lifecycle management mechanism. This enables precise logical-level control, anomaly interception, and transaction compensation rollback for the multi-service series paths. Simultaneously, it combines an intelligent load balancing algorithm based on end-to-end state awareness and response entropy calculation to optimize traffic distribution. Thus, while ensuring high system performance and high availability, it achieves automated orchestration, efficient collaborative operation, and lightweight deployment of multiple heterogeneous web services.

[0010] To achieve the above objectives, this invention provides a method for serial scheduling of multiple heterogeneous web services based on a custom Nginx module, comprising the following steps: Deploy a serial scheduling processing system within the Nginx server process, obtain a preset hierarchical structured service registration configuration file, and parse the basic information of each Web service to be scheduled; Upon receiving a front-end business request, the system performs regular expression matching through a preset service concatenation rule engine to match the concatenation execution chain corresponding to the front-end business request, and initializes a service concatenation-specific state machine; wherein, the concatenation execution chain defines the execution order, parameter passing rules, and result aggregation rules of multiple Web services; According to the execution order defined in the serial execution chain, the protocol type and data format of heterogeneous Web services with different technology stacks are automatically identified and adapted through the generalized adaptation layer; During the request processing phase of Nginx, the state machine drives the flow of the serial execution chain. A dual storage mechanism combining request headers and Nginx shared memory is used to maintain the call context, so as to pass through parameters and share intermediate results among multiple Nginx worker processes. The entire path operation status of the serial execution chain is collected in real time, and intelligent load balancing scheduling at the link level is performed to dynamically adjust the allocation weight of each service instance. The processing results of each Web service in the chain of execution are aggregated and a unified response data is returned to the front end.

[0011] Furthermore, obtaining the preset hierarchical structured service registration configuration file includes: A hierarchical structure is adopted to classify and register multiple Web services to be scheduled according to business modules, so as to achieve logical isolation of configuration rules between business modules; The basic information includes service name, access address, port, technology stack type, initial weight, and availability status; The method also includes: triggering a custom configuration module to reread the configuration file by listening to a semaphore, thereby enabling dynamic updates of service information without restarting the Nginx process.

[0012] Furthermore, the execution of regular expression matching and the matching chain through the service concatenation rule engine includes: Secondary development is performed based on Nginx's rewrite and location modules, using regular expressions to match the front-end request path; The rule engine is invoked to break down a single request from the front end into multiple requests to call web services, and declarative rules are used to define the dependencies and triggering conditions between each request.

[0013] Furthermore, automatic identification and adaptation through a generalized adaptation layer includes: By using the common HTTP or HTTPS protocol to shield the underlying differences between different technology stacks, it can be adapted to heterogeneous technology stacks such as Java, Python, Node.js and PHP. The generalized adaptation layer performs request format adaptation, response result adaptation, and communication protocol adaptation; wherein, the request format adaptation supports multi-directional conversion between JSON, Form and XML formats.

[0014] Furthermore, the service-connected dedicated state machine adopts a six-state transition model to manage the entire lifecycle of scheduling. This six-state transition model includes: IDLE state, NAVIGATING state, AUTH_VALIDATING state, COMPONENT_LOADING state, RENDERING state, and COMPLETED state; The state machine triggers a corresponding pluggable middleware at each state transition point. The middleware performs error handling, permission interception, and loading progress display, and supports pluggable middleware architecture expansion.

[0015] Furthermore, performing link-level intelligent load balancing scheduling includes: Real-time monitoring of CPU utilization, memory usage, concurrent connections, and response latency metrics for each Web service instance; Based on the discrete probability of the response time distribution of each service instance within a preset sampling window, the response entropy of the perception system's operating trend is calculated. By combining performance metrics with the response entropy, the request weights allocated to each service instance are adjusted in real time using a dynamic weighting algorithm.

[0016] Furthermore, it also includes end-to-end transaction consistency guarantee steps: Generate a globally unique distributed transaction ID for each chained call request, and record the execution status and return result of each service node; Logical matching is performed on the key business fields returned by each Web service based on the preset business semantic model; When a call failure or business semantic conflict is detected, the rollback interface of the successfully executed service is called in reverse order according to the predefined compensation strategy to ensure the data consistency of the entire chain of calls.

[0017] Furthermore, it also includes fault tolerance degradation and flow control circuit breaking steps: Perform heartbeat checks to monitor the liveness of each Web service instance and configure dedicated degradation rules for core business services; When a web service call fails, an exponential backoff retries are performed according to a preset number of retries. When the number of consecutive failures reaches a threshold, a flow circuit breaker is triggered, and the state machine calls a preset degradation interface.

[0018] Furthermore, it also includes configuring the canary release steps: When service configuration changes, the production environment traffic is cloned as shadow traffic, and the complete flow process of the serial execution chain is simulated in the shadow link, and the interfaces involving write operations are mocked. The validity of the new configuration rules is verified by controlling the traffic ratio. Once the verification is successful, the full release is completed.

[0019] Furthermore, it also includes end-to-end tracing steps: Generate a globally unique link ID for each chained call request, and transmit the link ID between each Web service node; Record the entire request log in real time to locate the faulty node using the link ID.

[0020] This invention, by deeply integrating custom modules such as service registration configuration, rule orchestration, state machine control, and intelligent scheduling within Nginx, offers the following significant advantages over existing technologies: By decoupling the physical information of each service from the application code through a custom service registration configuration module, changes to service configurations only require modifying the Nginx configuration file and performing hot reloading to take effect, without modifying the business logic code. This mechanism significantly reduces system coupling and effectively improves the response speed of development and operations in large-scale service scenarios.

[0021] The generalized adaptation layer successfully shields the underlying differences in communication protocols and data formats between different technology stacks, supporting multi-directional conversion between various formats. When adding heterogeneous services, the system can automatically complete protocol and format adaptation, enabling rapid integration and "code-free access" of heterogeneous services, greatly enhancing the system's scalability.

[0022] A dedicated state machine based on a six-state transition model is introduced to integrate complex asynchronous call logic into a unified state management framework. By triggering middleware at state transition points, permission interception and error handling are implemented throughout the entire request processing process, effectively enhancing system robustness in complex orchestration scenarios and significantly reducing the risk of failure in microservice environments.

[0023] By using distributed transaction IDs and business semantic verification logic, the system can monitor the execution status of each node in the chain in real time. When a call failure or business semantic conflict is detected, a reverse compensation strategy can be automatically triggered to roll back the status. Combined with exponential backoff retries and traffic circuit breaking mechanisms, the atomicity of data across the entire chain is ensured, preventing the "avalanche effect" caused by local failures.

[0024] The intelligent load balancing module, by calculating the "response entropy" that senses the system's operational trends, can more sensitively identify subtle system fluctuations than traditional solutions. Combined with real-time monitoring of CPU, memory, and response latency, the system achieves link-level intelligent scheduling. While maintaining high concurrency processing capabilities, it effectively improves the utilization efficiency of cluster resources and reduces request response latency.

[0025] Through the shadow link preheating mechanism, the system can verify the validity of new configuration rules without affecting production traffic, ensuring the security of canary releases. Meanwhile, the full-link tracing technology based on global link IDs enables operations personnel to quickly locate faulty nodes in complex links, significantly improving the observability and troubleshooting efficiency of distributed systems. Attached Figure Description

[0026] Figure 1 This is a flowchart of the serial scheduling method of the present invention. Detailed Implementation

[0027] like Figure 1 As shown, this embodiment provides a method for serial scheduling of multiple heterogeneous web services based on a custom Nginx module, including the following steps: Deployment and Initialization Phase: A sequential scheduling system is deployed within the Nginx server process. A pre-defined hierarchical service registration configuration file is obtained, and basic information about each web service to be scheduled is parsed. This deployment method eliminates the need for a separate gateway or service registry middleware; all scheduling logic is completed within the Nginx process, significantly reducing system resource consumption and deployment complexity. Furthermore, the hierarchical configuration file avoids configuration rule conflicts between different business modules, improving configuration maintainability. This step, by directly embedding the scheduling logic into the Nginx kernel-level module, effectively shortens the request processing path and eliminates the performance overhead caused by cross-process communication in traditional solutions.

[0028] Request interception and chain matching phase: Upon receiving a front-end business request, a pre-defined service concatenation rule engine performs regular expression matching to match the concatenation execution chain corresponding to the front-end business request, and initializes a service concatenation-specific state machine. The concatenation execution chain defines the execution order, parameter passing rules, and result aggregation rules for multiple Web services. The regular expression-based rule engine can flexibly adapt to different front-end request paths and business scenarios, and the service concatenation-specific state machine can incorporate complex multi-service call logic into a unified state management framework, avoiding state chaos caused by asynchronous calls and improving the controllability and determinism of the scheduling process.

[0029] Protocol adaptation and compatibility phase: Following the execution order defined in the aforementioned sequential execution chain, a generalized adaptation layer automatically identifies and adapts the protocol types and data formats of heterogeneous Web services with different technology stacks. This generalized adaptation layer decouples protocol and format conversion logic from business code, eliminating the need for business services to concern themselves with the technology stacks and data formats of other services. This completely shields the underlying differences between heterogeneous technology stacks, significantly reducing the development costs of multi-service collaboration. This adaptation layer acts as a technical translator, ensuring seamless collaboration between cross-language and cross-framework services.

[0030] Context Maintenance and Flow Phase: During the Nginx request processing phase, the state machine drives the flow of the sequential execution chain. A dual storage mechanism combining request headers and Nginx shared memory is used to maintain the call context, enabling parameter pass-through and intermediate result sharing across multiple Nginx worker processes. This dual storage mechanism achieves lightweight parameter pass-through through request headers and cross-worker process intermediate result sharing through Nginx shared memory, solving the context synchronization problem in Nginx's multi-process architecture and ensuring state consistency of multi-service sequential processes in high-concurrency scenarios. This design avoids frequent serialization and deserialization overhead, significantly improving data access throughput.

[0031] Intelligent scheduling and load balancing phase: The entire path operation status of the serial execution chain is collected in real time, and link-level intelligent load balancing scheduling is performed to dynamically adjust the allocation weight of each service instance. Link-level load balancing scheduling can allocate traffic from the perspective of the overall business chain, avoiding the local overload problem caused by traditional single-service load balancing. By collecting dynamic indicators such as CPU, memory, and response latency in real time, service resource utilization can be improved, and request response latency can be significantly reduced.

[0032] Result aggregation and response phase: Aggregate the processing results of each Web service in the chain of execution and return unified response data to the front end; unified result aggregation can provide the front end with a standardized response format, so the front end does not need to pay attention to the differences in the return formats of multiple backend services, which greatly reduces the complexity of front end integration and development costs.

[0033] As one implementation method, obtaining the preset hierarchical structured service registration configuration file in this embodiment includes: A hierarchical structure is adopted to classify and register multiple Web services to be scheduled according to business modules, thereby achieving logical isolation of configuration rules between business modules. This logical isolation mechanism ensures that the configurations of different business lines do not interfere with each other, greatly reducing the risk of configuration conflicts in large-scale clusters. The basic information includes service name, access address, port, technology stack type, initial weight, and availability status. The method also includes: triggering a custom configuration module to reread the configuration file by listening to a semaphore, enabling dynamic updates of service information without restarting the Nginx process. The dynamic hot-reloading mechanism can complete service configuration changes without interrupting business services, ensuring the real-time effect of configuration refreshes, and significantly improving business continuity and operational agility.

[0034] As one implementation method, this embodiment includes performing regular expression matching and matching chain execution through a service concatenation rule engine, including: Secondary development is performed based on Nginx's rewrite and location modules. Regular expressions are used to match frontend request paths. The rule engine is invoked to break down a single frontend request into multiple web service call requests, and declarative rules are used to define the dependencies and triggering conditions between these requests. This secondary development based on Nginx's native modules fully leverages its mature high-concurrency processing capabilities. The declarative rule definition method allows operations personnel to orchestrate services without writing code, significantly reducing the technical threshold and timeline for business deployment.

[0035] As one implementation method, automatic identification and adaptation through a generalized adaptation layer in this embodiment includes: This system masks the underlying differences between different technology stacks by using the universal HTTP or HTTPS protocol to adapt to heterogeneous technology stacks such as Java, Python, Node.js, and PHP. A generalized adaptation layer performs request format adaptation, response result adaptation, and communication protocol adaptation. The request format adaptation supports multi-directional conversion between JSON, Form, and XML formats. This multi-format and multi-directional conversion capability can adapt to the vast majority of existing services. When adding heterogeneous services, only the type needs to be marked in the configuration, enabling rapid service integration and code-free adaptation.

[0036] As one implementation method, in this embodiment, the service-in-series dedicated state machine adopts a six-state transition model to manage the entire lifecycle of scheduling. The six-state transition model includes: The state machine comprises four states: IDLE (idle state), NAVIGATING (navigation / route matching state), AUTH_VALIDATING (authentication / identification state), COMPONENT_LOADING (component / sub-service loading state), RENDERING (rendering / result processing state), and COMPLETED (complete state). At each state transition point, the state machine triggers a corresponding pluggable middleware. This middleware performs error handling, permission interception, and loading progress display, and supports pluggable middleware architecture extensions. This six-state transition model breaks down the complex multi-service scheduling process into clear, standardized stages, each with clearly defined responsibilities. The pluggable middleware architecture allows for flexible extension of different general processing logics, enabling the addition of new features without modifying the core scheduling code, significantly improving the system's scalability and robustness.

[0037] As one implementation method, the link-level intelligent load balancing scheduling in this embodiment includes: The system monitors the CPU utilization, memory usage, concurrent connections, and response latency of each Web service instance in real time. Based on the probability of the response time distribution of each service instance within a preset sampling window, it calculates the response entropy to perceive the system's operational trend. Combining performance metrics with the response entropy, a dynamic weighting algorithm adjusts the request weights allocated to each service instance in real time. Response entropy can detect the dispersion of service response time and identify potential system jitter issues in advance. Compared to traditional scheduling methods based solely on average response time, response entropy can more accurately predict service sub-health states, adjust traffic allocation in advance, and ensure extremely high service availability.

[0038] As one implementation method, this embodiment also includes a full-link transaction consistency guarantee step: A globally unique distributed transaction ID is generated for each chained call request, recording the execution status and return result of each service node. Based on a predefined business semantic model, key business fields returned by each Web service are logically matched. When a call failure or business semantic conflict is detected, the rollback interface of the successfully executed service is called in reverse order according to a predefined compensation strategy, ensuring data consistency throughout the entire chained call. Business semantic verification can detect logical errors that traditional status code detection cannot identify, while the reverse compensation rollback mechanism ensures the atomicity of cross-service calls, effectively guaranteeing the accuracy and eventual consistency of business data.

[0039] As one implementation method, this embodiment also includes fault tolerance degradation and flow circuit breaking steps: Heartbeat detection is performed to monitor the liveness of each Web service instance, and dedicated degradation rules are configured for core business services. When a Web service call fails, exponential backoff retries are executed according to a preset number of retries. When the number of consecutive failures reaches a threshold, a circuit breaker is triggered, and the state machine calls a preset degradation interface. Exponential backoff retries can avoid secondary impacts on the failed service, and the circuit breaker mechanism can promptly cut off the source of the failure, prevent the failure from spreading along the service chain, completely eliminate the "avalanche effect," and ensure the overall stability of the system.

[0040] As one implementation method, this embodiment also includes a step of configuring canary release: When service configuration changes, production environment traffic is cloned as shadow traffic, and the complete flow of the serial execution chain is simulated in the shadow link. Interfaces involving write operations are also mocked. The validity of the new configuration rules is verified through traffic ratio control. Once verification is successful, a full deployment is completed. This shadow traffic verification mechanism enables full testing of configuration changes without affecting real production data, significantly reducing the risk of production incidents caused by configuration changes.

[0041] As one implementation method, this embodiment also includes a full-link tracing step: A globally unique link ID is generated for each chained call request and is transparently transmitted among all Web service nodes. The entire link request log is recorded in real time to locate faulty nodes using the link ID. The global link ID enables log association across the entire link, allowing operations personnel to quickly and accurately locate faulty nodes and root causes without having to check service logs one by one, significantly improving operational efficiency.

[0042] As a supplement to the foregoing embodiments, the following extended description is provided: The multi-heterogeneous Web service serial scheduling system of this embodiment is implemented based on the Nginx custom module architecture. It integrates six major functional modules within the Nginx process, without the need to deploy an additional independent gateway or service registry middleware. The six major modules are: Nginx custom service registration configuration module, Nginx-based service serialization rule engine, heterogeneous Web service generalized adaptation layer, Nginx service-level fault tolerance and degradation module, business link-based intelligent load balancing module, and full-link monitoring module.

[0043] I. Specific implementation of each core functional module; 1. Nginx custom service registration configuration module; This module is a custom configuration extension component for Nginx. By designing a standardized service registration configuration format, it uniformly registers the basic information of each web service (including service name, access address, port, technology stack type, initial weight, and availability status) into the Nginx configuration file, achieving unified management of multiple web services. This module supports a dynamic configuration refresh mechanism, triggering a configuration reread process by listening to system semaphores. Service configuration changes take effect without restarting the Nginx process, solving the problem of needing to redeploy services after configuration modifications in traditional solutions. Simultaneously, the service registration configuration file adopts a layered structured design, classifying and registering web services according to business modules. This achieves logical isolation of configuration rules between different business modules, avoids configuration rule conflicts, and improves the maintainability of the configuration file. In practical applications, this module can support the unified registration of hundreds of heterogeneous web services with low latency in configuration refresh effects.

[0044] 2. Service chaining rule engine based on Nginx; This rule engine is built upon Nginx's native request rewriting and path matching modules, supporting both visual and script-based rule configuration. It allows for defining the execution order of multiple web services, request parameter passing rules, and return result aggregation rules based on business needs. The engine employs a combination of regular expression matching and route forwarding. Upon receiving a single business request from the frontend, it breaks it down into multiple web service call requests. Following the defined concatenation rules, it performs collaborative processing across multiple services, aggregates the results, and returns a unified response to the frontend. This engine automatically passes and converts request parameters, automatically adapting to the parameter requirements of different web services. This eliminates the need for additional parameter adaptation in the business code, significantly reducing development workload in multi-service concatenation scenarios.

[0045] 3. A generalized adaptation layer for heterogeneous web services; This adaptation layer is a lightweight component built within Nginx, implemented based on the common HTTP or HTTPS protocol. It shields the underlying differences between web services using different technology stacks, achieving compatibility with web services across all technology stacks, including Java, Python, Node.js, and PHP. The adaptation layer includes three core functions: first, request format adaptation, supporting multi-directional conversion between JSON, Form, and XML formats; second, response result adaptation, converting the return results from different web services into a unified return format; and third, communication protocol adaptation, supporting compatibility with multiple communication protocols such as HTTP 1.1, HTTP 2, and HTTPS. When adding heterogeneous web services, simply mark the corresponding service's technology stack type in the service registration configuration, and the adaptation layer will automatically complete the protocol and format conversion, achieving rapid integration without code modification.

[0046] 4. Nginx service-level fault tolerance and degradation module; This module constructs a dedicated state machine for service interconnection based on state management design principles, enabling precise control over the entire lifecycle of scheduling. The state machine employs a six-state transition model, specifically including idle, scheduling, authentication, component loading, result processing, and completion states. Each state transition node triggers a corresponding pluggable middleware, which enables unified error handling, permission interception, and loading progress display. This module incorporates asynchronous loading and data prefetching into the unified management framework of the state machine. Furthermore, the pluggable middleware architecture supports functional expansion, significantly reducing code volume in complex routing scenarios and achieving full coverage of exception handling.

[0047] 5. Intelligent load balancing module based on business links; This module extends Nginx's native load balancing functionality to implement traffic scheduling based on business links. It can collect real-time operational status metrics for each web service, including CPU utilization, memory usage, request response time, and concurrent connections. It dynamically adjusts request allocation weights based on the service's actual operational status; the better the service's performance, the higher the allocated request weight. Furthermore, for business links with multiple services interconnected, this module implements link-level load balancing scheduling, distributing traffic from the perspective of the entire business link and preventing overall link congestion caused by overload of a single service instance. In cluster scenarios with dozens of service instances, this module effectively improves the resource utilization of the service cluster and reduces request response latency in multi-service interconnected scenarios.

[0048] 6. End-to-end monitoring module; This module is a custom monitoring extension component for Nginx. It generates a globally unique link ID for each chained call request. Throughout the entire process of chaining multiple services, the link ID is transparently transmitted between each web service node. The module uses the link ID to record the call time, input / output parameters, and state machine transition logs of each service node in real time. When a fault occurs, operations and maintenance personnel can quickly locate the specific faulty node using the link ID, significantly shortening troubleshooting time and improving operational efficiency.

[0049] II. Specific implementation process of this embodiment; 1. Environment Preparation and Custom Module Compilation: First, download the corresponding version of the Nginx source code and the source code of the six custom modules of this invention. Configure the necessary environment for Nginx compilation on the server's Linux operating system, including compilation tools, regular expression libraries, compression libraries, and Secure Sockets Layer (SSL) libraries. Integrate the six custom modules into the Nginx source code using Nginx's module integration configuration commands. Execute the Nginx compilation and installation commands to complete the deployment of Nginx with the custom modules. After installation, use the Nginx version and module query commands to check the loaded custom modules and verify that all modules are functioning correctly.

[0050] 2. Unified Registration Configuration for Multiple Web Services: Create a dedicated service registration configuration file in the default Nginx configuration directory. Following the standardized format of the custom service registration configuration module, write the basic information of each web service into the file. Taking the user service (Python technology stack) and payment service (Java technology stack) as examples, the service registration configuration content is as follows: The service identifier for the user service is `user_service`, the service access address is 192.168.1.100, the service port is 8001, the technology stack type is marked as `python`, the initial weight is 8, and the service status is marked as online; the service identifier for the payment service is `pay_service`, the service access address is 192.168.1.101, the service port is 8080, the technology stack type is marked as `java`, the initial weight is 10, and the service status is marked as online. Incorporate the service registration configuration file into the main configuration file using Nginx configuration import directives, enable the service registration configuration module, and execute the Nginx configuration refresh directive to complete the unified registration of multiple web services. The registration status of the services can be viewed through Nginx's built-in status interface.

[0051] 3. Configuring Service Chaining Rules and Enabling the Engine: Create a service chaining rule configuration file in the Nginx configuration directory. Define the chaining rules for multiple web services in the file according to business needs, including request matching rules, service call order, parameter passing rules, and result aggregation rules. Taking order creation as an example, its service chaining rule configuration is as follows: the request path matched by the rule is / api / create_order, the matching request method is POST, the service call order is user service, order service, and payment service are executed sequentially, the parameter passing rule is to pass through all frontend request parameters, and the result aggregation rule is to aggregate the return results of each service in JSON format. Import the above rule configuration file into the Nginx service configuration node, enable the service chaining rule engine, and configure the unified domain name and port for frontend access. After configuration, send a test frontend request to verify whether Nginx completes the chaining calls and result returns of multiple services according to the defined rules.

[0052] 4. Generalized Adaptation Layer and Intelligent Load Balancing Configuration: Enable the generalized adaptation layer module in the Nginx main configuration file. Configure default request and response format conversion rules based on the registered service technology stack type. The generalized adaptation layer configuration is as follows: the default request format is JSON, the default response format is JSON, and for services using the PHP technology stack, Form format requests are automatically converted to JSON format. Enable the intelligent load balancing module and configure parameters such as the service running status collection interval and dynamic weight adjustment threshold. The intelligent load balancing configuration is as follows: the service running status collection interval is 1 second, the CPU utilization threshold is set to 80%, and the weight adjustment ratio is set to 0.5. Configure multiple instances of load balancing nodes for each registered web service. The intelligent load balancing module will implement traffic scheduling based on the dynamic weight of the service. After configuration, verify the format conversion function of the adaptation layer by calling services with different technology stacks, and check whether traffic is dynamically distributed according to the service running status.

[0053] 5. Fault Tolerance and Degradation Configuration: Create a fault tolerance and degradation configuration file in the Nginx configuration directory, enable the fault tolerance and degradation module, and configure the relevant parameters for fault detection, automatic retry, service degradation, and traffic circuit breaking. The configuration content of the fault tolerance and degradation module is as follows: heartbeat interval is 3 seconds, request timeout is 500 milliseconds, automatic retries are 3 times, retry interval is 1 second, continuous fault circuit breaking threshold is 10 times, circuit breaking duration is 60 seconds, and the global degradation interface is / api / downgrade. Configure dedicated degradation rules for core business services to achieve fine-grained fault tolerance management. After configuration, simulate service failure to verify the functionality of the fault tolerance and degradation module, including service status marking for heartbeat detection, automatic request retry, degradation interface triggering, and traffic circuit breaking.

[0054] 6. Overall Integration and Optimization: After configuring and enabling all modules, conduct full-service integration testing to assess the overall performance of the multi-web service interconnection. Collect service performance metrics, including request response time, service availability, and resource utilization. Adjust the configuration parameters of each module based on actual performance. Verify the dynamic configuration refresh function by modifying service registration configurations or interconnection rules and executing Nginx's configuration refresh command to confirm that the configuration takes effect without restarting Nginx. Complete performance stress testing to ensure that under high concurrency scenarios, the request response latency of the multi-service interconnection meets business requirements and service availability remains at a high level.

[0055] In practical applications, the solution in this embodiment enables loosely coupled interconnection of multiple heterogeneous web services. Service configuration changes can be completed without modifying business code, simply by modifying the Nginx configuration file, significantly improving development and operation efficiency. Simultaneously, it achieves rapid, code-free integration of heterogeneous services across the entire technology stack, offering strong scalability. Through fault tolerance and transaction consistency mechanisms, it effectively avoids the cascading failure effect caused by service failures, improving system availability. The overall solution is based on Nginx, requiring no additional middleware deployment, resulting in low resource consumption and adaptability to web service cluster scenarios of varying sizes.

[0056] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention. It should be noted that any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for serial scheduling of multiple heterogeneous web services based on Nginx custom modules, characterized in that, Includes the following steps: Deploy a serial scheduling processing system within the Nginx server process, obtain a preset hierarchical structured service registration configuration file, and parse the basic information of each Web service to be scheduled; Upon receiving a front-end business request, the system performs regular expression matching through a preset service concatenation rule engine to match the concatenation execution chain corresponding to the front-end business request, and initializes a service concatenation-specific state machine; wherein, the concatenation execution chain defines the execution order, parameter passing rules, and result aggregation rules of multiple Web services; According to the execution order defined in the serial execution chain, the protocol type and data format of heterogeneous Web services with different technology stacks are automatically identified and adapted through the generalized adaptation layer; During the request processing phase of Nginx, the state machine drives the flow of the serial execution chain. A dual storage mechanism combining request headers and Nginx shared memory is used to maintain the call context, so as to pass through parameters and share intermediate results among multiple Nginx worker processes. The entire path operation status of the serial execution chain is collected in real time, and intelligent load balancing scheduling at the link level is performed to dynamically adjust the allocation weight of each service instance. The processing results of each Web service in the chain of execution are aggregated and a unified response data is returned to the front end.

2. The method according to claim 1, characterized in that, Obtaining the preset hierarchical structured service registration configuration file includes: A hierarchical structure is adopted to classify and register multiple Web services to be scheduled according to business modules, so as to achieve logical isolation of configuration rules between business modules; The basic information includes service name, access address, port, technology stack type, initial weight, and availability status; The method also includes: triggering a custom configuration module to reread the configuration file by listening to a semaphore, thereby enabling dynamic updates of service information without restarting the Nginx process.

3. The method according to claim 1, characterized in that, The execution of regular expression matching and matching chain through the service concatenation rule engine includes: Secondary development is performed based on Nginx's rewrite and location modules, using regular expressions to match the front-end request path; The rule engine is invoked to break down a single request from the front end into multiple requests to call web services, and declarative rules are used to define the dependencies and triggering conditions between each request.

4. The method according to claim 1, characterized in that, Automatic identification and adaptation through a generalized adaptation layer includes: By using the common HTTP or HTTPS protocol to shield the underlying differences between different technology stacks, it can be adapted to heterogeneous technology stacks such as Java, Python, Node.js and PHP. The generalized adaptation layer performs request format adaptation, response result adaptation, and communication protocol adaptation; wherein, the request format adaptation supports multi-directional conversion between JSON, Form and XML formats.

5. The method according to claim 1, characterized in that, The service-connected dedicated state machine uses a six-state transition model to manage the entire lifecycle of scheduling. This six-state transition model includes: IDLE state, NAVIGATING state, AUTH_VALIDATING state, COMPONENT_LOADING state, RENDERING state, and COMPLETED state; The state machine triggers a corresponding pluggable middleware at each state transition point. The middleware performs error handling, permission interception, and loading progress display, and supports pluggable middleware architecture expansion.

6. The method according to claim 1, characterized in that, Performing link-level intelligent load balancing scheduling includes: Real-time monitoring of CPU utilization, memory usage, concurrent connections, and response latency metrics for each Web service instance; Based on the discrete probability of the response time distribution of each service instance within a preset sampling window, the response entropy of the perception system's operating trend is calculated. By combining performance metrics with the response entropy, the request weights allocated to each service instance are adjusted in real time using a dynamic weighting algorithm.

7. The method according to claim 1, characterized in that, It also includes end-to-end transaction consistency guarantee steps: Generate a globally unique distributed transaction ID for each chained call request, and record the execution status and return result of each service node; Logical matching is performed on the key business fields returned by each Web service based on the preset business semantic model; When a call failure or business semantic conflict is detected, the rollback interface of the successfully executed service is called in reverse order according to the predefined compensation strategy to ensure the data consistency of the entire chain of calls.

8. The method according to claim 1, characterized in that, It also includes fault tolerance degradation and flow circuit breaking steps: Perform heartbeat checks to monitor the liveness of each Web service instance and configure dedicated degradation rules for core business services; When a web service call fails, an exponential backoff retries are performed according to a preset number of retries. When the number of consecutive failures reaches a threshold, a flow circuit breaker is triggered, and the state machine calls a preset degradation interface.

9. The method according to claim 1, characterized in that, It also includes configuring the canary release steps: When service configuration changes, the production environment traffic is cloned as shadow traffic, and the complete flow process of the serial execution chain is simulated in the shadow link, and the interfaces involving write operations are mocked. The validity of the new configuration rules is verified by controlling the traffic ratio. Once the verification is successful, the full release is completed.

10. The method according to any one of claims 1 to 9, characterized in that, It also includes end-to-end tracing steps: Generate a globally unique link ID for each chained call request, and transmit the link ID between each Web service node; Record the entire request log in real time to locate the faulty node using the link ID.

Images