Let microservices no longer get "lost": actual code snippets and application stories of API gateways

Have you ever encountered this situation - there are more and more microservices in the company, each service has its own interface and address, and calling it is like finding the exit in a maze? For a while, service A needs to call B's data, and for a while, C has to find D to verify permissions. Just maintaining these calling relationships is a headache. Not to mention security control. Can't each service have its own set of identity verification?

That's why we have to talk about API gateways.

Imagine if the microservice architecture is a lively party, then the API gateway is the receptionist at the door. It is responsible for checking the invitation list (identity verification), guiding guests to the correct room (routing request), controlling the admission rhythm (current limiting), and recording who comes and who leaves (log monitoring). Without it, the party can easily descend into chaos.

What does it look like in code?

A simple gateway routing configuration example

Assuming you are using Spring Cloud Gateway (which is quite common in the Java ecosystem), a basic routing configuration might look like this:

@Bean public RouteLocator customRouteLocator(RouteLocatorBuilder builder) { return builder.routes() .route("product_service", r -> r .path("/api/products/**") .filters(f -> f .addRequestHeader("X-Request-Source", "gateway") .circuitBreaker(config -> config .setName("productCB") .setFallbackUri("forward:/fallback/product"))) .uri("lb://PRODUCT-SERVICE")) .route("order_service", r -> r .path("/api/orders/**") .uri("lb://ORDER-SERVICE")) .build(); }

What does this code do? It tells the gateway: All requests that start with /api/products/ are forwarded to the service named PRODUCT-SERVICE. By the way, a request header is added, and circuit breakers and downgrades are configured - in case the product service cannot respond temporarily, it will be transferred to the backup plan. The order service routing is simpler and is forwarded directly.

You see, with just a few lines, external callers don't need to know how many microservices there are and which IP address they live in. They only need to face the gateway.

The benefits are real

Someone may ask: Will adding an extra layer make the system slower? Indeed, there is always some overhead with one more link. But compared with the benefits it brings, the cost is often worth it.

For example, safety. Instead of implementing JWT verification repeatedly in each service, let the gateway handle it uniformly:

# A configuration example of a gateway filter filters: - name: JwtAuthFilter args: secretKey: "your-secret-key-here" excludePaths: - "/api/public/login" - "/health"

Now, except for the two public interfaces of login and health check, all other requests must first pass token verification. When you want to modify the verification rules, you only need to change this place.

Another example is monitoring. When all traffic passes through the gateway, you suddenly have an ideal observation point. Which interfaces are called most frequently? What is the average response time? Are there any abnormalities in the error rate? These data are collected at the gateway level, which is much more convenient than going to each service to retrieve logs.

There is also version management. When you want to upgrade the API of a certain service but cannot make all callers change it immediately, you can make a fuss in the gateway - direct traffic to different versions of service instances based on the version number in the request header. Old users continue to use the old interface, while new users enjoy new features, and the transition is smooth.

What should you pay attention to when choosing?

There are many choices of API gateways on the market. How to choose? I don’t think you need to pursue the most complete functions. The key is whether these things are convenient:

First, the performance loss must be within an acceptable range. A good gateway should find a balance between added functionality and introduced latency. Second, the configuration must be flexible enough. Like the code example above, routing rules can be defined using configuration or code to adapt to the habits of different teams. Third, the monitoring information must be detailed. When something goes wrong, you need to be able to quickly determine whether it's a fault with the gateway or a fault with one of the services behind it.

Its compatibility with your existing technology stack is also important. If your microservices are mainly written in Go, it may be more practical to choose a gateway that is Go-friendly and has good community support.

Some considerations during actual deployment

Talking on paper is ultimately shallow. To actually use it, you have to think about some details in advance.

For example, what should I do if the gateway itself becomes a single point of failure? Simple, deploy a few more instances and add load balancing in front. For another example, how can the configuration be updated without restarting the service? Some gateways support hot update configuration. Changing routing rules does not require restarting the process, which is very friendly to online services.

Logging also needs to be designed carefully. What logs should the gateway keep? Too much will affect performance, too little will be detrimental to troubleshooting. Usually the metadata of the request and response (time, path, status code, client IP) is necessary, but for potentially large content like the request body, you have to choose carefully, maybe only record the request body of a specific path, or only sample the record.

There is also caching. Some query request results will not change in a short period of time and can be cached at the gateway layer and returned directly to reduce the pressure on back-end services. But which interfaces are suitable for caching and how long they should be cached depend on business characteristics.

Be honest

The microservice architecture is like a double-edged sword. Splitting it into small services makes development and deployment more flexible, but it also increases the complexity of management. The API gateway is like the "front desk" of this complex system. It does not handle the core business, but without it, it will be difficult for the entire system to operate gracefully.

Starting with a few lines of routing configuration, and slowly adding security, monitoring, and current limiting capabilities, you will find that this "receptionist" role is becoming more and more important. It allows backend services to do what they do best without having to deal with cross-cutting concerns.

That’s what a good tool should be—easy to use, not messy, and helpful at critical moments. You can probably appreciate this when you no longer need to worry about the messy details of calling services all day long.

Established in 2005,kpowerhas been dedicated to a professional compact motion unit manufacturer, headquartered in Dongguan, Guangdong Province, China. Leveraging innovations in modular drive technology,kpowerintegrates high-performance motors, precision reducers, and multi-protocol control systems to provide efficient and customized smart drive system solutions.kpowerhas delivered professional drive system solutions to over 500 enterprise clients globally with products covering various fields such as Smart Home Systems, Automatic Electronics, Robotics, Precision Agriculture, Drones, and Industrial Automation.