关于 SaaS 和 Serverless，相信关注我的很多读者都已经不陌生，所以这篇不会聊它们的技术细节，而将重点放在 SaaS 软件架构中引入 Serverless 之后，能给我们的 SaaS 软件带来多大的收益。

在开始下面的内容之前，不妨先给自己半分钟时间，思考下：你认为 Serverless 的引入，对你现有的 SaaS 软件架构带来多大的提升？

先说一个大部分人都可以想到的：从 Serverless 简化运维的角度去思考，站在软件平台的运维方，能够降低运维复杂度。这个收益显而易见，我开始也只想到了这一点，直到这几天看了 AWS re:Invent 中几个关于 SaaS 架构与 Serverless 的演讲，才有了一些更高维度的思考。下面我们就来一起看看在 SaaS 遇到 Serverless，可以迸出怎么样的火花。

背景

SaaS 软件和 Serverless 服务，在国内的发展，一直有种难兄难弟的感觉。虽然做的事情不一样，但它们当前的用户现状和困境非常相似。

现状：相似的用户群体

目前国内做 SaaS 的已经非常多了，我自己即是 SaaS 软件的用户，也是 SaaS 软件的开发者，日常也订阅了一些好用的 SaaS（比如：在线作图工具 ProcessOn、在线表单金数据等）。大部分 SaaS 软件都是以实现低门槛的通用功能为主，拥有高复杂度功能支持的非常少见。因为这一功能特性的制约，它们的主要客户目前以小客户为主，集中在初创团队、小公司、甚至个人。

Serverless 在国内的现状也很相似，之前因为为某厂的 Serverless 服务做推广，目前比较容易被接受的还都是初创团队和小公司。因为 Serverless 简化运维这个直接收益的认识上，比较容易被大家理解、认可并接受（包括我自己）。所以针对运维能力薄弱的团队或企业，会是一个比较好的突破口，自然而然的，用户群体也落到了缺少技术能力或人力成本匮乏的小团队上。

困境：相似的焦虑

由于 SaaS 和 Serverless 有着类似的用户群体，所以他们的焦虑也非常相似。这一用户群体的特点就是目前厂商焦虑的核心：付费能力不高，续费意愿一般。现阶段解决这一焦虑的主要手段就是不断的营销增长，所以我们总会看到很多拉新活动或续费优惠活动。但营销活动做得再多，也无法改变这一焦虑存在的本质，尤其是在出现更多同类产品的竞争对手之后，这样的压力会越来越明显。

所以，为求突破，大家都开始把眼光放到大客户这块蓝海上，中大型企业对于软件与基础设施的消费能力强和续费可能也要远远高于初创团队和小企业，如果能有几个大客户常驻平台，那么对于 SaaS 和 Serverless 服务商的长期发展都是非常有益的。目标很美好，但是要支持大客户的入驻并不是一件容易的事，所以也就有了一直被热议的一个问题：大客户的这块蛋糕，到底要不要去吃？又该怎么吃？

困难的本质

SaaS 的难

SaaS 软件为什么推向大企业的时候会很难？这里面有很多原因，对于 SaaS 软件的开发商来说，大客户的需求更复杂，实现起来比较困难，成本会急剧升高，架构复杂度也会面临巨大的挑战。同时，大客户对于业务运行到 SaaS 平台，还有一个最大的担忧，就是 SaaS 的不稳定性。

如果你是 SaaS 平台的重度用户，一定碰到过这些问题：其他租户的故障影响到了你的功能、平台版本的升级直接把你的服务整挂了。为什么会产生这样的问题呢？其实本质还是当前国内 SaaS 软件的目标和架构设计原因，由于初期目标就是服务小客户，为了节省成本，利用好规模效应，获得更高的利润，大量的功能支持都在共享资源池中，所有租户的使用都有可能会造成互相的影响。而该问题的本质其实就是租户的隔离级别不满足大客户的要求，所以如果要拓宽这类客户，就必须从架构上提升租户隔离的级别。

Serverless 的难

Serverless 在推向大客户的时候，与 SaaS 软件面对的困难并不一样。由于 Serverless 直接提升的是运维效率，而大企业往往已经有成熟的运维体系和团队支撑，引入 Serverless 是否真的可以带来提升，这其实并不好说，因为从更全面的实施角度去考虑，其中还包含大量诸如培训等容易被忽略的成本和风险。如果基于现有成熟体系去替换一般来说是比较难推动的。这就像已经在完善成熟的信用体系之下，移动支付很难流行起来，是一个道理。所以，Serverless 要被大客户接受，需要找到一个更痛的切入点去打动客户。

SaaS + Serverless 的新思路

