云端数据处理，让服务更轻—庞向才（ 1213 开发者实践日）

[庞向才] ：今天介绍七牛继续做云端这样数据的一些事情。

第一个简单聊聊计算本身的一些事情，过去从PC开始用起的时候，那时候单机系统比较多一点。像2000年左右的时候，对于我们做外部的应用、做单机的一些应用，基本上那时候数据也比较low一点，没有接触过高大上的系统。那时候所有的东西都设在单机上面，然后包括数据库，那时候还没有Git。很久以前没毕业的时候，在北京一家公司做兼职，做系统运维相关的工作时，系统比较乱，一台机器只有几十G的硬盘，都堆在上面。再往下面到了hadoop阶段，这时候分布式的文件系统，除了自己没有开源以外，会有各种实现。

对于hadoop来讲话，它数据本身是公布的，它的框架里面是说我计算的代码可以用各种语言实现。你可以调动各种不同的任务，然后来执行。总的来讲就是让计算离数据更近一点，总体来讲这个东西要越近越好。然后现在比较火的就是spark了，因为我们的量实际太大了，一天XXX亿的请求，分到内部的子系统里面去，又差一个数量级的产生。我们为了监控系统的稳定性以及性能的达标，日志基本上要做准时的分析。但是完成的时侯是很难的，比如说要特殊监控的地方，要不然这些东西都会导入到分布式的系统里面去，再做准时的分析。现在七牛在云端基本上都存HTTP系统协议，七牛也好，包括其他友商，基本上没有例外的。

数据放到云端以后，就会带来一个问题，你比如说拍了一个裸图，800像素的就是两、三兆的大小。相机可以表中图、大图、小图，原始图片放上去以后，基本上在国内的3G情况下你没法看。最后的需求还是说能不能把图放得小一点，手机屏幕够看就可以，刚刚好符合手机屏幕的一个尺寸。最后就是说你有这种需求，但是数据离你很远，你又想看，免不了做一些数据的处理。我们通过HTTP的方式，给它发个指令，让它处理完以后的结果，通过XX协议返回。

计算总体来讲，右边的图画得比较草，就是三个框。计算机体系从20年前到现在都没有实质性的改变。从CPU到各种所有的加速卡，我要不想办法，摩尔定律那样频率翻一番，快到一定的程度就没有办法了。后面就是说怎么少概念？很多人要去重复的，可能不同的纬度、时间访问同一个处理过的数据。后来就上cache，从CPU1、2、3级的cache，然后到你现在Web服务做得比较多的，我先简单的单机系统，这样的话我数据库抗不住了，我就上radis之类的。对于云端在做这些事情的时候，框架搭得更大一点，各家有各家的做法。比如说有些东西从一些慢盘取完以后，所谓的分级存储。我只是说数据访问了一次，第一次可能在很慢的三个盘上面，有第一个人访问以后，这个数据就激活了，然后就会转移到SASP上面去。然后小文件都会控制在一百纳秒的样子，然后就可以从盘上读出，剩下都是网络。现在网络很快的，每秒钟处理包可以处理几十万、百万，应该是没有问题的。包括数据存储过程的开启，这些东西主要都是为了加速用的，让你的感觉更好一点，变得更快一点。可能你们的应用里面也会用到，比如说我一台机器的计算资源是有限的，我内存可能是32G，服务端现在高一点，几百是肯定的。当然现在移动端的手机都是flash的芯片，仅仅是读取之类的还是很快的。但是一旦涉及到计算结果，放内存还是好一点。

现在来讲这不是高大上的内容，这都是一些比较现实的东西。实时性的一些处理，因为可能前两天陌陌上市了，大家都知道陌陌的数据很多都在我们这里，他们为了缩减流量，就是说数据流。一张图片可能要XXK，小的也是几K的样子。

