从 sl.yunjii.cn/um 迁移

背景

UM 现在是云集唯一的对外身份后端。老应用原先对接 sl.yunjii.cn/um，本指南说明如何迁移到 um.yunjii.cn/php。

迁移方案对比

方案 A：Nginx 反代（零改动）

在 sl.yunjii.cn 的 Nginx 配置中添加：

# /www/wwwroot/sl.yunjii.cn 的 nginx 配置
location /um/ {
    proxy_pass https://127.0.0.1:3100/php/;
    proxy_set_header Host um.yunjii.cn;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

配置后：

• 老应用继续调用 https://sl.yunjii.cn/um/connect.php，Nginx 内网转发到 um.yunjii.cn/php/connect.php
• 老应用零代码改动
• 延迟增加 < 5ms（同机房内网）
• sl.yunjii.cn/um 目录下的 PHP 文件可全部删除

mv /www/wwwroot/sl.yunjii.cn/um /www/wwwroot/sl.yunjii.cn/um.bak

方案 B：配置切换（1 行改动）

如果应用代码里 API 地址是配置项，直接改一行：

PHP 应用

// 改前
$apiUrl = 'https://sl.yunjii.cn/um';

// 改后
$apiUrl = 'https://um.yunjii.cn/php';

Node.js 应用

# .env
UM_API_URL=https://um.yunjii.cn/php  # 改前是 https://sl.yunjii.cn/um

Python 应用

# settings.py
UM_API_URL = 'https://um.yunjii.cn/php'  # 改前是 https://sl.yunjii.cn/um

redirect_uri 处理

不需要改 redirect_uri，因为：

• 现有应用的回调地址都是回调到自己的域名（如 https://ai.yunjii.cn/login/callback）
• 不是回调到 sl.yunjii.cn/um/callback.php
• OAuth 回调地址与应用域名绑定，与 API 端点无关

域名授权补充

迁移后需要在 um_appdomain 表补充应用的授权域名（如果之前没配置）：

-- 批量补充授权域名（按需修改）
INSERT INTO um_appdomain (appid, domain) VALUES
(1000, 'sl.yunjii.cn'),
(1003, 'vip.yunjii.cn'),
(1005, 'pay.yunjii.cn'),
(1006, 'os.yunjii.cn'),
(1007, 'es.yunjii.cn'),
(1008, 'up.yunjii.cn'),
(1010, 'dl.yunjii.cn'),
(1011, 'win.yunjii.cn'),
(1012, 'vi.yunjii.cn'),
(1013, 'ai.yunjii.cn'),
(1015, 'work.yunjii.cn'),
(1017, 'mf.yunjii.cn'),
(1018, 'studio.yunjii.cn');

验证清单

迁移后逐项验证：

• 调用 https://um.yunjii.cn/php/connect.php?act=login&appid=YOUR_APPID&type=wx 返回登录 URL
• OAuth 完整流程跑通（生成 URL → 扫码 → 回调 → 获取用户信息）
• check_token 接口返回 code: 1
• social_uid 与迁移前一致（同一用户身份不变）
• 二次查询 connect.php?act=query 正常返回

回滚方案

如果迁移后出现问题，可立即回滚：

方案 A 回滚：注释 Nginx 反代规则，恢复 sl 的 PHP 文件

mv /www/wwwroot/sl.yunjii.cn/um.bak /www/wwwroot/sl.yunjii.cn/um
# nginx reload

方案 B 回滚：把配置项改回 https://sl.yunjii.cn/um，重启应用

迁移时间线建议

1. 第 1 周：um.yunjii.cn/php 稳定运行，监控错误日志
2. 第 2 周：在 sl.yunjii.cn 配置 Nginx 反代，老应用零改动切换
3. 第 3-4 周：逐个应用把 API 端点配置改为 um.yunjii.cn/php
4. 第 5 周：确认所有应用已切换，删除 sl 的 Nginx 反代规则和 PHP 备份

常见问题

Q: 迁移后用户需要重新登录吗？

A: 不需要。Token 存在 um_user_token 表，数据库共享，现有 Token 继续有效。

Q: appid/appkey 会变吗？

A: 不会。数据库共享，um_apps 表的 appid/appkey 完全不变。

Q: 如果应用同时部署在多台服务器，需要都改吗？

A: 视方案而定：

• 方案 A（Nginx 反代）：应用零改动，多台服务器自动生效
• 方案 B（配置切换）：每台服务器的配置都要改

Q: 迁移期间可以双跑吗？

A: 可以。Nginx 反代方案本质上是双入口过渡，老应用走 sl.yunjii.cn/um，新应用走 um.yunjii.cn/php，数据库单一源，无冲突。