立即领取|华润集团、宁德核电、东风岚图等 20+ 标杆企业数字化人才培养实践案例 了解详情
写点什么

腾讯云 Serverless 技术演进

  • 2019-09-02
  • 本文字数:7353 字

    阅读完需:约 24 分钟

腾讯云 Serverless 技术演进

目录

Serverless 是一项新技术,可能有朋友不是很熟悉。所以我们先介绍下 Serverless 的概念和发展历史,接着介绍腾讯云 Serverless 从 1.0 到 2.0 的技术演进,以及我们如何支持 Serverless 这种技术的,也就是技术生态。最后再介绍下 Serverless 的应用场景和具体的应用案例。

Serverless:云计算新趋势

这是 Serverless 目前的发展情况。



最近几年,微服务和 k8s 很火。上图可以看到 Serverless 跟他们的热度对比,其中蓝色曲线是 Serverless 的热度曲线图。从 2016 年开始,Serverless 的热度是要大于微服务和 k8s 的。


Serverless 最初在 2010 年被提出,2014 年 AWS 推出了 lambda 服务,把 Serverless 产品化,并收到了很好的效果,微软、Google 和 IBM 看到后,也分别在 2016 年推出了自己的 Serverless 产品:Azure function、GCP 和 OpenWisk。阿里云和腾讯云也分别在 2017 年推出了自己的 Serverless 产品,腾讯云要早阿里云一天推出。


在 2018 年,我们联合微信,推出了基于 Serverless 的产品小程序云开发,用来协助用户快速的开发小程序。在 2019 年,我们推出了 Serverless 2.0 产品,后面会介绍 Serverless 2.0 和 Serverless1.0 在技术形态及计算资源上的区别。

什么是 Serverless

Serverless 直译过来就是无服务器,无服务器并不代表 Serverless 真的不需要服务器,只不过服务器的管理以及资源分配部分对用户不可见,由平台开发商维护,用户只需要关注业务逻辑的开发即可。Serverless 不是具体的一个编程框架、类库或者工具,它是一种软件系统架构思想和方法。它的核心思想是用户无须关注支撑应用服务运行的底层资源,比如:CPU、内存和数据库等,只需要关注自己的业务开发即可。


那么 Serverless 为什么这么火?


从云计算的发展阶段说起,一开始是 On-Premise 层,接着是 IaaS 层,之后再到 PaaS 层。最后是 FaaS 层,Serverless 就是在这一层。



在软件研发领域,绕不开的 2 个环节是软件的部署和运维。如果我们要上线一个业务,在 On-Premise 阶段,需要购买物理服务器,可能还需要自建机房、安装制冷设备、招聘运维人员,然后再在上面搭建一系列的基础设施,比如:虚拟化、操作系统、容器、Runtime,Runtime 可以理解为像 Python、golang、Node.js 这类软件。接下来我们要去安装软件类的开发框架。最后,我们才会去编写我们真正需要的业务函数。


到了 IaaS 层这一阶段,云厂商维护了硬件和虚拟化这 2 个基础设施,到了 PaaS 层云厂商又维护了 OS、容器和 Runtime,然后到了 FaaS 这个阶段,用户只需要关注 Function,也就是只需要关注自己的业务逻辑。可以看到随着阶段的演进用户需要关注的点越来越少,越来越聚焦于自己的业务逻辑。所以在 On-Premise 阶段我们开发一个业务可能需要 8 个人,在 FaaS 阶段,我们只需要 2 个业务,节省的人力可以投入到业务研发这块儿,提高产品的迭代速度,进而提高产品竞争力。


过去十多年,云计算其实是一个「去基础架构」的过程。这个过程可以让用户聚焦于自己真正需要的业务开发上,而不是底层的计算资源上。Serverless 符合云计算发展的方向,是云的终极形态,这种特有的模式使 Serverless 存在潜在的巨大价值。

Serverless 2.0 组件架构