国内带宽很贵的，用户在家里收了钱以后，运营商还要收钱的。你上陌陌，同时很多人聊天，你手机流量会耗得很快的。另外一端从运营商机房里头，全国是数千个节点。他们会以峰值给你打个XX折，但是你峰值很不稳定。这种情况第一就是说避免波动，第二就是说让传输的数据变少。原始的图片放上去，最后你要加速他的访问。你刷个图片，刷5秒钟刷不出来，可能最初怀疑自己网络慢，你换了个应用刷一下，不管哪家应用来说，刷图片太久刷不出来，又证明网络是好的，你开始骂这个应用太差了。比如说移动网络用3G，3秒、5秒你图片能刷出来，因为国内的网络覆盖不大一致，延迟、波动都是难以避免的。

我觉得国内的应用比较容易做，因为大家容忍度比较高一点。因为上下班中间要排队，吃饭要排队，排多了可能都适应了。但是实际上你实时性真的很好的时候，你觉得好爽好流畅。机器好坏明显有区别的。实时性的响应，当前就是保证起来，就像那头僵尸一样，你每一个问题可能都是一大波僵尸，需要付出代价的。当前比如说像美拍的应用，还有一些其他的游戏分享，就是游戏我在手机上录完以后，后台传输，过个10秒钟你就可以分享了。分享完了，伙伴们就可以看你录下来的很帅的记录。这种实时性要求高，从后端数百公里，数千公里的机房，通过各种路由器，最终到你小区的局域网，这条路是很长的，环境比较难控制。到真正的服务端，它必须数据要快，这就是雪上加霜。然后高吞吐，如果大家做服务端的话，你做APP有几千、几万用户的时候，可能和数据库有需求的时候，或者说和图片有需求的时候，你一秒钟一台服务器支个几百个KPS了不起了。这种情况下，怎么保证性能的响应依然是良好的？量大，本身就是说小图片太碎了。单机的系统来讲，早年用过windows的人可能比较明显，现在很多都有固态盘要好很多。以前没有固态盘的时候，不管你台式机还是笔记本，里面的碎片多一点的时候，你搜索、查询一个文件会越来越慢。这个东西的复杂度和量是直接关系的。我以前做相对底层的文件系统，就是说你从陌陌结构，你的整个文件系统就像数据库一样。你的文件名、你的路径，都是存放在某一块区域，你的数据是被安排到另外一块区域，找的时候就像一颗树一样，用树来找的已经比较快了。然后一层一层地找，你访问一次以后，你下一次访问就会变快。因为你的目录树都已经开启在里面了，这东西很重要。如果当前做服务端的话，用linux比较多，它的各种内存的配比都是干什么呢？可能你90%的内存都被page Cache耗掉了。其实不是系统可以，也不是磁盘可以，是他们的数据组织还可以。右边针对这些上面的所有的需求来讲，复杂度都很高，大家知道创意、技术团队其实人员是有限的。数据量多了以后，你需要找一个专门靠谱的地方帮你打理。

我们看下一页，如果有这些需求，特别是说你需求不管多复杂，你量少的时候都不是问题，量一变大都是问题。在国内做实时性的业务，有一大堆的坑。

我们服务端为了让这些坑里面跳得快一点，你服务端基本上一定要快的。你最终数据出去的地方一定要快。那就是说基本上最好的CPU，都放过来做计算，能减少一毫秒就是一毫秒。因为不同的CPU的主屏，都会影响到处理这些事。高效果Cache，在你数据计算正常的情况下，把它塞到Cache里面去，下一次不用再算了。可能说大家从手机上访问到的所有的，可能你永远不是第一个刷到这些内容的人，你基本上都会很快的。然后在原来的地方，你要有大容量的出口。如果你用过虚拟主机或者现在就买云主机的话，云主机就是VPS。都会有带宽的一个限制，是共享的还是独占的？独占可能比你主机还要贵。用户一旦多了以后，就会拥挤。你的APK一下就是几十兆，你瞬间其他用户就会有影响了。某服务商实际上都有限速，我尽可能把数据快地推到用户手里，你不会做限制的。不管用哪家服务，出口带宽现在都是按10GB去算的。一根光纤10GB，扯上10根、8根的。这样子保证出口一定是靠谱、稳定的，然后延迟是4GB的。

