SaaS产品的架构设计如同盖楼的地基，一旦出错便后患无穷。本文通过真实案例揭示‘伪SaaS’架构的致命陷阱，深入剖析多租户隔离、权限解耦与用户体系三大核心设计原则，带你掌握支撑千万级企业服务规模的产品骨架搭建方法论。

在上一篇文章中，我们探讨了客户分层。在SaaS产品的早期，我们需要识别长尾客户的共性需求与独特诉求，梳理清楚各分层下的用户角色，从而构建起一个初步的需求框架。这为后续产品架构的搭建提供了坚实的底层支撑。

如果把搭建SaaS产品比作盖一栋大楼：

• 文章一（精益产品探索）：如何正确盖，从地基到封顶做事原则与指导思想。
• 文章二（客户分层）：解决的是整栋楼“为谁盖”问题，客户类型有几种，要覆盖哪些户型。
• 本篇文章（主体框架）：则是解决“如何盖”的核心技术与产品结构问题。

一个优秀的产品架构，是产品未来能否稳健运行、是否具备高拓展性的关键。它决定了产品底层的耦合性（是否紧密纠缠）与未来的扩展性。今天，我们将深入阐述SaaS架构搭建的核心思路。

一、避坑：你真的理解SaaS吗？

在行业交流中，笔者曾遇到过一位自称SaaS初创公司的合伙人。当被问及“什么是SaaS”时，对方的回答让笔者有些意外。他认为：“SaaS就是为B端客户提供服务的软件。”

从字面上看，这个说法似乎没错，但却忽略了SaaS最核心的商业模式、交付模式与架构理念。如果连创始人都对SaaS的本质认知模糊，在产品设计时就极易陷入误区，搭建出所谓的“伪SaaS”——看似是云端服务，实则是传统软件的翻版，不仅限制了未来的发展可能性，后期若想重构，无异于拆楼重建，成本极高。

因此，一个懂SaaS产品架构的产品经理，以及具备资深经验的技术团队，对于规避这些风险至关重要。

二、SaaS架构的两大功能基石

1. 核心特征：云服务与租户订阅

SaaS的第一个架构特点是云服务模式。系统统一部署在SaaS厂商的服务器上，所有客户（租户）共用一套标准化代码基底。客户无需购买本地服务器，只需开通账号即可通过网络使用。

其商业模式通常为按年订阅，这要求产品必须具备标准化、可复用性的特质。

当然，针对有特殊定制需求的头部客户，SaaS也支持独立部署模式，即将系统部署在客户私有服务器上进行定制开发，以确保不影响主SaaS系统的迭代节奏。

2. 生命线：数据隔离原则

多租户（Multi-tenancy）是SaaS的灵魂，但随之而来的核心挑战是数据隔离。如何确保A客户的数据绝对不会与B客户混淆，是SaaS架构最基本的底线，也是保障客户商业安全的生命线。

三、惨痛教训：从“一套代码”到“系统臃肿”的危局

笔者曾深度参与过一个供应链SaaS系统的重构项目，这个案例堪称错误架构的教科书。

该系统的付费客户是各行业经销商。经销商需要利用系统整合上下游资源，实现交易数字化。他们会添加自己的上游供应商、下游门店采购商角色，上下游是免费用系统的，隶属于该经销商。按照传统认知，大家都认为“SaaS就是一套代码、一套权限体系”。

于是，这个系统设计成了全量菜单、角色过滤的模式：

• 代码层面：订单管理、供应商、门店订单等核心模块是一套代码通过角色权限来过滤数据展示。
• 体验层面：所有经销商登录后，看到的是一整套包含所有功能的菜单，只是根据角色不同，看到的数据和可用功能有所限制。

初期，这样做开发效率确实高。但随着业务迭代，系统迅速变得臃肿不堪，积重难返：

• 耦合度极高：每次新增功能，研发都要考虑是给谁开放的？数据如何差异化隔离？牵一发而动全身。
• 维护困难：试图拆解代码时发现根本无法拆分，只能通过“伪角色”切换（如登录后选择供应商/采购商/平台角色来屏蔽功能）。
• 用户体验灾难：客户看到的菜单全是全量功能，包含大量自己用不到的选项，造成操作混乱。

研发负责人的一句“Saas不就是一套代码一套权限吗”，道出了很多从业者的认知误区。这种在不稳定的地基上不断加楼层的做法，最终导致系统岌岌危矣。

四、破局之道：正确的架构应该如何设计？

针对上述痛点，一个科学的SaaS架构应该从权限架构和用户架构两个维度进行彻底重构。

1. 权限架构：解耦与灵活的三层分离

正确的架构不再是“大一统”，而是“分而治之”。 建议将权限体系拆分为三套独立的权限体系，并提供三个独立的登录入口：

• 供应商入口
• 采购商入口
• 平台管理（经销商）入口

在技术开发层面，每个角色体系都可以自由搭建功能模块，相互之间互不影响，极大降低了系统耦合性。

错误做法：订单管理可能是一个接口，通过角色去区分数据显示。

正确做法：可以针对不同角色设计独立的接口。例如，同样是订单管理，供应商看的是供货订单接口，采购商看的是采购订单接口。这样做灵活性高、耦合性低、拓展性极强。

在用户体验层面，每个角色只看到自己专属的功能菜单，干净清爽。同时，支持角色内部的自主权限配置，如供应商作为超级管理员，可以自行创建仓管、财务等子角色并分配权限。

2. 用户架构：支持“一个人玩转多个生意”

在设计用户体系时，必须预判商业经营的复杂性。

客户层面：一个经销商老板可能拥有多个公司、多个档口，每个都是独立的账本和经营主体。因此，系统必须支持创建多个租户（Tenant），即“客户系统”。这就像代理记账软件，一个老板可以管理多个公司的账套。

用户层面：一个用户可以同时存在于多个租户中。例如，一个投资人可能在A公司是合伙人，在B公司也是股东。他通过手机号登录后，可以自由选择进入哪个公司的租户进行管理。

这种设计模式类似腾讯云等成熟SaaS平台的登录逻辑，技术人员微信扫码登录后选择要进入的企业，极大提升了多主体经营用户的体验。

结语

产品架构是SaaS的骨架。正如本文案例所示，错误的架构决策会成为产品发展的沉重枷锁。作为产品经理，我们必须跳出“一套代码通吃”的传统思维，以高内聚、低耦合为原则，从数据隔离、权限解耦和用户多租户等维度，精心设计每一块基石。