腾讯云Serverless2.0架构精解

 点击观看大咖分享api

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

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

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

本课程目录：网络

一、腾讯云云函数功能简介架构

二、腾讯云云函数架构设计概览并发

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

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

腾讯云云函数功能简介

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

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

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

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

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

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

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

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

这样的架构就带来了不少的好处。

• 在事件驱动方面，模块间的调用使用了消息队列，实现了事件驱动的方式。例如链接维持等这种系统开销就会降到比较低。对比一个同步的api，它里面要作不少子业务模块调度。同步的api，他在等子任务模块执行完的时候，其自身也须要维护本身系统的开销，包括内存、连接，而咱们消息事件驱动的方式就不是这样。在工做流模块处理完这个消息以后把消息投递给下一模块，就再也不维护相应的系统资源，因此就作到了一个系统资源的节省。
• 在可用性方面，多个模块之间作到了完美的解耦，那么单个模块的故障就不会扩散。单个子模块的操做尽可能的原子化、幂等化，方便咱们去追溯与回放。 在研发效率方面，模块操做原子化，还有一些其余的好处，例如后续开发新的业务能力，就再也不须要开发业务子模块，只须要在工做流模块去拼接以前原有的原子操做就能够完成新的开发。
• 在用户体验方面，函数快速交付，服务稳定可靠。

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

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

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

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

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

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

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

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

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

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

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

一、轻量级虚拟机。

轻量级虚拟机实际上是咱们跑云函数的一个计算资源。计算资源的选择有不少种，好比咱们能够选择云主机生产出来的虚拟机，还能够选择容器。可是在资源的选择上，都有一个较大的缺点就是它们的生产时间较长，这就必然带来一个冷启动时间较长的问题，能够高达数秒。在某些产品下，用户是不能够接受的。因而，咱们和云主机团队就一块儿合做研发了轻量级虚拟化的这种计算资源。在这种计算资源的生产过程当中，只须要100毫秒或100毫秒之内，就能够生产出来一个计算资源，这样就极大下降了在计算资源生产上对冷启动带来的影响。

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

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

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

三、vpc网络资源建立的问题。

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

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

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

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

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

问卷

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

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