11月9日,腾讯云开发者社区技术沙龙“高效智能运维”圆满落幕。本期沙龙围绕运维展开了一场技术盛宴,从AIOps、Serverless DevOps、蓝鲸PaaS平台、K8S等分享关于业务运维的技术实践干货,同时带来腾讯海量业务自研上云实践,推动传统运维向云运维转型。下面是孔令飞老师关于腾讯云 Serverless 的运维能力,Serverless 对运维的影响,运维的案例等内容的分享。
讲师介绍:孔令飞,腾讯云高级架构师,负责腾讯云云函数的产品拓展工作,协助用户一起搭建基于Serverless的系统架构,和产品经理一起完成云函数平台的规划建设。之前在Red Hat和联想做过虚拟化相关的测试和研发工作,有过大规模容器集群的研发和架构经验,对虚拟化、容器等云计算相关技术有深层次的理解。
在开始讲之前,先来看下,在互联网时代我们的核心诉求是什么?我们的核心诉求是应用,能够提供业务能力的应用,为了能让应用对外提供服务,我们还需要能在某个地方部署应用,我们需要一系列的系统资源,比如计算、网络、存储、数据库等,应用部署起来之后,我们还要更新应用、监控应用的运行状态等。这3个维度基本涵盖了我们的所有需求。为了满足这些需求,在应用层面,我们引入了软件架构,比如单体架构和微服务开发框架。借助 doker,kvm 等来提供系统资源。借助 EFK, Promethus, coding 来实现应用生命周期管理。随着这些组件的引入,我们需要花费人力来对这些资源进行运维。底层的系统资源我们需要系统运维、虽然 EFK,Promethus 组件可以提供业务运维能力,但我们也需要对这些平台进行运维。其实我们真正需要的运维是业务运维,那么有没有一种手段,让我们尽可能少或者不进行系统系统和平台运维呢?答案是有的,我们可以采用 serverless 的技术方案。本次分享,我会借助腾讯云 serverless 产品,来说明 serverless 技术是如何淡化用户的平台运维和系统运维的。
这是这次的分享目录,会先重点介绍下什么是 serverless,然后介绍下腾讯云 serverless 是如何提供业务和系统运维能力的,然后通过跟 IaaS 层运维进行对比,来看下 serverless 下的运维效能提升。最后介绍一个在 serverless 技术下的运维案例。
在讲什么是 serverless 之前,我想先给大家展示下 serverless 目前有多火。
最近几年微服务和 k8s 很火,这是一张 serverless 跟他们的热度对比图,蓝色的曲线是 serverless 的热度曲线图,可以看到从 2016 年开始,serverless 的热度是要大于微服务和 k8s 的。右边这张图展示了 serverless 产品化落地情况。,serverless 最初是在 2010 年被提出,2014 年 aws 推出了 lambda 服务,把 serverless 产品化,并收到了很好的效果,微软、google 和 IBM 看到后,也分别在 2016 年推出了自己的 serverless 产品。阿里云和腾讯云也分别在 2017 年推出了自己的 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。
这里我们通过对比来看下 serverless 所能提供的价值。在软件研发领域,我们绕不开的 2 个环节是软件的部署和运维。如果我们要上线一个业务,在物理机阶段,我们要去购买物理服务器,然后还可能需要去建自己的机房,安装制冷设备,招聘运维人员,然后在上面搭建一系列的基础设施,比如:虚拟化,操作系统,容器等,有很多工作要去做。到了虚拟机这一阶段,云厂商维护了硬件和虚拟化这 2 个基础设施,到了容器这一阶段云厂商又维护了 OS、容器和 Runtime,可以看到用户需要做的运维工作越来越少。然后到了 serverless 这个阶段,用户只需要关注 Function,也就是只需要关注自己的业务逻辑。可以看到随着阶段的演进用户需要关注的点越来越少,越来越聚焦于自己的业务逻辑。所以在 物理机阶段我们开发一个业务可能需要 8 个人,在 serverless 阶段,我们只需要 2 个人,节省了很多人力,我们可以把节省的人力投入到业务研发这块儿,提高产品的迭代速度,进而提高产品的竞争力。
由这张图我们也可以看到,过去十多年云计算其实是一个“去基础架构”的过程。这个过程可以让用户聚焦于自己真正需要的业务开发上,而不是底层的计算资源上。serverless 符合云计算发展的方向,这种特有的模式使 serverless 存在潜在的巨大价值。用一张图来形容下,就是 serverless 可以认为是云计算的终极形态。
前面说的可能比较抽象这里,来举个在腾讯云 serverless 平台上运行函数的例子。
如果一个用户想用云函数,首先要在本地做业务开发,当研发把函数编码完成后通过我们提供的 VSCode 插件可以很方便的把代码部署到我们的平台上,函数里面可能会调用第三方的 BaaS 服务。接下来,会将该函数绑定各种触发器,比如:API 网关、Ckafka、COS 等。然后我们通过调用 API 网关、往 COS 上传文件等方式,来产生触发事件,进而触发绑定的函数,执行业务逻辑。当请求来的时候,平台会根据请求量的大小,去自动或缩容后端的 Function 实例。可以看到整个过程用户是不需要做任何系统层面的运维工作。
这里通过一个 video 来看下如何创建和执行云函数。
接下来介绍下,腾讯云 serverless 平台是如何提供开箱即用的业务运维能力。主要通过 4 个方面来介绍:工具建设、DevOps、日志、监控告警。
腾讯云 serverless 提供了多个工具来协助研发进行开发和调试、帮助运维更容易的将函数部署上线。国内用户用的比较多的 IDE 是 VS CODE,为此,我们开发了 VS CODE 插件,可以方便开发进行函数的开发和部署。我们也提供 web 版本的 IDE,可以直接在网页上做开发,我们还提供命令行工具,可以使开发直接在 Linux 终端进行开发和运维工作,同时基于命令行工具,还可以对接各种 DevOps 平台或者做一些自动化的工作。
除了开发者工具,我们也提供完善的 DevOps 支持,从最佳实战,到工作流,到工具链,以及产品打通,我们都提供了很多方案和支持。
比如工作流这里,我们支持编码、构建、打包、部署、测试和发布等一系列流程。在工具这里,我们提供了:CLI、应用模型等。产品这里,我们打通了很多产品供用户很方便的跟这些产品进行交互,利用这些产品提供的能力,比如: Git 仓库,API 网关 等。这个是 DevOps 支持。
这是通过 Coding DevOps 来管理 serverless 应用 CICD 的几个截图。通过 Coding 的持续集成,可以记录每一个函数应用的构建日志,测试日志。Coding 的制品库可以对函数镜像做集中存储以及做历史版本追溯。最后运维人员可以通过 Coding 部署将函数部署到不同的环境中。
日志这里我们支持 2 种日志查询方式。一种是可以直接在我们的 serverless 平台进行查询,能够查看函数调用成功与否,各阶段的调用时间,以及用户打印在日志或者标准输出的日志,支持用户按 RequestId 去搜索日志。另外我们还支持用户将日志输出到腾讯云日志服务系统,将日志持久化存储,在日志服务系统中,用户可以根据正则表达式来搜索日志,也可以自定义检索规则,方便下次检索,还可以基于日志进行告警。
我们提供 3 个维度的监控。提供本月调用次数、本月资源量、本月出流量的监控。提供按地域划分的调用次数、运行时间、错误次数、并发个数、受限次数监控,这些监控指标都是用户很关心的指标。另外我们也提供函数级别的监控:调用次数、资源超过限制次数、函数执行超时时间、内存超过限制次数等监控指标。所有这些监控指标都可以在腾讯云监控系统上配置告警,提供业务级别的监控能力。
这里来看下 serverless 提供的系统运维能力。serverless 底层会为每个用户创建一个 mvm,mvm 是轻量级的虚拟机,提供最强的安全隔离,轻量化虚拟机可以做到毫秒级启动,延时非常低。在 mvm 中创建 docker 容器,然后将用户的函数调度到 docker 容器中执行,通过 docker 进行进程级别的隔离同时通过容器来分配更细力度的资源,从而提高系统资源利用率,降低成本。同时在函数执行时会有一套调度算法,可以实时的根据 CPU、内存、网络 IO、请求量指标来进行扩容。满足用户业务高峰期的请求需求。当用户请求量降下来后,也会定时的进行缩容,释放资源,减少成本。所有这些能力都是云厂商来运维,不需要用户运维,用户只需要关注自己的业务逻辑即可。也就是说用户可以省去系统运维这方面的工作,只需要关注业务运维即可。
这里通过跟 IaaS 层提供的运维能力进行对比,来更直观的体验一下 serverless 所带来的运维效率的提升。 运维能力对比,主要按 2 个维度来对比: 1. 基本运维能力 2. 核心运维能力
先说说传统的 IaaS 应用,运维是如何开展的。首先是资源创建的阶段,这一阶段一般开始于开发部门对运维部门发起新应用的上线申请。收到申请后,运维部门一般会,根据需求文档,在各个可用区内,创建一批虚拟机,然后配置好网络,防火墙和路由规则。由于跨部门,就涉及排期的问题,速度并不会很快。
集群创建好后,再安装开发部门声明的软件比如运行时 JDK,服务器 Tomcat。然后运维部门会安装一些运维软件比如监控工具 Prometheus,日志工具 logstash,或者一些其他的软件比如安全软件,全链路追踪软件。
机器安装好后,就需要配置 DevOps 流程线。把机器加入到流水线的各个环境中,比如开发环境,预发环境,如果开发者比较多可能还会有第二套开发环境和第二套预发环境。最后就是生产环境,运维人员,为了高可用和容错,事先会将生产环境分为几个不同的小集群,分别部署在不同的可用区内。至此在运维人员的努力下,快的可能需要几天,比如企业内部有自动化运维平台。慢的可能需要几个星期,全部手动配置,才能把所有的环境给搭建起来。并且 CICD 的工具的部署及维护也需要运维部门花费大量的人力,比如,Jenkins 集群,GitLab 服务器,Chef 服务器等。
并且环境的验收来来回回又可能再花上几天。所以整个流程下来可能需要好几周时间。最后才会进入开发流程。
我们来看下 serverless 技术,是如何提供系统资源的,在介绍 serverless 的时候我们说到,serverless 底层的系统资源不需要用户去申请和运维,所以就不需要资源的申请和软件的按照这个阶段,同时 serverless 平台提供了开箱即可用的 DevOps 功能。在 serverless 下,用户只需要进行最后一步的开发即可。
可以看到在 serverless 下,我们不需要创建任何资源,因为无需运维所以可以提高研发效率进而提高产品的竞争力。
在虚拟机时代,部署一个业务,需要运维介入,同时需要配置操作系统环境、然后再对业务组件进行配置。同时业务运维还需要自己实现蓝绿发布和回滚的逻辑,比较复杂。
在容器时代、部署一个业务也需要运维介入,同时运维需要编写复杂的 yaml 文件,对运维人员有了更多的技能要求。每次部署的时候,还需要修改 yaml 文件,然后执行一堆命令部署业务,虽然要比虚拟机时代要简单很多,但是还是有一定的工作量。
在 serverless 平台上,只需要开发上传代码,即可完成部署。同时,serverless 平台已经实现了蓝绿发布和回滚的功能,不需要研发去关注这块儿,把业务部署的复杂度降到最低。
在传统的应用中,绝大多数的监控都依赖于运维人员来配置,包括网络监控,系统监控,应用监控,和业务监控。但是在 serverless 应用中,首先应用监控,系统监控,网络监控里面的绝大部分监控,都不需要再关注了,并且平台不会将其暴露出来,暴露出来的会是些更高级别的指标,比如调用次数,运行时间,运行内存,并发执行数,受限次数等。但是业务监控还是需要自行收集,通过捞日志的方式。
传统的应用故障排查的手段一般都非常丰富,比如全链路追踪,各类监控等。但是这仅仅限于大公司拥有比较强的技术实力,因为这些故障排查工具集的搭建和维护也是一个耗费人力的过程。在小公司内一般通常只能通过日志和走查代码来排查。
腾讯云 serverless 平台提供了非常多的故障排查工具。比如全链路追踪功能,各个维度的监控,以及专业的日志查询功能。所以 serverless 时代故障排查工具也不需要运维人员来搭建了。
弹性伸缩是运维一个核心的能力,弹性伸缩大家一般关注的是扩缩时间。在虚拟机阶段,如果资源不够了,需要申请虚拟机,申请完之后需要登陆虚拟机做一些系统级别的配置和部署,一般是小时级。在容器阶段,借助于k8s的弹性扩缩能力,但 k8s 的弹性扩缩容策略一般也只能做到分钟级。但在 serverless 这个阶段,可以做到实时的毫秒级的扩缩容。
故障恢复是另一个运维需要关注的点。在虚拟机阶段,故障恢复逻辑需要运维实现,如果运维没有一些故障恢复逻辑,出故障后需要运维介入,如果运维手工介入响应会很慢,同时也可能因为认为的一些失误导致业务异常,有风险。在容器阶段,借助 k8s 的自愈能力,可以实现秒级的故障恢复,但是在 serverless 阶段,因为每次请求都是一个新的实例,所以就不存在故障恢复这一工作。
性能调优一直就是个比较高级的问题,需要丰富经验。传统应用的调优一般涉及,虚拟机参数,数据库参数,网络参数,Linux 参数,运行时参数,服务器参数。但是由于 serverless 应用的特殊性,此类底层参数的调优由云厂商来进行调优。用户只需要进行代码级别的性能调优即可。
传统的 IaaS 应用由于技术栈复杂,灵活度很大所以安全需要保障的领域也非常多。比如主机和网络安全,应用安全,访问控制管理,终端安全,数据安全等都需要运维安全人员来关注。 大公司一般会为此保持一个大的安全部门来保障集团的安全。但是小公司如果也要维持这样一个部门,业务就会被极大的拖累,以致于小公司业务的安全非常难保障。比如有些数据库不改密码,或者暴露公网 IP 等,小公司不可能有精力去对这些产品进行充分调研。
但是 serverless 下,底层资源由云厂商来进行维护,安全性由云厂商提供专业的保障,比如,腾讯云 serverless 平台会提供网络隔离,执行环境与管理环境隔离,函数资源限制,文件系统目录限制,系统调用也会有限制。可以在提高安全保障的同时,节省这一部分人力。运维安全就主要用户代码的安全维护了。
这里举一个微信小程序相册的例子,看一下如何在 serverless 下去做运维,如果没有 serverless 的话,我们想开发一个相册小程序,首先要去组件 Team 可能需要N周,然后要注册各种账号,需要几天。接下来我们要做一些跟运维相关的工作,比如:购买域名、购买 CVM、域名备案等,购买完资源之后还需要安装 Nginx、安装 Mysql、安装监控和日志系统等,这块儿大概需要 3 周时间,甚至更多时间。接下来才会进入到真正的业务开发阶段。所以像如果开发一个小程序的话,一般是需要一两个月的时间。
当我们把小程序开发完成后,还面临各种复杂的运维工作。比如要运维一大堆服务器相关的组件、测试复杂、还要花费很多人力保障安全和稳定性。
这张图是 serverless 下的解决方案,可以看到,云厂商将资源申请和相关组件的部署都 serverless 化了,这部分运维工作由云厂商来维护,不需要用户关心,用户只需要关注核心业务逻辑开发和数据库相关的 CRUD 即可。大大简化了开发流程和运维工作量。
微信小程序相册在 serverless 解决方案下,一个同事只花了 2 周时间便完成了核心业务逻辑的开发。
Q:您好,serverless 它可以用来部署微服务吗?
A:其实 serverless 更多指代的是系统资源或者系统资源的 serverless 化,在系统资源上可以部署各类软件框架,比如 Function、单体架构或者微服务架构。针对微服务,我们目前有一个 TSF Serverless 的产品可以提供微服务这种架构的部署。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。