我在 GMTC 上的分享:腾讯 Serverless 前端落地与实践

Serverless 是当下炙手可热的技术,被认为是云计算发展的未来方向,拥有免运维、降低开发成本、按需自动扩展等诸多优点。尤其是在前端研发领域,使用 Node 开发云函数,可以让前端工程师更加专注于业务逻辑,实现全栈工程师的角色转变。但现有的开发模式、工具、脚手架已经标准化、流程化,存量业务正在线上稳定运行,如何将 Serverless 融入到现有开发模式和工具中?如何将 Serverless 和当前的业务进行结合落地?本文将尝试给出解答。

前端与 Serverless 的不解之缘

目前很多前端同学都在学习 Serverless,很多文章和教程对 Serverless 都有不同方式的解读,今天我们首先来回顾三个问题:

  • 究竟什么是 Serverless?
  • Serverless 是否等于 FaaS 加 BaaS?
  • 我们所说的 FaaS 是什么?

加州大学伯克利分校 2019 年 3 月份发表过一篇论文,名为《Cloud Programming Simplified: A Berkeley View on Serverless Computing》,文中对“Serverless 是什么”进行了一些描述:

Put simply,serverless computing = FaaS + BaaS.

简单来理解,Faas+BaaS 是 Serverless 的一种实现方式,这也是主流对 Serverless 的一种理解。那 Serverless 的真正概念是什么呢?论文最核心的摘要部分,我们可以看到如下图的一段话,它说出了 Serverless 真正内涵:

论文

中文大意是:

「无服务器云计算(Serverless Computing)几乎封装了所有的底层资源管理和系统运维工作,使开发人员更容易使用云基础设施。它提供了一个方式,极大地简化了基于云服务的编程,犹如汇编语言到高级编程语言般的转换。」

这段话中举了一个例子非常生动:

Assembly Language to high-level programming Languages.

「Serverless 给云计算带来的改变,就是相当于从汇编语言到高级语言」。汇编语言,计算机专业的学生都有了解过。写汇编的话,首先需要了解 CPU 的结构,知道加法器、寄存器,需要自己管理内存、IO 设备等一些底层资源。但开发者的目的并非如此,开发者应该是以业务为导向的。而高级语言提供了诸多能力和框架支持,可以令开发者专注于更快地完成业务上的事情,这才是高级语言所具备的优点,而不是让开发者把精力浪费在底层资源管理。

由此可见,Serverless 的内涵就是对全部底层资源和运维工作的封装,让开发者专注于业务逻辑。

理解完 Serverless 的内涵,我们再来谈一下 FaaS(Function as a Service)的本质。一句话而言,FaaS 就是至今为止最细粒度的算力分配方式,我们先理解下什么叫算力分配方式。

当我们谈论计算机应用科学的时候,共有三个维度:“算力、算法、数据” 。在「算力」又有两个方向:一是如何让算力更强,让 CPU 运行得更快;二是如何让算力分配的更合理。传统计算机,从单任务实时操作系统到多任务分时操作系统,是解决算力的分配问题,云计算诞生的初衷以及要解决问题,也是解决巨大算力资源的合理化分配。云的算力分配方式主要是以什么为粒度的呢?

答案是虚拟机。

比机器再降维一点的分配粒度是什么?

答案是容器。

那比容器再降一级的功能是什么?

答案是函数。

最早期的算力分配是物理机为单元,后来是虚拟机和容器。这个算力分配细化的过程,也基本是云计算发展的过程。现在云上可以函数作为一个计算单元,变成每一次业务执行分配一次资源,没有业务就没有资源分配。所以,FaaS 是一个以函数(业务)为粒度的算力分配方式。

当我们理解了 Serverless 和 FaaS 的内涵,我们在讨论下这一切跟前端有什么关系。

随着 Node 的流行,前端工程师一直希望回归 Web 工程师的角色,全栈工程师的也在各种场合和文章被提到,最近几年大前端组织架构也成为超火话题。