这张图描述了 Serverless 的组件架构。最底层是基础设施层,底层计算资源我们用到了 docker 和轻量化虚拟机技术,其中 docker 是 Serverless 1.0 的计算资源展现形态,轻量化虚拟机是 Serverless 2.0 的计算资源展现形式,相比于 docker,轻量化虚拟机性能得到了非常显著的提升,可以在几毫秒就可以启动一个业务进程。在最底层我们也做了双活,并且对底层资源做了严格的安全保护。



再上一层就是资源管理层,比如说我们有集群监控,监控我们的集群监控状况,如果有集群不可用,会立马安排运维人员去排障。当然了,我们底层是有双活的,当一个集群出故障的时候,我们可以把流量切换到另一个集群,用户是无感知的,也不会影响用户的请求。这一层我们有专门的自动扩缩容算法,来应对用户的请求变化。


再往上,我们有认证和授权系统,通过认证和授权来保证函数的安全。最上面就是接入层,接入层主要用来触发 Function 的调度和分配。接着往上是架构层,主要用来做一些流程上的调度。最上面这 2 层是用户需要关心的,用户主需要关注自己的业务代码,以及跟数据库,存储等的调用,还有自己使用的一些框架,其它底层的设施用户完全不用关心,全是由云厂商来提供专业的保障和维护。


我们还提供了很多外围的工具系统,来支持用户的研发、部署和排障。比如:DevOps 支持,日志、监控、告警支持。后面会有介绍。

Serverless 2.0 技术形态

如图,左边是 Serverless 1.0 的技术形态,右边这部分是 Serverless 2.0 的技术形态。1.0 的时候,只有 event function,event function 是基于事件驱动型的,大概意思就是外界触发一个事件给 Serverless 平台,Serverless 平台收到触发事件后会调用函数并传入触发事件数据和参数信息,函数内部做业务逻辑处理之后返回给调用方。event function 可以对接多种云上的产品,比如:api 网关、ckafka、cmq、cos 等。



event function 是一种开发模式,要求业务将业务逻辑拆分成 function 这种粒度,这种方式国外接受程度比较高,但是国内很多用户都还停留在 HTTP 这个阶段,为了能够方便现有的业务迁移到 Serverless 平台,适配现有业务的调用方式以及扩展 serverless 的使用场景,我们又开发了 2 个新的技术形态,http function 和 http service。


http function 这种形态可以理解为通过 HTTP 请求来触发函数的运行,通过 HTTP Request 传递参数,通过 HTTP Response 来返回参数。同时在创建 HTTP Function 的时候会自动生成外网域名,供用户直接调用。


event function 和 HTTP Function 都是只有在请求的时候才会调用,函数完成之后便不再运行,也就是不再占用资源,换句话说不用再为这些资源付费,后面会有一页 PPT 介绍,serverless 是如何节省资源,以及跟 CVM 比 Serverless 这个技术的价格优势在哪里。


接着介绍一下 HTTP Service,Service 这种形态可以理解为我们通常意义上的 HTTP 服务,简单理解就是把 HTTP 服务的运行环境从物理机或者虚拟机或者容器换成 Serverless 计算资源。这种形态服务进程常驻,不限制运行时间,因为服务进程常驻,所以它一直在监听请求,所以请求延时更低。因为 service 这种形态,跟我们现在的服务运行方式是一致的,所以业务可以无缝迁移到 Serverless 平台上,不需要做过多的改造。同时在用户创建 service 之后平台会自动创建一个外网域名供调用。


3 种形态各有使用场景。比如:event function 适合基于事件触发型的请求,比如:cos, ckafka, cmq, api 网关,也适合用完即走的请求。http function 适合期望函数以 http 请求的方式调用的场景,http service 适合期望服务以 HTTP 服务持久监听请求的场景。


到 2.0 的时候我们跟友商已经形成了一个差异,像 AWS 和阿里的 FaaS 还停留在这个阶段,这边业界有个比较好的产品叫 Google Cloud Run。所以我们跟其他友商的优势是他们是割裂开的 2 款产品,我们把他放到同一个入口了,更方便用户去使用。

