Service bus design and implementation method based on micro-service architecture

Abstract

The invention relates to a service bus design and implementation method based on a micro-service architecture, and belongs to the field of micro-services. According to the invention, load balancing and regularized forwarding are supported through the dynamic routing module, the centralized bottleneck is avoided, and the routing efficiency can be effectively improved and the request forwarding delay can be reduced by combining the real-time updating of the service registration center and the dynamic capacity expansion and shrinkage of the adaptive micro-service; the functions of fusing, degrading, current limiting and gray release are integrated, dependence on a third-party component is not needed, the system complexity is reduced, and the service iteration period is shortened; and calling chain tracking is realized based on Trace ID, and log and index analysis is combined, so that the fault positioning time is shortened from an hour level to a minute level, and the operation and maintenance efficiency is remarkably improved.

Description

Technical Field

[0001] This invention belongs to the field of microservices, specifically relating to a service bus design and implementation method based on a microservice architecture. Background Technology

[0002] As software architecture evolves towards microservices, systems are broken down into multiple independently deployed microservices with single responsibilities, making communication and collaboration between microservices a core requirement. Traditional Service Buses (ESBs) are primarily designed for monolithic architectures, but they suffer from key drawbacks in microservice scenarios: First, routing efficiency is low. Traditional ESBs use a centralized forwarding model, requiring all service requests to pass through the core bus node, easily creating performance bottlenecks. Furthermore, they cannot dynamically adjust routing paths based on service load and network latency, making them ill-suited for the dynamic scaling characteristics of microservices. Second, service governance capabilities are weak. They lack native support for microservice registration and discovery, circuit breaking and degradation, and rate limiting, requiring integration with third-party components, increasing system complexity. They also cannot implement canary releases and dynamic switching of service versions, impacting business iteration efficiency. Third, observability is lacking. They can only monitor the operational status of the bus nodes themselves, unable to track the full-link logs, latency, and exception information of microservice calls. When service calls fail, locating the root cause requires investigation across multiple systems, which is time-consuming and inefficient.

[0003] While some lightweight service gateways (such as Spring Cloud Gateway) in the industry attempt to address these issues, these gateways primarily focus on routing and forwarding, lacking unified service governance and end-to-end monitoring capabilities. They fail to form a closed loop of "communication-governance-monitoring," making it difficult to meet the stable operation requirements of large-scale microservice clusters. Therefore, designing a service bus that adapts to microservice architectures and possesses efficient routing, dynamic governance, and end-to-end observability has become a pressing technical challenge in this field. Summary of the Invention (a) Technical problems to be solved The technical problem this invention aims to solve is how to provide a service bus design and implementation method based on a microservice architecture, so as to solve the problems of traditional service buses being unable to perform dynamic routing selection and having weak service governance capabilities.

[0004] (II) Technical Solution To address the aforementioned technical problems, this invention proposes a service bus design and implementation method based on a microservice architecture, which includes the following steps: Step 1: After the microservice instance starts, it submits registration information to the service registry module; Step 2: The registry center checks the service's liveness status through a heartbeat mechanism. After completing the health check, it adds the instance information to the service registry. Step 3: The client sends a request to the API gateway module. After the gateway completes authentication, authorization, and protocol conversion, it forwards the request to the dynamic routing module. Step 4: The dynamic routing module selects the optimal microservice instance based on the service registry and preset routing rules, and forwards the request to the target instance; Step 5: The service governance module monitors the call status of microservice instances in real time. When a service anomaly is detected, it triggers the circuit breaker / degradation mechanism to ensure the overall stability of the system. Step Six: The end-to-end monitoring module traces the complete call chain of a request through the Trace ID, collects call data, and generates monitoring metrics and logs for operations and maintenance personnel to troubleshoot problems and optimize performance.

[0005] (III) Beneficial Effects This invention proposes a service bus design and implementation method based on a microservice architecture. Compared with traditional service bus methods, it supports load balancing and rule-based forwarding through a dynamic routing module, avoiding centralized bottlenecks. Combined with real-time updates from the service registry, it adapts to the dynamic scaling of microservices, effectively improving routing efficiency and reducing request forwarding latency. It integrates circuit breaking, degradation, rate limiting, and canary release functions without relying on third-party components, reducing system complexity and shortening business iteration cycles. Based on Trace ID, it implements call chain tracing, and combined with log and indicator analysis, the fault location time is shortened from hours to minutes, significantly improving operation and maintenance efficiency. Attached Figure Description

