BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

叶理灯:原来Serverless可以这么容易理解
录制于:

| 受访者 叶理灯 关注 0 他的粉丝 作者 InfoQ 关注 7 他的粉丝 发布于 2017年10月1日 | QCon北京2018全面起航:开启与Netflix、微软、ThoughtWorks等公司的技术创新之路!
13:25

个人简介 叶理灯,UCloud创新产品线研发总监,拥有10年丰富的互联网研发经验,先后任职于腾讯、盛大云等互联网公司,从事海量分布式后台系统研发及运营。现负责UCloud创新产品及研发,专注面向企业的云计算产品的研发及运营。

容器大会的介绍:CNUTCon是由InfoQ主办的顶级容器技术盛会,大会的目的是促进容器技术的发展与应用。CNUTCon为期两天,主要面向对容器技术感兴趣的中高端技术人员,大会聚焦技术落地,旨在帮助参会者了解相关开源项目和技术栈,使企业可以根据最佳实践构建自己的容器解决方案,并了解容器技术的发展趋势。

   

2. 请问与传统架构相比,Serverless有哪些优势?

叶理灯:Serverless是最近这几年才火起来的概念,从它的字面上去理解,就是无服务器的架构。什么意思呢?就是你就不用买服务器去搭建你的架构。为了做到这点,要求你对这个架构做无状态的改造,把它变成一个个函数托管起来。

从优势来讲有几个,第一呢,它是按需付费的。传统架构你买物理机也好,买虚拟机也好,不是真的按需付费,因为你可能用不到所买的配置。但Serverless是可以的,因为它以函数为级别,完全可以按照这个函数消耗的资源给你计费,它是非常彻底的。

第二个优势是很明显的,它会节省很多运维成本,因为你没有服务器了,所以就不用你去运维它。

第三个优点我认为是,它加快了上线的速度。之前的架构,你需要买服务器,把东西部署,做些初始化的工作,但是有Serverless这个东西,有函数计算这个东西,你直接把代码写好,上传上去就可以直接用了,面对的一个Serverless环境是直接可以把函数上载上去直接运行的,这样会加快你的业务上线的速度。

   

3. Serverless架构有这些优点,那它适合哪些业务场景?

叶理灯:我刚才说的是优点,其实Serverless也有缺点,一个非常明显的是,它是要求你这个函数是无状态的,因为Serverless是不保证你每次函数地址是一样的,它在海量机群里面,你函数第一次运行可能在这个节点,第一次运行在另一个节点,也就是说它这两次运行过程中是不保存状态的,这是第一点。

第二点,普通架构下提供的是一个常驻的进程,但Serverless它是一个函数,来一个请求,他拉起一个函数,再销毁掉,那么相对一个长驻镜像来说它有一个比较高的延时。

这两个原因,使得Serverless一般会用在一些无状态的场景,还有一些相对来说,对延时不敏感的场景。我举个例子,图片处理,很简单的例子,图片处理也是一个图片进来,然后推出去的操作,它本来是无状态的。

另外,因为我们也算国内第一个做这个Serverless产品的厂商,在我跟用户聊天,或者见用户的过程中,发现有一些场景也是很合适的。图片处理其实是很大的场景的,包括OCR识别,包括机器学习也是个场景,对基因数据的分析是个场景,包括我们最近去聊了一个叫医疗影像,医疗影像叫dicom格式的文件,看起来像图片,其实是一帧帧的东西。

当然我们在内部有很多类似的场景可以挖掘的,例如我们有个多媒体事业部,里面有些短视频的,本身你可以把它抽象为一个不管图片也好,短视频也好,它是个小文件,基因数据也是小文件,你可以认为它对小文件的无状态处理是非常合适的。在这个前提上可以推广到很多业务场景里去,包括直播,编解码,这些涉及到计算的,也是无状态的,也可以用。

   

4. 您的演讲题目是容器与Serverless架构实践,谈一下容器在Serverless架构和产品中的作用。

叶理灯:我们这个UCloud通用计算(UGC)产品和普通的那些所谓的FaaS还是有点不一样的,我们抽象的层次更高一点,他们抽象的是函数的,我们的抽象的是算法,那么既然是算法的话,我们一定要想个相对,大家都能接受,开发者能接受的方式,打包这个算法。

我们当时选了容器,因为容器从13年出现到现在,相对来说它是个标准化的东西,大家都愿意接受它,也习惯它,而且它比较轻量,第三个它具有跨语言的特点,这三个特征决定我们选择了容器作为我们打包算法的一个工具。

当然我们用这个容器的过程中也遇到很多坑,就像刚才我在演讲里说了,我们的计算资源是通过受限的虚拟机提供出去的,但是我们当时是想,既然是受限的虚拟机,那这个虚拟机所用的资源越少越好,我们当时选了CoreOS,CoreOS我们用的资源是很少的,CoreOS跑Docker性能也还不错,但我们遇到一个坑是这样的:因为我们的场景是说来一个请求,拉起一个Docker,然后执行完就把Docker直接销毁掉,那么就会有大量增删操作。