Serverless 2.0 运行过程

这两种技术形态,又是如何支持用户请求的呢?



如果一个用户想用云函数,首先要在本地做开业务开发,目前用的比较多的是 VS Code IDE,当研发把代码和依赖编码完成后通过我们提供的 VS Code 插件可以很方便的把代码部署到我们的平台上,或者通过我们提供的 SCF 命令行工具,也可以很方便的把代码部署到云端,也可以通过我们的控制台进行代码提交。这是我们的云函数平台,分为 function 和 service 2 种形态。因为他是一个完整的业务逻辑,势必会用到像数据库,对象存储这些服务,云函数已经把相关产品的 sdk 内置到我们的 runtime 中了,用户在使用这些后端服务时,直接 import sdk,然后掉 SDK 相关接口即可,用起来会更方便一些。后端的这些服务在 Serverless 中统一称为 BaaS (Backend as a Service)。也就是把像数据库,对象存储等能力统一通过 API 的形式供用户使用,至于这些组件的高可用,扩缩容也不需要用户去关心,用户只需要去使用即可。


用户把业务逻辑部署完成之后,可以通过终端去发起请求,比如浏览器、安卓或者 IOS,Serverless 提供不同的触发方式,比如 HTTP,也就是通过 HTTP 请求来直接触发。通过 COS 触发,举个简单的例子,用户把一张图片上传到 COS 平台,COS 平台收到用户上传图片的时间后,会去请求配置的云函数,并且传入事件的数据,和用户自定义的数据,业务在云函数中通过解析这些数据和参数完成业务逻辑。


当请求来的时候,我们平台会根据请求量的大小,去自动或缩容。像 Function 这种,我们会瞬时拉取足够的函数实例来满足所有的请求,我们有一个调度层,会根据请求量的大小来判断需要起多少个 function 实例,同时我们也有一套算法,根据用户每天的请求情况,提前创建好一些资源,当用户请求过来时,直接将请求切换到已经创建好的资源上,减少请求延时。像 Service 这种,我们也会根据请求流量动态的做水平扩容,业务无须感知。

Serverless 2.0 技术生态

Serverless 更多的是解决计算资源的按需分配,无须运维,但如果想真正在 Serverless 平台上跑业务,还需要其它系统的支持,来满足业务对开发、运维和排障的需求。我们从开发者工具,DevOps、监控运维 3 个方面,来介绍下我们是如何支持函数的研发、运维和排障的。


开发者工具

首先来介绍下开发工具,为了支持开发者能够方便高效的开发和部署云函数,我们开发了一系列的工具,比如:我们提供 VS Code 插件,通过 VS Code 插件,开发者可以很方便的通过 IDE 直接部署、更新和调试云函数。我们也提供了 Web IDE 来方便用户直接在网页开发代码。此外我们还提供 CLI 工具,通过 CLI 用户可以在终端很方便的通过命令调用完成诸如配置、部署、调试、调用等功能。最后我们还提供 API 接口来满足用户对自动化和定制化的需求。最后我们还提供 SDK 供用户更方便的调用云函数的接口。所以可以看到要将 serverless 产品化,还需要做很多其它工作来支撑 Serverless 这个技术,尤其是工具这块儿。

DevOps 支持

除了开发者工具,我们也提供完善的 DevOps 支持,从最佳实战,到工作流,到工具链,以及产品打通,我们都提供了很多方案和支持。


比如工作流这里,我们支持编码、构建、打包、部署、测试和发布等一系列流程。在工具这里,我们提供了:CLI、应用模型等。产品这里,我们打通了很多产品供用户很方便的跟这些产品进行交互,利用这些产品提供的能力,比如:Git 仓库,API 网关,Serverless DB 等。这个是 DevOps 支持。

日志

