Operations 11 min read

Mastering Nginx: From Monolith to Microservices, Load Balancing & URL Rewrites

This article traces the evolution of Java web architectures from early JSP/Servlet projects to modern SpringBoot+Vue stacks, explains Nginx’s role as a high‑performance reverse proxy, details server name matching, load‑balancing strategies, static‑dynamic separation, and URL rewrite techniques with practical configuration examples.

Sanyou's Java Diary
Sanyou's Java Diary
Sanyou's Java Diary
Mastering Nginx: From Monolith to Microservices, Load Balancing & URL Rewrites

Hello everyone, I am Sanyou.

1. System Architecture Evolution

When I first started with Java, my initial project was a book management system built with JSP+Servlet , which felt cutting‑edge at the time.

Later it evolved into a JSP+SSM architecture.

Today the most popular monolithic stack is SpringBoot+Vue .

However, as business volume grows, monolithic architectures cannot handle the exploding data and QPS demands (tens of thousands of requests per second). To address performance, the SpringCloud microservice architecture emerged, breaking an application into small, independently deployable services that provide single business functions, reducing coupling and improving fault tolerance.

Microservices provide:

High availability : traffic can be shifted to other nodes when a server fails.

High performance : multiple servers serve the same service, increasing throughput.

High scalability : additional nodes can be added to handle traffic spikes.

Note: This chapter focuses on Nginx; other microservice components are omitted.

2. What Is Nginx?

Nginx, created by Igor Sysoev, is a high‑performance HTTP and reverse‑proxy server. It uses epoll/kqueue for I/O, supports up to 50,000 concurrent connections, runs stably, and consumes very little memory and CPU.

3. server_name Matching Rules

Exact match

Wildcard match

Regex match

Regex must start with ~ , e.g., server_name ~^www\d+\.nzbc\.com$; . Without ~ , Nginx treats it as an exact match and requires ^ and $ anchors. In regex, . is a meta‑character and must be escaped; braces {} need double quotes to avoid errors.

4. Forward Proxy vs. Reverse Proxy

1. Forward Proxy

A forward proxy sits between the user and the target server; the user accesses resources through the proxy.

Typical use case: accessing a foreign website that is blocked domestically. The user sends a request to the forward proxy, which forwards it to the target server and returns the response.

In a forward proxy, the proxy acts on behalf of the client.

2. Reverse Proxy

A reverse proxy also sits between the user and the application server, but the user accesses the reverse proxy without knowing the backend server’s address. It reduces load and improves efficiency.

In a reverse proxy, the proxy acts on behalf of the server.

Nginx is a high‑performance reverse proxy server.

3. LVS

LVS solves the single‑machine performance bottleneck of Nginx.

It provides layer‑4 load balancing for multiple servers, offering high performance and high availability, often used together with keepalived. LVS can handle more concurrent connections than Nginx, while Nginx remains a layer‑7 node in the cluster.

When a user accesses an application server through Nginx, the response can bypass Nginx on the return path, reducing its load.

5. Load‑Balancing Strategies

1. Round Robin

Requests are forwarded sequentially, suitable for stateless requests; session persistence can be achieved via client‑side mechanisms.

2. Weight

Define weights using the upstream block:

<code>http{
  upstream httpnz {
    server 192.168.66.1 weight=1 down;
    server 192.168.66.2 weight=5 backup;
    server 192.168.66.3 weight=10;
  }
  server{
    listen 80;
    server_name nzbc;
    location / {
      proxy_pass http://httpnz;
    }
    error_page 500.html;
    location =/500.html{
      root html;
    }
  }
}</code>

Parameters: weight (weight), down (temporarily disabled), backup (standby server).

After modifying the config, reload Nginx with systemctl reload nginx .

3. ip_hash

Requests are assigned based on the hash of the client IP, which can lead to imbalance.

If a server goes down, its sessions are lost and subsequent requests are routed to another healthy server, preserving session continuity.

4. least_conn

Routes to the server with the fewest active connections.

5. url_hash

Routes based on a hash of the request URL; useful for static resources distributed across multiple servers.

6. fair

Routes based on server response time.

7. Summary

The most common strategy is weight‑based load balancing; other methods are less frequently used.

Methods such as ip_hash , least_conn , url_hash , and fair cannot dynamically add or remove Nginx nodes and may cause traffic skew under sudden spikes, potentially crashing a server.

6. Static‑Dynamic Separation

The goal is to separate static and dynamic resources to improve performance and availability.

<code>http{
  upstream httpnz {
    server 192.168.66.1 weight=1 down;
    server 192.168.66.2 weight=5 backup;
    server 192.168.66.3 weight=10;
  }
  server{
    listen 80;
    server_name nzbc;
    location / {
      proxy_pass http://httpnz;
    }
    location ~*/(js/img/css) {
      root html;
      index index.html index.htm;
    }
    error_page 500 502 503 504 /50x.html;
    location =/50x.html{
      root html;
    }
  }
}</code>

7. URL Rewrite

URL rewrite uses regular expressions to redirect requests.

Flags:

break – stop processing further rules.

last – continue processing subsequent rules.

redirect – return a 302 temporary redirect.

permanent – return a 301 permanent redirect.

<code>http{
  upstream httpnz {
    server 192.168.66.1 weight=1 down;
    server 192.168.66.2 weight=5 backup;
    server 192.168.66.3 weight=10;
  }
  server{
    listen 80;
    server_name nzbc;
    location / {
      rewrite ^/([0-9]+).html$ /index.jsp?pageNum=$1 break;
      proxy_pass http://httpnz;
    }
    location ~*/(js/img/css) {
      root html;
      index index.html index.htm;
    }
    error_page 500 502 503 504 /50x.html;
    location =/50x.html{
      root html;
    }
  }
}</code>
MicroservicesLoad BalancingNginxReverse ProxyServer Configuration
Sanyou's Java Diary
Written by

Sanyou's Java Diary

Passionate about technology, though not great at solving problems; eager to share, never tire of learning!

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.