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

Posted 2020-11-25 serverlesscloud

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

Serverless 的优势

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

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

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

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

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

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

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

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

还要说明的是人力成本。很多技术 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 把需求做成产品，那才叫真全栈。如果张全占完成了前端功能开发、后端开发以及数据库开发，实现了所有的需求功能，并且部署到对应的服务上，就完事了，那么问题也就来了：服务挂了谁来重启？环境稳定性谁来做？日志把磁盘写满了谁来清理？定时任务怎么搞？产品突然火爆了，流量一夜间突然扩大了十几倍的时候（产品经理狂喜中），谁负责扩容？这些问题虽然不是核心业务需求，却是每一个线上产品都必须考虑的东西，否则只能称为功能集合，不能称之为产品。

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

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

采用 Serverless 的准备

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

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

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

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

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

最后是一些实施上的准备，以腾讯云函数为例，只要是写过代码的，花小半天时间阅读一些基础文档、教程，或者是跟着 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 的组合，构成了 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 接下来的发展方向。

传送门：

• GitHub: github.com/serverless
• 官网：serverless.com

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