这种操作,使我们触发了一个内核Bug,那个Bug我们是在去年的5月份遇到的,这个Bug在4月份发现,提了一个Patch到内核,但内核的官方版本不可能那么快合进去,我们找到内核团队,看能不能把这个Patch去更新这个CoreOS内核,但我们发现更新CoreOS是个非常大成本的事件,CoreOS很激进,你要重新编译一个CoreOS,你要把很多依赖也编进来,虽然可以做,但是对我们来说维护成本太高了,我们就从各方面的权衡,决定把操作系统换掉,换成CentOS,在上面搭个Docker。在CentOS上面的存储存储驱动,默认用的是DeviceMapper。我们对比测试发现,这个CentOS里面,在Docker这个DeviceMapper的IO性能,比CoreOs默认的OverlayFS要慢,慢了大概两到三倍。我们就把CentOS上面的那个DeviceMapper替换成OverlayFS,再压测发现现在还OK,后来用了这个方案,就CentOS+Docker+OverlayFS。

我对Docker社区有点悲观,我一直不认可它某些做法,例如说很多问题,比如内存泄露,因为我们的管理进程也是Docker管理的,进程如果有标准输出的话就会导致docker deamon内存泄露,我们找了半天发生了这个问题之后, 发现2013年这个问题存在了,2016年还没人解决,这么明显的Bug为什么三年没有解决,我对这个社区有点失望,感觉缺乏管理和领导。我觉得Docker最大的功劳可能就是定义了镜像的格式和把container这种相对开发者比较难操作的东西通过一个易用的工具提供出来。

   

5. 其实您刚才讲到的Serverless的最主要的作用就是打包算法,并且扩展讲了一些遇到的坑?那么坑是一回事,UCloud在容器和Serverless相结合的实践中遇到了哪些难点呢?如何解决?

叶理灯:因为传统的Serverless里面存在一个问题,来一个请求去拉起一个Docker,这就有个问题,这个初始化成本很高,尤其是说如果你这个计算结点里面,这个计算不存在的话,你得从Docker里面重新拉一下,Docker镜像很大的话,这个任务非常慢了,这个操作分为几个阶段,因为我要把镜像下载到这个本地节点里面,再把它拉起来。

首先最明显的优化就是我们要能做用户Push一个镜像上来,我们会在一批节点把它预热,就是镜像已经先下载下来的,当真正在请求这个算法的时候,我们把这个请求转向这些有预下载好镜像的节点上面,这是一个相对来说比较复杂的算法。而且因为每个节点的存储空间是有限的,你不能说一下子把所有的镜像都下载到本地来,这样子存储是撑不住的,所以算法要考虑怎么去预热掉一批镜像,去淘汰一些冷镜像,但是都是跟容器本身是没有关系的,跟这个机制有关系,跟Docker容器启动的时候有点关系。

还有个很大的难点是架构上面,因为这是个平台类的产品,这个架构和稳定性和高可用,要做得非常好才行,它不像应用产品,你自己挂了,只会影响自己一个人,这个平台挂了影响上面的很多个任务,上面的很多用户。

那么在高可用上面我们做了很多工作,但我们最希望能做到的容灾级别和高可用级别是跨可用区的,刚好我们公司有个叫ULB(UCloud Load Balancer)的产品,非常好地满足这个要求。ULB可以把它的所有的real server会放到不同的可用区里面,当一个可用区挂了之后,可以快速地把故障可用区踢掉,就不会影响到用户的任务执行,用户的任务可以调度到另外一个可容区里面去,这是第一个问题。

第二个难点就是你要保证整个架构的高可用,任何一个模块,任何一个依赖点都不能有单点,所以我们当时是有想了各种办法,因为我们的存储层一定是可以自动扩展的,不能成为单点的,每个模块所部署的机器,我们都尽量做到跨可容区,或者跨交换机来做容灾,我们部署之后会检查各个部署的环境。

第三个难点,架构特点是我们管理的机器非常多的,那么任何一个节点挂了,我们来保证它不会影响这个服务,我们当时对提交任务,是做了多副本的工作,就是来一个任务时候,可能会同时发给多个副本机跑,哪个先完成了就把它跑回来,这样的话,我们能做到,一个机器挂了,我们可以慢点处理,对我们服务不会有影响,完成这个目标,而且对用户来说也是很好的事情。

   

6. 请分享一下Serverless在UCloud的落地情况。

叶理灯:我们应该是在内部先开始用Serverless,因为我们做平台的一个思路就说要先吃自己的狗食,把这个平台打造的健壮了以后再对外是比较好的思路,我们落地是在内部落地的。

我们当时在ufile这个产品场景下落地,取得了很好的结果,就是真的帮用户节省了大量的运维的人力和机器的成本。

图片处理这个场景建完之后,我们还有一些其他的场景,例如我们最近提出短视频的场景,短视频的场景就是目前那些用户上传了短视频,传到我们的存储上面去,我们做些处理,再去变成一个想要的东西,这里面有大量的小文件处理,而且这是另外一个产品,我们公司做的一个umedia的产品,对外提供服务的,背后的计算也是通过我们这个UGC来落地的,这是第二个场景。

第三个场景是,视频的推流,编解码,涉及到大量的计算,这个计算是不可预测的,他们也是把推流逻辑放到UGC去跑。

还有一些就是说,我们基于我们的场景还做了一些改造,比如说目前比较火的AI,我们对这个Serverless和UGC的产品的机制做些改造,允许它支持常驻的进程,这个东西就不是个Serverless的概念,但是为了支持内部业务,我们在上面加了一层PaaS,来对外提供AI的服务,也是基于同一套的东西来做的。

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT