11.3 多租户 SaaS 能力

11.3 多租户 SaaS 能力

本节摘要：QuantDinger 官方支持多租户形态，可以在此基础上自建一个小型策略平台（官方 README 口径）。本节把「自用」到「开放给多个租户」要补的课列成三层：数据隔离（租户间的策略、订单、账户数据互不可见）、权限隔离（谁能看、谁能交易、谁是管理员，与第 10 章作用域 token 的权限模型衔接）、资源隔离（API 配额、任务队列与 worker 资源的租户级限额）。然后是产品化前的检查表——计费与用量、审计、支持流程、合规边界——每一项都是自营阶段不存在、开放后绕不开的新成本。本节的立场与全书一致：多租户是能力，不是目标；先把前三节的观测、备份、升级做到位，再谈开放。

学习目标

• 说明多租户与自营部署的差异清单。
• 设计数据、权限、资源三层隔离的最小方案。
• 用产品化检查表评估是否具备开放条件。
• 划定平台运营者的合规边界与免责体例。

一、从自营到多租户：差异清单

差异清单的每一行都对应下面三层隔离里的一项功课。官方多租户能力提供的是结构（租户实体、归属关系），三层隔离的强度仍由部署者决定。

还要改掉一些自营阶段的习惯：自营时「自己看一眼数据库」是无害动作，多租户时绕过审计直连租户数据就是事故；自营时配额不存在，资源争用只影响自己，多租户时一个租户的失控回测能拖垮所有人的交易——差异清单上的每一行，都在把「个人的随意」兑换成「平台的纪律」之前，先标出价码。

二、三层隔离的最小方案

数据隔离。所有业务表带租户归属，查询路径强制按租户过滤——验收方法很简单：用租户 A 的凭据去拉租户 B 的订单列表，必须返回空。平台运营者自己查看租户数据也要走审计留痕的通道，而不是数据库直连。

权限隔离。复用第 10 章作用域 token 的分级思路并扩展到人：管理员（管租户与配额）、可交易（绑定了交易所账户的租户用户）、只读（看面板看报告）。最小原则：默认只读，交易权限逐人授予；每份 token 记录归属人与作用域，第 10 章的应急开关在平台层要能按租户粒度执行（只停某个租户的开仓，而不是全平台停摆）。

按租户粒度刹车，意味着每个租户还要有自己的生命周期状态，开关才有抓手（状态命名为示意）：

这张表与第 10.3 节四重开关的关系是"平台层的细化"：全平台开关仍由平台方掌握，租户级冻结则是日常运营的常规动作——一个租户的异常不该连累其他租户停摆，这正是多租户与自营在应急处理上最大的分野。注销态的"数据按约定保留期处置"要在注册协议里写明，它同时是第 8.3 节合规自查里数据留存要求在平台形态下的投影。

资源隔离。三个配额维度：API 请求配额（防一个租户的高频轮询拖垮 backend）、回测任务配额（celery 队列按租户分池或限并发，防回测占满 worker）、数据订阅配额（行情连接数按租户上限）。配额超限的行为要可预期：限流返回明确错误码，而不是静默排队。

多租户三层隔离（与既有章节的衔接）

 租户请求 ──▶ 权限层（作用域 token，第 10 章）──▶ 数据层（租户过滤）──▶ 资源层（配额）
                    │                                │                    │
                审计留痕                          验收：跨租户读为空      验收：超限有错误码
​

三层隔离落到配置上长什么样（示意结构，字段以官方文档为准）：

# tenant_quota.yaml —— 租户级配额配置（示意，字段以官方文档为准）
tenant: tenant_demo_a
quota:
  api_requests_per_min: 60       # API 请求配额（示意值）
  backtest_concurrent: 2         # 回测并发上限（示意值）
  feed_symbols: 20               # 行情订阅标的数上限（示意值）
token:
  default_scope: readonly        # 新租户成员默认只读
  trade_grant: manual            # 交易权限逐人显式授予
over_limit: explicit_error       # 超限返回明确错误码，不静默排队
​