在聊了 SaaS 和 Serverless 各自的现状和面向大客户应用的难点之后，回头看 SaaS 和 Serverless 的结合，会擦出怎么样的火花呢？

首先来看看在 SaaS 中引入 Serverless，除了基本平台运维的效率提升之外，我们试着把注意力转移到大客户的租户隔离上来。是不是有点感觉了？

在没有 Serverless 的支持之前，我们要如何为客户提供更高级别的隔离？是不是需要我们去编写很多脚本去完成各种资源的创建、应用的部署、数据的初始化等等操作？而且这样的操作复杂度与系统依赖其他资源的复杂度成正比，那么对于一个租户的独有资源管理（资源创建、弹性伸缩、以及不续费之后的销毁）存在着很大的挑战。

但如果我们使用 Serverless 来完成租户需要的资源隔离，运维层面就可以带来很大的改善，整体运维复杂度也不会提升太多。在这样的思路之下，我们还可以做更灵活的多层租户服务，以满足各种不同级别用户的要求，比如：对普通租户采用共享资源提供服务，白银租户采用部分共享资源 + 部分 Serverless 的独立资源提供服务，黄金租户采用完全 Serverless 部署的独立资源服务等。

下图就是采用了 Serverless 来部署不同级别租户的架构图，其中 Tenant 1 和 Tenant 2 通过独立的 Serverless 部署，拥有更好的隔离型，这类租户往往是更高级别的付费用户。而一些基础付费用户则还是通过池化资源对外提供服务。

由于 Serverless 拥有弹性伸缩特性，这使得所有资源的开销变得更加经济。如下图，当我们使用 Serverless 来构建 SaaS 服务的时候，整体的资源消耗可以随着租户的使用情况呈现一个最佳状态。

对于 SaaS 软件供应商来说，通过 Serverless 来构建 SaaS 服务不仅可以在多租户隔离上的要求上做的更好，在资源成本控制上也会更为出色。另外一方面，从 Serverless 供应商而言，走进大客户的难点，或许可以通过为 SaaS 软件提供多租户解决方案，从而找到一条更容易的快速通道。原本 SaaS 和 Serverless 面向大客户都存在一定的难度，而这样的结合，是不是有种难兄难弟双双把大客户带回家的感觉？

如何通过 Serverless 构建 SaaS 软件

既然通过 Serverless 来构建 SaaS 软件这么爽，那么我们又该如何做呢？这次大会的主题演讲中也给出了几个非常具有指导意义的解决方案。其中《深入探寻无服务器 SaaS 参考解决方案的内部原理》主题中有一个使用 Amazon Lamdba 来构建的例子

下面这里 DD 给大家也简单拆解一下大家最关心的租户创建与隔离资源的创建流程是怎么样的。先来看看这个参考解决方案的架构图：

图中 Control Plane 是整个 SaaS 系统的控制中间，这里负责管理租户、租户下的用户以及各个租户的资源配置等。Application Plane 部分则是具体运行 SaaS 业务的核心集群，在 Application Services 部分，可以看到有两个微服务集群，这里就体现了隔离的思想，你可以把其中一个作为普通租户的资源池，而其他的可作为高级租户的独立资源池。

既然我们要实现租户的资源隔离，这一整套隔离资源是如何一步步创建出来的呢？

上图展示了一个新租户注册的时候，在 Control Plane 中完成的一系列细节操作：

1. 租户配置（确定是 pool 用户还是 silo 用户）

2. 根据租户类型，创建不同的用户管理服务，并创建租户管理员用户

3. 构建租户管理服务，存储该租户的配置

4. 如果是 silo 用户，则为该租户构建独有的服务资源（下图展示了这一步的具体流程）

不同租户的服务版本和构建部署是如何映射的呢？下面这张图就很清晰了，左侧的表格记录了租户 ID、代码版本、所属 stackName（不知道怎么翻译，其实就是不同的资源池）。

所以，通过这样来实现，对于一些高级租户来说，除了资源的隔离之外，软件版本的隔离也是可以做到的。这样也消除了，大平台版本的升级（可能租户自己并不想升级）影响到某个租户的情况。

整个租户创建与隔离资源创建的大概步骤讲完了，该演讲中还有一些租户管理、用户管理、权限管理、API Gateway 上的授权管理等细节这里就不细节说了，有兴趣的小伙伴可以自行观看这个专题演讲：深入探寻无服务器 SaaS 参考解决方案的内部原理进一步了解，里面还有一些简单代码供参考。除此之外，对于正在研究 SaaS 解决方案的同学，还有一个多租户 EKS SaaS 解决方案 的演讲也非常值得一看。