关于SaaS和Serverless，相信很多关注我的读者都不陌生，所以本文不谈它们的技术细节，而是重点on在SaaS软件架构中引入Serverless之后，它能给我们的SaaS软件带来多大的收益。在开始下面的内容之前，您不妨给自己半分钟的时间思考一下：您认为Serverless的引入对您现有的SaaS软件架构有多大的改进？先说一个大多数人能想到的：从serverless简化运维的角度，站在软件平台的运维端，可以降低运维的复杂度。这个好处是显而易见的，一开始只是想着。直到这几天看了几个AWSre: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部署不同级别租户的架构图。租户1和租户2通过独立的Serverless部署实现了更好的隔离。此类租户通常是更高级别的付费用户。部分基础付费用户仍通过池化资源对外提供服务。由于Serverless具有弹性伸缩的特性，使得所有资源的开销更加经济。如下图所示，当我们使用Serverless构建SaaS服务时，整体的资源消耗可以根据租户的使用情况处于最佳状态。对于SaaS软件提供商来说，通过Serverless构建SaaS服务，不仅可以满足多租户隔离的需求，还可以更好地控制资源成本。另一方面，从Serverless供应商的角度来看，通过为SaaS软件提供多租户解决方案进入大客户的困境，或许更容易找到快速通道。本来SaaS和Serverless在迎合大客户方面都有一定的难度，但是这样的组合，是不是感觉兄弟姐妹都把大客户带回家了？如何通过Serverless构建SaaS软件既然通过Serverless构建SaaS软件这么酷，那我们应该怎么做呢？本次大会的主题演讲中也给出了几个非常有指导意义的参考方案。其中，《深入探寻无服务器SaaS参考解决方案的内部原理》主题有一个使用AmazonLamdba构建的例子。下面来拆解一下大家最关心的创建租户和隔离资源的过程。我们先来看看这个参考方案的架构图：图中的ControlPlane是整个SaaS系统的控制中心，负责管理租户、租户下的用户，以及每个租户的资源分配。ApplicationPlane部分是核心集群，专门运行SaaS业务。在ApplicationServices部分，可以看到有两个微服务集群，体现了隔离的思想。您可以将其中一个用作普通租户的资源池，而另一个可以用作高级租户的独立资源池。既然我们要实现租户资源隔离，那么这一整套隔离资源是如何一步步创建出来的呢？上图展示了新租户注册时在ControlPlane中完成的一系列详细操作：租户配置（判断是pool用户还是silo用户）根据租户类型创建不同的用户管理服务，创建租户管理员user构建一个租户管理服务，存储租户的配置。如果是筒仓用户，则为租户构建独有的服务资源（下图为该步骤的具体流程）。不同租户的服务版本和构建部署是如何映射的？下面这张图就很清楚了。左边的表格记录了租户ID、代码版本、stackName（不知道怎么翻译，其实是不同的资源池）。因此，通过这种方式，对于一些高级租户来说，除了资源隔离之外，还可以实现软件版本隔离。这样也杜绝了大平台版本升级（可能是租户不想升级）影响到某个租户的情况。租户创建和隔离资源创建的一般步骤就完成了。本次演讲中还有一些关于APIGateway的租户管理、用户管理、权限管理、授权管理的细节。观看此主题演讲：深入了解无服务器SaaS参考解决方案的内部结构以获得更深入的见解，包括一些简单的参考代码。另外，对于正在研究SaaS解决方案的同学，还有一个多租户EKSSaaS解决方案演讲也值得一看。当然，AWSre:Invent的内容不仅限于SaaS和Serverless，还有DevOps、GraphQL等很多精彩的前沿内容。感兴趣的朋友，可以点这里直接进入内容首页。欢迎关注我的公众号：程序员DD，分享别处看不到的知识和思考
