微信邦 发表于 2018-7-16 22:38:23

让业务感知不到服务器的存在——基于弹性计算的无服务器化实践

导读:2018年7月6 - 7日,一年一度的技术圈盛会ArchSummit全球架构师峰会在深圳华侨城洲际酒店举办。100余位国内外技术专家将齐聚深圳,分享各类技术架构最佳实践。来自腾讯技术工程事业群架构平台部的jerome作了主题为《基于弹性计算的无服务器化实践》的分享,以下为现场演讲内容。


据Gartner和麦肯锡统计,全球的服务器CPU平均利用率只有6%到12%。国内阿里,腾讯等大型互联网企业CPU平均利用率均10%出头左右,这里主要是三种原因导致:• 单一业务难以均衡利用各类资源导致99%情况下有资源闲置
• 在线服务的特点决定了有30%的时间段处于低负载
• 服务器流转过程可能造成5%的时间段闲置


理想的情况是像Google那样有公司级borg资源调度平台,各业务基于统一平台构建,共享资源池混搭调度,但基于BG分开运营的历史现状,公司运管联合架平弹性计算及各BG运营部门联合打造的共享算力平台,尝试收集全公司的空闲资源,从现网中挖掘金矿,以docker容器的形式满足计算类的需求。

经过一年的建设,当前已挖掘了约140w核,支持了亿级的视频转码,图片压缩以及腾讯围棋,王者荣耀等游戏AI,手机浏览器等,但当前依然存在许多挑战,比如:
比如业务接入门槛较高,需要业务理解多样变化弹性的资源并做好适配,长尾业务接入困难;另外利用率也不受控,有些有状态的业务利用率跑不高,且没法自动扩缩容;小资源碎片,比如剩下1核1GB这种用不出去;最后平台没法准确监控业务的运行状态和质量,比如请求延时等,总结起来,当前困境根源还是我们只是提供资源层面的服务,而资源要用好确依赖很多业务层面的工作。回顾集群资源管理平台走过的历程,从最开始使用物理机(Nothing-as-Service)到IaaS虚拟机服务,再到PaaS容器服务,其实每一步都在尝试为业务做更多的事情,解放更多的生产力同时提升利用效率,下一步资源管理平台能否直接跳出资源服务层级,让业务只需关系业务逻辑,按需付费便可以了呢?
答案是肯定的,它名字叫serverless,serverless不是指没有服务器,而是指用户无须关注服务器的存在,广义上来讲,现在的SaaS,BaaS,FaaS,PaaS都可以称为serverless,区别是从下到上平台控制力越来越强,从左到右,平台通用性越来越好;但Serverless真正广为人知,是因为以aws lambda为代表的FaaS函数即服务的出现,所以当前狭义上来讲,Serverless一般指FaaS函数即服务,我们今天就用Serverless来指代函数即服务。Serverless正好是解决我们当前问题的答案,业务接入门槛高,用serverelss可以不用关心资源,做到更快业务上线;利用率不受控,用serverless平台可以完全控制资源的分配,利用率不再受制于人;碎片资源用不出去,用serverless可以让业务把计算切成函数更小粒度的函数级别;业务质量难以监控,用serverless我们感知业务的每次调用与返回,知道延时及返回结果。