[0006] Figure 1 This is a flowchart of the processing method of the present invention. Detailed Implementation

[0007] To make the objectives, contents, and advantages of the present invention clearer, the specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples.

[0008] The purpose of this invention is to overcome the shortcomings of traditional service buses, such as the inability to perform dynamic routing and weak service governance capabilities. It proposes a service bus design and implementation method based on microservice architecture, which enables efficient communication, dynamic governance and end-to-end observability between microservices, reduces the operational complexity of microservice systems and improves system stability and business iteration efficiency.

[0009] To address the aforementioned technical problems, this invention proposes a service bus design and implementation method based on a microservice architecture, which includes the following steps: Step 1: After the microservice instance starts, it submits registration information (including service name, IP, port, version number, etc.) to the service registry module. Step 2: The registry center checks the service's liveness status through a heartbeat mechanism. After completing the health check, it adds the instance information to the service registry. Step 3: The client sends a request to the API gateway module. After the gateway completes authentication, authorization, and protocol conversion, it forwards the request to the dynamic routing module. Step 4: The dynamic routing module selects the optimal microservice instance based on the service registry and preset routing rules, and forwards the request to the target instance; Step 5: The service governance module monitors the call status of microservice instances in real time. When a service anomaly is detected (request time exceeds the set threshold), the circuit breaker / degradation mechanism is triggered to ensure the overall stability of the system. Step Six: The end-to-end monitoring module traces the complete call chain of a request through the Trace ID, collects call data, and generates monitoring metrics and logs for operations and maintenance personnel to troubleshoot problems and optimize performance.

[0010] Example 1: Figure 1 This is the main flowchart of the technical solution of this invention. For example... Figure 1 As shown, the present invention proposes a service bus design and implementation method based on a microservice architecture, which includes the following steps: Step 1: After the microservice instance starts, submit registration information to the service registry module. (1) Send registration request Service registration is the first step for microservices to access the message bus. When a new microservice instance starts, it sends a registration request to the service registry. Registration information is typically submitted in the form of structured data, including key metadata such as service name, network address, version number, and health check endpoint. The service name is used to uniquely identify a group of service instances providing the same functionality, such as user-service; the network address includes the instance's IP address and port number, such as 192.168.1.1:8080; the version number is used to manage different versions of service instances and supports scenarios such as canary releases; a health check endpoint is set up so that it can be periodically called by the registry to detect the health status of the instance.

[0011] Step 2: The registry center checks the service's liveness status using a heartbeat mechanism. After completing the health check, it adds the instance information to the service registry. Upon receiving a registration request, the service registry persists the aforementioned information to its registry, which establishes a mapping between service names and specific instance network addresses. To ensure the real-time nature and accuracy of registration information, the registry monitors the health status of instances by periodically sending heartbeat or health check requests. If an instance fails to respond multiple times consecutively, the registry marks it as unhealthy or removes it directly from the registry, thus ensuring that subsequent service discovery does not route traffic to failed instances.

[0012] Step 3: The client sends a request to the API gateway module. After the gateway completes authentication, authorization, and protocol conversion, it forwards the request to the dynamic routing module. (1) Gateway receives request As the sole entry point to the message bus, the API gateway handles the reception and preprocessing of all external requests. When a client initiates a request, it first reaches the API gateway. The gateway performs pre-processing operations such as authentication / authorization, protocol conversion, and flow control to ensure system security and consistency.

[0013] (2) The gateway authenticates the request. The gateway first verifies the requester's identity (authentication) through methods such as APP authentication (using AppKey / AppSecret) and Token authentication, and then determines whether the requester has permission to access the target resource based on the authentication result (authorization).

[0014] (3) Request Protocol Conversion The gateway converts external request protocols into internal communication protocols, transforming external HTTP / 1.1 or gRPC requests into protocols for communication between internal microservices.

[0015] In addition, to prevent backend microservices from being impacted by sudden traffic surges or malicious requests, the gateway can be configured with policies such as rate limiting and circuit breaking.

[0016] After completing the above preprocessing, the gateway will forward the standardized request to the internal dynamic routing module for further processing.

