腾讯云Serverless2.0架构精解

点击观看大咖分享

无服务器化后台服务已成为后台服务转型一个炙手可热的方向，相对于传统后台架构有降低运维、资源成本等诸多优点，云函数就是目前应用较为成熟的无服务器架构方案。那么云函数自身后台架构是如何实现的呢？

腾讯云云函数（Serverless Cloud Function， SCF）是腾讯云为企业和广大开发者们提供的无服务器执行环境，您无需购买和管理服务器，而只需使用平台支持的语言编写核心代码并设置代码运行的条件，代码即可在腾讯云基础设施上弹性、安全地运行。

本次腾讯云大学大咖分享《腾讯云Serverless2.0架构精解》邀请了腾讯云高级工程师庞博，以腾讯云云函数SCF为例，讲解云函数架构的实现。

本课程目录：

1、腾讯云云函数功能简介

2、腾讯云云函数架构设计概览

3、腾讯云云函数控制流架构原理详解

4、腾讯云云函数数据流架构原理详解

腾讯云云函数功能简介

腾讯云云函数是腾讯云提供给客户的FAAS（Function As A Service）服务，所提供的是比微服务更加服务碎片化的软件架构范式，可以让研发只需要关心业务代码逻辑的编写，不再需要关注后台的架构和运维，可以将更多时间投入到业务上。

不仅提供了代码的编写，还提供了函数代码版本的管理能力。发布后生成的版本是较为稳定的版本，不可修改，可以在安全的生产环境中使用

为了客户方便使用自己编写的业务逻辑，提供了多种触发方式：API网关、定时触发器、COS、CMQ、CKafka、云函数API。

腾讯云云函数架构设计概览

如何实现一个云函数服务。在前面的演示中，可以看到主要操作有两类：控制流和数据流。

控制流需要调度计算网络存储资源为客户提供服务，数据流是为客户的客户提供触发业务函数的途径。

腾讯云云函数控制流架构原理详解

以创建函数操作为例，创建函数是提供给客户的API接口，如果是同步的，后台需要在同步的接口里对代码进行检查并格式化，存储在相应的位置，还需为客户准备相应的网络资源和计算资源，启动环境，准备接受相应的请求，最后还需在调用的总入口为客户增加数据通用，这样的流程下来，客户在调用的总入口需等待的时间较长，体验差。因此腾讯云云函数控制流是进行异步化操作，当接受到请求时确认任务交付，返回成功，API将任务给到工作流模块，工作流模块会根据请求的数据组装成一个消息，将消息异步投给需要做任务的子资源模块，每个子资源模块在完成了自己的操作后会把任务执行是否成功的结果，以及相应的数据结果交给工作流模块。工作流模块根据回调的结果决定是否进行下一步操作，或是终止该流程。就这样周而复始的工作，完成用户提交的任务。另外，这里多个业务模块进行消息通讯是基于mq消息，并且我们每一个子业务模块的操作都是尽量的原子化。

这样的架构就带来了很多的好处。

• 在事件驱动方面，模块间的调用使用了消息队列，实现了事件驱动的方式。例如连接维持等这种系统开销就会降到比较低。对比一个同步的api，它里面要做很多子业务模块调度。同步的api，他在等子任务模块执行完的时候，其自身也需要维护自己系统的开销，包括内存、链接，而我们消息事件驱动的方式就不是这样。在工作流模块处理完这个消息之后把消息投递给下一模块，就不再维护相应的系统资源，所以就做到了一个系统资源的节省。
• 在可用性方面，多个模块之间做到了完美的解耦，那么单个模块的故障就不会扩散。单个子模块的操作尽量的原子化、幂等化，方便我们去追溯与回放。

在研发效率方面，模块操作原子化，还有一些其他的好处，例如后续开发新的业务能力，就不再需要开发业务子模块，只需要在工作流模块去拼接之前原有的原子操作就可以完成新的开发。

• 在用户体验方面，函数快速交付，服务稳定可靠。

腾讯云云函数数据流架构原理详解

对于数据流最多的诉求就是触发的调用链路延迟要尽量的低。

那么影响调用链路延迟有哪些因素呢

• 链路延迟。
• 冷启动时间。
• 冷启动率。

为了降低掉延迟调用链路应该是越短越好，中间的操作越简单越好。

但由于腾讯云后台架构的复杂性和为了保证客户业务稳定和安全的可靠性，在该基础上我们的后台调用链路还是稍微有点长的。这样才能保证客户业务的安全和稳定，有很多必要的东西。api触发的一个例子，它是最长的一条调用链路。首先请求进来之后，会到达云api层然后请求做一个健全的操作。当健全操作通过之后，会将这一个请求分发给云函数的后台模块。云函数的后台模块会根据入参去检验该函数是否存在以及一些入参是否合法。在这之后，会再做一个技术服务，是为用户设置一个并发限制的能力。之后，会将这个请求分发给集群的链路入口。集群的链路入口选择一个计算资源来执行这个实际的计算操作。整个链路调用就增加了很多的耗时，但用户实际跑的业务函数可能耗时非常低。如果在链路上消耗了很多无谓的耗时。用户体验是十分不好的。

