Why Tomcat Alone Won’t Cut It: Leveraging Nginx for Load Balancing and Health Checks

Why Tomcat Alone Won’t Cut It: Leveraging Nginx

When a browser sends an HTTP request it first resolves the domain via DNS to an IP address. In a typical Alibaba Cloud setup a domain can bind at most three public IPs, so deploying multiple Tomcat instances quickly hits DNS limits.

Problems of Using Only Tomcat

DNS can bind only three IPs, preventing horizontal scaling beyond three Tomcat nodes.

Each service requires its own Tomcat cluster; ten services would need thirty public‑IP servers, driving up cost.

Each service also needs a separate domain, increasing DNS management overhead.

Public‑IP addresses must be purchased from carriers or cloud providers, which is expensive.

Public servers act as the entry layer and must be protected by firewalls and other security measures.

Tomcat cannot serve static files efficiently; a front‑end server such as Nginx or Apache is required for static content.

During a Tomcat deployment the server is unavailable, causing a one‑third request failure rate when only three DNS‑bound IPs are used. DNS itself cannot automatically remove a faulty IP because it only resolves names and has no knowledge of server health.

Why Nginx Helps

Nginx provides health‑check and automatic retry capabilities that Tomcat lacks. If one Tomcat node becomes unreachable, Nginx can forward the request to another healthy node and temporarily remove the failed node from the upstream pool.

upstream test {<br/>    server 127.0.0.1:8001 fail_timeout=60s max_fails=2; # Server A<br/>    server 127.0.0.1:8002 fail_timeout=60s max_fails=2; # Server B<br/>}

This failover is transparent to the client; the client never sees a request failure because Nginx retries the request on a working node.

Virtual Hosts and Reverse Proxy

Nginx can map multiple sub‑domains to different directories or Tomcat clusters, enabling clean separation of services.

http {<br/>    include mime.types;<br/>    default_type application/octet-stream;<br/>    sendfile on;<br/>    keepalive_timeout 65;<br/>    server {<br/>        listen 80;<br/>        server_name www.abc.com;<br/>        location / { root html/www; index index.html index.htm; }<br/>    }<br/>    server {<br/>        listen 80;<br/>        server_name bbs.abc.com;<br/>        location / { root html/bbs; index index.html index.htm; }<br/>    }<br/>    server {<br/>        listen 80;<br/>        server_name blog.abc.com;<br/>        location / { root html/blog; index index.html index.htm; }<br/>    }<br/>}

For routing to Tomcat clusters, define upstream groups and proxy specific URL paths:

upstream serverGroup1 {<br/>    server 192.168.225.100:8080;<br/>    server 192.168.225.101:8082 weight=2;<br/>    server 192.168.225.102:8083;<br/>    server 192.168.225.103:8084 backup;<br/>}<br/><br/>upstream serverGroup2 {<br/>    server 192.168.225.110:8080;<br/>    server 192.168.225.111:8080 weight=2;<br/>    server 192.168.225.112:8080;<br/>    server 192.168.225.113:8080 backup;<br/>}<br/><br/>server {<br/>    listen 80;<br/>    server_name picture.itdragon.com;<br/>    location /group1 { proxy_pass http://serverGroup1; }<br/>    location /group2 { proxy_pass http://serverGroup2; }<br/>    error_page 500 502 503 504 /50x.html;<br/>    location = /50x.html { root html; }<br/>}

With this setup, a single public domain can host multiple sub‑domains, each pointing to a distinct Tomcat cluster, while Nginx handles health checks, failover, and static content delivery.

In summary, relying solely on Tomcat leads to scalability, cost, and reliability issues; integrating Nginx provides essential load balancing, health monitoring, and virtual‑host capabilities.