SaaS软件架构

在国内的SaaS软件市场，发展到一定阶段，都可能会遇到大客户私有化部署的需求。如果SaaS系统设计之初没有考虑私有化部署场景，会就面临诸多挑战。

灰度发布有多种方式，目的主要是提升系统的可用性，当出现问题时能够减少影响范围，同时能够快速回滚。灰度发布也有降低发布风险的作用。SaaS系统的灰度发布也有其特点，我们一起来看一下。

相比于单体模式，各个服务相对比较独立，开发和运行能够自闭环，各团队间的耦合更低。同时微服务架构对基础设施的依赖会增强。

从单体架构重构到微服务，是一个漫长的过程，单体和微服务架构会共存较长时间，基于前面的分析，我们一起看一下过度阶段的系统架构。

随着系统复杂度的上升，我们需要能够更好的对其进行管理。通常我们会考虑将大单体拆分为分布式系统，以减少单个单元的复杂度。但同时会引入分布式系统带来的问题，比如通讯的性能损耗、可能的异常、分布式事务等

当系统已经积累了大量的租户，产品也由多产品发展为多个产品线，几十个产品时。现有的单体架构在性能、可用性、团队协作方面都面临巨大的挑战。

在多产品阶段，跨团队协作和之前单产品会所有区别。不同产品团队之间的“距离”会更远一些，所以在系统设计上需要更高层次的一致性，而产品内部设计需要有一定的自由度。

在前面的多产品架构升级中，我们讨论了多产品业务隔离的发展。我们可以看到，随着业务发展，我们会把公共的业务独立出来。虽然这是一个相对自然的过程，但其中也会面临很多挑战。

当系统有多个产品，且由多个团队分别开发时，产品间的隔离就需要提上日程了。如果继续在一个大单体上开发，很容易造成同一模块多方维护，导致功能无规划的混乱增长，系统逻辑复杂，冲突变多，质量问题频发。

随着客户的增多及业务的扩展，SaaS系统从单业务发展到了多业务模式，形成了多产品的形态。这些产品属于同一个垂直领域，但服务于不同的业务节点和场景。多产品的解耦与公共业务的设计形成了新的挑战。

随着业务发展，团队人员越来越多，不得不分成多个团队来工作（参考两张披萨原则）。多团队带来了团队协作的挑战，同时人员扩张也会带来团队文化被稀释，规范被破坏的风险。

随着系统的深度使用，产品进行快速迭代以满足租户新的需求，随之会出现与产品规划不一致的需求，甚至会出现不同租户对同一场景提出不同解决方案的情况。

考虑到大租户在举行活动时，会带来大量的流量，产生很多的消息，为了报表的展示，也需有大量的数据清洗加工任务。此时单个租户可能会消耗大量的系统资源，系统需要运行层面按租户调整的解决方案。

随着系统的上线，已经收获了一部分客户的持续使用，当前系统客户数处于快速增长期。系统面临整体流量和大租户流量的双重挑战。

在初创阶段，一般用户规模不大，而且业务并不成熟，更多的精力需要放在功能开发上，一般不会有太多资源投入进行技术打磨。因此建议尽量使用通用且团队熟悉的技术。

从简约的多租户设计开始： 我们可以先将数据分为结构化和非结构化数据。结构化数据存储在关系型数据库，非结构化数据存储在对象存储中。

虚拟背景：我们现在是一个初创的SaaS团队，人员较少，就只有一个敏捷团队。我们已经有了一个好的想法，而且通过了立项的分析和讨论。我们现在需要进行技术基础建设。

SaaS软件和其他软件最大的不同，是一套软件服务于多个租户，也就是我们常说的多租户架构。几乎所有架构层面的设计，都需要考虑多租户的因素，所以“多租户”并不是一个独立的设计层或模块。

SaaS软件的特点 在讨论SaaS软件技术相关的话题前，我们先来看看SaaS软件是什么，有什么特点。

从2014年参加公司的SaaS软件项目算起，到今年已经整10年了。也算经历了SaaS软件从起步到快速发展再到回落的整个周期。公司的SaaS业务也随着大周期起落沉浮。现在是时候总结一下了。