对于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来构建的例子，上面给拆解一下大家最关怀的租户创立与隔离资源的创立流程是怎么样的。
先来看看这个参考解决方案的架构图：
图中Control Plane是整个SaaS零碎的管制两头，这里负责管理租户、租户下的用户以及各个租户的资源配置等。Application Plane局部则是具体运行SaaS业务的外围集群，在Application Services局部，能够看到有两个微服务集群，这里就体现了隔离的思维，你能够把其中一个作为一般租户的资源池，而其余的可作为高级租户的独立资源池。
既然咱们要实现租户的资源隔离，这一整套隔离资源是如何一步步创立进去的呢？
上图展现了一个新租户注册的时候，在Control Plane中实现的一系列细节操作：
- 租户配置（确定是pool用户还是silo用户）
- 依据租户类型，创立不同的用户治理服务，并创立租户管理员用户
- 构建租户治理服务，存储该租户的配置
- 如果是silo用户，则为该租户构建独有的服务资源（下图展现了这一步的具体流程）
不同租户的服务版本和构建部署是如何映射的呢？上面这张图就很清晰了，左侧的表格记录了租户ID、代码版本、所属stackName（不晓得怎么翻译，其实就是不同的资源池）。
所以，通过这样来实现，对于一些高级租户来说，除了资源的隔离之外，软件版本的隔离也是能够做到的。这样也打消了，大平台版本的降级（可能租户本人并不想降级）影响到某个租户的状况。
整个租户创立与隔离资源创立的大略步骤讲完了，该演讲中还有一些租户治理、用户治理、权限治理、API Gateway上的受权治理等细节这里就不细节说了，有趣味的小伙伴能够自行观看这个专题演讲：深刻探寻无服务器SaaS参考解决方案的外部原理 进一步理解，外面还有一些简略代码供参考。除此之外，对于正在钻研SaaS解决方案的同学，还有一个 多租户EKS SaaS解决方案 的演讲也十分值得一看。
当然了，AWS re:Invent的内容不仅限于SaaS和Serverless，还有很多对于DevOps、GraphQL等精彩的前沿内容。有趣味的小伙伴，能够点击这里中转内容首页。
欢送关注我的公众号：程序猿DD，分享其余中央看不到的常识与思考