于是我们基于现有的容器平台构建了serverless云函数平台,主要包括:• 构建函数管理模块来管理函数的配置,包括元数据,代码,权限,触发方式等;
• 构建函数调用模块来分发调用函数,解决负载均衡,故障容灾,扩缩容等问题;
• 构建多语言的运行时环境,代理函数的网络监听请求,运行用户函数代码,监控函数运行过程,收集函数日志等;
• 构建函数触发器等模块,实现云函数事件触发式的自动调用;
新平台的构建有诸多考虑点,比如怎么做到足够的易用,使得业务可以乐于尝试;怎么做到足够的稳定,来留住业务;如何做到比容器平台的成本更加节省,让业务看到实实在在的好处;如何做到更快、更安全、能持续发展等,本文将一一分享。
足够易用的关键在于能否让用户做更少的事情,在开发上,云函数提炼业务逻辑之外的部分代为实现,比如网络数据包收发,负载均衡,扩缩容,故障容灾等,平台把龙画好,只需要业务最后点睛即可上线;在运维上,托管代码包管理,服务器故障处理,服务质量监控及容灾、负载均衡、扩缩容等配置;甚至在应用上,提供文件上传\删除,定时器,主题的消息时等事件触发式自动调用,虽然当前一些微服务平台也在做类似的事情,但依然以容器为维度,容器内部对平台而言是黑盒;云函数参与了容器内部每一次用户请求调用和返回的过程,可以获取更多业务维度的信息,使得在资源调度和质量控制上可以更加的精准。
对比传统的分布式系统,云函数平台要做到足够稳定还需要解决好函数调用流的问题,最简单的调用流程是从云api进来,走invoker做分发,再到计算节点执行,在同步调用一来一回的场景这样没问题,因为同步调用失败时业务可以自行重试;但异步调用时不会返回调用结果给用户,请求丢了用户感知不到,所以需要有持久化方式保存所有的异步调用,以免丢失;另异步调用业务无法自行重试,当平台自动重试依然失败时,需持久化保存便于问题追溯;重试本身也需要谨慎的设计,因为资源是调用请求到来时实时分配,重试可能会造成后台资源成倍增加,且在某些流式计算场景,计算有严格的时序要求,重试的时候还需要阻塞整个流的计算等。稳定性最常见的挑战是热更新能力,而Serverless云函数平台天生支持热更新,因为能获知业务的每次请求和返回,且能控制业务请求的分发过程,做热更新,其实就是简单的禁掉节点,等待请求结束,更新后再重新启用节点。

云函数平台要比容器平台做到更低成本,需要尽量避免闲置及无效浪费的资源,在传统的业务架构下,一个业务模块最少需要1个实例,如果要容灾,至少需要2个;而云函数平台被设计为调用时实时分配资源,业务模块最小实例数可以缩减到0,无负载时不保留资源,收到业务请求时再实时分配资源;业务申请资源时,会按照峰值指定cpu核心数,内存大小,磁盘容量,网络带宽等一系列资源参数,但绝大多数情况下用不完,所以云函数平台一般只让用户配置内存大小,因为内存是不可压缩资源,少了程序跑不起来,而对于cpu,带宽等可压缩资源,都由平台方根据内存大小及实际所需来配置且动态调整,以避免由于业务过量申请资源造成的浪费;另外云函数有一个特殊点是支持事件触发执行,但触发配置不当可能造成无效循环造成资源浪费,比如配置文件上传时执行某函数,但函数内又上传了文件形成循环触发,所以云函数会监控函数调用流,发现无效循环,避免资源浪费。

由于云函数的资源是收到请求后实时分配并初始化的,而用户能容忍的等待时间一般不超过3s,故第一次请求的冷启动的时间要足够的快,而函数的初始化需要做很多的事情:先要申请资源,确定位置后要下载镜像,下载函数代码,启动容器,初始化函数后才能执行函数,返回结果。其中镜像下载的时间一般都超过3s,所以我们用了很多预处理,缓存和并行化的方式来提升性能,比如镜像预分发到服务器避免实时下载,容器资源使用多级缓存以重利用,小到用指针代替内存拷贝来传递参数等,这里有个小问题,一个用户函数用过的容器可以交给另一个用户去使用吗?并行化容器启动与代码下载流程,函数大参数传递使用共享内存指针方式传递等,最终将冷启动的时间控制到200ms,热启动的时间控制到了5ms内,达到业界一流水准。
云函数平台由于共享粒度更细,不可避免需要共享服务器内核,在安全方面挑战会更大一些,所以我们在docker隔离的基础上,额外做了一些安全措施,比如限制函数运行时环境只有/tmp目录可写,通过seccomp等内核特性限制端口监听,端口扫描等敏感系统调用;但做安全的同时,也关注业务兼容性,比如大家习惯性的使用root来运行程序,禁止root可能会给用户带来一些额外的适配成本,所以我们使用root namespace技术把容器内的root映射成了容器外的普通用户以控制权限,另外由于我们无法审核用户代码,而用户技术上可以写代码去做尝试做任何事情,比如收集运行环境信息,窥探管理服务器位置等,为了安全,对比开源的serverless平台,实现了函数运行环境和管理环境的分离,函数网络包收发代理及日志收集等均放在容器外,容器内函数运行时环境不感知管理节点的的任何IP,端口信息及平台日志等信息。
由于业务除核心逻辑之外的非功能性需求都依托云函数实现,对云函数平台必然会有更多的需求,为支持业务可持续发展,跟上业务迭代速度,我们也做了一些优化,比如在过去一年,业务对我们平台提得最多的需求是支持各种编程语言,运行时环境安装各种库等,为了加快迭代效率,我们提炼了各类语言运行时环境的公共部分用C语言实现,因为各种高级语言均易实现对C库的直接调用,这样新增加一种语言支持能够在1~2周内完成,在库更新方面,我们把所有的运行时库部署到母机上,通过目录mount的方式挂进容器,使得库的更新无须变更运行时环境镜像。

