BT

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

七牛韩拓谈公有云:扩容,持续集成与拥抱故障
录制于:

| 受访者 韩拓 关注 0 他的粉丝 作者 胥昕 关注 0 他的粉丝 发布于 2013年9月3日 | 如何结合区块链技术,帮助企业降本增效?让我们深度了解几个成功的案例。
28:58

个人简介 韩拓,现任七牛云存储首席技术官(CTO),全面负责领导七牛云存储平台架构,功能研发和产品运维。韩拓是一个热爱生活,自封吃货的程序猿,酷爱运动尤其擅长踢球,喜欢阅读尤其喜欢科幻类小说。其毕业于中国地质大学,物理学学士。先后在金山、童话网络等国内知名的IT企业从事研究,架构等技术负责人工作。有接近10年的IT行业开发经验,对服务器端技术尤其是分布式存储技术有非常深入的了解,曾经作为核心架构师,成功的主导和上线了多个以存储为主题的互联网产品。

作为InfoQ主办的全球顶级盛会,QCon在伦敦、北京、东京、纽约、圣保罗、 杭州、旧金山举办过多次,这次是首次走进中国首都北京。希望能给当 地的公司、技术社区和技术人员提供一流的学习、交流平台。

   

1. 韩拓你好,感谢你接受我们采访!您先自我介绍一下吧。

韩拓:我是来自上海七牛的韩拓,上海七牛主要是提供云存储的服务,主要是面向企业和一些中小开发者,提供类似于S3的存储服务,并且在这个基础上提供一些上传和下载的加速的功能,还有一些富媒体数据的处理。

   

2. 以下有几个问题我问一下。首先是作为公有的S3的服务,增长肯定是非常快的,像一个互联网服务一样,而且我们这种服务对扩容的需求肯定是司空见惯的,七牛对扩容的处理有什么心得吗?

韩拓:这个问题是从两方面来说,首先从我们软件的层面,就肯定是要去做处理,就是在我们的这个从基础架构上来讲,要做到,就做扩容时候很容易,包括运维的支撑的系统,像部署系统、监控系统这些东西,首先要把它做得很完善。也就是说从软件层面,要做到扩容的边界成本要很低。另外一方面就是从硬件上来讲,可能是跟软件是不太一样。因为硬件的采购是需要一个周期的,包括买服务器,去做IDC的选址这些东西。我们的原则大概是预留一个月的余量,我们会预估一个月以后使用量是多大,然后去采购。当然我们现在也处于一个快速发展的时期,所以很多时候,我们会打破这个一个月,可能就是以周为单位去买服务器。

   

3. 其实七牛行动还是很快的,作为新兴的互联网企业,行动力是很强的,我们从发起扩容的需求到完成一般需要以天为单位,几天能完成这个动作?

韩拓:如果是说要快的话,我们最快的一次大概是,并不是用按天算的,是按小时算的。我们有一个真实的案例,我们有一个客户,他们在教育网的用户很多,就普遍反映教育网慢,那我们就需要去扩,在教育网去扩了一个机房,带宽大概有大几百兆这样子。我们当时大概是七个小时就OK了。当然这算是比较加急去处理的,常规的大概就是一周。

   

5. 我想知道,七牛对于持续集成肯定是有一定经验的,持续流程它的整个流程是比较长的,如果要把它做大,从我们工程师commit代码,到单元测试的处理,到最后打包,到重新构建测试,到最后发布,一大串的流程。有很多企业是一个流程是一个判断,从头走到尾就完了,是说构建完成,然后以这个发布为单位再去发布一次。那也有企业是,比如说我们工程师从成立到打包是一个阶段,然后从包到测试是一个阶段,从测试到发布,然后人工去处理这个过程。七牛是什么样的形式呢?

韩拓:我先介绍一下我们持续集成的几个关键的环节。首先就是,工程师写Code,然后配套的单元测试都做好,代码就commit到它的功能的分支上,然后由代码的审核人员去做好几个轮的Code Review,通过之后,就会把这个代码给合到我们的发布分支上。当然被合到发布分支上,也不光是只有这个功能的这个Code,它还包括对运维支撑系统的一些变更,也会在里面包括,比如我新上了一个服务,针对这个服务的监控的脚本和代码就要上。然后就是针对这个服务的集成测试的案例也要上。甚至说这个服务去部署的时候,部署的描述,这也是同时是在开发的。那我们认为刚才说的这几个组成,就构成了一个持续集成的一个最小的单元。这个单元被合到我们的发布分支上以后,由我们的系统自动的去构建,到这一步是自动的。构建之后,当然构建的时候要跑单元测试和集成测试的案例,都通过之后,就算是构建成功。然后构建成功会推到我们预发布的环境,去再运行那个集成测试的案例。到目前为止就全都是自动的,当然我们目前也是很保守,下一步往线上推的时候,是要人去点一下的。

   

