type
status
date
slug
summary
tags
category
icon
password
先说一个大部分人都可以想到的：从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参考解决方案的内部原理open in new window》主题中有一个使用Amazon Lamdba来构建的例子，下面给拆解一下大家最关心的租户创建与隔离资源的创建流程是怎么样的。
先来看看这个参考解决方案的架构图：
图中Control Plane是整个SaaS系统的控制中间，这里负责管理租户、租户下的用户以及各个租户的资源配置等。Application Plane部分则是具体运行SaaS业务的核心集群，在Application Services部分，可以看到有两个微服务集群，这里就体现了隔离的思想，你可以把其中一个作为普通租户的资源池，而其他的可作为高级租户的独立资源池。
既然我们要实现租户的资源隔离，这一整套隔离资源是如何一步步创建出来的呢？
上图展示了一个新租户注册的时候，在Control Plane中完成的一系列细节操作：
- 租户配置（确定是pool用户还是silo用户）
- 根据租户类型，创建不同的用户管理服务，并创建租户管理员用户
- 构建租户管理服务，存储该租户的配置
- 如果是silo用户，则为该租户构建独有的服务资源（下图展示了这一步的具体流程）
不同租户的服务版本和构建部署是如何映射的呢？下面这张图就很清晰了，左侧的表格记录了租户ID、代码版本、所属stackName（不知道怎么翻译，其实就是不同的资源池）。
所以，通过这样来实现，对于一些高级租户来说，除了资源的隔离之外，软件版本的隔离也是可以做到的。这样也消除了，大平台版本的升级（可能租户自己并不想升级）影响到某个租户的情况。