Servlet/JSP平台多前端单后端架构方案咨询与部署优化

Hey there! Let's walk through practical architecture patterns that check all your boxes: a single backend managing multiple distinct frontends, solving session sharing headaches, keeping deployments lightweight, enabling independent development, and avoiding backend downtime when adding new frontends.

1. Reverse Proxy + Distributed Session Storage #

This is a common, battle-tested approach that keeps your frontends and backend decoupled while fixing session issues:

• Setup: Use a reverse proxy like Nginx or Apache to route requests. Map different frontend domains (e.g., frontend1.yourdomain.com, frontend2.yourdomain.com) or paths (e.g., /frontend1, /frontend2) to their respective WAR files. All backend API requests (e.g., /api/*) get forwarded to your backend WAR.
• Session Fix: Replace Tomcat's default in-memory session with a distributed session store (like Redis, Memcached, or JDBC-backed sessions). Configure your backend to read/write sessions from this shared store instead of the local Tomcat instance. This way, no matter which frontend sends a request, the backend pulls the same session data.
• Deployment Perks: Deploy frontends independently—upload a new WAR, update the proxy config, and you're done without touching the backend. Backend deployments also don't affect frontends (as long as API contracts stay compatible).
• Independent Development: Frontend teams can build their own WARs with unique styles/features, while the backend team focuses on core business logic.

2. Backend as API Gateway + Static Frontends #

If you're open to shifting away from JSP for frontend rendering, this approach simplifies things even more:

• Setup: Refactor your backend to act as a pure API service (using Servlet/JSP to build REST endpoints, or frameworks like Jersey/Spring MVC for easier API development). Build each frontend as static assets (HTML, CSS, JS) using modern frameworks like Vue, React, or even plain vanilla code. Host these static files on Nginx, a CDN, or a static hosting service.
• Session Fix: Ditch HttpSession entirely and use JWT (JSON Web Tokens) for authentication. When a user logs in, the backend returns a signed JWT, which the frontend stores in a cookie or localStorage. Every subsequent request to the backend includes this token, which the backend verifies to identify the user. No session sharing issues because there's no server-side session to sync.
• Deployment Perks: Frontends can be deployed in seconds—just upload new static files. Backend updates are isolated, and you can even scale the backend independently if needed. Adding a new frontend is as simple as deploying a new set of static assets pointing to the same API.
• Independent Development: Frontend teams have full control over their tech stack and UI/UX, while the backend team focuses on stable, reusable APIs.

3. Tomcat Virtual Hosts + Shared Session Configuration #

If you prefer keeping everything within a single Tomcat instance, this works too:

• Setup: Configure Tomcat's server.xml to add virtual hosts for each frontend. Each virtual host maps to its own WAR file. Your backend can be deployed as a shared context accessible to all virtual hosts (e.g., /api).
• Session Fix: Configure Tomcat to use a distributed session manager across all virtual hosts. For example, use the Redis Session Manager by adding the appropriate Manager element to your context.xml:

  <Manager className="org.apache.catalina.session.RedisSessionManager"
           host="localhost"
           port="6379"
           database="0"
           maxInactiveInterval="1800"/>
  

  This ensures all virtual hosts share the same session store, eliminating cross-frontend session issues.
• Deployment Perks: You can deploy new frontends by adding a new virtual host and dropping the WAR into the corresponding directory. If Tomcat is configured for hot deployment, you can do this without restarting the entire server.
• Note: Be careful with resource conflicts (e.g., shared library versions) across virtual hosts—keep dependencies isolated where possible.

Practical Tips #

• Decouple Logic: Ensure your backend focuses solely on business logic and data handling, not frontend rendering. This makes it easier to support multiple frontends without code changes.
• API Contracts: Define clear, stable API contracts between backend and frontends. Use tools like OpenAPI/Swagger to document endpoints, so frontend teams know exactly what to expect.
• Testing: Validate session behavior across all frontends—test that a user logged into one frontend stays authenticated when switching to another.

内容的提问来源于stack exchange，提问作者tiamat