SaaS产品的架构设计如同盖楼的地基，一旦出错便后患无穷。本文通过真实案例揭示‘伪SaaS’架构的致命陷阱，深入剖析多租户隔离、权限解耦与用户体系三大核心设计原则，带你掌握支撑千万级企业服务规模的产品骨架搭建方法论。
在上一篇文章中，我们探讨了客户分层。在SaaS产品的早期，我们需要识别长尾客户的共性需求与独特诉求，梳理清楚各分层下的用户角色，从而构建起一个初步的需求框架。这为后续产品架构的搭建提供了坚实的底层支撑。
如果把搭建SaaS产品比作盖一栋大楼：
一个优秀的产品架构，是产品未来能否稳健运行、是否具备高拓展性的关键。它决定了产品底层的耦合性（是否紧密纠缠）与未来的扩展性。今天，我们将深入阐述SaaS架构搭建的核心思路。
在行业交流中，笔者曾遇到过一位自称SaaS初创公司的合伙人。当被问及“什么是SaaS”时，对方的回答让笔者有些意外。他认为：“SaaS就是为B端客户提供服务的软件。”
从字面上看，这个说法似乎没错，但却忽略了SaaS最核心的商业模式、交付模式与架构理念。如果连创始人都对SaaS的本质认知模糊，在产品设计时就极易陷入误区，搭建出所谓的“伪SaaS”——看似是云端服务，实则是传统软件的翻版，不仅限制了未来的发展可能性，后期若想重构，无异于拆楼重建，成本极高。
因此，一个懂SaaS产品架构的产品经理，以及具备资深经验的技术团队，对于规避这些风险至关重要。
SaaS的第一个架构特点是云服务模式。系统统一部署在SaaS厂商的服务器上，所有客户（租户）共用一套标准化代码基底。客户无需购买本地服务器，只需开通账号即可通过网络使用。
其商业模式通常为按年订阅，这要求产品必须具备标准化、可复用性的特质。
当然，针对有特殊定制需求的头部客户，SaaS也支持独立部署模式，即将系统部署在客户私有服务器上进行定制开发，以确保不影响主SaaS系统的迭代节奏。
多租户（Multi-tenancy）是SaaS的灵魂，但随之而来的核心挑战是数据隔离。如何确保A客户的数据绝对不会与B客户混淆，是SaaS架构最基本的底线，也是保障客户商业安全的生命线。
笔者曾深度参与过一个供应链SaaS系统的重构项目，这个案例堪称错误架构的教科书。
该系统的付费客户是各行业经销商。经销商需要利用系统整合上下游资源，实现交易数字化。他们会添加自己的上游供应商、下游门店采购商角色，上下游是免费用系统的，隶属于该经销商。按照传统认知，大家都认为“SaaS就是一套代码、一套权限体系”。
于是，这个系统设计成了全量菜单、角色过滤的模式：
初期，这样做开发效率确实高。但随着业务迭代，系统迅速变得臃肿不堪，积重难返：
研发负责人的一句“Saas不就是一套代码一套权限吗”，道出了很多从业者的认知误区。这种在不稳定的地基上不断加楼层的做法，最终导致系统岌岌危矣。
针对上述痛点，一个科学的SaaS架构应该从权限架构和用户架构两个维度进行彻底重构。
正确的架构不再是“大一统”，而是“分而治之”。 建议将权限体系拆分为三套独立的权限体系，并提供三个独立的登录入口：
在技术开发层面，每个角色体系都可以自由搭建功能模块，相互之间互不影响，极大降低了系统耦合性。
错误做法：订单管理可能是一个接口，通过角色去区分数据显示。
正确做法：可以针对不同角色设计独立的接口。例如，同样是订单管理，供应商看的是供货订单接口，采购商看的是采购订单接口。这样做灵活性高、耦合性低、拓展性极强。
在用户体验层面，每个角色只看到自己专属的功能菜单，干净清爽。同时，支持角色内部的自主权限配置，如供应商作为超级管理员，可以自行创建仓管、财务等子角色并分配权限。
在设计用户体系时，必须预判商业经营的复杂性。
客户层面：一个经销商老板可能拥有多个公司、多个档口，每个都是独立的账本和经营主体。因此，系统必须支持创建多个租户（Tenant），即“客户系统”。这就像代理记账软件，一个老板可以管理多个公司的账套。
用户层面：一个用户可以同时存在于多个租户中。例如，一个投资人可能在A公司是合伙人，在B公司也是股东。他通过手机号登录后，可以自由选择进入哪个公司的租户进行管理。
这种设计模式类似腾讯云等成熟SaaS平台的登录逻辑，技术人员微信扫码登录后选择要进入的企业，极大提升了多主体经营用户的体验。
产品架构是SaaS的骨架。正如本文案例所示，错误的架构决策会成为产品发展的沉重枷锁。作为产品经理，我们必须跳出“一套代码通吃”的传统思维，以高内聚、低耦合为原则，从数据隔离、权限解耦和用户多租户等维度，精心设计每一块基石。
本文由 @Phoenix 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。