下面就是说只有一个点快是不行的，因为大中华的局域网非常复杂，电信连不通联通的。北方联通到南方联通，每天每个时候还会堵一下。这些可能还不可控，最终只能说从更大层次的方案上面去规避。比方说北方的客户用北方机房，南方的客户用南方的机房。不是黑他们，确实很差，有些小运营商到你的节点路由都不通，这些需要专门的人干。像国内的几家CDN服务商，很多都是布点公司，在各个机房和运营商那边都摆上他们的服务器，保证你的服务可连通性。他们的节点到你网站的快慢速度，到你当前用户所在的位置，不管你用电信还是联通的3G、4G，你第一跳跳到那个节点，直接决定了你这一把网络的快慢。这些东西都比较重要，也有一些自建的节点，但是在管理上主要靠CBD保证这些事情。处理这一块上面说靠自己来保证，或者说放云端，靠云端来保证。

顺便说一下我们现在纯做数据处理的服务器，线上在跑的就有几台，有些客户的量太大了。简单、高效的方式就是扩容，都说互联网公司都是不差钱嘛。剩下的就是说简单讲一下坑吧，就是说什么叫实时的处理呢？你在服务端秒以内能处理完，这算实时的请求。如果你在服务端一秒钟能处理完，我觉得这基本上不算实时了。如果有界面的一些应用，没有界面的还好，可能说是一些任务了。如果影响体验的话，我觉得服务端处理绝对不应该超过一秒，超过一秒绝对是故障了。不管用哪一家的语言，用数据处理也好，用什么服务也好，如果超过了一秒，用户体验受影响了，这基本上是必然的，因为路很长。如果数据都很小，然后你的数据本身的包括你可能有些实时的计算，比如说打个缩略图，第一次访问的时候，这种情况下你用实时的处理都是没问题的。这样的话同步，你就坐等结果回来，这样的逻辑简单很多，就是这样等就行了，这是最简单的。但是有些东西一旦是说你访问过以后，这样子你又掉到下面一个坑里面去了。主要是说CBD的缓存，经常有更新的情况下，你对同一个文件更新，你发现更新完之后，你的用户依然没有刷出新的。你清完Cache，发现刷出来还是老的。这样的话，CBD他的运营商的节点非常多，本身是互联网数据通道了。这种情况下，可能一个小文件，要不就是你是他的客户，去找他实时的刷新，但是它还是有故障。他放上去的Key是一样的，我们默认第一天重复，第二天重新拉一遍。搞了好几天，看一下还是很早以前的。它确实是某CDN，因为某些原因没有更新掉。你要做活动，你把主页都换掉了，结果你刷了几天还是原来的图，这样人家会很伤心的。比如说你更新你所有的展示资源，你就索性用不同的名字，这是最简单的。因为CDN的缓存一般都是靠URL，以及有定制的话，就是URL的某一段来缓存的，来识别你的内容是不是有变更。或者有没有新内容需要缓存。这种情况下，你干脆把它淘汰掉，换数据的时候顺便换名字。名字你随便起一个，因为图片的URL用户从来不会看。这种情况下，你对你的实时性，包括你的整个内容的更新是放在自己手里的。用户刷你的源站，你的用户服务器变掉了以后，就不存在刷新的问题。这可能是我们所有的客户，包括所有的合作伙伴平时遇到的小烦恼，通过人工流或者特殊的途径，去把你网站上的垃圾清掉是可以的，只是过程比较久一点。主要就是说缓存这个坑，只要帮你加了速，你的应用就在这个区，可能有某CDN的服务器就在上海某个机房。一旦时间长了之后，就是说你更新的东西，他没有更新，这样也很坑。就是说也算是一种平衡吧。