第一,从前端工程师自身视角来讲,希望扩大自己的业务范围,进而才能有职业发展,仅仅做前台展现相关的东西,碰不到核心业务,价值得不到展现。

第二,如果从组织或是技术 leader 视角上来看问题的话,则会更关注技术对业务的贡献,关注团队的整体的执行效率、质量控制、角色合作这样一些问题。大前端的开发模式,会提升业务的迭代效率。

  1. 前端和后端都使用 JavasScript,技术栈是统一的。从写代码,到编译、打包、脚手架、组件化、包管理,再到 CICD,采用同一套都不是问题。
  2. Client Side JavaScript 和 Server Side JavaScript 本身就有很多可复用的代码,例如现在行业里有很多同构代码的 CSR 和 SSR 解决方案。
  3. 优化研发组织结构。大前端的开发模式,让接口定义、接口联调、环境模拟等,原来需要两种不同技术能力栈的工程师互相协作的模式,变为同一种技术技术能力栈的工程师独立完成的模式,让沟通和推动的成本降到最低。

想法很美好,但是实话实说,大前端这条路一直走的不是很顺畅。 我个人认为,其中主要的原因还是对 Full-Stack 的理解问题,在 Google 上搜 Full-Stack 有很多图示,其中大多数长成下面这样子:

full-stack

这个理解是建立在业务功能实现层面的,好像有了前端 + 后端 + 数据库,基本业务就能做出来了。而实际上真实情况往往与之相差甚远!真正能够支撑业务的 Full-Stack 架构,至少分为四层。

  • 第一层,是核心业务逻辑,前、后端功能、API、数据;
  • 第二层,是业务架构,具体包括应用框架、技术架构、数据库等;
  • 第三层:是业务运维,包括日志、监控告警、扩展性、负载均衡等;
  • 第四层:是底层架构,包括计算资源、系统及网络安全、灾备等。

四层

越往上层,对业务价值的驱动力更高,因为聚焦业务逻辑;而越往底层,往往技术难度越大,对于人员的技术能力要求越高。继续分析,我们就可以的发现:

  • 第一层:全栈工程师们想做的东西
  • 第二层到第四层:Serverless 可以解决的问题

在 Serverless 的赋能下,前端工程师依旧只需要关注核心的业务逻辑,而底层的技术架构、计算资源、稳定性、系统运维工作,则可以完全由 Serverless 进行支撑。即实现了从前端到真全栈的可能。这也就回答了我们的主题,Serverless 为何与前端有不解之缘。

Serverless 前端工程化的基本思路

当今的前端研发,组件化、工程化都有比较好的解决方案。那么我们要问的是,对于 Serverless 开发有没有比较好的解决方案呢?那么我们到底要不要用一个框架?前端开发者最喜欢用框架了。因为框架能解决很多问题:代码重用、统一规范、降低门槛、专注业务逻辑、社区优势、易于维护、提升效率…… 好处多的犹如一段相声贯口。

那么一个好的 Serverless 框架应该是什么样子? 我觉得需要满足两个要求。

Serverless 框架

  • 组件化

利用组件机制,以业务功能为单元,进行代码的组织和管理,可以在业务内部、跨业务或跨公司进行重复使用,达到易于维护、提升效率的目的,好处很多,不在赘述。

  • 标准化

对于开发者提供一套标准的接口和使用方式,屏蔽底层云的异构系统之间的差异。就好比前端工程师熟悉的 JQuery 或者 Polyfill,它们不用关注浏览器的差异,直接用就完了。Serverless 的框架也应该做到这点。

Serverless 的原理与实现

架构图

Serverless Framework 就是这样的一款标准化、组件化的框架。在底层,提供了针对开发者的基础支持,包括开发、部署、调试、监控,这些支持针对云厂商接口进行了封装,开发者完全不用关注云计算平台的差异;在上层,每一个业务场景、业务框架都以组件化的方式进行封装,以更好的进行维护和复用。

Serverless Framework 是一个拥有 34.5K star 的开源框架:https://github.com/serverless/serverless

