做B2B SaaS，租户架构这个问题迟早会找上门，通常就是某个大客户问“我们的数据能不能和别人分开放”的那一天。这种讨论我经历过不止一次。答案基本就两个：给每个客户独立的实例（单租户，多实例），或者让所有人共享一个实例（多租户，单实例）。没有哪个是“正确答案”，只是坏起来的方式不一样。
基础设施设计#
单租户，多实例#
这条路的吸引力就在“隔离”二字，几乎所有好处都由此而来。每个客户的数据都在自己独立的环境里，安全审查和合规谈判会轻松很多。一次糟糕的部署或一个吃资源的任务，只会影响一个客户，而不是全部。每个实例可以独立扩容、调优、定制；资源专用，性能不会因为隔壁租户在跑什么而波动。维护也能按客户逐个安排，停机影响小而可控。定价合理的话，还能让基础设施成本对上每个租户的实际用量。
代价是：所有东西你都要运维N份。资源开销不断累积，实例之间的配置慢慢漂移，让整个集群的版本和数据保持一致本身就成了一个项目。扩容、隔离、成本管理的问题不会消失，只会成倍增加。
多租户，单实例#
它是默认选项不是没有原因的：一套部署、一个要备份的数据库、生产环境只有一个版本。资源利用率高，运维简单，所有客户同时拿到更新和安全补丁。
难点是共享的另一面。一个租户用得猛，所有人的性能都会被拖累；按客户定制的空间有限；数据隔离不再靠基础设施，而是落在你的应用代码里，一个bug就可能变成跨租户的数据泄露。扩容瓶颈一来就是所有客户一起受影响，维护也要更小心，因为再也没有“只影响这一个客户”的爆炸半径了。
单租户从哪里开始？#
真要走单租户，工具决定它是“可以管”还是一场慢动作灾难。三十套环境，靠手是管不过来的。
核心是容器加基础设施即代码。Docker把应用打包成对每个租户都完全一致的形态，Kubernetes负责这一堆实例的部署和扩缩容；用Terraform、Pulumi或AWS CloudFormation把一个租户的完整技术栈定义成代码，第31个客户的开通就是一个PR，而不是一个报废的周末。如果你更贴近虚拟机的世界，Ansible、Chef、Puppet这类配置管理工具可以承担同样的角色。CI/CD流水线（Jenkins、GitLab CI/CD）在这里比平时更重要，因为每次发布都要在所有实例上滚动完成，不能靠人盯。
再往后就看产品形态了。有些工作负载可以直接用无服务器（AWS Lambda、Azure Functions）把服务器这一层整个抹掉。Amazon RDS、Azure SQL Database这类托管数据库，能把你从“每个租户手动维护一个库”的苦役里救出来。有了一个集群之后，监控（Prometheus、Grafana、New Relic）就不再是可选项：哪个实例不舒服，你得赶在客户开口之前知道。身份这块交给Auth0或Okta这样的IAM服务，就不用每个租户重造一遍认证。不管你用什么语言，多半都有面向SaaS的框架或库能帮你省掉一部分管道工程；托管方面，AWS、Azure、Google Cloud Platform这些大厂云都能轻松接住。
别想着第一天就把清单买齐。先上容器和IaC，租户多起来再加监控和IAM，剩下的，让真实的痛点来决定。