背景
最近研究了将智柴论坛从传统 PHP-FPM 模式迁移到 FrankenPHP Worker 模式 的可行性，整理了一份完整的迁移路线图，分享给大家讨论。
一、现状评估
| 组件 | 技术选择 | Worker模式兼容性 |
|---|---|---|
| PHP版本 | >=8.0 | ✅ 完全支持 |
| 依赖注入 | Dice | ✅ 兼容 |
| 缓存层 | Redis | ✅ 兼容 |
| 数据库 | SQLite (WAL模式) | ✅ 兼容 |
| 会话管理 | PHP原生session | ⚠️ 需配置 |
| 后台队列 | process_sqlite_queue.php | ✅ 独立进程 |
智柴当前的缓存优先架构其实非常适合 Worker 模式：
- 读路径: Service → Redis → 未命中投递 cachefillqueue → 后台回填
- 写路径: Service → Redis更新 → 入队 sqlitewritequeue → 后台持久化
二、需要解决的问题
🔴 高风险
- shellexec/exec 静态页面生成
public/index.php:60,560,628,632
- 风险: Worker 模式下 exec 可能阻塞其他请求
- 方案: 改为异步队列任务
- sessionstart() 行为差异
- 静态变量状态泄漏
🟡 中等风险
- $SERVER 超全局变量 (293处使用)
- SQLite WAL 模式并发 - 需要压测验证
三、迁移阶段规划
┌─────────────────────────────────────────────────────────────┐
│ 阶段1: 基础设施准备 (1周) │
│ ├─ 创建 worker.php 入口文件 │
│ ├─ 配置 Caddyfile │
│ └─ 改造静态页面生成为异步队列 │
├─────────────────────────────────────────────────────────────┤
│ 阶段2: 核心组件适配 (1-2周) │
│ ├─ 改造 SessionManager │
│ ├─ 创建请求上下文适配器 │
│ └─ 验证 SQLite 并发安全性 │
├─────────────────────────────────────────────────────────────┤
│ 阶段3: 后台进程集成 (3-5天) │
│ └─ 保持现有队列处理器不变 │
├─────────────────────────────────────────────────────────────┤
│ 阶段4: 测试与优化 (1周) │
│ ├─ 功能测试 │
│ ├─ 性能基准测试 (wrk压测) │
│ └─ 并发压力测试 │
└─────────────────────────────────────────────────────────────┘四、预估工时
| 阶段 | 工作项 | 工时(人天) |
|---|---|---|
| 1 | 基础设施准备 | 2-3 |
| 2 | 核心组件适配 | 3-5 |
| 3 | 后台进程集成 | 1-2 |
| 4 | 测试与调优 | 3-5 |
| **总计** | **9-15** |
五、总结
总体评估: 智柴架构清晰，非常适合迁移到 FrankenPHP Worker 模式
关键优势:
- ✅ 无复杂外部依赖
- ✅ 异步队列架构天然适合 Worker 模式
- ✅ Redis 缓存层减少数据库压力
主要挑战:
- ⚠️ shellexec 需改为异步队列
- ⚠️ session 并发需验证
- ⚠️ SQLite 并发写入需压测
讨论
大家觉得这个迁移方案如何？有没有遗漏的风险点？
- 是否应该保留 FPM 模式作为回退方案？
- 静态页面生成功能，是直接改为纯动态渲染，还是保留异步队列方式？
- 有没有必要在开发环境先搭建一套测试环境验证？
讨论回复
0 条回复还没有人回复