Serverless Framework 的 CLI 就叫「serverless」,以命令行的形式提供了全部功能。

cli

Serverless Framework 有一个很重要的机制就是 Component 机制。

Component机制

每个 component 都是一个 NPM 模块。它使用一个 YML 的配置文件,用来描述该 component 如何使用和分配云平台上面的资源。上图是一个 Express Component 的架构图,它由包括了 Tencent API gateway、Tencent SCF 和 Tencent PostgreSQL。

serverless.js

Component 代码结构非常清晰,遵循 NPM module 标准。一个非常值得提起的特性 —— 组件支持嵌套使用。例如一个 Serverless Full-Stack Application 包括了 Express Component 用于处理服务端逻辑,还包括一个 Website Component 组件用于管理静态文件和资源。而这两个组件又分别包括了他们的子组件。

组件结构

Serverless Now

理解完 Serverless Framework 的基础结构之后,我今天要给大家展示一个 Servereless Hexo 博客的 demo,让大家对 Serverless Framework 有一些感觉。这个 demo 是团队一个 MM 做的。她不是学计算机的,也没有任何代码经验,没写过前端 JavaScript,我们需要让她来用 Serverless Framework 和 Website 组件完成一个静态博客的部署。

这个三分钟的 video demo, 不仅是完成了 Hexo 发布代码的上传,还包括了以下云资源的申请和配置。这说明我们的产品是非常有弹性的。所谓技术产品的弹性,就是可选配置特别多,但是默认必填项特别少。如果你富有经验,技术功底很深,让你自由的去编写每一个配置,以达到你想要的效果;反之,如果你跟这位 MM 一样是一名初学者,你也可以快速上手,再几分钟内用起来。

website

除了 Website 组件,下面整个图中都是 Serverless Framework 现在已经支持的组件,包括了 Node、Python、PHP 语言的各种框架。

组件支持

如果你对 Serverless Express 感兴趣可以关注这个 Github 网址:

https://github.com/serverless-components/tencent-express

如果你已经有一个 Express 的项目,你现在就可以利用 Serverless framework 将它部署上云,具体的操作步骤也可以访问上面的 Github.

  • 第一步,通过 npm 安装 serverless;

Step1

  • 第二步,安装 Express,然后创建 app.js 文件;

Step2

  • 第三步,配置 serverless.yml,最简单的配置如左图,仅有四行代码(右边是可选配置项);

Step3

  • 第四步,微信扫描二维码进行授权注册或登陆,然后执行 sls 命令(serverless 简写)进行部署;

Step3

  • 第五步,使用 remove 删掉这个项目,同时清理云资源。

Step5

对于前端开发者来讲,你甚至不需要了解什么是云,做了哪些事情。这一切都有 Serverless framework 给你做好了。除了 Express.js,Koa 和 Eggjs 同样由社区开发者贡献支持。

koa

总结

本文主要分为四点:

  • 前端和 Serverless 的确是不解之缘,只有 Serverless 能够真正让一个前端工程师去挑大梁,Full-Stack 完成一个产品;
  • Serverless 前端工程化的基本思路,直接在云厂商的云函数上自己去做,还是基于现有的 Serverless Framework;
  • 讲了一些 Serverless Framework 的原理,包括底层以标准化方式对云厂商接口的支撑,上层是利用 Serverless 的组件化,进行业务复用,提升效率;
  • 最后演示了一位从未学过编程的女生的第一个 Serverless Demo。

合照

结束之前展示一张照片,最右边是《Serverless 架构》的作者刘宇,中间是 Austen Collins,他是 Serverless.com 的 CEO 和 Founder,也是 Serverless Framework 的作者。

我希望用他一段话来结束今天的演讲:Serverless 是云的未来。Serverless 就是我们开发者的一个非常有利的力量,我们相信未来 Serverless 一定能够赋能开发者。 尤其对端开发者而言,从前端工程师的角色升级为全栈工程师,独立完成整个应用的从 0 到 1。

传送门:

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

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

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 应用的开发!