# ai-gateway 设计:按用户粘性的多机器转发网关
> 状态:方案设计稿(未实施)
> 目标:在多台 ai-server 部署环境下,把同一用户的请求固定转发到该用户所属的机器上。
> 本文只描述方案,不包含代码实施。
---
## 1. 背景与现状约束
### 1.1 需求
1. 能配置多个后端服务地址(多个服务、每个服务多台机器)。
2. 自动转发用户请求:用户注册/首次登录在哪台机器上,后续请求就转发到哪台机器。
3. 部署多台机器时,按用户做粘性路由,而不是普通轮询负载均衡。
### 1.2 仓库现状
- 仓库是 **Spring Boot 单体后端 `ai-server` + Electron/Vue 前端**,没有独立网关、Spring Cloud Gateway、Nginx 配置或服务注册中心。
- 后端统一端口 `8980`,context-path `/js/a`;前端所有请求最终落到 `/js/a/...`。
- 没有自助注册接口:用户由管理员通过 `POST /user/create` 创建,只写入共享 PostgreSQL 的 `sys_user`,不记录所属机器。
- 登录使用 **sa-token 1.46**:token 是不透明 UUID,请求头 `x-token`,登录态和 Token-Session 都存 Redis。多台后端只要连同一个 Redis,就能识别同一个 token。
- 案件、上传文件、聊天附件、Agent 记忆/技能、Python 产物都落在**各机器本地磁盘**;`/case/open` 还会把案件数据源注册到当前 JVM 内存。
- 每台 ai-server 需要独立授权(机器码绑定)和独立工作目录,不能共享 DuckDB 文件(跨进程文件锁会失败)。
### 1.3 关键结论
不能做普通的无状态负载均衡。请求落到非用户所属机器时,即使 token 和 `caseId` 都能从 Redis 恢复,本机也没有对应的案件数据源,会直接报“当前案件数据源未打开或已释放”。
因此必须:
- 按用户做粘性路由;
- 用户绑定的节点不可用时明确失败,不自动切到其他机器;
- 用户数据迁移不在本期范围。
---
## 2. 已定型的决策
| 项 | 决策 |
|---|---|
| 工程形态 | 当前仓库新增 `ai-gateway` Maven 模块 |
| 技术栈 | Spring Boot 3.5.16 + Spring Cloud Gateway 2025.0.x(WebFlux/Netty),独立端口 `8080` |
| 用户绑定 | 用户**首次登录成功**时自动绑定到一台机器;管理员可通过接口预先绑定 |
| 用户识别 | `x-token` → sa-token 共享 Redis → userId |
| 配置 | YAML 首次播种 + PostgreSQL 运行时配置 + `/gateway/admin/**` 管理接口 |
| 节点故障 | 返回 HTTP 503 + 明确提示,不自动切换 |
| 前端 | 不改业务代码,只把 API 基地址指向网关 |
> 当前仓库没有注册接口,所以“注册在哪台机器”落地为“首次登录成功在哪台机器”。如果以后新增注册接口,只需在注册成功后调用同一个绑定服务。
---
## 3. 目标架构
```
Electron / Web
│ http://gateway:8080/js/a/**
▼
┌──────────────────────── ai-gateway :8080 ────────────────────────┐
│ 登录请求:username → node(首次成功登录后写映射) │
│ 普通请求:x-token → userId → node(Redis 缓存 + PostgreSQL 兜底)│
│ 无 token:健康节点轮询;MCP:固定节点 │
└───────────────┬──────────────────────────┬───────────────────────┘
│ │
ai-server node-1 :8980 ai-server node-2 :8980
(本地 DuckDB/附件/Agent) (本地 DuckDB/附件/Agent)
│ │
└──────── 共享 PostgreSQL(服务/节点/用户路由)
└──────── 共享 Redis(sa-token + 网关路由缓存)
```
网关只做转发和粘性决策,不复制后端鉴权逻辑;业务接口仍由 ai-server 校验 token。
### 3.1 请求处理总流程
1. 客户端请求进入网关(默认 `8080`)。
2. 按路径前缀匹配已配置的服务(如 `/js/a/**` → `zsjz-ai`)。
3. 根据登录用户名或 `x-token` 解析出目标节点。
4. 校验节点启用状态和健康状态。
5. 把请求流式转发到目标节点,保留原始路径、查询参数、请求头、请求体。
6. 响应流式返回客户端,并附加 `X-Gateway-Node` 便于排查。
---
## 4. 路由与绑定算法
### 4.1 登录请求
登录请求没有 token,只能靠请求体里的 `username` 定位用户。
1. `LoginRequestFilter` 只对配置的登录路径(`/js/a/auth/login`)生效:
- 缓存 ≤64KB 请求体;
- 解析 JSON 中的 `username`;
- 把 `Accept-Encoding` 改为 `identity`,避免后端压缩导致无法解析响应;
- 原样转发请求体,不改变业务内容。
2. `StickyRouteFilter` 决定目标节点:
- 有 `username → node` 映射:走该节点;节点 DOWN 直接 503。
- 无映射:查 `sys_user` 得到 `userId`,再查 `userId → node`;有则使用并回填 username 缓存。
- 仍无映射:在所有健康节点中轮询选一个“候选节点”,**此时不写绑定**。
3. `LoginResponseFilter` 缓存 ≤256KB 登录响应,解析:
```json
{
"code": 200,
"message": "",
"data": {
"token": "...",
"userId": 1,
"username": "admin",
"displayName": "系统管理员",
"isAdmin": 1
}
}
```
- `code == 200` 且 `userId` 非空时,调用 `bindIfAbsent(userId, username, 候选节点)`。
- 并发首次登录由数据库唯一索引裁决:先插入者生效,后到者读取赢家节点;不会来回漂移。
- 缓存 `gateway:token:{serviceId}:{token} → userId`,TTL 24h。
- 无论绑定成功与否,响应原样写回。
4. 登录失败(密码错等)不产生绑定,避免无效映射。
### 4.2 普通请求
1. 从 `x-token` 读 token;先查 `gateway:token:*` 得到 userId。
2. 缓存未命中时用 sa-token `StpUtil.getLoginIdByToken`(共享 Redis)解析,并回填 token 缓存;兼容网关上线前已签发的 token。
3. 查 `userId → node`(Redis 缓存,未命中查 `gateway_user_route` 并回填)。
4. 没有该用户的映射时:
- 服务配置了 `default-node-id`:绑定到该节点(用于存量用户迁移);
- 否则返回 503「用户未绑定节点,请重新登录或联系管理员」。
5. 绑定节点被禁用或健康检查 DOWN:返回 503,不切换。
6. 节点健康时把 `GATEWAY_REQUEST_URL_ATTR` 重写为 `节点 origin + 原始 rawPath + rawQuery`,由 Netty 流式转发;响应头加 `X-Gateway-Node` 便于排查。
### 4.3 无 token 与 MCP
- 登录以外的无 token 请求(`/sys/health`、`/sys/map/**` 等)在健康节点间轮询。
- MCP 路径(`/mcpsse`、`/mcpstreamable`、`/mcp/message`)无 token 且会话有状态,固定转发到服务配置的 `mcp-node-id`;未配置时走首个健康节点。本期不做 MCP 会话级粘性。
- 其他无 token 请求如果后端需要鉴权,由后端返回现有的 `code=401`,网关不重复鉴权。
### 4.4 绑定写入与并发
`bindIfAbsent` 的语义:
1. 先按 `(serviceId, userId)` 和 `(serviceId, lower(username))` 查已有路由;有则直接返回已有节点,不覆盖。
2. 没有则插入一行,同时写 `user_id`、`username`、`node_id`。
3. 使用 `ON CONFLICT DO NOTHING`,再按 userId、username 重新查询,读取并发下的赢家。
4. 写入成功后更新 Redis 的 `user`、`name` 两个缓存键。
数据库唯一索引是最终裁决,保证同一用户/用户名只存在一条路由。
### 4.5 用户路由的 Redis 键
| 键 | 值 | TTL | 用途 |
|---|---|---|---|
| `gateway:token:{serviceId}:{token}` | userId | 24h | 避免每个请求都调 sa-token |
| `gateway:route:user:{serviceId}:{userId}` | nodeId | 无 | 普通请求热路径 |
| `gateway:route:name:{serviceId}:{lower(username)}` | nodeId | 无 | 登录请求热路径 |
- PostgreSQL 是事实来源,Redis 只是缓存。
- Redis 清空后按需求回源数据库,不影响正确性。
- 管理员重绑/解绑时同时更新数据库和 Redis。
### 4.6 健康检查与故障处理
- 每 10 秒对每个节点 `GET {base-url}{health-path}`,2 秒超时。
- 连续 3 次失败标记 DOWN;1 次成功恢复 UP。
- 新用户分配只选健康且启用的节点。
- 已绑定用户的节点 DOWN 时直接 503,不切换。
- 背景节点恢复后自动恢复服务,用户映射不变。
- `/sys/health` 目前只证明进程存活,不检查 PG/Redis/ES;节点级探活够用,深度健康可作为后续增强。
---
## 5. 配置模型
`ai-gateway/src/main/resources/application.yaml`:
```yaml
server:
port: 8080
spring:
application:
name: ai-gateway
datasource:
url: jdbc:postgresql://192.168.0.106:5432/zsjz-ai
username: postgres
password: postgres
data:
redis:
host: 192.168.0.106
port: 6379
sql:
init:
mode: always
schema-locations: classpath:db/gateway.sql
sa-token:
token-name: x-token
is-read-header: true
is-read-cookie: false
is-read-body: false
timeout: 2592000
is-concurrent: true
is-share: false
token-style: uuid
gateway:
admin:
enabled: true
ip-whitelist: [] # 支持单 IP / CIDR;空表示不限制
health-check:
interval: 10s
timeout: 2s
failure-threshold: 3
cors:
allowed-origin-patterns: ["*"]
services:
- id: zsjz-ai
name: 智能分析后端
path-prefix: /js/a
login-path: /auth/login
health-path: /js/a/sys/health
default-node-id: node-1
mcp-node-id: node-1
mcp-paths: ["/mcpsse", "/mcpstreamable", "/mcp/message"]
nodes:
- id: node-1
name: 节点1
base-url: http://192.168.0.101:8980
- id: node-2
name: 节点2
base-url: http://192.168.0.102:8980
```
### 5.1 配置优先级
- **数据库为准**:首次启动若 `gateway_service` 为空,用 YAML 播种;之后 YAML 不再覆盖数据库。
- 节点、服务变更通过管理接口完成。
- 支持多个服务,每个服务一个路径前缀、一组节点;前缀冲突在保存时拒绝。
- 网关的 Redis/sa-token 配置必须与后端一致(同一 Redis、同一 `token-name`、同一 DB index),否则 token 无法解析。
### 5.2 生产配置建议
- 数据库密码、Redis 密码用环境变量注入,不写进仓库。
- `gateway.admin.ip-whitelist` 配置为运维网段。
- 多个网关实例可同时运行,共享 PG/Redis,粘性结果一致。
- 网关本身无本地状态,可放在 VIP/Nginx 后面。
---
## 6. 数据库模型
新增 `sql/gateway.sql`(`CREATE TABLE IF NOT EXISTS`,可重复执行),Maven 把它复制到 classpath 供 `spring.sql.init` 自动建表。
### 6.1 `gateway_service`
| 字段 | 类型 | 说明 |
|---|---|---|
| `id` | varchar(64) PK | 服务标识,如 `zsjz-ai` |
| `name` | varchar(128) | 服务名称 |
| `path_prefix` | varchar(128) UNIQUE | 对外路径前缀,如 `/js/a` |
| `login_path` | varchar(128) | 相对登录路径,如 `/auth/login`,可空 |
| `health_path` | varchar(255) | 完整健康检查路径,如 `/js/a/sys/health` |
| `default_node_id` | varchar(64) | 存量用户兜底节点,可空 |
| `mcp_node_id` | varchar(64) | MCP 固定节点,可空 |
| `mcp_paths` | varchar(512) | MCP 路径列表,逗号分隔,可空 |
| `enabled` | smallint | 1 启用 0 停用 |
| `create_time` / `update_time` | timestamp | 审计 |
### 6.2 `gateway_node`
| 字段 | 类型 | 说明 |
|---|---|---|
| `id` | varchar(64) PK | 节点标识,全局唯一,如 `node-1` |
| `service_id` | varchar(64) FK | 所属服务 |
| `name` | varchar(128) | 节点名称 |
| `base_url` | varchar(255) | `http(s)://host:port`,不含路径 |
| `enabled` | smallint | 1 启用 0 停用 |
| `remark` | varchar(512) | 备注 |
| `create_time` / `update_time` | timestamp | 审计 |
`(service_id, base_url)` 唯一。
### 6.3 `gateway_user_route`
| 字段 | 类型 | 说明 |
|---|---|---|
| `id` | bigserial PK | 主键 |
| `service_id` | varchar(64) FK | 服务 |
| `user_id` | bigint | `sys_user.id`,可空 |
| `username` | varchar(64) | 登录名,可空 |
| `node_id` | varchar(64) FK | 目标节点 |
| `create_time` / `update_time` | timestamp | 审计 |
约束:
- `(service_id, user_id)` 唯一(user_id 非空时);
- `(service_id, lower(username))` 唯一(username 非空时);
- `user_id`、`username` 至少一个非空;
- 所有外键 `ON DELETE RESTRICT`;
- 删除有绑定用户的节点直接拒绝,避免产生无主用户。
### 6.4 与后端表的关系
- 网关只读 `sys_user` 的 `id/username/is_admin/status`,不修改后端表。
- 用户路由放独立表,不侵入 `sys_user`,支持同一用户在不同服务绑定不同节点。
---
## 7. 核心实现设计
### 7.1 模块与依赖
- 根 `pom.xml` 增加 `ai-gateway`。
- `ai-gateway/pom.xml`:
- 父 POM `com.zsjz:zsjz-ai:1.0`,JDK 25;
- 导入 Spring Cloud 2025.0.x BOM;
- 依赖:
- `spring-cloud-starter-gateway-server-webflux`
- `spring-boot-starter-webflux`
- `spring-boot-starter-jdbc`
- PostgreSQL 驱动
- `spring-boot-starter-data-redis-reactive`
- `sa-token-reactor-spring-boot3-starter:1.46.0`
- `sa-token-redis-jackson:1.46.0`
- `spring-boot-starter-validation`
- 测试依赖:Reactor Test、WireMock、Testcontainers(PostgreSQL + Redis 容器)。
- Maven resources 把 `../sql/gateway.sql` 打进 `classpath:db/gateway.sql`,避免 DDL 两份维护。
### 7.2 动态路由
- `GatewayRouteDefinitionRepository` 实现 `RouteDefinitionRepository`:
- 每个服务生成一条路由;
- `Path=/js/a/**`;
- URI 用占位符 `http://gateway.invalid`;
- metadata 携带 `serviceId`;
- 按路径前缀长度降序设置 route order,保证更长前缀优先。
- `GatewayRegistry` 从数据库加载服务/节点快照。
- 配置变化后发布 `RefreshRoutesEvent`,清理路由缓存。
- `StickyRouteFilter`(order 10001,排在 `RouteToRequestUrlFilter` 之后)负责把占位 URI 改写成实际节点地址。
### 7.3 过滤器与核心类
| 组件 | 职责 |
|---|---|
| `LoginRequestFilter`(order 9999) | 登录路径请求体缓存、username 解析、`Accept-Encoding: identity` |
| `LoginResponseFilter`(order 10002) | 登录响应缓存解析、首次成功登录绑定、token 缓存 |
| `StickyRouteFilter`(order 10001) | 粘性节点选择、节点健康校验、URL 重写、`X-Gateway-Node` 响应头、503 错误输出 |
| `TokenResolver` | Redis token 缓存 → sa-token Redis 兜底,阻塞调用放 `boundedElastic` |
| `UserRouteService` / `UserRouteRepository` | username/userId 路由查询、`bindIfAbsent`、管理端重绑/解绑、存量用户导入 |
| `NodeSelector` | 轮询选择健康节点,跳过 disabled/DOWN |
| `HealthChecker` + `NodeHealthRegistry` | 定时探测、失败阈值、状态变更日志 |
| `AdminAuthWebFilter` | `x-token` → userId → `sys_user.is_admin=1 && status=1`,叠加 IP 白名单;管理接口关闭时返回 404 |
| `GatewayErrorHandler` | 连接失败/超时统一返回 502,其他异常 500,响应体沿用 `{code,message,data}` |
| `CorsConfig` | `allowedOriginPatterns=*`、暴露 `X-Gateway-Node`;`x-token` 不走 Cookie,允许无凭证跨域 |
| `RequestIdFilter` | 透传/生成 `X-Request-Id`,日志按请求串联 |
### 7.4 流式与请求体
- 除登录外不缓存请求/响应,上传、下载、SSE 全部走 Netty 流式转发。
- `spring.cloud.gateway.httpclient.connect-timeout=3s`,`response-timeout=0s`(SSE 不设总超时),关闭客户端压缩。
- 保留 `Range`、`Content-Type`、`x-token`、Cookie 等端到端头;SCG 自动剔除 hop-by-hop 头。
- 登录体 ≤64KB、登录响应 ≤256KB;超出返回 413/502,避免大响应被缓存。
- 后端返回的 4xx/5xx 状态码、响应头、响应体原样透传。
### 7.5 错误响应
- 用户绑定节点不可用:HTTP 503 + `{code:503,message:"用户绑定的后端节点不可用:node-2,请稍后重试或联系管理员"}`。
- 无健康节点:HTTP 503 + 明确提示。
- 上游连接失败/超时:HTTP 502 + 明确提示。
- 管理接口未登录:HTTP 401;非管理员:HTTP 403。
- 不在错误信息里暴露后端完整地址,只暴露节点 ID。
### 7.6 配置热更新
- 管理接口写库后立即刷新本实例路由。
- 其他网关实例每 10 秒比对 `max(update_time) + count`,有变化则重载服务/节点并刷新路由。
- 用户路由变更直接更新 PostgreSQL 和 Redis,所有网关实例立即生效。
- 健康状态是每个网关实例自己的内存状态,不跨实例同步。
---
## 8. 管理 API(`/gateway/admin/**`)
所有接口要求管理员登录态(`x-token`),可选 IP 白名单。
```text
GET /gateway/admin/status 服务、节点、健康状态、绑定用户数
GET /gateway/admin/services
POST /gateway/admin/services
PUT /gateway/admin/services/{serviceId}
DELETE /gateway/admin/services/{serviceId} (有节点/路由时拒绝)
POST /gateway/admin/services/{serviceId}/nodes
PUT /gateway/admin/nodes/{nodeId} 修改地址/启停
DELETE /gateway/admin/nodes/{nodeId} 有绑定用户时拒绝
POST /gateway/admin/nodes/{nodeId}/check 手动探活
GET /gateway/admin/routes?serviceId=&keyword=&page=&size=
POST /gateway/admin/routes/bind {serviceId,username|userId,nodeId} 预绑定/重绑
DELETE /gateway/admin/routes/{id} 解绑并清 Redis 缓存
POST /gateway/admin/routes/import-existing {serviceId,nodeId} 把 sys_user 存量用户批量绑到该节点
POST /gateway/admin/reload 强制刷新配置
```
### 8.1 校验规则
- 服务 id:`^[a-z][a-z0-9-]{1,63}$`。
- `path-prefix` 必须以 `/` 开头、不能以 `/` 结尾、不能是 `/gateway`,且全局唯一。
- `base-url` 必须是 `http(s)://host[:port]`,不含 path/query/fragment。
- 节点 id 全局唯一。
- 绑定时节点必须属于对应服务且启用。
- 删除服务/节点前检查关联数据,返回 409。
### 8.2 存量用户导入
`POST /gateway/admin/routes/import-existing` 的核心 SQL:
```sql
INSERT INTO gateway_user_route (service_id, user_id, username, node_id)
SELECT :serviceId, u.id, u.username, :nodeId
FROM sys_user u
WHERE NOT EXISTS (
SELECT 1 FROM gateway_user_route r
WHERE r.service_id = :serviceId
AND (r.user_id = u.id OR lower(r.username) = lower(u.username))
)
ON CONFLICT DO NOTHING;
```
用于网关首次上线时把现有用户全部归到当前唯一后端,避免存量用户被分配错机器。
---
## 9. 文件清单
```text
pom.xml + ai-gateway 模块
sql/gateway.sql 三张表 DDL
ai-gateway/pom.xml
ai-gateway/src/main/resources/application.yaml
ai-gateway/src/main/resources/application-dev.yaml
ai-gateway/src/main/java/com/zsjz/gateway/
GatewayApplication.java
config/GatewayProperties.java
config/CorsConfig.java
config/WebClientConfig.java
registry/GatewayRegistry.java
registry/GatewayConfigRepository.java
registry/HealthChecker.java
registry/NodeHealthRegistry.java
route/GatewayRouteDefinitionRepository.java
route/LoginRequestFilter.java
route/LoginResponseFilter.java
route/StickyRouteFilter.java
route/TokenResolver.java
route/UserRouteService.java
route/UserRouteRepository.java
route/NodeSelector.java
route/GatewayAttributes.java
admin/AdminController.java
admin/AdminService.java
admin/AdminAuthWebFilter.java
support/ApiResult.java
support/GatewayErrorHandler.java
support/RequestIdFilter.java
support/IpWhitelist.java
ai-gateway/src/test/java/com/zsjz/gateway/... 单元测试 + 集成测试
ai-gateway/README.md 架构、配置、接口、部署、排障
AI_AGENT.md 仓库结构补充 ai-gateway
```
---
## 10. 部署与切换步骤
1. 在现有唯一的 ai-server 上确认工作目录、授权和 `QingJian/` 数据目录。
2. 启动网关,配置 `node-1` 指向现有后端,`default-node-id=node-1`。
3. 调用 `POST /gateway/admin/routes/import-existing {serviceId:"zsjz-ai",nodeId:"node-1"}`,把现有 `sys_user` 全部绑定到 node-1;未导入的用户也会走 default-node 兜底。
4. 把前端 `VITE_GLOB_API_URL`(或打包后的 `_app.config.js`)改为 `http://:8080`;开发环境把 `VITE_PROXY` 指向网关。
5. 验证登录、案件打开、附件上传、SSE 聊天都走同一节点。
6. 再部署 node-2,新用户由轮询分配,或管理员预绑定。
7. 防火墙只允许客户端访问网关端口,禁止直接访问 8980;否则用户可以绕过粘性。
8. 每台 ai-server 仍需独立授权和独立数据目录;不要共享 DuckDB 文件。
后端不需要改代码;可选加一行 `server.forward-headers-strategy: framework`,让后端正确识别 `X-Forwarded-*`。
---
## 11. 测试与验收
### 11.1 单元测试
- 登录体解析(正常/空/非法 JSON/超大)。
- 首次登录绑定、并发 `bindIfAbsent` 唯一性、登录失败不绑定。
- token 缓存命中/未命中、sa-token 兜底。
- 节点轮询跳过 DOWN/disabled、绑定节点 DOWN 返回 503。
- 管理接口权限(非管理员 403、停用用户 403、IP 白名单)。
### 11.2 集成测试
使用 Testcontainers PostgreSQL + Redis + WireMock 两个后端:
- 用户 A 首次登录 → node-1;后续带 token 请求始终 node-1;用户 B → node-2。
- node-1 停止探活后,A 的请求返回 503;恢复后继续 node-1,且不切 node-2。
- 管理接口新增/禁用节点后路由即时生效;重绑用户后新请求切到新节点。
- SSE 分块响应不被缓冲;multipart 上传和 Range 下载原样透传。
- 清空 Redis 路由缓存后能从 PostgreSQL 重新加载。
- 存量用户导入后,已有 token 的请求能正确路由。
### 11.3 人工验收
- 两台真实 ai-server(各自独立工作目录和授权)分别登录两个用户。
- 打开案件、上传附件、发起 SSE 研判,确认 `X-Gateway-Node` 始终一致。
- 停掉一台后端,确认 503 提示可读且没有跨节点写入。
- 直接访问后端 8980 被防火墙拒绝,只能经过网关。
### 11.4 验收标准
1. 配置两个后端节点后,`/js/a/**` 的所有请求自动转发,无需逐接口配置。
2. 同一用户首次登录后,后续所有请求(含 SSE、上传、下载)固定到同一节点。
3. 不同用户可分配到不同节点。
4. 绑定节点故障返回明确 503,不自动切换。
5. 管理接口可在不重启网关的情况下增删/启停节点、查看和重绑用户。
6. 现有用户可通过导入接口一次性绑定到当前节点,旧 token 继续可用。
7. 单元测试和集成测试通过。
---
## 12. 不在本期范围
- 用户数据在两台机器之间的自动迁移。
- 节点故障自动切换/共享存储。
- MCP 会话级粘性(本期固定节点)。
- 管理 UI(本期只提供 REST 接口)。
- 限流、TLS 终止、深度健康检查。
- 自助注册页面(当前仓库没有;如有需要,未来在注册成功后调用绑定服务)。
- 按案件粘性(本期按用户;当前案件仅创建者可见,用户级粘性已覆盖)。
---
## 13. 风险与注意事项
| 风险 | 说明 | 应对 |
|---|---|---|
| 网关只读耦合 `sys_user` | 绑定用户和管理员校验需要读 `sys_user.id/username/is_admin/status` | 字段变更时同步网关;只读不写 |
| 健康检查较浅 | `/sys/health` 只证明进程存活,不检查 PG/Redis/ES | 节点级探活够用;后续可加深度健康接口 |
| 登录响应结构变化 | 首次绑定依赖 `Result + LoginVO` 的 `code/data.userId/data.username` | 结构变化时调整解析,或改用管理端预绑定 |
| 多服务鉴权差异 | 网关共用一套 sa-token Redis/token-name | 本期所有服务复用同一套鉴权;未来扩展为按服务配置 |
| 绕过网关 | 用户直连 8980 会落到非绑定节点 | 防火墙限制后端端口只对网关开放 |
| 节点 DOWN 即不可用 | 按设计不自动切换,用户会看到 503 | 运维尽快恢复节点;提供管理端重绑(需人工确认数据位置) |
| MCP 无鉴权 | 现有 `/mcpsse` 等端点本身无 token | 网关固定节点 + 防火墙限制来源 |
| 每机授权 | 多台 ai-server 需要各自机器码授权 | 部署前逐台申请/导入授权 |
| Redis 清空 | 路由缓存和 sa-token 都会丢 | 用户重新登录;路由从 PostgreSQL 恢复 |
| 并发首次登录 | 两个网关同时为同一用户选不同节点 | 数据库唯一索引裁决,后到者读取赢家 |
---
## 14. 一句话总结
新增 `ai-gateway`(Spring Cloud Gateway WebFlux),用“首次登录成功绑定 + `x-token`→userId→node 的 Redis/PG 两级路由”把每个用户固定到一台 ai-server;配置由 YAML 播种、PostgreSQL 持久化、管理接口热更新;节点故障明确返回 503,不做破坏本地数据一致性的自动切换。