SpiffWorkflow项目中使用基于路径的路由配置指南

前言

在现代Web应用部署中，合理的路由配置对于系统架构至关重要。本文将详细介绍如何在SpiffWorkflow项目中配置基于路径的路由策略，帮助开发者在单一域名下优雅地部署前后端服务。

为什么需要基于路径的路由

在传统部署方案中，前后端分离应用通常采用不同的子域名部署，例如：

• 前端：frontend.example.com
• 后端：backend.example.com

但这种方案存在Cookie共享问题。由于浏览器安全策略限制，跨子域名的Cookie访问会受到限制，而SpiffWorkflow的后端服务需要设置Cookie供前端读取。

基于路径的路由方案则能完美解决这个问题，它允许我们在同一域名下部署前后端服务：

• 前端：spiff.example.com
• 后端：spiff.example.com/api

配置步骤详解

1. 前端配置

在前端环境中，需要设置路由策略为基于路径的模式：

SPIFFWORKFLOW_FRONTEND_RUNTIME_CONFIG_APP_ROUTING_STRATEGY=path_based

2. 后端配置

后端服务需要知晓完整的访问路径，以下是关键环境变量配置：

# 前端访问地址
SPIFFWORKFLOW_BACKEND_URL_FOR_FRONTEND=https://spiff.example.com

# 后端API基础地址
SPIFFWORKFLOW_BACKEND_URL=https://spiff.example.com/api

# OpenID服务器地址（开发环境示例，生产环境请勿使用）
SPIFFWORKFLOW_BACKEND_OPEN_ID_SERVER_URL=https://spiff.example.com/api/openid

# 连接器代理地址（集群内部DNS）
SPIFFWORKFLOW_BACKEND_CONNECTOR_PROXY_URL=http://spiffworkflow-connector:8004

3. 路径前缀处理

SpiffWorkflow后端API设计遵循特定路径规范，它期望接收的请求路径格式为/v1.0/status而非/api/v1.0/status。因此，我们需要处理路径前缀问题。

方案一：代理重写

在反向代理层（如Nginx、Apache）配置路径重写规则，将/api/v1.0/status重写为/v1.0/status后再转发给后端服务。

方案二：WSGI路径前缀配置

如果无法在代理层进行路径重写，可以通过以下环境变量告知后端服务路径前缀：

SPIFFWORKFLOW_BACKEND_WSGI_PATH_PREFIX=/api

此配置将：

1. 作为WSGI的SCRIPT_NAME参数
2. 在路由前自动移除指定的路径前缀
3. 确保后端生成的URL仍包含/api前缀

WSGI技术背景

WSGI（Web Server Gateway Interface）是Python Web应用与Web服务器之间的标准接口。常见的WSGI实现包括：

• Gunicorn（Green Unicorn）
• uWSGI
• mod_wsgi（Apache模块）
• CherryPy

在SpiffWorkflow项目中，正确配置WSGI路径前缀对于基于路径的路由策略至关重要。

生产环境建议

1. 安全考虑：生产环境中不建议使用内置的OpenID服务器，应配置专业的身份认证服务
2. 连接器代理：尽可能使用集群内部DNS地址，确保网络通信安全高效
3. HTTPS：所有外部访问都应启用HTTPS加密
4. 负载均衡：考虑在代理层实现负载均衡以提高系统可用性

总结

通过基于路径的路由配置，我们可以在单一域名下优雅地部署SpiffWorkflow前后端服务，解决Cookie共享问题，同时保持系统的可维护性和扩展性。正确理解并配置路径前缀处理是方案成功的关键所在。