6. 那我们知道这个流程,他需要的系统,软件是一个,大家都知道工具链这样的东西,那有的企业百度他提到Ruby中的一套组件,还有业界很多,比方说像Gerrit来管理,到最后的FaceBook这套系统,最后的发布系统也是。七牛用什么样的工具链?为什么选用这样的工具链,和团队和项目之间有什么样的契合?

韩拓:首先说一下在开发阶段。在开发阶段我们放的很开,不要求这个你是用什么操作系统,用IDE,这些是没限制的,所以你可以有人用VI,用emacs,这比较爽。包括我们公司有人用Mac,我们公司用Mac的人是最多的,然后Linux的、用Windows的也有,很杂。然后版本的管理是在Github上面的,就是去买的他那个最高的收费的档,可以支持创建几十个私有的库。所以我们的工程师基本上是分布式办公的,比如说你上午,你如果说睡过头了,你索性就在家里敲代码去提交,中午吃完饭再去公司,这样也是可以的,源代码管理是Github。我们的集成系统,编译这块是用Jenkins来做的,Jenkins我们认为是做得挺不错的,也基本上没有对它去改,就是用原生的。当然我们的makefile,这些编译的脚本,打包的脚本是我们来写的,就是由Jenkins去做触发的动作。触发的来源,比如某个分支的commit,或者有人去点按钮,这些东西都可以去触发这个编译的动作。还有很重要的是监控系统,我们是用的是Zabbix,用下来也是觉得挺不错的,因为它支持这种在大网络内的有properties的这种概念,它的性能也还OK。因为我们Zabbix的数据库用的是MySQL,我们现在监控点有三万多个,模板有一百来个,然后再乘以服务器数。剩下的系统就是部署系统了,我们是基于Puppet去做,但是对它进行了一些封装,也就是你在描述这个部署的时候。因为我们在贯彻DevOps的理念,就是任何人都可以去主张一次发布。所以我们认为,Puppet那个东西对于非专业的运维人员来讲太复杂了,所以我们对他进行了一些很简单的封装,你可以用我们的,我们那个格式也是在很大程度上是参考了Puppet,有花括号那些东西,但是很简单,我们去定义了那个类。所以这样的话,我们的开发人员、运维人员,包括是QA人员,他们都可以去写,他描述这个东西出来之后,再丢给我们的部署系统。部署系统把它给认为是编译也好,是转换也好,把它给变成Puppet能识别的那个配置,然后再由Puppet这个系统去推。工具链大概是这样的。

   

7. 正是因为得益于这套快速的随时构建的这样一个东西,所以我们才能做到快速的扩容,因为可以随时构建新的机群,并加入大集群工作。那我们的监控一般是分层的,比如说我有系统的监控,网络级监控,甚至说API级的监控,最后以客户为角度的监控。七牛是否有这样的监控分层等级,分层的力度是如何?

