大多数SaaS应用起步时都用同一套架构：一个共享后端、一个共享运行时、一个共享进程，租户隔离全靠代码里的tenant_id字段。这套模型简单、便宜、开发快，跟主流Web框架天然契合。

但产品做大了，尤其是开始做白标、扩展功能或客户定制时，这套玩法会变得脆弱。一个租户的bug能波及其他人，一次糟糕的定制能搞垮整个服务，某个插件或自定义应用可能越权访问，共享进程还会放大故障的爆炸半径。

打开网易新闻 查看精彩图片

租户隔离从单纯的应用层问题，变成了运维层问题。纯逻辑多租户不是万能药——应用负责检查当前租户、过滤数据、校验权限，确保A客户碰不到B客户的资源。架构本身没问题，但高度依赖代码的正确性。漏写租户过滤、暴露错误文件路径、状态共享出错、加载了不安全的自定义行为，运行时本身不会提供额外保护。租户逻辑上分离，运维上却挨得很近。

打开网易新闻 查看精彩图片

爆炸半径是基础设施和安全领域的概念，指一次故障或入侵能造成的破坏范围。传统共享运行时SaaS里，这个半径可能很大：一个进程挂了，所有租户都受影响。对小系统、内部工具、定制需求有限的产品来说，共享进程完全够用。但面向白标客户、支持租户专属应用、插件、自定义域名或有更强隔离需求的SaaS平台，这个模型就开始显得冒险。

租户隔离应该只存在于应用代码里吗？我认为不总是这样。

打开网易新闻 查看精彩图片

另一种思路是把部分隔离下沉到运行时层。不是让所有租户挤在同一个进程里，而是给每个租户更强的运行时边界：一个运行时监管器下面，A、B、C各跑自己的进程，各自拥有隔离的应用工作线程。这不意味着取代应用层安全——认证、授权、输入校验、数据库权限、良好的软件设计仍然需要。但运行时能在出错时帮忙兜底，把后果关进更小的笼子里。