[0017] Step 4: The dynamic routing module selects the optimal microservice instance based on the service registry and preset routing rules, and forwards the request to the target instance. (1) Microservice health instance query The dynamic routing module acts as the intelligent traffic scheduling center. It first queries the service registry to obtain a list of all healthy instances of the target microservice.

[0018] (2) Determine the target instance set The dynamic routing module combines preset routing rules to determine which specific instance to send the request to. Routing rules can be set to weight-based routing, path-based routing, or parameter-based routing. Weight-based routing allocates traffic with different weights to servers with different performance levels. Servers with higher performance have higher weights and can therefore receive more traffic. Path-based or parameter-based routing directs requests to different versions of services based on the URL path of the request or a specific header.

[0019] (3) Select the best instance After determining the target instance set, a load balancing algorithm (such as round-robin, least connections, response time weighting, etc.) will ultimately select the optimal instance. Dynamic routing can automatically select the best path based on real-time conditions such as network latency and load, ensuring efficient request distribution. Finally, the gateway forwards the request to the selected target microservice instance through the internal network.

[0020] Step 5: The service governance module monitors the call status of microservice instances in real time. When a service anomaly is detected, it triggers the circuit breaker / degradation mechanism to ensure the overall stability of the system. During the request processing process of microservice instances, the service governance module monitors the status of the entire call chain in real time. By monitoring key indicators such as service response time and error rate, an elastic fault tolerance mechanism is immediately triggered to ensure the overall stability of the system when an anomaly occurs. When the response time of a service exceeds a threshold (1.2 to 1.5 times the normal average response time) or the error rate of a service exceeds a preset threshold (60%-80%), the circuit breaker will quickly trip, directly rejecting all requests sent to that service for a period of time thereafter.

[0021] Step Six: The end-to-end monitoring module traces the complete call chain of a request using the Trace ID, collects call data, and generates monitoring metrics and logs for operations and maintenance personnel to troubleshoot problems and optimize performance. (1) Assign a Trace ID to the request When a request first enters the message bus system, i.e., the API gateway, the system assigns it a globally unique Trace ID. This ID will be automatically passed to subsequent services in every subsequent service call.

[0022] (2) Generate local logs Each service generates detailed local logs when processing requests, recording metrics such as service request start time, end time, and error messages, and associates them with the Trace ID.

[0023] (3) Statistical data from the monitoring platform The monitoring platform collects the aforementioned local log data and indicator data into the monitoring platform.

[0024] (4) Reproduce the call chain The monitoring platform uses the Trace ID to piece together logs scattered across different services, reconstructing a complete call chain diagram of the request.

[0025] (5) System optimization By reviewing the call chain diagram, operations and maintenance personnel can quickly locate performance bottlenecks and root causes of faults, thereby optimizing system performance.

[0026] This invention proposes a service bus design and implementation method based on a microservice architecture. Compared with traditional service bus methods, it supports load balancing and rule-based forwarding through a dynamic routing module, avoiding centralized bottlenecks. Combined with real-time updates of the service registry, it adapts to the dynamic scaling of microservices, effectively improving routing efficiency and reducing request forwarding latency. It integrates circuit breaking, degradation, rate limiting, and canary release functions without relying on third-party components, reducing system complexity and shortening business iteration cycles. Based on Trace ID, it implements call chain tracing, and combined with log and indicator analysis, the fault location time is shortened from hours to minutes, significantly improving operation and maintenance efficiency.

[0027] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the technical principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for designing and implementing a service bus based on a microservice architecture, characterized in that, The method includes the following steps: Step 1: After the microservice instance starts, it submits registration information to the service registry module; Step 2: The registry center checks the service's liveness status through a heartbeat mechanism. After completing the health check, it adds the instance information to the service registry. Step 3: The client sends a request to the API gateway module. After the gateway completes authentication, authorization, and protocol conversion, it forwards the request to the dynamic routing module. Step 4: The dynamic routing module selects the optimal microservice instance based on the service registry and preset routing rules, and forwards the request to the target instance; Step 5: The service governance module monitors the call status of microservice instances in real time. When a service anomaly is detected, it triggers the circuit breaker / degradation mechanism to ensure the overall stability of the system. Step Six: The end-to-end monitoring module traces the complete call chain of a request through the Trace ID, collects call data, and generates monitoring metrics and logs for operations and maintenance personnel to troubleshoot problems and optimize performance.

