从 sl.yunjii.cn/um 迁移

架构更新（2026-07）：本文档描述的是 SL 作为 um.yunjii.cn/php 反向代理中间层时，老应用如何迁移到 UM 的方案。自 2026-07 起，sl.yunjii.cn 已改为 UM 的整站镜像——由 OpenResty vhost 直接把 sl.yunjii.cn 的 root 指向 /www/wwwroot/um.yunjii.cn，与 um.yunjii.cn 共享同一套代码与数据库（yunjii.um_*）。因此 SL 与 UM 现已等价：老应用无论对接 sl.yunjii.cn 还是 um.yunjii.cn 都落到同一后端，无需"迁移"即可继续运行。本页下方方案仅作为"保留历史兼容入口"的参考；新对接请直接走 um.yunjii.cn/oauth/*（OAuth 2.1）或开放平台 open.yunjii.cn。

背景

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

好消息：sl 和 um 共享同一个 MySQL 数据库（yunjii.um_*），所以 appid / appkey 完全不变，无需重新申请。SL 作为老应用兼容中间层长期保留，迁移是渐进式的——老应用不迁也能继续跑，新对接直接走 OAuth 2.1。

迁移方案对比

方案	代码改动	推荐场景
A. Nginx 反代（推荐）	0	老应用不想改代码
B. 配置切换	1 行	应用有 API 地址配置项
C. 硬切换	多处	应用重构期

方案 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 作为内部应用中间层长期保留

SL 中间层定位：sl.yunjii.cn/um/* 路由长期保留，作为老应用的兼容入口。该目录下的 PHP 文件已被 Nginx 反代接管不再直接执行，可清空冗余文件但路由本身不删。新对接请直接走 um.yunjii.cn/oauth/*（OAuth 2.1 + OIDC）。

方案 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_apps.domains 字段（JSON 数组）补充应用的授权域名（如果之前没配置）。在控制台应用编辑页通过标签式输入添加，或直接 SQL 更新：

-- 补充授权域名（domains 字段为 JSON 数组，按需修改）
UPDATE um_apps SET domains = JSON_ARRAY_APPEND(domains, '$', 'sl.yunjii.cn') WHERE appid = 1000;
UPDATE um_apps SET domains = JSON_ARRAY_APPEND(domains, '$', 'vip.yunjii.cn') WHERE appid = 1003;
UPDATE um_apps SET domains = JSON_ARRAY_APPEND(domains, '$', 'pay.yunjii.cn')  WHERE appid = 1005;
-- ...按需补充其他应用

um_apps.domains 字段支持域名、IP、带端口格式，后台采用标签式输入交互。已删除旧的 um_appdomain 独立表，域名信息统一存储在 um_apps.domains。

验证清单

迁移后逐项验证：

调用 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 周：um.yunjii.cn/php 稳定运行，监控错误日志
第 2 周：在 sl.yunjii.cn 配置 Nginx 反代，老应用零改动切换
第 3-4 周：逐个应用把 API 端点配置改为 um.yunjii.cn/php
第 5 周起：SL 中间层作为兼容层长期保留，仅清理已确认无流量的 PHP 备份；新对接应用直接走 um.yunjii.cn/oauth/*

常见问题

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，数据库单一源，无冲突。