如何用Serverless让SaaS获得更灵活的租户隔离和更优的资源开销

标签: 架构运维 Serverless SaaS | 发表时间:2021-12-10 12:54 | 作者:
出处:https://blog.didispace.com/

关于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中完成的一系列细节操作:

  1. 租户配置(确定是pool用户还是silo用户)
  2. 根据租户类型,创建不同的用户管理服务,并创建租户管理员用户
  3. 构建租户管理服务,存储该租户的配置
  4. 如果是silo用户,则为该租户构建独有的服务资源(下图展示了这一步的具体流程)

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

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

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

当然了,AWS re:Invent的内容不仅限于SaaS和Serverless,还有很多关于DevOps、GraphQL等精彩的前沿内容。有兴趣的小伙伴,可以 点击这里直达内容首页

相关 [serverless saas 隔离] 推荐:

如何用Serverless让SaaS获得更灵活的租户隔离和更优的资源开销

- - 程序猿DD
关于SaaS和Serverless,相信关注我的很多读者都已经不陌生,所以这篇不会聊它们的技术细节,而将重点放在SaaS软件架构中引入Serverless之后,能给我们的SaaS软件带来多大的收益. 在开始下面的内容之前,不妨先给自己半分钟时间,思考下:你认为Serverless的引入,对你现有的SaaS软件架构带来多大的提升.

Serverless 初探

- - 掘金 前端
广义的 Serverless :构建和运行软件时不需要关心服务器的一种架构思想. 虽然 Serverless 翻译过来是 “无服务器”,但这并不代表着应用运行不需要服务器,而是开发者不需要关心服务器. 而基于 Serverless 思想实现的软件架构就是 Serverless 架构. 现阶段关于 Serverless 的实现主要是基于 FaaS(函数即服务) 和 BaaS (后端即服务)的方案.

Knative serverless架构详解

- -
服务器是一个高性能的 Web 和反向代理服务器. Nginx 在激烈的 Web 服务器竞争中依旧保持良好的发展势头,一度成为. Web 服务器市场的后期之秀,这一切跟 Nginx 的架构设计是分不开的. 来自于my.oschina.net,,由火龙果软件Alice编辑、推荐. 无服务器架构(serverless),则表示代码可以只在需要时运行,在不需要时就停止,从而让你的基础设施能在其他方面自由使用计算资源.

SAAS创业两大原罪

- -
相对于美国,中国的 SaaS 创业者面临更多的不确定因素. 政策的变化,专业人员的缺乏,一浪又一浪的社会思潮迭代,想要在这个不确定性极高的环境中想要做到很好是很困难的事情. 然而应对不确定性就是创业者的必然挑战之一. 除了上述提到的这些所有行业都会面临的挑战之外,有两大挑战是 SaaS 创业特有的.

中国人不爱用SaaS?

- - 钛媒体:引领未来商业与生活新知
钛媒体注:本文来自于微信公众号 ToB行业头条(微信ID:wwwqifu),作者为李晓松,编辑为Robin、Jenny,钛媒体经授权发布. 前段时间,有朋友跟企服君吐槽,说他们公司新上了一套SaaS系统. 这套SaaS系统集考勤、OA、CRM、财务报销等各种功能于一体,功能不可谓不全,可这套SaaS却不怎么得员工的心.

Serverless/FaaS 的现状和未来

- - 午夜咖啡
FaaS 是一种新兴的技术平台,个人认为 2018 年即将迎来 FaaS 的崛起. 本文给大家提供一个 Serverless/FaaS 的现状与未来的报告,也作为自己的年度技术总结. 什么是 Serverless/FaaS. 但传统的 Application PaaS 平台,开发者对服务运行的实例还是有感的,即便是没有调用,也依然需要占用资源,并对资源付费,并不是完全的 Serverless,直到 FaaS 出现.

Serverless 的初心、现状和未来

- -
作者 | 不瞋  阿里云高级技术专家. 导读:Serverless 是如何产生的. Serverless 的未来又将如何. 本文分享了阿里云高级技术专家不瞋对于 Serverless 的看法,回顾其发展历程,并对 Serverless 的发展趋势做出预测. 回望整个计算机技术发展史,我们会发现 “抽象、解耦、集成” 的主题贯穿其中.

引入:从云计算到Serverless

- - InfoQ推荐
自世界第一台通用计算机ENIAC(Electronic Numerical Integrator And Computer, 如图1)诞生以来,计算机科学与技术的发展就从未停止过前进的脚步,尤其是近些年计算机的发展更是日新月异,有不断突破和进化的人工智能领域,有5G带来更多机会的物联网领域,还有“可信“的区块链技术,当然也有不断更新、不断迭代,不断走进“寻常百姓家”的云计算.

谈SaaS应用趋势和变化

- - 人月神话的BLOG
SaaS可以说是云计算三层里面发展最早的一层,包括在线邮箱也可以说是个人SaaS应用,而Saleforce等在国外发展也很早,那个时候还没有完全提出完整的云计算架构框架. 现在来看,SaaS应用的发展,一个必须要解决的问题不是多租户运营问题,而是SaaS应用本身的可伸缩性问题,并不是说SaaS一定要基于IaaS或PaaS,而重要的是随着客户的增多应用必须支持应用和平台层的可伸缩性.

中国特色的 SaaS 产品运营

- - OneAPM 博客
根据二八法则,80%的流量聚集在20%的站点. 这个特点放在国内,更具有代表性,以 BAT 为代表的互联网公司几乎“垄断”了国内流量入口,因此,国内 SaaS 产品运营自有其特殊性,我们姑且称之为 “中国特色的 SaaS 产品运营”. 中国特色的 SaaS 产品运营之:卧薪尝胆. 对于企业级 SaaS 产品,通过自建平台、渠道去构建运营护城河,代价是高昂的且难度是极大的.