SaaS单体架构向模块化架构演进：先重构，仅在测试表明必要时才拆分

本指南面向SaaS创始人、CTO及工程负责人——这些产品因每次变更都牵一发而动全身，导致发布缓慢。本指南假设产品已上线并有付费租户。首个版本的构建参见我们的SaaS MVP架构路线图，整体视图参见SaaS平台工程指南，重建、重构与重平台之间的通用选择参见数字化转型与现代化指南。

本指南目录

• 单体架构真的是问题所在吗？
• 目标：在拆分服务之前先实现模块化单体
• 选择路线
• 找到接缝，再划定边界
• 分步操作：模块化路径
• 迁移过程中的租户、计费与数据
• 现代化改造中的AI
• 已有哪些交付记录，哪些尚无
• 备选方案：由谁主导工作
• 本指南的局限性
• 常见问题
• 下一步

单体架构真的是问题所在吗？

单体架构是指将一个应用作为一个单元部署。这本身并非缺陷：Martin Fowler的“单体优先”建议指出，几乎所有成功的微服务案例都始于一个体量过大的单体架构，而且在充分了解业务领域之前，稳定的服务边界很难划定。在着手重构之前，请先寻找以下迹象：

• 变更相互冲突。多个团队编辑同一文件，发布相互等待，一处小修复需要完整的回归测试。
• 一处故障波及全局。一份繁重的报表或导入任务会拖慢所有租户的登录和计费。
• 没人能解释某个部分。代码直接访问其他代码的数据，导致一处改动引发另一处故障。
• 某个工作负载需要不同处理方式。搜索、媒体处理或AI功能需要与其他部分不同的硬件、扩展或发布规则。

不要为并非单体耦合引起的问题而重构。页面缓慢往往是缺少索引，发布不稳定往往是缺少测试，账单过高往往是缺少成本归因——后者参见我们的云成本控制指南。如果系统整体已老旧、不受支持或不透明，请先运行遗留系统评估清单。

目标：在拆分服务之前先实现模块化单体

模块化单体仍是一个可部署的应用，但其代码被划分为若干模块，每个模块有清晰的公共接口和独立的数据。Shopify工程团队描述了其大型Rails应用的这一方案：通过定义明确边界的组件，开发者只需关注与自己相关的部分，测试也可针对单个组件而非整体运行。同一文章还列出了团队若重新开始会有所不同的经验教训，因此需要为迭代做好规划。

真正的模块而非仅仅是一个文件夹，需具备：

1. 公共接口。其他模块调用函数或发送事件，而不直接访问内部实现。
2. 数据归属。每个模块拥有自己的数据表，其他模块不能直接读取或联查。
3. 负责人。由一个团队对该模块的行为及其测试负责。
4. 强制规则。构建中的检查会在某模块导入另一模块内部实现时报错。

对于SaaS产品，典型模块包括身份与访问、租户与权益、计费与订阅、核心产品域、通知与报表。租户上下文贯穿每个模块；该决策所依赖的隔离选项详见多租户架构指南。

选择路线

大多数产品最终以模块化核心加零至少数提取服务的形式落地。团队应将完整的微服务体系视为需要努力争取的目标，而非出发点。

找到接缝，再划定边界

接缝是指代码中某一部分只需少量改动即可与其余部分分离的位置。应从实证而非架构图中寻找接缝：

• 依赖关系图。生成真实的导入关系图。入站调用多、出站调用少的模块是最佳首选；耦合严重的核心部分放到最后处理。
• 数据归属。对每张表，列出哪些代码读写它。被多处写入的表说明边界尚未存在。
• 变更历史。经常一起变更的文件通常属于同一模块；独立变更的文件则暗示一条边界。
• 业务语言。在不同地方含义不同的名称——例如计费中的“account”与登录中的“account”——标志着业务域之间的边界。

以低风险、高学习价值为原则选择第一个模块：功能明确、接口简单、共享数据少。通知或报表模块通常符合条件。计费和身份模块留到方法经过验证后再处理，届时需格外谨慎，因为这两个模块的错误会影响每一个租户。

迁移过程中的租户、计费与数据

多租户是重构中容易悄然出错的环节。以下三条规则有所帮助：

• 租户上下文不可省略。每个模块和每个新服务都必须接收并强制执行租户标识符，最好通过共享代码实现，而非手工重复。
• 分批迁移租户。从内部和友好租户开始，观察错误和性能，再逐步扩大范围。对十个小租户有效的迁移方案，对一个拥有多年数据的大租户未必适用。
• 将计费和权益视为合约。在底层代码变更期间，使用事件和套餐限额对客户必须保持一致。在切换前，对新旧路径的账单和权益结果进行比对。

数据迁移需要规划过渡期间的读写方案：双写、变更捕获或短暂冻结，每种方案之后都需进行一致性校验。

已有哪些交付记录，哪些尚无

Netbase构建并运营多租户SaaS产品，本指南正是为此场景而写：

• Cloodo Workspace。一款集CRM、HRM、Cloud ERP和AI模块于一体的工作管理数字化工作台，由Netbase作为业务部门构建并运营（Cloodo记录）。
• 面向美国客户的Cloud ERP（未具名）。一个多租户云ERP，Netbase自2020年起作为离岸开发及管理合作伙伴持续开发（Cloud ERP记录）。
• Printcart。Netbase业务部门的Web to Print SaaS平台（Printcart记录）。
• Netztech。一个在35个工作日内从Magento 1迁移到Magento 2 Commerce的商店（Netztech记录）。这是平台迁移，而非单体分解。

Netbase的交付生命周期包含模块化和产品化组件，其SaaS产品加速器由可复用模块构建而成。

尚无记录。目前没有已发布的Netbase案例描述将运行中的SaaS单体拆分为模块或服务，也没有发布此类工作的持续时间、部署频率、成本或性能结果。上述方法来源于所引用的资料和通用工程实践，而非Netbase的实测结果。

备选方案：由谁主导工作

四项标准决定选择：是否已有测试和监控、有多少人了解旧代码、迁移期间需要持续进行多少路线图工作，以及之后由谁拥有架构。Netbase从对租户架构、计费、安全和成本的架构评审开始，然后规划各个切片。在Netbase定制开发中，客户拥有为其创建的知识产权，大多数项目在发现阶段后以固定总价合同执行。相关服务详见SaaS开发和云平台工程。

本指南的局限性

• 每个代码库各不相同；第一次依赖关系映射往往会改变计划。
• 不同框架和语言提供了不同的边界强制工具；请检查您所用技术的支持情况。
• 引用来源仅限于其所记录的内容；未声明任何速度、成本或可靠性数据。

常见问题

我们应该迁移到微服务吗？通常不建议作为第一步。先在单一应用内重构为模块，仅当某模块有经过量化验证的独立扩展、发布节奏或隔离需求时，才提取为服务。

需要多长时间？取决于代码规模、测试覆盖率以及数据耦合程度。Netbase在架构评审和第一次依赖关系映射后给出估算，不公布典型工期。

迁移期间能继续发布新功能吗？可以，前提是工作以切片方式发布，且构建在新边界出现时即强制执行。请为两者都规划容量。

如果单体是遗留系统怎么办？先进行评估。如果平台不受支持或规则不明确，重平台或发现阶段可能需要在模块化之前进行。

下一步

告诉我们产品当前的部署方式、有多少团队在修改它，以及哪个部分最令您头疼，我们将预约解决方案评审，梳理接缝并提出第一个模块的建议。您也可以阅读更多Netbase洞察。

相关服务与解决方案