多租户与信创适配
多品牌 / 多租户的数据隔离方案对比（独立库 / 独立 schema / 行级隔离），国产化适配清单（数据库 / 中间件 / 操作系统 / CPU / 密码算法），以及等保要求与租户隔离的对应关系。
当前租户数
1个
女装（预留多品牌扩展）
推荐隔离方案
独立库
品牌方主数据与决策库
信创适配项
12项
已完成 5 / 进行中 5 / 未开始 2
整体适配完成度
58%
按项数与工作量加权
性能损失（预估）
6–11%
x86 → 鲲鹏 / 飞腾 ARM64
信创改造预算
¥860,000
含国密改造与多架构镜像
i本页口径：多租户隔离方案与信创适配是两件不同的事，但都会被等保测评追问。隔离方案决定"数据能不能被别的品牌看见"，信创适配决定"这套系统能不能建在国产底座上"。两者都不能事后补 —— 隔离方案改造成本随数据量线性上升，信创适配越晚做越贵。
多租户隔离方案对比（三选一）
推荐组合：品牌方独立库 + 分析型租户独立 schema + 试用租户行级隔离| 对比维度 | 独立数据库 Database per Tenant | 独立 Schema Schema per Tenant | 行级隔离 Shared Table + tenant_id |
|---|---|---|---|
| 数据落地 | 每租户独立数据库实例与连接串 | 同一实例内每租户独立 schema | 所有租户共享表，靠 tenant_id 列区分 |
| 隔离强度 | 强（实例级隔离，无共享对象） | 中（表空间共享，schema 隔离） | 弱（依赖应用层与数据库策略） |
| 横向越权风险 | 极低（连接串层面即隔离） | 低（需保证 schema 路由无 bug） | 中（任一 SQL 漏写 tenant_id 即泄露） |
| 单租户成本 | 高（约 1.0× 基准，资源无法复用） | 中（约 0.55× 基准） | 低（约 0.25× 基准） |
| 扩容方式 | 按租户加实例，粒度粗 | 按实例扩，可多租户共享 | 水平扩表，粒度最细 |
| 跨租户分析 | 需 ETL 汇聚到分析库，链路长 | 同实例可跨 schema 查询 | 天然同表，聚合最简单 |
| 大租户性能影响 | 无（互不影响） | 中（共享实例资源） | 高（大租户可拖垮全表） |
| 运维复杂度 | 高（N 套备份 / 升级 / 监控） | 中（实例少，schema 多） | 低（一套实例一个库） |
| 等保测评配合度 | 最易说明（物理隔离直观） | 较易说明（需出示 schema 路由审计） | 较难说明（需出示全量 SQL 的 tenant_id 校验证据） |
| 适用租户 | 品牌方总部、强合规大客户 | 中型品牌、区域代理 | 小微租户、试用租户 |
| 本项目建议 | 推荐 · 品牌方主数据与决策库 | 备选 · 分析型租户 | 不推荐用于生产决策数据 |
推荐架构：混合隔离
一个方案打天下是错的STEP 1
品牌方租户
独立数据库 + 独立实例
STEP 2
区域 / 代理租户
独立 Schema
STEP 3
试用 / 演示租户
共享表 + tenant_id
STEP 4
平台侧分析
匿名化后汇聚到分析库
- 租户识别
- 登录态携带 tenant_id，网关强制注入请求头
- 强制校验
- 数据访问层统一拦截器校验 tenant_id，不依赖业务代码自觉
- 越权拦截
- 跨租户访问返回 404 而非 403（不泄露资源存在性）
- 租户级限流
- 按 tenant_id 独立限流，防大租户拖垮平台
- 备份恢复
- 按租户独立备份，支持单租户时间点恢复
- 退租清除
- 7 步流程：冻结 → 导出 → 校验 → 清除 → 复核 → 出证 → 归档记录
隔离方案的选择依据
- 租户数据敏感度
- 含成本与毛利 → 独立库
- 租户规模（数据量）
- > 5,000 万行 → 独立库
- 合规要求
- 要求独立审计 → 独立库
- 租户数量
- < 20 个 → 独立库可行
- 成本约束
- 预算优先 → 独立 schema
- 跨租户分析需求
- 强 → 行级隔离更省事
判断口诀
当租户数量少、单租户数据敏感度高、合规要求强时选独立库；当租户数量多、单租户数据量小、成本敏感时选行级隔离。本项目当前只有 1 个品牌方租户、且含成本毛利数据，独立库是唯一稳妥选择。
国产化适配清单（信创）
按"类别 → 当前 → 替代 → 要点 → 实测 → 计划"逐项评估| 类别 | 当前技术栈 | 国产化替代方案 | 适配要点 | 实测结论 / 风险 | 计划 |
|---|---|---|---|---|---|
| 数据库 | PostgreSQL 15 | OceanBase 4.x / GaussDB 200 / TiDB 7.x | SQL 兼容层 + 存储过程改写 | 已完成 92% 语法适配，剩余 8% 为窗口函数与自定义聚合 | 2026 Q1 |
| 数据库 | Redis 7（会话 / 缓存） | TongRDS / OceanBase KV / 腾讯云 TDSQL-C | 客户端协议兼容 | TongRDS 协议兼容良好，压测 QPS 达基准 96% | 2026 Q1 |
| 中间件 | Kafka 3.x | Apache RocketMQ 5 / 华为云 DMS Kafka | 消费组与幂等键约定不变 | RocketMQ 事务消息更契合补调单据的幂等要求 | 2026 Q1 |
| 中间件 | RabbitMQ 3.x | TongLINK/Q 9.x | AMQP 协议适配 | TongLINK/Q 需自研适配层，工作量约 15 人日 | 2026 Q2 |
| 中间件 | Nginx 1.24 | Tengine / 东方通负载均衡 | 配置语法基本一致 | 无阻塞，配置文件可平移 | 2026 Q1 |
| 中间件 | Elasticsearch 8 | OpenSearch / 华为 CSS | 索引映射与查询 DSL 兼容 | 审计日志检索场景可直接迁移 | 2026 Q2 |
| 操作系统 | CentOS 7 / Ubuntu 22.04 | 麒麟 V10 SP3 / 统信 UOS 服务器版 | 系统调用与包管理差异 | 已完成容器化，OS 依赖下沉到基础镜像，迁移成本低 | 2026 Q1 |
| 操作系统 | Windows Server（门店端打印） | 麒麟 V10 桌面版 + 国产打印驱动 | 打印驱动适配 | 门店标签打印需逐型号验证（已测 3 款，通过 2 款） | 2026 Q2 |
| CPU / 芯片 | Intel Xeon / AMD EPYC (x86_64) | 鲲鹏 920 / 飞腾 S2500 / 海光 3 号 (ARM64 / x86) | ARM64 指令集与依赖包编译 | Docker 镜像需重建多架构版本，性能损失实测 6–11% | 2026 Q1 |
| CPU / 芯片 | NVIDIA T4（模型推理） | 昇腾 910B / 寒武纪 MLU370 | 推理框架与算子适配 | 补调模型为树模型 + 统计方法，算力需求低，适配风险小 | 2026 Q2 |
| 终端 / 浏览器 | Chrome / Edge | 奇安信可信浏览器 / 红莲花 | 内核版本 90+ 兼容 | 前端未使用新特性，实测兼容 | 2026 Q1 |
| 密码算法 | AES-256 / RSA-2048 / SHA-256 | SM4 / SM2 / SM3（国密） | 国密 SSL 改造 + 签名算法切换 | 需申请国密证书并改造网关，影响所有外部接口 | 2026 Q2 |
共 12 项 · 已完成 5 项（Nginx / ES / OS 容器化 / 浏览器 / 部分驱动）· 2026 Q1 完成主体，Q2 收尾国密改造每页
适配进度与风险分布
按项数与工作量加权最大风险项
国密改造（20%）是唯一的高风险项：它影响所有外部接口与已发证书，且需要与 ERP / WMS 双方同步改造。建议单独立项，不作为本系统信创改造的子项。
ARM64 适配的性能实测
实测环境：同等核数、同等内存| 场景 | x86_64 基准 | 鲲鹏 920 | 差异 |
|---|---|---|---|
| 决策批次（14,968 行候选） | 4 分 12 秒 | 4 分 39 秒 | +10.7% |
| 库存口径四表联动查询 | 820 ms | 871 ms | +6.2% |
| 单 SKC 预测（加权移动平均） | 36 ms | 38 ms | +5.6% |
| Excel 导出（330 行 168 列） | 2.1 s | 2.3 s | +9.5% |
| 并发 200 用户页面响应 | 410 ms | 462 ms | +12.7% |
i性能损失 5.6%–12.7%，全部落在 S6 非功能要求的允许区间内（决策批次时限 ≤ 15 分钟、页面响应 ≤ 800ms）。无需为信创替换专门扩容。
等保要求 ↔ 租户隔离的对应关系（S6 · X16）
等保测评会追问"多租户下如何证明隔离有效"| 等保控制点 | 在租户隔离场景下的落地要求 | 依赖的隔离能力 | 状态 | 说明 |
|---|---|---|---|---|
| 身份鉴别 | 各租户独立账号体系，租户内账号唯一 | 隔离方案 A（独立库） | 符合 | A 方案天然满足，无需额外行级校验 |
| 访问控制 | 数据范围按品牌 / 区域 / 门店三层收敛，租户间不可见 | 隔离方案 A + 应用层租户上下文 | 符合 | 每个 API 强制注入 tenant_id 并校验归属 |
| 安全审计 | 审计日志按租户分库存储，租户管理员仅见本租户日志 | 隔离方案 A | 符合 | 跨租户日志仅平台审计管理员可见 |
| 剩余信息保护 | 租户退租时执行 7 步清除并出具销毁证明 | 隔离方案 A + 存储层擦除 | 基本符合 | 备份介质中的残留数据依赖归档介质销毁周期（≤ 1 年） |
| 数据备份恢复 | 按租户独立备份与恢复，支持单租户时间点恢复 | 隔离方案 A + 逻辑备份 | 符合 | 单租户恢复不影响其他租户，RTO ≤ 30 分钟 |
| 个人信息保护 | 租户内个人信息不跨租户汇聚，平台侧匿名化统计 | 隔离方案 A + 平台侧脱敏 | 符合 | 平台运维看板只展示聚合值 |
共 6 项控制点与租户隔离直接相关 · 其中 5 项符合、1 项基本符合每页
退租数据清除流程
STEP 1
① 冻结
停写保留读
STEP 2
② 导出
交付客户
STEP 3
③ 校验
导出完整性
STEP 4
④ 清除
库 + 备份 + 缓存
STEP 5
⑤ 复核
自动化扫描
STEP 6
⑥ 出证
销毁证明
STEP 7
⑦ 归档
记录留痕
!清理范围必须覆盖：主库、只读副本、缓存、对象存储、搜索索引、备份介质。最容易漏的是备份介质，它依赖归档介质的自然销毁周期（≤ 1 年）。
多品牌主数据的隔离边界
- 品牌间完全隔离
- 商品、门店、库存、决策、单据、报表
- 平台级共享
- 节假日日历、行业基准、算法版本、字典
- 平台侧可见
- 仅匿名化聚合指标（不含成本与毛利）
- 跨品牌调拨
- 禁止（不同品牌货权完全独立）
- 品牌新增
- 复制平台级配置 + 空业务库，1 小时内完成
- 品牌退租
- 执行 7 步清除并对账复核
信创与等保的交叉影响
信创改造会重新打开部分等保控制点| 项 | 影响 |
|---|---|
| 国密改造 → 通信传输控制点 | 联动 |
| 国产 OS → 剩余信息保护（内存清零实现） | 需复测 |
| 国产数据库 → 审计日志的只追加保证 | 需验证 |
| ARM 平台 → EDR 与堡垒机的兼容性 | 已验证 |
| 国产浏览器 → 前端功能完整性 | 已验证 |
i设计说明：多租户与信创是架构决策，不是页面功能。本页把决策依据、对比表、实测数据与等保对应关系集中呈现，目的是让评审在一个页面上完成"选哪个方案、要花多少钱、能不能过等保"三个判断，而不是分散在架构文档与预算表里。