阅读 630

以微信小程序相册为例,看Serverless DevOps最佳实践

近日,云+社区技术沙龙“高效智能运维”圆满落幕。本期沙龙围绕运维展开了一场技术盛宴,从AIOps、Serverless DevOps、蓝鲸PaaS平台、K8S等分享关于业务运维的技术实践干货,同时带来腾讯海量业务自研上云实践,推动传统运维向云运维转型。本文是孔令飞老师关于腾讯云 Serverless 的运维能力,Serverless 对运维的影响,微信小程序相册的运维案例等内容的分享。本文首发于「云加社区」公众号

一、前言:在互联网时代我们的核心诉求是什么?

在开始讲之前,先来看下,在互联网时代我们的核心诉求是什么?——我们的核心诉求是应用,能够提供业务能力的应用。

如下图所示,为了能让应用对外提供服务,我们还需要能在某个地方部署应用,需要一系列的系统资源,比如计算、网络、存储、数据库等;等应用部署起来之后,我们还要更新应用、监控应用的运行状态等,这几个维度基本涵盖了我们的所有需求。

为了满足这些需求,在应用层面,我们引入了软件架构,比如单体架构和微服务开发框架。借助 Doker、KVM 等来提供系统资源。借助 EFK、Promethus、Coding 来实现应用生命周期管理。随着这些组件的引入,我们需要花费人力来对这些资源进行运维。底层的系统资源我们需要系统运维、虽然 EFK,Promethus 组件可以提供业务运维能力,但我们也需要对这些平台进行运维。其实我们真正需要的运维是业务运维。

那么有没有一种手段,让我们尽可能少或者不进行系统系统和平台运维呢?答案是有的,我们可以采用 Serverless 的技术方案。本次分享,我会借助腾讯云 Serverless 产品,来说明 Serverless 技术是如何淡化用户的平台运维和系统运维的。

本次分享将从以下几方面讲解:

什么是 Serverless

Serverless 的业务运维能力

Serverless 与 IaaS 层运维能力对比

微信小程序相册是如何在 Serverless 技术下做运维

二、Serverless 介绍

Serverless:云计算新趋势

在讲什么是 Serverless 之前,我想先给大家展示下 Serverless 目前有多火。

最近几年微服务和 k8s 很火,这是一张 Serverless 跟他们的热度对比图,蓝色的曲线是 Serverless 的热度曲线图,可以看到从 2016 年开始,Serverless 的热度是要大于微服务和 k8s 的。右边这张图展示了 Serverless 产品化落地情况。,Serverless 最初是在 2010 年被提出,2014 年 aws 推出了 lambda 服务,把 Serverless 产品化,并收到了很好的效果,微软、google 和 IBM 看到后,也分别在 2016 年推出了自己的 Serverless 产品。阿里云和腾讯云也分别在 2017 年推出了自己的 Serverless 产品。

2. 什么是 Serverless?

这里介绍下什么是 Serverless。这是一张逻辑架构图,最上面是我们的 application,下面是系统资源。我们可以通过虚拟机、容器、数据库、存储等来提供系统资源。同时,我们需要对这些系统资源进行维护,比如:资源申请、环境搭建、容灾、扩缩容等。Serverless 是什么呢,Serverless 就是把底层的这些资源以及对这些资源的运维都交给云厂商来维护、这些资源对业务来说是黑盒的,业务只需要关注自己业务逻辑的开发即可。这种架构思想和方法就是 Serverless。

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

我们把系统资源进行 Serverless 化,这些系统资源大概分为 2 大类,一种是 CaaS:compute as a service 用来提供计算能力,一种是 BaaS:backend as a service,相当于把第三方组件也 Serverless 化,用户也不用去关注第三方组建的搭建和运维,只需要调用 api 去使用即可。所以 Serverless 大概可以理解为:CaaS + BaaS。

3. Physical Machine vs. Virtaul Machine vs. Container vs. Serverless

这里我们通过对比来看下 Serverless 所能提供的价值。在软件研发领域,我们绕不开的 2 个环节是软件的部署和运维。如果我们要上线一个业务,在物理机阶段,我们要去购买物理服务器,然后还可能需要去建自己的机房,安装制冷设备,招聘运维人员,然后在上面搭建一系列的基础设施,比如:虚拟化,操作系统,容器等,有很多工作要去做。到了虚拟机这一阶段,云厂商维护了硬件和虚拟化这 2 个基础设施,到了容器这一阶段云厂商又维护了 OS、容器和 Runtime,可以看到用户需要做的运维工作越来越少。然后到了 Serverless 这个阶段,用户只需要关注 Function,也就是只需要关注自己的业务逻辑。可以看到随着阶段的演进用户需要关注的点越来越少,越来越聚焦于自己的业务逻辑。所以在 物理机阶段我们开发一个业务可能需要 8 个人,在 Serverless 阶段,我们只需要 2 个人,节省了很多人力,我们可以把节省的人力投入到业务研发这块儿,提高产品的迭代速度,进而提高产品的竞争力。

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

4. Serverless 运行示例

前面说的可能比较抽象这里,来举个在腾讯云 Serverless 平台上运行函数的例子。

如果一个用户想用云函数,首先要在本地做业务开发,当研发把函数编码完成后通过我们提供的 VSCode 插件可以很方便的把代码部署到我们的平台上,函数里面可能会调用第三方的 BaaS 服务。接下来,会将该函数绑定各种触发器,比如:API 网关、Ckafka、COS 等。然后我们通过调用 API 网关、往 COS 上传文件等方式,来产生触发事件,进而触发绑定的函数,执行业务逻辑。当请求来的时候,平台会根据请求量的大小,去自动或缩容后端的 Function 实例。可以看到整个过程用户是不需要做任何系统层面的运维工作。

5. Serverless 实战

这里通过一个 video 来看下如何创建和执行云函数。

三、Serverless 业务运维能力

接下来介绍下,腾讯云 Serverless 平台是如何提供开箱即用的业务运维能力。主要通过 4 个方面来介绍:工具建设、DevOps、日志、监控告警。

1.工具建设

腾讯云 Serverless 提供了多个工具来协助研发进行开发和调试、帮助运维更容易的将函数部署上线。国内用户用的比较多的 IDE 是 VS CODE,为此,我们开发了 VS CODE 插件,可以方便开发进行函数的开发和部署。我们也提供 web 版本的 IDE,可以直接在网页上做开发,我们还提供命令行工具,可以使开发直接在 Linux 终端进行开发和运维工作,同时基于命令行工具,还可以对接各种 DevOps 平台或者做一些自动化的工作。

2. DevOps 解决方案

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

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

3. Coding DevOps

这是通过 Coding DevOps 来管理 Serverless 应用 CICD 的几个截图。通过 Coding 的持续集成,可以记录每一个函数应用的构建日志,测试日志。Coding 的制品库可以对函数镜像做集中存储以及做历史版本追溯。最后运维人员可以通过 Coding 部署将函数部署到不同的环境中。

4. 日志

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

5. 监控告警

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

四、 Serverless 系统运维能力

这里来看下 Serverless 提供的系统运维能力。Serverless 底层会为每个用户创建一个 mvm,mvm 是轻量级的虚拟机,提供最强的安全隔离,轻量化虚拟机可以做到毫秒级启动,延时非常低。在 mvm 中创建 docker 容器,然后将用户的函数调度到 docker 容器中执行,通过 docker 进行进程级别的隔离同时通过容器来分配更细力度的资源,从而提高系统资源利用率,降低成本。同时在函数执行时会有一套调度算法,可以实时的根据 CPU、内存、网络 IO、请求量指标来进行扩容。满足用户业务高峰期的请求需求。当用户请求量降下来后,也会定时的进行缩容,释放资源,减少成本。所有这些能力都是云厂商来运维,不需要用户运维,用户只需要关注自己的业务逻辑即可。也就是说用户可以省去系统运维这方面的工作,只需要关注业务运维即可。

五、Serverless 与 IaaS 运维能力对比