两个讲法。其一，三个配额数字全是示意值，正确的取值来自观察：开放后按 11.1 的租户级指标看真实用量分布，再回收紧或放宽——先给紧的，放宽是显式决策，方向与第 10 章 token 升级一致。其二，over_limit: explicit_error 这一行比数字更重要：超限行为可预期，租户侧的智能体与脚本才能正确处理限流，静默排队只会把「被限流」伪装成「系统慢」，最后变成一单谁都说不清的支持工单。

三、产品化前检查表

这张表的使用时机是"开放前"，不是"开放后"：每一项都要在第一位付费租户进来之前有书面答案，因为开放之后这些答案的任何修改都涉及既有租户的知情与同意，成本翻倍。一个务实的做法是把检查表转成注册协议与服务说明的条款清单——每项检查对应协议里的哪一条，答不上来的那一项就是开放前的最后一块缺口。

四、运营者的合规边界

多租户把第 8.3 节的个人合规升级为平台责任，三条底线：其一，平台提供工具不提供意见——策略由租户自建自管，平台不推荐策略、不代客交易，免责声明（全书各章末尾那行）在平台注册协议里要有对应的条款；其二，敏感凭据能不碰就不碰，交易所 key 由租户侧加密托管的设计优于平台集中保管；其三，各地对「提供交易工具/服务」的监管口径不同，开放收费前做一次属地合规自查——这不是法律意见，是提醒这项工作必须在开放前完成。

第一条底线在平台形态下还有个容易漏掉的延伸：租户自己接的智能体。第 10 章的作用域 token 机制同样要开放给租户使用（租户给自己的智能体签发低权限 token），注册协议的责任划分就要覆盖这条链路——租户的智能体在平台上做了什么，责任在租户的凭证管理，而平台的责任是让这条链路的审计记录完整可查。工具给到位、审计不缺位、意见不出口，三条都守住，平台方才算把「自营者的自由」换成了「运营者的清白」。

五、第一个租户的接入走查（示意）

把三层隔离串成一次真实操作。假设第一位租户带着自己的策略与交易所账户入驻：

三个踩坑点。其一，第 3 步只做一次是不够的：隔离断言要进回归测试，任何一次版本升级后重跑——隔离是靠持续验证维持的属性，不是一次性工程。其二，第 5 步的「配额无长期打满」：长期贴着配额上限的租户，要么在酝酿高频循环，要么配额定得太低拖累正常使用，两种都要跟进，而不是简单调大了事。其三，第 6 步的授予记录要能回答「谁在什么时候基于什么材料批准的」——这是平台方在纠纷场景下唯一能自证流程合规的材料，也是与自营阶段最大的区别：自营的授权只对自己负责，平台的授权要对所有相关方负责。

走查整体还有一条隐线值得点破：六个步骤里没有一个需要平台方替租户做判断——建租户、发凭证、验隔离、设配额、做观察、授权限，全部是运营动作。判断（策略怎么写、参数怎么调、单怎么下）始终在租户侧。这条线不是巧合，是第一条合规底线「提供工具不提供意见」在操作层的具体形状：接入流程里每出现一处"平台替租户判断"，就多一处将来无法自证清白的位置。

六、常见问题与排查

第一行是开放后最高频的支持请求，也是 11.1 租户级观测的直接考题：「慢」在下钻之后必然落到三处之一——他的配额（资源层）、他的请求链路（平台正常但他的用法重）、平台共性（真事故）。三处的处置动作完全不同，所以在多租户形态里，「说不清是谁的慢」本身就是可观测层不达标的信号，先修观测再处理工单。

本节要点回顾

• 多租户三层隔离：数据（跨租户读必须为空）、权限（默认只读）、资源（三配额）。
• 产品化检查表六项：计费、审计、租户级观测、支持、升级窗口、合规。
• 平台三底线：提供工具不提供意见、凭据能不碰就不碰、开放前属地合规自查。
• 先有 11.1~11.2 的观测与备份，再谈开放——多租户是能力不是目标。

全书正文到此结束。附录 A/B/C 收拢术语、部署与配置速查和练习题——速查表贴在运维手边，练习题留给下一轮复盘。