日志这里我们支持 2 种日志查询方式,方便用户查看日志。在 scf 控制台上,能够查看函数调用成功与否,各阶段的调用时间,以及用户打印在日志或者标准输出的日志,支持用户按 RequestId 去搜索日志。另外我们还支持用户将日志输出到腾讯云日志服务系统,将日志持久化存储,在日志服务系统中,用户可以根据正则表达式来搜索日志,也可以自定义检索规则,方便下次检索。

监控

我们提供 3 个维度的监控。提供本月调用次数、本月资源量、本月出流量的监控。提供按地域划分的调用次数、运行时间、错误次数、并发个数、受限次数监控,这些监控指标都是用户很关心的指标。另外我们也提供函数级别的监控::调用次数、资源超过限制次数、函数执行超时时间、内存超过限制次数等监控指标。所有这些监控指标都可以在腾讯云监控系统上配置告警。

性能监控

我们还提供一些更高阶的监控,现在在启动开发,大概在 8 月底或者 9 月初的时候会发布。我们会提供函数与函数之间的调用链追踪,展示每个调用节点函数的执行情况、函数执行的性能分析,以及支持对失败函数进行流量重放。所谓的流量重放,就是说,我们会把调用失败的函数放在 DLQ 队列中,用户可以很方便的从 DLQ 队列中重试该失败的函数,方便用户 Debug。

计费模型

之前有提到过,我们会有一页 PPT 来专门分析下 Serverless 下的计费模式和优势。Serverless 平台下的计费按如下 3 个维度进行计费:


  1. 资源使用费用:(资源使用量 - 免费资源额度) X 资源使用单价

  2. 调用次数:(函数调用量 - 免费调用额度) X 调用次数单价

  3. 外网流量费用:外网出流量 X 流量单价


但是这种比较难理解,所以我们一般会跟 CVM 进行对比:如果用户部署业务,需要购买 CVM,可能需要 10 台 CVM,那对计算资源的投入就是这条黄线,相当于计算资源一直在使用这些计算资源。对于云函数来讲,当没有请求的时候是不占用计算资源的,不会产生任何费用,只有请求的时候才占用计算资源,白天会有个波峰,晚上会有个波谷,大部分业务都是这种模式,可以看到这些阴影面积就是云函数的实际使用资源,我们只会对这些阴影面积进行收费。


这个是跟 CVM 的计费对比,当资源使用率小 60% 的时候 serverless 下的费用比 CVM 小很多,一般业务很难达到资源使用率 60%,能达到 30% 就已经很不错了。

Serverless Event Function 应用场景

这里介绍一下应用场景,先介绍下 event function 的应用场景,通过这张图,我们可以看到,云函数可以作为浏览器、APP 和小程序的后端服务。通过我们提供的不同触发器可以支持不同的场景,比如通过 API 网关触发器,可以匹配 websockt 的应用场景,通过 cos/cmq/ckafka 触发器可以支持像:消息处理、流失计算,事件通知这类的应用场景。


Serverless HTTP Service 应用场景:BFF

刚才那个是比较简单的一个 Demo,这个就是一个比较复杂的场景。假设我有一个 APP 应用跨多端的,比如 Android,iOS,Web。如果想写后台的话,我可能要写多个接口,去适配不同的终端。这样如果后端有变更,需要去更改 3 个终端的 API 接口,与此同时,当我们需要对一个字符串进行处理,如限定 140 个字符的时候,我们需要在每一个客户端(Android,iOS,Web)分别实现一遍,这样的代价显然相当大。。现在有一个比较流行的解决方案就是在前后端加一个 BFF 层(Backend For Frontend)将前后端解耦,这里是 BFF 层可以承载的能力比如:身份校验,日志记录,数据组合等。BFF 一般由前端工程师去编写,适配不同的后端当后端有变更的时候,只需要改 BFF 层就可以,不用去更改客户端。BFF 层可以部署成 HTTP Service,也就是可以直接利用我们提供的 HTTP Service 技术形态来部署。通过 BFF,可以让前端工程师变成全栈工程师,开发不用去关注底层的资源。

