深入浅出 Serverless:优势、意义与应用

更新于 2月12日  约 14 分钟

Serverless 是炙手可热的技术,被认为是云计算发展的未来方向。尤其是在前端研发领域,使用 Node 开发云函数,可以让前端工程师更加专注于业务逻辑,实现全栈工程师的角色转变。

Serverless 的优势

技术 Leader 和架构师在进行技术选型时会关注很多指标, Serverless 贡献最大的就是 研发交付速度(Time to Market) 和 成本(Cost)

研发交付速度方面,衡量的指标是 Time to Market,是从需求产出到上线所用的总时长,Serverless 在这方面的优势在技术和团队协作两个视角上均有体现。

一是技术视角。 有一种观点称 Serverless 是一种很简单的技术,我对这种观点并不完全同意。Serverless 架构让用户和底层架构的关系发生了变化,之前开发者需要关注核心业务逻辑、运维和底层架构的治理,在 Serverless 架构中底层的部分由 Serverless 架构提供方来解决。从整个应用系统的角度来看,系统架构的难度和复杂度并没有实质简化。

Serverless 底层复杂架构(用户完全不用关注的部分)

这里我们不展开讲 Serverless 架构的底层实现细节。只需要了解一点:Serverless 底层架构做的事情越多,业务层面需要关注的架构和运维工作就越少,因为做的工作少了,所以交付的时间就更快了。

Serverless 架构下开发者需要关注的两块内容

二是团队协作视角。在 Serverless 的模式下,全栈开发的工作模式会执行得更加顺畅。我们知道,前后端分离确实是一种很好的架构模式:细化了分工,降低了耦合,提升了复用。但随之而来的问题,是团队间的沟通成本、KPI 目标的差异所带来的各种催排期、接口确认以及联调测试。不少技术团队用全栈开发的模式来解决这些问题, Serverless 下不需要在架构和技术栈花费过多精力,Runtime 和语言也没有强制依赖,而是完全面向业务,每个前端工程师都可以是全栈的。

另一个优势就是 Serverless 会大大降低成本,体现在计算资源和人力两个层面。

在计算资源的成本方面,主要体现在弹性扩缩容量,按需付费。在传统的计算资源预算时,往往为了能抗住峰值流量,系统容量都有 Buffer,说白了就是日常的浪费。

资源对比

在 Serverless 模式下,当业务代码上线后,一分钱都不需要支付。只有当真实请求和流量过来了,平台才会根据请求量,瞬时拉起对应数量的函数实例,去接收请求和执行业务代码,此时才需要为真正的代码执行所消耗的资源付费。No Pay for Idle ,从会计学的角度,Serverless 让计算资源从固定成本变成了可变成本。这种付费模式对于那种流量波动很大的业务优势明显。

资源对比 2

还要说明的是人力成本。很多技术 Leader 总抱怨人手不够,也许真实情况并非如此,只是没有足够比例的人投入到业务功能的开发和迭代上,而是去做了架构、底层等必要的支撑性工作。我承认这些工作确实非常有挑战、非常必要,也非常重要。在 Serverless 模式下,由于不再需要关注底层架构,所以缩小这部分的工作量和人力占比,就有了更多的工程师可以放在核心业务上,多做迭代,从而加速产品功能的研发。这不是更高的 ROI 吗?

Serverless 的适用场景

Serverless 适用于事件触发的场景。当某个事件发生时,拉起并调用 Serverless 云函数,比如文件上传、消息队列中的消息事件、定时器事件,也可以是 IoT 设备的某个事件。还可以用于一些文件处理,比如图像处理、音视频处理和日志分析等场景。

当然,这些事件也包括 HTTP 请求事件,这是 Serverless 的一个很大的适用场景—— HTTP Service,主要实现基于 HTTP 应用的后端服务,比如 REST API、BFF 和 SSR 服务,以及业务逻辑的实现。