汇总一下刚才的关键设计,我们通过让用户做得更少来提升易用性;谨慎的设计异步调用及重试来提升稳定性;消除闲置及过量申请来降低成本;利用缓存及并行来提升启动速度;通过内核层技术及管理环境与运行环境隔离来提升安全性;通过提炼公共功能及避免重制镜像来提升迭代速度,那实际效果怎样呢?接下来给大家分享一下我们当前的一些用户案例及经验教训。
当前云函数平台在内部最大的用户是游戏AI的特征提取,游戏AI在整个行业目前还处于摸索阶段,算法变化很快,程序经常更新,计算量非常巨大,比如王者荣耀1天需执行上亿录像文件的特征提取。如果基于云函数实现,只需要AI工程师用python写两个函数,一个脚本将从录像文件中提取特征,生成HDF5文件,另一个函数将HDF5文件打散随机化再推送到训练平台进行训练,算法更新时,提交新的函数即可,可以更专注于算法研究,无需再关心服务器的管理,计算的分布,扩缩容,故障容灾等。除游戏AI之外,微信小程序的开发者工具也开始集成云函数正在内测中,欢迎大家体验。
回顾这1年多来的建设历程,最大的教训主要有2点:
• 前不久腾讯云云函数出现了一个安全漏洞,在云函数的上下文通过bash反射,尝试各种linux命令可获知k8s的kubelet访问地址,且由于k8s没有配置鉴权,用户可直接控制k8s去获取其它容器内部数据,造成安全隐患,幸亏公司安全团队及时发现未造成严重后果,这个问题的原因在于我们对k8s的安全机制缺乏了解,给我们的教训是每引入一个开源组件,都需要吃透后再开放服务;
• 由于云函数平台被设计为7*24不间断工作,每次计算节点升级时需要经历屏蔽,等待函数执行完,升级再启用的过程,早年未做自动化,整个集群升级一次要耗费将近一周的时间,拖慢了版本迭代过程;
同时,我们觉得好的经验主要有2点:
• 设计之初就考虑了平台的平滑升级,所以一年来变更了大大小小50来个版本,从未让业务停过机;• 另外我们重视了平台公共功能的提取,比如多语言支持方面,1~2周可搞定一种新编程语言,远比其它serverless平台快;

在推广serverless云函数平台的过程中,我们发现对于无状态微服务,负载波动大,对延时不敏感的场景,比较容易服务好,但对于有状态的服务,需要业务自行保存状态,对于持续高负载的业务,没法发挥资源按需取用的优势,对于延时敏感应用,由于中间函数的分发多了一层,延时有差不多5ms的损耗,对这些场景,serverless当前还不太适合。
但未来,serverless是可以期待的,当前serverless已经成了各大公有云的标配,对于公有云而言,serverless不仅仅是一种新形态的计算服务,更能充当整个云平台的粘合剂,便于打包推广其它云服务,让公有云从各个分散的云产品集合变成了有机的整体,成为用户公共的云后台;在开源社区,serverless平台也蓬勃发展,每隔一段时间都会出现新的值得关注学习的serverless平台;虽然当前serverless主要战场在数据中心,但随着IOT的发展,IOT边缘设备可能成为serverless更大的战场,因为边缘设备的计算资源管理,软件包发布更为复杂,更加有挑战性,能解决好相当于雪中送炭。

武学修为对各路招数融汇贯通时,可以达到无招胜有招的境界,对于我们做集群资源调度的程序员来说,能把资源调度做到极致,让业务根本感知不到服务器的存在,是我们最高的追求。
页: [1]
查看完整版本: 让业务感知不到服务器的存在——基于弹性计算的无服务器化实践