掌握Serverless：运行原理与组件架构

Posted 2021-04-30 云加社区

| 导语 从行业趋势看，Serverless 是云计算必经的一场革命。2019 年，Serverless 被 Gartner 称为最有潜力的云计算技术发展方向，并被赋予是必然性的发展趋势。Serverless 从底层开始变革计算资源的形态，为软件架构设计与应用服务部署带来了新的设计思路。

为了帮助大家掌握Serverless，我们将推出系列文章，从基础概念入门，到前后台架构设计、应用拓展、最佳实践等多维度，揭开 Serverless 的面纱，带你走进无服务器的世界。欢迎关注“云加社区”公众号，回复关键词“Serverless”，获取系列文章。

前言

中我们已经了解到与 Serverless 相关的基本知识以及 Serverless 所带来的一些优势，本文就不再赘述。 接下来，我们重点探讨下现阶段，开发者在使用 Serverless 时经常遇到的一些问题，以及腾讯云 Serverless，尤其是云函数为此所做出的一些探索。

在过去一年多的时间里，我们和大量的 Serverless 用户做过线上、线下交流，了解他们的业务场景、以及对 Serverless 的看法或者使用上的体验。大部分用户认为 Serverless 会是云计算下一阶段的必然趋势，但不是现在。为什么呢？因为构成 Serverless 架构的云函数虽然有引以为傲的自动扩缩能力，但是糟糕的开发体验、让人畏惧的冷启动、原有业务需要改造等等，均降低了使用者的信心。这也是当前不少用户虽然认可 Serverless 的价值，但是认为很难承载核心业务的原因。

针对这些关键问题，腾讯云在今年 6 月份的上海 KubeCon & CloudNativeCon 上发布了 Serverless 2.0，全面升级了产品形态、系统调度以及开发者工具。为了便于大家理解，我们就从云函数的运行原理作为切入点，一步一步解释问题产生的原因以及云函数的应对方法。

FaaS 和 IaaS、PaaS 的区别

首先，我们看一下云函数，或者说 FaaS 和 IaaS、PaaS 的区别。如下图所示，FaaS 不仅给用户提供了标准的 Runtime，同时在应用层，也帮用户管理了请求的调度。开发者只用聚焦在核心业务逻辑开发上，按照函数的粒度去编写代码。而底层硬件相关的资源维护，则交给更加专业的云厂商来搞定。因此，对于用户来讲，则可以把更多的精力和时间放在业务上。而 IaaS 和 PasS，则均需要用户去运维云主机或者容器集群、搭建业务所需的运行环境。

云函数如何解决问题

其次，我们再来看下云函数是怎么构成 Serverless 架构，以及云函数是怎么帮用户做的资源管理和请求调度，在这里也将会回答云函数是怎么解决冷启、降低核心业务迁移复杂度的。 如下图所示，开发者在实际使用时，可以借助 Web IDE 或者本地 IDE 完成代码开发，然后通过在线或者插件、工具的方式把代码以及所用到的相关依赖，一起打包部署到云函数平台，用户可以自行选择部署成函数的形态或者服务的形态。

在代码里，用户需要自己实现业务逻辑，比如访问数据库、对象存储、消息队列、第三方服务接口等。 计算逻辑和后端服务共同构成了所谓的 Serverless 应用架构 。 而终端用户根据平台提供的请求方式，去触发部署在云函数平台上的业务代码，比如发送 http 请求，平台会根据用户的请求量去拉起相应的计算资源去运行用户代码。

这里需要重点解释下，函数形态和服务形态的差异，因为服务的形态可以大大降低复杂业务迁移的成本。

• 服务形态支持直接部署基于框架开发的核心业务，如node.js的express、koa等框架，而不用为了应用Serverless而拆分成函数。平台会帮用户启动服务进程、端口监听，同时服务形态不会限制业务的实际运行时长。

• 函数形态和服务形态在收到用户请求的时候，均能实现自动扩缩。函数形态会针对用户的每个请求都分配一个运行实例，因此所有请求的执行体验是一样的。当没有请求的时候，平台是没有实例在运行的，所以可以做到按需请求，但是这也会造成所谓的冷启动，即当用户的首次请求进入平台的时候，平台会临时拉起资源，而这个过程会消耗一定的时间。为了消除冷启，云函数平台会预先初始化一批不同规格的实例放在资源池中，当用户有请求进入时，可以快速从资源池申请一个实例，直接挂载用户的代码运行，从而降低了资源申请时间。同时，针对函数形态，平台会根据历史并发数据进行预测，帮用户预留一定量的实例，这些实例会预先分配到用户的账号下并且加载好了用户的代码，从而不仅直接消除了冷启，也增加了实例复用几率。

• 而服务形态可以至少帮用户预留一个常驻实例，并且把用户的所有请求都投递到首个实例，根据实例的使用情况，自动的动态扩缩。

• 函数形态更适合新建项目，可以敏捷迭代，业务按照函数的粒度开发，不仅可以轻松实现云上多产品的联动，也可以享受函数的高并发及性能一致体验。服务形态更适合已有项目的迁移、重度复杂业务、需要长时运行的业务。

Serverless 2.0 的组件架构

最后再来看下，Serverless 2.0 的组件架构。如下图所示，用户虽然只用关注绿色部分和业务相关的代码实现，但是平台也需要提供强大的开发者工具来保障开发和使用体验。如云函数推出的 Serverless 本地开发工具、VS Code 插件，和 Coding 联合推出的 WEB IDE、DevOps 平台等，均能很大程度上提升开发、部署效率，实现本次开发、本地调试、联动云端调试、本地部署、版本发布等能力。

同时云函数也完善了配套的监控和告警机制，提供如调用次数、内存使用、并发使用、超时、代码错误等多维度的监控和告警能力。对于基础设施、资源管理、安全、容灾等能力，是云函数平台必备的基础能力，也是开发者关心的核心能力。

Serverless 不仅仅是计算，还需要不断完善周边生态 。 随着用户量的增加，Serverless 必然会面临更多的挑战，怎么帮助用户组织管理代码，怎么解决带状态的业务诉求，怎么实现数据库连接数管理，怎么实现应用级部署等等。 我们也在不断探索和优化用户的使用体验，计划提供诸如 Serverless DB、性能监控、日志分析、Serverless 框架、函数编排、高性能调用等功能。 后续的文章也会陆续推出更多的核心能力解读，帮助开发者更好的理解和使用 Serverless。

---------下方更多精彩----------

活动推荐

点击阅读原文即可免费报名

关注云加社区，回复 3 加读者群

点 在看，让更多人看到！