我主要关注 Serverless 在 HTTP 场景下的应用。这也是和前端工程师结合最紧密的部分。小到为小游戏、运营活动提供后端的支持,大到整个 App 或站点的 REST API、BFF,或是 H5 页面的 SSR,都是 Serverless 适用的场景。

Serverless 对前端开发者的意义

Serverless 的诸多优势业内有很多讨论,也有不少文章谈及。我想聚焦到前端开发者身上来说一说,Serverless 能够帮助前端工程师实现真全栈的梦想。可能有人会质疑,为什么你又提出一个真全栈,和之前的全栈有什么区别吗?

业内对于全栈的定义:前端 + 后端 + 数据库

我先明确一下真全栈的定义:如何判断一个工程师是真全栈工程师?

当公司有了一堆产品功能需求,招了一个程序员张全占,如果他能从 0 到 1 把需求做成产品,那才叫真全栈。如果张全占完成了前端功能开发、后端开发以及数据库开发,实现了所有的需求功能,并且部署到对应的服务上,就完事了,那么问题也就来了:服务挂了谁来重启?环境稳定性谁来做?日志把磁盘写满了谁来清理?定时任务怎么搞?产品突然火爆了,流量一夜间突然扩大了十几倍的时候(产品经理狂喜中),谁负责扩容?这些问题虽然不是核心业务需求,却是每一个线上产品都必须考虑的东西,否则只能称为功能集合,不能称之为产品。

从需求到产品,从 0 到 1 的技术全栈

Serverless 架构的出现,将刚才说到的一些非核心业务逻辑,以及运维相关的事情给“屏蔽”了。前端工程师张全占只需关注前台功能、后台功能和数据这些核心的业务逻辑,就可以独立做出产品。例如目前的微信小程序云开发就是 Serverless 式的,开发者完全不用关注底层架构。

Serverless 对前端工程师群体来说是一个机会。让一个前端工程师能够得到独立负责某些产品研发的机会,完成某些产品从需求到上线的从 0 到 1 的机会,一个回归到互联网研发工程师角色的机会。我希望所有的前端工程师都有机会成为 Serverless 工程师,有机会独立负责研发整个产品。

采用 Serverless 的准备

总体上来说,采用 Serverless 不需要工程师大量的学习和准备过程。

Serverless 本身就是在现有的架构中做减法,减去那些服务器的管理和配置工作。当然在具体落地的时候,还是有一些准备工作要做:

首先是明确目标,开发者在了解 Serverless 之后,应该去思考对于自身业务和开发架构,采用 Serverless 是为了解决什么问题?想取得哪方面的提升?没有一种技术是为了用而用,都是针对具体场景解决具体问题。这是第一个需要搞明白的。

明确了目标之后,接着是 Serverless 模式下架构的一些设计工作。与传统的开发模式一样,系统设计的工作量是根据业务的复杂程度决定的。对于复杂业务逻辑来说,在开发之前需要明确有多少个云函数,每个云函数的输入输出定义、采用哪些 BaaS 后端服务,都需要提前设计规划好。

特别要说明的是,这些设计和非 Serverless 并没有什么本质上的不同,Serverless 云函数也不是神秘莫测的。简单理解,它所提供的就是一个语言的 Runtime。在非 Serverless 架构下如何执行的代码,Serverless 架构下还是那样执行。如果业务是基于 Express 或者 koa 这类应用框架,那么 Serverless 云函数下,还是直接使用这些框架即可。

腾讯云函数已支持一键部署 Express.js 应用

最后是一些实施上的准备,以腾讯云函数为例,只要是写过代码的,花小半天时间阅读一些基础文档、教程,或者是跟着 Demo 走一遍,就可以立刻开始写代码,几乎没有什么门槛和不同。要敲黑板强调的是,别忘记了工程化和 CI/CD 方面的考虑,尤其是和现有研发流程的结合。这块有一些小小的工作量,毕竟是开发模式的升级,但基于云函数提供的 CLI 和 SDK 都很容易实现。

Serverless 和云函数的关系

