一讲了解Serverless,以腾讯地图、微信小程序为例


Serverless从去年开始尤其是最近特别火,因为确实能够解决我们的一些业务问题。我会借助腾讯云Serverless产品,来介绍下腾讯云是如何落地Serverless技术,以及Serverless技术所适用的场景,最后会介绍一些客户案例。

Serverless 简介

pic1.jpg


在左边这张图上,蓝色的是Serverless,在2016年它的热度已经超过微服务和Kubernetes。右边展示的是Serverless产品化的情况。比如,2014年的时候,AWS首先推出了Lambda,2016年微软、Google、IBM都分别出了自己的产品。国内来说,17年国内厂商腾讯云推出了Tencent Cloud SCF,阿里云也推出了自己的Serverless产品。18年腾讯云联合微信,推出了微信小程序云开发的产品TCB,19年,腾讯云推出了Serverless 2.0产品TSF Serverless,支持新的应用场景。

什么是 Serverless?

pic2.jpg


Serverless无服务器,不代表真的不需要服务器,只不过服务器由云厂商维护。它是一种软件系统架构思想和方法,不是软件框架、类库或者工具。它的核心思想是,无须关注底层资源,比如:CPU、内存和数据库等,只需关注业务开发。

我们从另一个角度来看下 serverless 技术为什么这么火。

这张图的前三列大家应该可以看到这 3 列代表了云计算的发展阶段,从刚开始的 On-Premise 到 IaaS 层,再到 PaaS 层。第四列 FaaS 层,serverless就在这一层。

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

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

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

Serverless技术形态

这里介绍下Serverless的技术形态。目前腾讯云Serverless一共有3种技术形态。

pic3.jpg


一种是Cloud Function,Serverless Cloud Function 是基于事件驱动型的,大概意思就是外界触发一个事件给 Serverless 平台,Serverless 平台收到触发事件后,会调用函数并传入触发事件数据和参数信息,函数内部做业务逻辑处理之后返回给调用方。Serverless Cloud Function 可以对接多种云上的产品,比如:api网关、ckafka、cmq、COS对象存储等。

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

TSF Serverless,Service 这种形态可以理解为我们通常意义上的 HTTP 服务,简单理解就是把 HTTP 服务的运行环境从物理机或者虚拟机或者容器换成 serverless 计算资源。这种形态服务进程常驻,不限制运行时间,因为服务进程常驻,所以它一直在监听请求,所以请求延时更低,同时也支持长连接和一定的内场共享能力。因为 service 这种形态,跟我们现在的服务运行方式是一致的,所以业务可以无缝迁移到serverless 平台上,不需要做过多的改造。同时TSF Serverless支持Spring Cloud这种微服务框架,也支持Service Mesh这种服务形态。

还有一种就是Tencent Cloud Base这种形态,这种形态是我们联合微信团队推出,简化小程序开发流程,里面封装了很多功能,比如:云函数,对象存储,数据库,方便用户开发小程序。这也是云函数的一个典型应用场景,通过封装云函数,提供一些PaaS能力。

Serverless Cloud Function 组件架构

Cloud Function 组件架构

pic4.jpg


这里介绍一下Cloud Function的组件架构,让大家了解下,我们底层都做了哪些工作,来实现serverless这门技术。这张图描述了 serverless 的组件架构。最底层是基础设施层,底层计算资源我们用到了 docker 和轻量化虚拟机技术,其中 docker 是 serverless1.0 的计算资源展现形态,轻量化虚拟机是serverless2.0 的计算资源展现形式,相比于 docker,轻量化虚拟机性能得到了非常显著的提升,可以在几毫秒就可以启动一个业务进程。在最底层我们也做了双活,并且对底层资源做了严格的安全保护。

再上一层就是资源管理层,比如说我们有集群监控,监控我们的集群监控状况,如果有集群不可用,会立马安排运维人员去排障,当然了,我们刚说过我们底层是有双活的,当一个集群出故障的时候,我们可以把流量切换到另一个集群,用户是无感知的,也不会影响用户的请求。这一层我们有专门的自动扩缩容算法,来应对用户的请求变化。再往上,我们有认证和授权系统,通过认证和授权来保证函数的安全。再上面就是接入层,接入层主要用来触发 Function 的调度和执行。在往上就是架构层,主要用来做一些流程上的调度。最上面这2 层是用户需要关心的,用户主需要关注自己的业务代码,以及跟数据库,存储等的调用,还有自己使用的一些框架,其它底层的设施用户完全不用关心,全是由云厂商来提供专业的保障和维护。

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

运维工具建设

pic5.jpg


刚才讲了Serverless是如何支持函数的运行,其实就是讲了计算资源。但是要真正使用Serverless这个技术,光有计算资源还不行,还要有其它工具来支持Serverlss的开发和运维。接下来我从开发者工具,CI/CD,日志,监控告警来介绍下腾讯云是如何支持serverless的。

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

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

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

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

Serverless Cloud Function 应用场景

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

Serverless Cloud Function 客户案例

pic7.jpg


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

Tencent Cloud Base

pic8.jpg


下面介绍一下TCB。做小程序开发时,要有一个小程序前端,也需要有后端,写后端时,需要处理很多后端需要的组件或者功能,比如数据库、存储或者CDN等等,都需要研发工程师自己去给产品写接口、做调用,工作量非常大,这时候可以通过TCB来解决,TCB就会变成右边这样。前端仍然有一个小程序的前端,中间We-Chat Backed主要用来做授权,当授权通过后,会把请求转发到TCB组件,这个组件会提供很多SDK,提供的SDK里面封装了很多功能,比如数据库、对象存储以及云函数,直接通过TCB的SDK调用,这样就不需要处理后端那么多组件,让用户非常方便的去开发一个小程序。

TSF Serverless

pic9.jpg


这里介绍一下TSF Serverless,TSF是腾讯云的微服务产品,这个产品底层之前是支持基于虚拟机和基于容器部署应用,我们又增加了基于Serverless第三种部署方式。基于Serverless的话,用户不需要去关注底层资源,只需要去部署容器就可以了。

这个是它的组件架构,最底层是Serverless计算托管的一些功能,比如集群管理容器,这是Serverless底层的一些计算的展现形式。再上一层微服务部署框架,这个部署可以原生支持一些微服务功能,比如服务注册、服务发现以及服务限流、服务熔断、动态配置、服务监控、负载均衡、服务容错、服务审计等等。

TSF Serverless 应用场景

这里介绍下TSF Serverless其中的一个典型场景。假设我有一个 APP 应用跨多端的,比如 Android,iOS,Web。如果想写后台的话,我可能要写多个接口,去适配不同的终端。这样如果后端有变更,需要去更改 3 个终端的 API 接口,与此同时,当我们需要对一个字符串进行处理,如限定 140 个字符的时候,我们需要在每一个客户端(Android,iOS,Web)分别实现一遍,这样的代价显然相当大。

现在有一个比较流行的解决方案就是在前后端加一个 BFF 层(Backend For Frontend)将前后端解耦,这里是 BFF 层可以承载的能力比如:身份校验,日志记录,数据组合等。BFF 一般由前端工程师去编写,适配不同的后端当后端有变更的时候,只需要改 BFF 层就可以,不用去更改客户端。BFF 层可以部署成 HTTP Service,也就是可以直接利用我们提供的 HTTP Service 技术形态来部署。通过 BFF,可以让前端工程师变成全栈工程师,开发不用去关注底层的资源。因为BFF一般是HTTP服务,所以TSF Serverless就很适合这个场景。
pic6.jpg

0 个评论

要回复文章请先登录注册