这里通过跟 IaaS 层提供的运维能力进行对比,来更直观的体验一下 Serverless 所带来的运维效率的提升。 运维能力对比,主要按 2 个维度来对比: 1. 基本运维能力 2. 核心运维能力

1. 资源创建

(1) IaaS

先说说传统的 IaaS 应用,运维是如何开展的。首先是资源创建的阶段,这一阶段一般开始于开发部门对运维部门发起新应用的上线申请。收到申请后,运维部门一般会,根据需求文档,在各个可用区内,创建一批虚拟机,然后配置好网络,防火墙和路由规则。由于跨部门,就涉及排期的问题,速度并不会很快。

集群创建好后,再安装开发部门声明的软件比如运行时 JDK,服务器 Tomcat。然后运维部门会安装一些运维软件比如监控工具 Prometheus,日志工具 logstash,或者一些其他的软件比如安全软件,全链路追踪软件。

机器安装好后,就需要配置 DevOps 流程线。把机器加入到流水线的各个环境中,比如开发环境,预发环境,如果开发者比较多可能还会有第二套开发环境和第二套预发环境。最后就是生产环境,运维人员,为了高可用和容错,事先会将生产环境分为几个不同的小集群,分别部署在不同的可用区内。至此在运维人员的努力下,快的可能需要几天,比如企业内部有自动化运维平台。慢的可能需要几个星期,全部手动配置,才能把所有的环境给搭建起来。并且 CICD 的工具的部署及维护也需要运维部门花费大量的人力,比如,Jenkins 集群,GitLab 服务器,Chef 服务器等。

并且环境的验收来来回回又可能再花上几天。所以整个流程下来可能需要好几周时间。最后才会进入开发流程。

(2)Serverless

我们来看下 Serverless 技术,是如何提供系统资源的,在介绍 Serverless 的时候我们说到,Serverless 底层的系统资源不需要用户去申请和运维,所以就不需要资源的申请和软件的按照这个阶段,同时 Serverless 平台提供了开箱即可用的 DevOps 功能。在 Serverless 下,用户只需要进行最后一步的开发即可。

可以看到在 Serverless 下,我们不需要创建任何资源,因为无需运维所以可以提高研发效率进而提高产品的竞争力。

2.业务部署

在虚拟机时代,部署一个业务,需要运维介入,同时需要配置操作系统环境、然后再对业务组件进行配置。同时业务运维还需要自己实现蓝绿发布和回滚的逻辑,比较复杂。

在容器时代、部署一个业务也需要运维介入,同时运维需要编写复杂的 yaml 文件,对运维人员有了更多的技能要求。每次部署的时候,还需要修改 yaml 文件,然后执行一堆命令部署业务,虽然要比虚拟机时代要简单很多,但是还是有一定的工作量。

在 Serverless 平台上,只需要开发上传代码,即可完成部署。同时,Serverless 平台已经实现了蓝绿发布和回滚的功能,不需要研发去关注这块儿,把业务部署的复杂度降到最低。

3.监控告警

在传统的应用中,绝大多数的监控都依赖于运维人员来配置,包括网络监控,系统监控,应用监控,和业务监控。但是在 Serverless 应用中,首先应用监控,系统监控,网络监控里面的绝大部分监控,都不需要再关注了,并且平台不会将其暴露出来,暴露出来的会是些更高级别的指标,比如调用次数,运行时间,运行内存,并发执行数,受限次数等。但是业务监控还是需要自行收集,通过捞日志的方式。

4. 故障排查

传统的应用故障排查的手段一般都非常丰富,比如全链路追踪,各类监控等。但是这仅仅限于大公司拥有比较强的技术实力,因为这些故障排查工具集的搭建和维护也是一个耗费人力的过程。在小公司内一般通常只能通过日志和走查代码来排查。

腾讯云 Serverless 平台提供了非常多的故障排查工具。比如全链路追踪功能,各个维度的监控,以及专业的日志查询功能。所以 Serverless 时代故障排查工具也不需要运维人员来搭建了。

5. 弹性扩缩