Serverless 架构由两部分构成,分别是 FaaS(Functions as a Service)和 BasS(Backend as a Sevice)。其中 FaaS 就是指云函数,它是一种新的算力组织和提供方式,它让用户不再需要关心服务器的管理和配置,只用专注于核心业务逻辑业务代码的编写。BaaS 指的是一些服务化的后端功能,包括数据库 / 对象存储、账户权鉴、消息队列、社交媒体整合和 AI 能力等,这些服务和接口在 FaaS 层使用相应的 SDK 或 API 来连接和调用。

FaaS + BaaS

FaaS+BaaS 的组合,构成了 Serverless 无服务器架构,免除了所有运维性操作,让企业和开发者可以更加专注于核心业务的开发,实现快速上线和迭代,把握业务发展的节奏。

由此可见,云函数是 Severless 架构中的算力部分,是实现 Severless 架构的基础计算资源。在 Severless 架构下的业务系统中,因业务功能、需求场景不同,所需的 BaaS 后端服务也可能各不相同,但业务逻辑都需要通过云函数来实现。

具体案例

刚才也提到 Serverless 本身有很多很多的应用场景,这个问题在不同的 Serverless 的场景下,答案也是不同的。

如果业务需求是基于类似于 Express、koa 的应用框架来实现的,那么在设计上,基本没有任何区别。Serverless 云函数可以很好地支持这些应用框架,只是部署方式不同而已。

如果需求场景不需要任何应用框架,直接使用原生代码,在 Serverless 架构下进行设计时,需要以函数为粒度来考虑,将函数作为业务中的最小功能单元。

还有一个场景使用 Serverless 和不使用就有很大的不同——企业上云。

现在很多企业应用都做应用上云,上云其实是一件非常有技术门槛的事情。可能需要上云的代码只有几百行,但传统上云绝不是上传部署几百行代码那么简单(估计很多工程师看到 Kubernetes 那几本厚书的时候就已经快疯了)。这个过程需要专业的、有经验的工程师,花费大量的工作,才能把业务系统迁移到云上。

传统的应用上云:大量的技术门槛和环境配置

Serverless 下的体验就非常不同,因为无服务器架构,所以不需要关注虚机或者容器配置和治理工作,基本上只用上传代码就完成了上云。

Serverless 的未来演化

从以往的历史来看,技术的演化还是存在一些一般规律的。

首先我预测 Serverless 生态一定会趋于繁荣。一个技术很有优势,相关的社区贡献,以及周边的支持就越强大,用的人就越多;用的人越多,这个技术就越火,类似于经济学里的有效市场理论。最近 Serverless 的发展很快,可能大家看到这篇内容的时候,我们的 Serverless DB 产品已经发布了,就是开发者连数据库的存在都不需要关注了。Serverless 的使用者会越来越多,同时生态里的贡献者也会更多,整个生态也会更加繁荣。

第二个方向是 Serverless 的标准化。当生态繁荣之后,对于标准化的需求就变得非常强烈了。国内外各家云都有了自己的 Serverless 解决方案,对开发者隐藏了底层基础设置。但是各家的接口、实现还是不一样。试想一下,开发者在国内云上用 Serverless 实现的代码,在做国际化的时候,要迁移到另一个云厂商,却发现完全无法平滑迁移是什么感受?公司内两个技术团队如何在 Serverless 的架构下复用功能和代码?如何能够用统一的标准或者框架来构建应用?Serverless 开发需要一些标准,或是某一种框架来适配各个云厂商之间的不同实现和接口,很可能是 Serverless 接下来的发展方向。

传送门:

欢迎访问:Serverless 中文网,您可以在 最佳实践 里体验更多关于 Serverless 应用的开发!


推荐阅读:《Serverless 架构:从原理、设计到项目实战》
阅读 416更新于 2月12日

推荐阅读
玩转Serverless
用户专栏

我们专注于 Serverless 架构最佳实践,欢迎关注:[链接]

6 人关注
45 篇文章
专栏主页
目录