所以为了解决这个问题，我们在整个调用链路上，选择性地增加了业务数据的cache以及链接的饱和能力。在不断的优化后，我们最后能够做到最长吊链路的延迟在12到20毫秒之间，基本可以满足绝大部分的业务场景。另外，还有更多像例如api网关，这种链路较短的触发延迟，其延迟是更低的。

如何解决冷启动时间再调链路中的问题和影响。

首先我们看一下冷启动时间主要关心哪几个核心的问题。

• 计算资源的准备。就是类似于虚拟机的创建、容器的创建。
• 下载代码的时间。当有了一个计算资源后我们还是需要把代码装载进计算资源才能够执行相应的业务逻辑。下载代码的耗时，在较为敏感的场景下也是不可以接受的。
• 部署vpc网络。主要是部署弹性网卡的耗时。

关于如何解决这几个问题。冷启动时间解决方案是轻量级虚拟机、代码缓存、vpc网络的代理。

1、轻量级虚拟机。

轻量级虚拟机其实是我们跑云函数的一个计算资源。计算资源的选择有很多种，比如我们可以选择云主机生产出来的虚拟机，还可以选择容器。但是在资源的选择上，都有一个较大的缺点就是它们的生产时间较长，这就必然带来一个冷启动时间较长的问题，可以高达数秒。在某些产品下，用户是不可以接受的。于是，我们和云主机团队就一起合作研发了轻量级虚拟化的这种计算资源。在这种计算资源的生产过程中，只需要100毫秒或100毫秒以内，就可以生产出来一个计算资源，这样就极大降低了在计算资源生产上对冷启动带来的影响。

2、代码下载时间的优化。

据统计，98%以上的用户代码都是小于100kb。在我们的架构中，一个计算资源的节点是属于同一个用户的，该节点上可以跑用户的多个函数。基于这种场景，我们设计了将用户所有较小的100kb函数，全都缓存来这个单个计算节点上，这样绝大部分的扩容请求不会触发一个代码的下载逻辑，有效降低了代码下载的延迟。

另外，对于后台架构的部署，是以单个地域为单位的，地域的概念就比如说像广州，北京和上海，单个地域下面有多个可用区就比如说广州一广州二广州三。实际单个的计算节点的运行还需要在一个确定的物理位置， 对于新创建的容器，它是没有代码缓存的。这种情况下，就需要远端下载用户的代码。但是，单个地域下我们中心的代码存储又只有一份。这就可能导致跨可用区域的下载延迟较高，所以我们在单个可用区下为该可用区单独设计了一份函数的缓存，进一步降低了跨可用区的延迟。由之前的一到两毫秒优化到了一毫秒之内。

3、vpc网络资源创建的问题。

时间的消耗主要是在用户使用自己的vpc网络来跑他自己的函数这个场景。在较早的时候，我们调研了业界,基本也都是使用了该方式，就是将用户vpc下的弹性网卡插在每一个跑函数的节点上，这种架构的就有一个缺点就是每当有一个用户计算资源节点扩容的时候，都会触发一个弹性网卡的插拔操作。这个操作是十分耗时的，可以耗时超过十秒以上，这个影响对冷启动的时间是非常大的，用户基本是不可接受的。

针对这个问题，我们设计了一套新的方案，在跑云函数的网站下，为用户创建一个网络流量转发的代理。然后用户所有跑函数的资源节点的网络流量都要通过这个代理的转发，我们只需要将这个代理节点插上用户vpc资源的弹性网卡，就可以有效节省在后续扩容计算节点中产生的插拔弹性网卡的时间，而且代理的创建可以为用户预创建，用户基本再也感受不到创建vpc资源给用户带来的冷启动时间。

综合续解决了上面三个问题，我们用户的冷启动时间已经优化了几百毫秒左右。

虽然我们前面说用户冷启动的时间在几百毫秒，但是在某些延迟敏感的业务下，可能几百毫秒还是需要进一步优化的。我们就此设计了一个自动扩缩模块，它会为用户的每一个函数去做一个过去调用趋势的一个分析，做一个实时计算，来预测未来一段时间内，用户可能调用资源使用的走势，通过这种预测我们就会为用户提前扩容好计算的资源，来防止一个冷启动的发生。在这种情况下，据统计，冷启动率可以控制在千分之一左右。

那么今天的讲解就到这里，腾讯云函数的架构优化和演技还是在不断的进行当中的，也欢迎大家和我们进行更多的交流和探讨。

---

问卷

为了给广大开发者提供最实用、最热门前沿、最干货的视频教程，请让我们听到你的需要，感谢您的时间！点击填写 问卷

腾讯云大学是腾讯云旗下面向云生态用户的一站式学习成长平台。腾讯云大学大咖分享每周邀请内部技术大咖，为你提供免费、专业、行业最新技术动态分享。