韩拓:我们的监控系统为分有几大块,首先我们的那个集成测试的案例,会挂到那个监控系统上去跑,其实这两套的案例是同一套。这一套案例我们在每个机房是有一个点去跑这个案例,这一套案例可以认为是黑盒的,比如说我新做了一个服务,针对我新的API,他正常的行为应该是什么样的。比如说一个我上传再下载,然后再转缩略图,它的行为什么样是OK的,这个东西要被一个代码给固化下来,所以我们也积累了很多这样的集成测试的案例。我们在每个机房会有一个点去把这些集成测试案例全挂上。外部我们是用监控宝,因为监控宝它监控的是一个HTTP,它就看你这个网页是不是OK的。但是它访问这个HTTP到我们那之后,会在后台把所有的集成测试案例都跑一遍。如果通过了就是两百,如果有一个没通过是五百,这个时候监控宝就会有报警。我们之所以选择监控宝,就是因为它的监控点比较多,更重要是因为它是一个第三方的,一个异构的一个监控点。比如说就我们这个机房之间,如果有问题的话,就可能查不出来。但是如果用它的就是OK的。这个是你认为是黑盒的那个监控。刚才提到有Zabbix,里面那三万多个监控点,这个认为是白盒的,三万多个里面有一部分是那个系统层面的,比如说是带宽,就磁盘的使用率、机器的负载和CPU的占用率等等这样的值,我们会把它监控起来,并且有对应的阀值去报警,这个所有公司都是一样的。其实一多半以上是和业务相关的,比如说我单个一个服务它缓存的命中率是多少,它最近十五分钟被访问的平均的速度是多少,它这个磁盘IO的IOPS是多少,这样的东西我们会监控起来。包括每个服务它的存在性我们也会去监控。因为你后面做到高可用的服务,他挂到一个之后,其实前面的那个黑盒子是看不到的,这个时候Zabbix那个三万多的监控点去做监控。你刚才提了一点就是非常好,对业务数据,我们也是很关注的。对业务数据这块我们也是分了几个层面,首先最外层的访问的HTTP的Code,比如说200,平均一秒钟是八千个,然后404是0.8个,500是1.2个,这个我们会监控起来,对每一个的指标会有报警,超过某个值有报警,这个是很有效的一个手段。另外在更高阶的这个业务数据上,我们也会做监控,这个中间有很多层面。到最高层面就是什么?就是钱,就比如说你上个月在我们这花了,就存了数据又有流量,你的费用是一万块钱,我们会平均到每五分钟,你花的钱比如说是15块钱。因为我们这个帐单是实时去算的。如果发现上五分钟突然你的钱少了或者多了,通常这也是代表出问题了。这个时候我们的原则是,先和客户一起去查问题。这个问题查到以后,咱们再商量一下,说是怎么样弄一下,然后再避免以后再发生这样的问题,大概就是这样。

   

8. 现在很流行拥抱故障啊,故障可以给我们带来进步。先清查问题,最后你排除故障之后再总结问题。那提到这个公有云的服务,其实他客户越多,你的量越大,你的社会责任就越强。因为我们的客户,有教育界的客户,有传统行业的客户,有互联网客户,有各种客户。比如我们某个公有云服务一旦有紧急状况,我们损失了千分之一的SLA,但是正好被中招的客户,可能就是他的全部。其实我们作为公有云服务,我们的压力是比较大的,那如何去在压力下来确保我们尽可能接近完美的SLA来给客户信心?

韩拓:其实你提到这个问题对我们来讲也是很困扰的,当客户的客户那出问题了,你要怎么去查,我们也是在很长一段时间内是很困扰的。因为你能拿到的信息其实非常少,我们就采取了一个措施,我们做了一个客户端的诊断小工具。客户端有本地的那个可执行版本,还有网页的版本。这个时候比如说我们客户的客户,他报告说这个图看不到了,或者说这个单词我听不到了,我们就会建议我们的客户说,你把这个链接给发过去,让你的客户去Run一下,再把这个结果给发回来,我们去排查。这个事实证明是很有效的。另外一个措施,当然这个是还没上,我们准备做一个Feedback的一个系统,也就是这个Feedback,比如说是网页的一个插件,会提供给我们的客户,他们在他们的站上就可以放。也就是说这个终端客户的这个Feedback,就可以很直接的回来,传到我们这来之后,就由我们去处理。可能这个客户就在家睡午觉,好像什么都没过发生一样,这个问题就OK了,这个也是比较少的事情。当然就是说这两种措施呢,也不能是百分之百的都覆盖到,也有一些很极端的情况,说怎么查也查不出来了,这个时候我们怎么呢?也挺有意思,就是我们会跟我们的客户去取得一个授权,就伪装成他的技术支持去加客户的QQ、加MSN去聊。甚至说就聊完之后,就我们的小的那个纪念品会给客户寄过去,去感谢一下。

   

9. 所以我们知道公有云的提供商,他往往面临这种问题,就是我们客户的客户,甚至客户的客户的客户,这样就多层信息沟通会比较困难,像你刚才提到的这样,我们的工作人员、运行人员、市场人员会伪装成我们客户的人员,那各种,特别像七牛这种Startup,成立时间也不长,而且人数肯定不如那些巨头那么庞大。而且最关键的是我们是,我们大部分的员工是技术牛,那怎么样去控制我们的团队,在做客户支持这块的这个时间占用率这个方面,七牛有什么样的心得?

韩拓:这个东西就不得不得承认确实是对工作是有干扰的,就包括一些很疑难的问题,我都可能会亲自去跟客户去交流。但是我们认为这个是必须要做的,就宁可说你的功能开发慢,甚至你去加班,这都是OK的。但是让我们的客户爽,这个是第一位的。
InfoQ:今天感谢你参加QCon北京2013的采访,我们经过这个采访也对七牛更加深入了解的更多,谢谢。

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


找回密码....

Follow

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

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

Like

内容自由定制

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

Notifications

获取更新

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

BT