弹性伸缩是运维一个核心的能力,弹性伸缩大家一般关注的是扩缩时间。在虚拟机阶段,如果资源不够了,需要申请虚拟机,申请完之后需要登陆虚拟机做一些系统级别的配置和部署,一般是小时级。在容器阶段,借助于k8s的弹性扩缩能力,但 k8s 的弹性扩缩容策略一般也只能做到分钟级。但在 Serverless 这个阶段,可以做到实时的毫秒级的扩缩容。

6. 故障恢复

故障恢复是另一个运维需要关注的点。在虚拟机阶段,故障恢复逻辑需要运维实现,如果运维没有一些故障恢复逻辑,出故障后需要运维介入,如果运维手工介入响应会很慢,同时也可能因为认为的一些失误导致业务异常,有风险。在容器阶段,借助 k8s 的自愈能力,可以实现秒级的故障恢复,但是在 Serverless 阶段,因为每次请求都是一个新的实例,所以就不存在故障恢复这一工作。

7. 性能调优

性能调优一直就是个比较高级的问题,需要丰富经验。传统应用的调优一般涉及,虚拟机参数,数据库参数,网络参数,Linux 参数,运行时参数,服务器参数。但是由于 Serverless 应用的特殊性,此类底层参数的调优由云厂商来进行调优。用户只需要进行代码级别的性能调优即可。

8. 安全保障

传统的 IaaS 应用由于技术栈复杂,灵活度很大所以安全需要保障的领域也非常多。比如主机和网络安全,应用安全,访问控制管理,终端安全,数据安全等都需要运维安全人员来关注。 大公司一般会为此保持一个大的安全部门来保障集团的安全。但是小公司如果也要维持这样一个部门,业务就会被极大的拖累,以致于小公司业务的安全非常难保障。比如有些数据库不改密码,或者暴露公网 IP 等,小公司不可能有精力去对这些产品进行充分调研。

但是 Serverless 下,底层资源由云厂商来进行维护,安全性由云厂商提供专业的保障,比如,腾讯云 Serverless 平台会提供网络隔离,执行环境与管理环境隔离,函数资源限制,文件系统目录限制,系统调用也会有限制。可以在提高安全保障的同时,节省这一部分人力。运维安全就主要用户代码的安全维护了。

开发流程

六、案例:微信小程序相册如何在 Serverless 下去做运维

这里举一个微信小程序相册的例子,看一下如何在 Serverless 下去做运维,如果没有 Serverless 的话,我们想开发一个相册小程序,首先要去组件 Team 可能需要N周,然后要注册各种账号,需要几天。接下来我们要做一些跟运维相关的工作,比如:购买域名、购买 CVM、域名备案等,购买完资源之后还需要安装 Nginx、安装 Mysql、安装监控和日志系统等,这块儿大概需要 3 周时间,甚至更多时间。接下来才会进入到真正的业务开发阶段。所以像如果开发一个小程序的话,一般是需要一两个月的时间。

最终上线后,我需要维护…

当我们把小程序开发完成后,还面临各种复杂的运维工作。比如要运维一大堆服务器相关的组件、测试复杂、还要花费很多人力保障安全和稳定性。

只关注核心业务

这张图是 Serverless 下的解决方案,可以看到,云厂商将资源申请和相关组件的部署都 Serverless 化了,这部分运维工作由云厂商来维护,不需要用户关心,用户只需要关注核心业务逻辑开发和数据库相关的 CRUD 即可。大大简化了开发流程和运维工作量。

微信小程序相册在 Serverless 解决方案下,一个同事只花了 2 周时间便完成了核心业务逻辑的开发。

讲师介绍

孔令飞,腾讯云高级架构师,负责腾讯云云函数的产品拓展工作,协助用户一起搭建基于Serverless的系统架构,和产品经理一起完成云函数平台的规划建设。之前在Red Hat和联想做过虚拟化相关的测试和研发工作,有过大规模容器集群的研发和架构经验,对虚拟化、容器等云计算相关技术有深层次的理解。




关注下面的标签,发现更多相似文章
评论