从大型JSF单体应用拆分模块至异构技术栈并保留原有访问方式

Got it, let's walk through a practical, low-risk approach to split your JSF monolith module into a separate heterogeneous stack while keeping all existing links functional and maintaining feature parity.

1. 统一路由层：反向代理实现无缝转发 #

The core of keeping old links working is routing traffic intended for your target module to the new service, while leaving the rest of the JSF app untouched. Here's how to set this up:

• Use a reverse proxy (like Nginx or Apache) as the entry point for all user requests. Configure location rules to match the old module's URL pattern (e.g., /app/legacy-module/*) and forward those requests to your new service's backend.
• Preserve critical request context: Make sure to pass cookies, headers, and request parameters through the proxy so the new service can access user sessions and input data correctly.

Example Nginx config snippet:

# Forward all legacy module traffic to the new service
location /app/legacy-module/ {
    proxy_pass http://new-service:8080;
    proxy_set_header Host $host;
    proxy_set_header Cookie $http_cookie;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

# All other traffic goes to the JSF monolith
location / {
    proxy_pass http://jsf-monolith:8080;
    # Same header preservation rules here
}

This way, users hitting the old URL will be served by the new service without noticing any change in the address bar.

2. Session & Authentication Sharing #

Since your JSF app uses HTTP sessions, the new service needs to access the same session data to keep users authenticated and maintain state. Two reliable options:

• Shared session storage: Use a distributed cache like Redis to store session data. Configure both the JSF monolith (via libraries like redisson or Spring Session if using Spring) and the new service (e.g., Express.js with connect-redis, Spring Boot with Spring Session) to use the same Redis instance. This lets both apps read/write the same session data using the user's session ID cookie.
• Token-based auth (for longer-term): If you want to move away from session-based auth, you can add an OAuth2/OpenID Connect layer. The JSF app can issue JWT tokens when users log in, and the new service can validate these tokens to authenticate users. This requires more upfront work but is better for microservices scalability.

3. Feature Parity & Gradual Migration #

Don't try to migrate the entire module at once—break it into smaller, testable chunks to reduce risk:

• Start with isolated pages: Pick a standalone page from the module (e.g., a settings page with no tight dependencies on other JSF components) to migrate first. Build its equivalent in your chosen JS framework and backend REST service, then route only that page's traffic to the new service via the proxy.
• Validate with automated tests: Use tools like Cypress or Selenium to create end-to-end tests that run against both the old JSF page and the new page. Ensure all user actions (form submissions, navigation, data displays) behave identically.
• Gray rollouts: Use the proxy to route a small percentage of traffic (e.g., 10% of users) to the new service. Monitor error rates, performance, and user feedback before expanding to more users. For example, Nginx's split_clients module can split traffic based on user IP:

split_clients "${remote_addr}" $traffic_target {
    10%       "http://new-service:8080";
    *         "http://jsf-monolith:8080";
}

location /app/legacy-module/ {
    proxy_pass $traffic_target;
    # Header preservation rules
}

4. Handling Cross-Module Interactions #

If the legacy module interacts with other parts of the JSF app (e.g., redirects from JSF pages to the module, data sharing), ensure these flows still work:

• Redirects: Update any JSF beans that redirect to the legacy module to use the same URL path—since the proxy handles routing, the redirect will go to the new service automatically.
• Data sharing: If the JSF app needs to pass data to the new service, use URL parameters, request bodies, or shared database records. Avoid tight coupling; prefer REST API calls from the JSF app to the new service if direct data access isn't feasible.

5. Data Consistency #

If both the JSF monolith and new service access the same database:

• Use database transactions carefully to avoid race conditions. For example, if both apps update the same record, ensure transactions are properly isolated.
• If the new service uses its own database, implement change data capture (CDC) with tools like Debezium to sync data from the JSF app's database to the new service's database in real time.

Final Tips #

• Monitor everything: Set up logging (ELK Stack) and monitoring (Prometheus + Grafana) for both the JSF app and new service to catch issues early.
• Keep the old module running temporarily: Don't delete the legacy code until you're confident the new service is fully stable and all users are migrated. This gives you a rollback option if something goes wrong.

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