Serverless 助力微信小程序云开发

这个是小程序云开发了,是腾讯云和微信合作的一个标杆场景。左边是传统模式,首先是小程序前端,后面对应一个后端,这个后端可能是一个 API 服务器,后端又对接了很多其它子系统比如:数据库、存储、负载均衡、网络、容灾等。需要考虑很多因素,但是用云开发,就可以简化成右边这种架构,前端页面,然后到微信后台,微信后台会走专线的形式,将用户的请求转到 Tencent Cloud Base 组件,简称 TCB,TCB 后边挂接了数据库、存储、网络、容灾等系统,后端这些都不需要工程师去考虑,全都有 TCB 进行对接。TCB 相对纯云函数来讲它屏蔽了更多的东西比如:云函数、存储和数据库,做小程序开发会更简单。



接下来我们看下 serverless 的具体落地情况。

Serverless 助力腾讯六大业务线

这里先介绍下腾讯云 serverless 产品在内部的使用情况。目前在腾讯内部已经有大量业务在用,比如微信小程序云开发底层用的是 serverless 做计算资源,企业微信的机器人。QQ 小程序相册,腾讯新闻底层也用到了 serverless 等。


客户案例 - 腾讯地图:100 亿条消息/天

这个是腾讯地图的客户案例,走的是 event function 这种方式。场景是这样的:用户在访问腾讯地图时会产生一些数据库,腾讯地图会将这些数据进行整理并保存到 Hbase 和 ES 上,然后再配上一个 UI 用来查询数据。当用户产生一条数据时,会将这条数据放在 kafka 队列中,kafka 触发后端的云函数,云函数做数据处理之后又将数据放入 kafka 队列中,由另外一个进程从 kafka 队列中取走处理后的数据,放入 ES 和 Hbase 中。

客户案例 - 企业辅导背单词

企业辅导背单词没有用云开发那一套去做这个小程序,是因为他有多端,有 QQ 小程序,有微信小程序。这个是企业背单词的逻辑架构,这边是小程序的功能侧,这边是管理后台,它所有跟后台的交互都是用 API 网关去跟后端的 Function 交互,然后后端的 Function 去跟后端的 BaaS 交互。这个是背单词的的技术架构,小程序端会实现听、读、学习等逻辑,小程序端调用后端的 Function 会去完成鉴权、语音合成、学习记录存储等工作。像语音合成是直接调用 Baa S 层的 AI 接口,学习存储是直接调用 BaaS 层的数据库接口把单词等信息存入数据库的。

客户案例 - 腾讯相册小程序

这个是小程序的案例,去年发布小程序云开发的时候,这个是我们第一家用户,也是调用量最大的,这个小程序是把腾讯相册和 QQ 空间做了打通,在微信端用相册小程序,就可以把原来放在空间的相册、图片下载出来,也可以在手机端去做一些图片的上传和分享等,相册小程序用户量是比较大的,目前的注册用户是 1 个亿,月活 1200 万,如果用传统的形式去实现,他要搭业务集群,域名备案,负载均衡,监控,包括日志,会话管理还有数据库,它全部都要自己搞一套,比较复杂。当时他们选云开发时因为他们人力不够,包括测试、研发人力都不够,就几个前端工程师。用云开发之后,架构就比较简单了,微信端开发完之后,然后到业务集群,业务集群就相当于后端的云函数,去写业务逻辑,最后到数据库,对象存储。


这个小程序最初是一个前端工程师花了 2 周时间写了一个 Beta 版本,基本上就把相册的上传下载分享等逻辑全部写好。

Serverless 带来的用户价值

业务迁移到 serverless 平台可以带来如下价值:


  1. 用户不需要去购买和维护计算资源,并且不需要关注高可用、负载均衡等问题,用户只需要去编写数据处理的业务代码即可

  2. 我们天然的支持了基于 ckafka 的触发器,用户不需要再去实现这一套逻辑,节省了很多工作量

  3. 资源按需分配,只有用户浏览地图的时候才会触发底层资源的分配

  4. 借助于云的能力,我们提供了非常大的资源池,用户不需要去担心后台计算资源的问题