2. The service bus design and implementation method based on microservice architecture as described in claim 1, characterized in that, In step one, service registration is the first step for microservices to access the message bus. When a new microservice instance starts, it sends a registration request to the service registry. Registration information is submitted in the form of structured data, including service name, network address, version number, and health check endpoint data. The service name is used to uniquely identify a group of service instances that provide the same function. The network address includes the IP address and port number of the instance. The version number is used to manage different versions of service instances and supports canary release scenarios. Configure a health check endpoint to be periodically invoked by the registry center to detect the health status of instances.

3. The service bus design and implementation method based on microservice architecture as described in claim 1, characterized in that, In step two, after receiving the registration request, the service registry persists the above information to its registry. The registry establishes a mapping relationship from the service name to the network address of the specific instance. The registry monitors the health status of the instance by periodically sending heartbeat or health check requests. If an instance fails to respond multiple times consecutively, the registry center will mark it as unhealthy or remove it directly from the registry, thereby ensuring that subsequent service discovery will not route traffic to the failed instance.

4. The service bus design and implementation method based on microservice architecture as described in claim 1, characterized in that, In step three, the API gateway, as the sole entry point to the message bus, is responsible for receiving and preprocessing all external requests. When a client initiates a request, it first reaches the API gateway; The gateway performs authentication / authorization, protocol conversion, and flow control operations to ensure the security and consistency of the system.

5. The service bus design and implementation method based on microservice architecture as described in claim 4, characterized in that, In step three, the gateway first verifies the identity of the requester through APP authentication and Token authentication, and determines whether the requester has permission to access the target resource based on the authentication result.

6. The service bus design and implementation method based on microservice architecture as described in claim 5, characterized in that, In step three, the gateway converts the external request protocol into an internal communication protocol, and converts the external HTTP / 1.1 or gRPC request into a protocol for communication between internal microservices. After completing the above preprocessing, the gateway forwards the standardized request to the internal dynamic routing module for further processing.

7. The service bus design and implementation method based on microservice architecture as described in claim 1, characterized in that, Step four includes: (1) Microservice health instance query The dynamic routing module is the intelligent traffic scheduling center; it first queries the service registry to obtain a list of all healthy instances of the target microservice. (2) Determine the target instance set The dynamic routing module combines preset routing rules to determine which specific instance to send the request to; (3) Select the best instance After determining the target instance set, the load balancing algorithm will eventually select the optimal instance; dynamic routing can automatically select the best path based on real-time conditions such as network latency and load to ensure efficient distribution of requests; finally, the gateway forwards the requests to the selected target microservice instance through the internal network.

8. The service bus design and implementation method based on microservice architecture as described in claim 7, characterized in that, Routing rules can be set to weight-based routing, path-based routing, or parameter-based routing. Weight-based routing assigns different weights to servers with different performance levels, with higher-performance servers receiving higher weights and thus attracting more traffic. Path-based or parameter-based routing directs requests to different versions of services based on the requested URL path or a specific header.

9. The service bus design and implementation method based on microservice architecture as described in claim 7, characterized in that, Step five includes: during the process of microservice instance processing requests, the service governance module monitors the status of the entire call chain in real time; by monitoring key indicators such as service response time and error rate, when an abnormal situation occurs, the elastic fault tolerance mechanism will be triggered immediately to ensure the overall stability of the system. When the response time of a certain service exceeds the threshold or the error rate of a certain service exceeds the preset threshold, the circuit breaker will quickly "trip" and directly reject all requests sent to that service for a period of time thereafter.

10. The service bus design and implementation method based on microservice architecture as described in claim 9, characterized in that, Step six includes: (1) Assign a Trace ID to the request When a request first enters the message bus system, i.e., the first time it enters the API gateway, the system assigns it a globally unique Trace ID; this ID will be automatically passed to subsequent services in every subsequent service call. (2) Generate local logs Each service generates detailed local logs when processing a request, recording the service request start time, end time, error information indicators, and associating them with the Trace ID; (3) Statistical data from the monitoring platform The monitoring platform collects the aforementioned local log data and indicator data into the monitoring platform. (4) Reproduce the call chain The monitoring platform uses the Trace ID to piece together logs scattered across different services, reconstructing a complete call chain diagram of the request; (5) System optimization By reviewing the call chain diagram, operations and maintenance personnel can quickly locate performance bottlenecks and root causes of faults, thereby optimizing system performance.

Images