Node.js Deployment with Tomcat: Architecture Options and Step‑by‑Step Implementation

The 京友邦 project needed to support PC, mobile app, and WeChat clients. The previous Velocity‑template approach required maintaining two sets of controller interfaces (ModelAndView for PC and RESTful for app/WeChat), tightly coupled front‑end and back‑end, and made first‑page rendering inefficient due to heavy database queries.

To solve these problems, the team decided to adopt Node.js, enabling front‑back separation via RESTful APIs and leveraging server‑side rendering to improve initial page load performance. The article focuses on the deployment strategy for a Node.js application that calls a Tomcat service, rather than on Node.js development details.

2. Node.js Deployment Structures

2.1 Independent deployment of Node and Tomcat

Advantages:

Each service runs in its own environment, providing resource isolation and easier troubleshooting.

Disadvantages:

Load balancing for Node‑to‑Tomcat traffic is cumbersome; it may require an internal VIP and additional load‑balancing configuration.

Additional Docker containers are needed.

Extra domain, VIP, and other resources must be provisioned.

Jone and the operations team support this scheme by allowing Node to be deployed as a worker application and by providing compilation and packaging support for Node.

2.2 Co‑locating Node and Tomcat in the same Docker container

Advantages:

No need for external load balancing; Node can call Tomcat via localhost.

No extra Docker containers, VIPs, or domain resources are required.

Disadvantages:

Node and Tomcat compete for the same container resources.

Both services must be started together via a combined script, which adds restart complexity.

Operations support this approach by allowing Node to be started before Tomcat and by providing script hooks for joint deployment.

2.3 Summary

After evaluating both options, the team selected the second approach—running Node and Tomcat in a single Docker container—because it avoids additional resource requests and eliminates the need for load‑balancing configuration.

3. Deployment and Release Steps

1. After testing the Node application locally, package it with all dependencies and place the complete Node package as a subdirectory of the Tomcat web application. The Tomcat build process remains unchanged, but the Node package is shipped together with the Tomcat artifact.

2. Build and deploy the Tomcat application on Jone as usual. The resulting Docker directory contains both the Tomcat files and the Node subdirectory.

3. Add a startup script that launches the Node process before Tomcat starts. Example:

#!/bin/bash
# Wait for Node dependencies to be ready
sleep 10
# Start Node application
node /path/to/node_app/app.js &
# Start Tomcat
catalina.sh run

4. Update each host's Nginx configuration so that the upstream points to the Node port (default 3000) instead of Tomcat. Example:

upstream tomcat_you.jd {
    server 127.0.0.1:3000 weight=10 max_fails=2 fail_timeout=30s;
}

5. Change the Tomcat instance port inside the Docker container to match the Node port defined in Nginx. This decouples Tomcat's internal port from the external routing.

4. Monitoring and Logging

The released application must be monitored to avoid silent failures. The project uses UMP for URL health checks, port availability monitoring, and a unified logging platform to trace issues in the Node layer. Optional PM2 integration can provide process‑level monitoring for Node clusters, though it was not introduced in the production environment due to time constraints.