作者介绍


孔令飞,腾讯云 Serverless 产品架构师。


本文转载自公众号 ServerlessCloudNative(ID:ServerlessGo)


原文链接


https://mp.weixin.qq.com/s/LxmvKBfQpV1h5mpX_1y6ew


2019-09-02 08:006324

评论

发布
暂无评论
发现更多内容

从大模型到内容生成,初窥门径的AI新次元

阿里云视频云

云计算 视频云 AIGC

杜绝硬编码,为系统安全保驾护航

尚思卓越

网络安全 硬编码 内嵌账号

软件测试/人工智能丨引领未来:软件测试中的人工智能

测试人

人工智能 软件测试

Vue公共loading升级版(处理并发异步差时响应)

快乐非自愿限量之名

Vue 前端 处理机制

青椒云云桌面系统_企业上云桌面云服务解决方案

青椒云云电脑

云桌面 云桌面解决方案 云桌面系统

EndNote 21更新 最新EndNote 21mac破解版下载 支持MacOS14

iMac小白

2G内存搞定一亿数据的分析引擎

Western Panda

数据库 大数据 开源 数据分析 OLAP

原来 TinyVue 组件库跨框架(Vue2、Vue3、React、Solid)是这样实现的?

OpenTiny社区

开源 Vue 前端 React SOLID

技术分享| anyRTC之RTN网络

anyRTC开发者

音视频 网络 RTC RTN

软件测试/人工智能丨人工智能会取代软件测试工程师吗

测试人

人工智能 软件测试

开源流程设计器的对比与选型

小狗围观科幻

item_search_pro-高级关键字搜索淘宝商品api接口

技术冰糖葫芦

API 文档

Util应用框架基础(七)- 本地缓存

何镇汐

开源 后端 .net core

JNPF开发平台凭什么火?

互联网工科生

低代码 JNPF

bitget钱包VS imtoken 钱包大比拼,全方面对比

大瞿科技

Util应用框架基础(七)- 二级缓存

何镇汐

开源 后端 .net core

使用 LCM LoRA 4 步完成 SDXL 推理

快乐非自愿限量之名

逻辑思维 流程模型

云桌面架构的全面剖析

青椒云云电脑

云桌面 云桌面解决方案 云桌面系统

RTC技术沦陷后,人类或将一夜回到解放前?

X2Rtc

RTC 未来世界 科技趋势

mac电脑音乐创作软件Ableton Live Suite 11中文破解版下载

iMac小白

Java多线程消费消息

不在线第一只蜗牛

Java 多线程 RocketM

Util应用框架开发环境搭建(十)- 安装 Redis

何镇汐

开源 后端 .net core

文心一言 VS 讯飞星火 VS chatgpt (140)-- 算法导论11.4 5题

福大大架构师每日一题

福大大架构师每日一题

这6个复盘模型,你知道几个?让你轻松搞定年终总结

彭宏豪95

个人成长 复盘 年终总结 在线白板 项目复盘

矢量图形编辑软件Sketch for mac完美破解版下载

iMac小白

Util应用框架基础(七)- Redis 缓存

何镇汐

开源 后端 .net core

影视行业如何远程完整快速传输大文件?

镭速

传输大文件

国内外传输大文件有哪些好用又便宜的文件传输工具?

镭速

传输大文件 文件传输工具 国内外传输大文件

Util应用框架基础(七)- 缓存

何镇汐

开源 后端 .net core

最新demo版|如何0-1开发支付宝小程序之如何调试小程序(二)

盐焗代码虾

支付宝小程序 小程序调试 如何调试

Util应用框架基础(七)- API

何镇汐

开源 后端 .net core

腾讯云 Serverless 技术演进_服务革新_孔令飞_InfoQ精选文章