然后这个题目起得比较矬一点，没有细想。比方说你拍完了一段手机的录屏，比如说今天这个活动下来，我们视频可能以后也会放在网站上分享。这种情况下，它消耗是比较高的，以至于你用最好的CPU，也不可能把它在一秒钟内处理完。这种情况下，就可能要引入一套异步的机制。当前为了兼容性也好，门槛也好，一些传统的很老的一些协议，可能在互联网时代都被抛弃了。很久以前家里面都有机顶盒之类的，就是说有线电视的，他们走的一些协议都是非常复杂的。

包括数据流的协议，都是非常复杂。现在手机打电话，这套通讯协议，学计算机的都知道是相对复杂的协议，这是保证可靠性的代价。电话费降不下来，运营商告诉你是因为什么什么，这是一方面。最后你可能异步化掉，你没办法做的，你发出请求，他告诉你收到请求了。最后结果要继续查或者等通知，你去XX机关，告诉你XX工作日以后来取。最近我们公司说去旅行，然后就有很多小伙伴连护照都没有，因为刚毕业，也没有出去过。办护照，你就提交材料，告诉你15工作日就15工作日。早一天过去查，他们说还没有，看日期，明明还没到你就来了。要么就是坐等，要么就是没事去查一下。这样会带来应用层面的一些复杂性。这种东西要提前预料好的，你为了自己的可控性以及体验，就要这样做。前天晚上我们有一家厦门的客户，是哪家不能说，凌晨一点50分左右，我在公司处理其他公事，他们说他们的服务器挂了，从他们的老板打到他们的CTO没有一个接通的。最终从角落里找到他们的销售，那哥们的电话终于接通了。不管哪家云服务，涉及到回调任务的，要仔细检查每个流程是不是稳定和可靠。因为对某些用户来说，可能是丢数据，这个问题比较严重。我们正常来讲一次回调不成功，再重试，比如说一个小时回调不成功，就不再重试了。

剩下的都不再细讲了，反正就是注意回调里面的坑。这个是处理完以后，你要重新再拿，以备后期自己拿。把Cache另存一个文件，然后方便自己去处理。这边还有一些所谓的多样化的应用，我们客户接多了。有些不能算奇葩类的公司，比如说有些公司JPG的图片压缩过了500M。可能一张图片需要几十G的内存，可能它一个图片要切成5百万份之类的事情。但是有点夸张了，切成几千份是有的。数据的多样性和应有性，每家云公司都会提供一套基础的支持，让大众接近的应用，但是有些很难接。

这边有一些云平台作为一个框架，作为你有储存接口、计算接口，我们希望真的是有用户有自己的开发能力，有特殊的需求，可以定义自己的数据处理逻辑。

但是用户说去我们机房买一个处理器是可以的。但是结果你要运维、机器全部覆盖，这个流程做起来很累。然后我们允许用户把自定义程序打包完，放在这个框架里跑。流程一样，接口一样，只是说command换一换。用户的应用处理完以后，进入到指定的框架，让用户以插电的方式体验自己的逻辑。

东西还是这些东西，只是说希望大家如果有需求，可以用服务来实现的，就不要自己来搞，这个事太累了。我们累一次就可以了，包括其他的云公司一样的。信息处理就是数据加计算，现在主要是消费型的数据比较多一点，互联网客户这边。传统客户可能有归档类的，为了安全用来备份类的都有。但互联网类的主要是用来消费的比较多，给客户直接提供一些服务。这样大家选储存或者选服务商的时候要关注一些东西，为了后期的一些发展。比如说会不会因为接口太复杂，接进去就出不来了，还是基础的服务不能满足要求，或者说给你制定一个计算的能力。

PS：开发者最佳实践日·第8期－互联网产品从设计到上线 北京站
报名地址： http://qiniu-8.eventdove.com