SaaS 系统上云

多租户安全与快速迭代

保障多租户数据隔离与安全，用全栈安全产品构建稳固防护，帮助 SaaS 快速实现全球化布局。

方案包含

把功能做出来不难，难的是数据隔离、成本分摊和容量规划这三件事 —— 它们都随着客户数量增长而变复杂，且没有一个「做完了」的时点。

隔离决定了安全的底线，成本分摊决定了哪些客户实际在亏钱，容量规划决定了下一个大客户签约时你能不能按时交付。这三件事在只有几个客户时都可以靠人工应付，客户一多就必须有系统性的做法。

共享库共享表最省资源，靠租户标识做逻辑隔离，但任何一处查询漏加过滤条件就是数据串号，风险全部压在代码规范上。独立库共享实例隔离性更好，单租户的性能问题不易外溢，是多数中大型 SaaS 的平衡点。

独立实例隔离性最强，适合有强合规要求的客户，成本也最高。实际做法通常是混合：默认走共享实例，对合规或性能敏感的客户提供独立部署，并用统一的账号体系打通。

SaaS 的成本优势建立在复用上，但如果不知道每个客户消耗了多少资源，就无从判断定价是否合理。落地手段是给资源打上租户标签，把计算、存储、流量按标签归集，定期看每个客户的毛利。这一步没做，定价就是在猜。

除非一开始就面向有强合规要求的客户，否则建议从共享库共享表起步 —— 资源效率最高，成本最低。关键是在代码层面把租户上下文做成强制的、难以绕过的机制，而不是靠每个查询自觉加上过滤条件。等出现明确需求再迁移到大客户独立库。

两件事：一是给每个租户设资源上限（连接数、请求频率、存储配额），防止单个租户占用过多共享资源；二是把重负载操作（报表导出、批量处理）放到独立队列里异步执行，不让它们和时间敏感的正常请求争抢资源。

静态资源走 CDN 是最基本的一步。动态请求如果要求低延迟，需要在主要客户区域部署应用层，数据层则按合规要求决定能否跟随分布。折中做法是应用多区域部署、数据集中在主区域，通过在边缘缓存读接口来降低跨区访问的频次。

不同业务的架构差异很大，工程师可以帮你评估。