金山云CTO杨钢：拒绝Hadoop 从零开始做大数据

大家好，刚接到分论坛题目觉得不太好讲，这个分论坛是移动互联网和新型终端，大家知道，金山云目前主要业务是金山快盘，虽然定位是个人存储中心，在各种终端上面都有客户端而且在国内排名也是领先的，关键问题是和移动终端互联网应用我们还是学习者，和大家一起交流。金山云做云存储做得挺早的，当时那时候存储实验室的负责人，许式伟在隔壁分会场跟大家讲。快盘做到现在，事实上它的存储技术一直支持了它的发展，我会介绍一下我们整个技术演进的过程，以及希望快盘和金山云如何帮助移动互联网开发通过云计算的服务性质的应用。

在现在这个年代，如果你做的是单机的应该不会有这样的项目出现，或多或少现在所有新的应用都会带着各种各样互联网服务，我们看看，以金山为例子，我们团队来自WPS，我做了八年的Office软件，快盘主要来自WPS团队，因为是客户端软件开发团队，怎么样开始一段云计算的冒险，我们从头开始。这个地方和我们的发展轨迹稍微做一些介绍，为了在学术上更好说一些。

首先，我们需要做在线服务，有一个很经典的架构，阿帕奇加上PHP，这个图上的结构，所有的服务都可以做在一台服务器上，我们叫它的All In Server，业务再往前发展可以看到一台业务服务器已经没有办法支撑业务本身发展的需求，这个时候需要多台业务服务器，多台业务服务器，前面需要有负载均衡的方案，比较简单可以采取的方案有三种。第一种，DNS Polling，第二种LVS，第三种利用反向代理来实现。我们发现数据库开始关注了，我们首先关注数据库的第一个方面，互联网服务最重要的东西在数据库里面，如果数据库出了任何的问题，我们就回高老庄了。有一个同步的模型按照主流关系数据库来做，这样可以马上利用冗余的机器来顶上。

到了下一步，随着互联网越来越大，比如说我们的每日报告用户超过了一万人之后，单台的机器通过本身扩展，加CPU，加硬盘，其实已经不够用了，我们做一个水平分表，最常用的方面把USDE用一个值做到某一台服务器，我们也可以看到这图里面继续往前演进，数据库出现了Cluster的概念。再往下一步，实际上我们会遇到另外一个问题，绝大部分数据库操作行为冷、热数据之分，一般的读写比比较高的读写值，我们自己业务也有例外的情况，但是绝大部分是这种情况，这种情况下面我们与其说不停的提高数据库，不管台数还是数据库的配置，让数据库显示得更快，还不如采取更节省钱的方式，这样数据库投资不用那么大，这时候很自然引用了Cache。使用Cache有两种方式，第一种方式Cache只读，如果数据发生了变化就把Cache除掉，还有透写，写操作由Cache写进去，看大家的个人喜好了。

到这个时候一个完整的互联网服务的结构，就已经搭成了，基本上跑到这个时候业务到底有没有人用，基本上看得出来。剩下的就是当这个业务继续往前发展，移动互联网越来越大，每年负载越来越大，大家每天都在为宕机这些事情奔波的时候，我们继续往前走。刚才提到了水平分表，我们刚才的方案非常简单，比如说就按照USID取一台数据库，这种属于固定的，固定的方式有一个比较麻烦的事情，我们要进行数据扩展，加服务器，这个时候很可能影响服务，要求一致性非常高我们得暂时中断服务，这种对于在线上运行一段时间的业务来说不可接受的。所以我们还可以加一个数据库路由，由它来记录一个用户放在哪个数据库里面，假设增加数据库，我们可以慢慢的进行数据迁移，如果我们的区分力度是user，如果没有数据库路由停机避免数据导入，这种方式不用停机，相对来说非常大的进展。

大家知道数据库的维护非常危险，千万不要没事儿干去重启数据库或者做一些比较大的维护操作，你很可能把数据库读死，造成整个业务的血崩，这种方案相对温和。

当业务量再往上的时候，读写比不断上升，Cache，数据热度、密度不是那么高，这个时候很可能出现数据库在写出请求可以做的，由于量太大就读不出来了，常见办法是读写分离，其他的从库用来做读，这种情况使用场景有一定的局限性，比如说数据是否要求严格一致性，这个是会影响方案。那么相对来说，很多网站都在用，因为在业界同行之间聊天都在用，很多网站跳过这个方案，金山快盘没有使用这个方案，跳到后面了。到这块一般来说这个网站的负载量已经非常大了，比如说，我们到了这步，我们可以看到在之前的时候，把所有的逻辑只是做了横向拆分，比如说，负载均衡，像最开始的时候，所有的逻辑做了负载均衡，有多个逻辑服务器，但是当逻辑越来越复杂的时候，如果把它整合到单一的业务逻辑服务器，这个业务逻辑本身很复杂，之间有可能因为各种数据操作在一起就无法应付了，怎么都无法提高，这点基本上每个公司做互联网服务，慢慢往前做都会遇到这个情况，而且大家都会经过这一关，把逻辑进行纵向拆分。

大家可以看到这张示意图，这张示意图首先是分出了两部分，Logical Server和Website Server，同样的数据库本身也要做这种，除了刚才按照水平区分之外，如果单一数据库涵盖了所有数据，表比较复杂，这个数据库本身性能影响非常大，其实做云服务，最重要的一点就是把逻辑一致的东西尽量的把它单独划分出来，实际上在数据库也要做垂直分表，比如说帐号会在单独库里面，我们做电商库存，商品的展现数据，评论数据放到不同数据库里面，要求实质性非常高，比如说对于库存要求非常高，有一些要求很低，比如说评论，延迟就延迟，无所谓。放到不同的数据库之后，它们可以根据不同的需求去选择不同的数据库配置方案，这个时候大家可以看到整个业务系统，相对来说分离已经比较细了。像快盘业务逻辑拆分下来，如果在上面手绘，A4的纸已经画不下了，得拿一张跟北京地图那么大的纸，把服务分解和关系画在一张图上。

在这种情况下，还会有一个问题，业务逻辑和业务逻辑之间它们会进行通讯，因为真正的应用会连贯的过程，比如说，在网上拍了一个物品，不管是库存的逻辑还是用户这边的逻辑，订单处理那边的逻辑必须都串起来，这时候有两种方式，一种同步，一种是异步，同步是一个逻辑服务，另外一个逻辑服务等他返回，对要求一致性非常适用，但这种有很大的问题，很容易由一个端点引起整个系统的血崩，大家基本上可以看到，特别是网购，在做活动的时候，会出现明年买3倍服务器，对于电商来说是经常遇到的事情。

另外一种方式是异步，把这个请求发过去，这个请求完成之后，由后者再通知另外一个地方，完成这业务链，这个对一致性要求不是那么高的场合，对用户评论，晚个半分钟出来没什么问题，这种需要消息系统他们来做，用户接入这块第一排最右边是消息系统，有很多开源的方案，随便选一个就可以，我们自己开发，性能上还不是太够。另外是在用户接入的时候，调度系统，因为现在业务逻辑非常多，但你不可能对用户来说，每个企业起不同的域名，接到不同前端负载服务器，域名方案不是太适合，这时候需要集中调度，用户所有请求到调度里面去做一次清洗，很多用户请求是错误的，因为出了问题，很多业务尝试破解你的服务，这种情况在调度里面会清洗掉，有的不一定是恶意，有的尝试破解你的谢意，量其实是挺多的。

这张图实际上来自我们金山云团队内部的技术培训，当然画到这张图，当时想到一个东西，12306.CN，事实上，不管多庞大，多么复杂的系统，其实解决方法只有一条，把它拆分，拆分成最小的粒度，每个粒度保证自己的稳定性，再看业务的需求，如果对持续要求非常高，就用同步模型，配置加大一点，如果要求不高，就用异步。到这步基本上已经能够适应所有的网络服务需求，包括架构模型，实际上大家都殊途同归。

我在这上面做了页面编号，这个时候我们做的是云存储服务，刚才提的东西跟存储没什么相关的，确实是最开始很长一段时间做基础的工作。说实话，对于所有公司来说，如果要进入云存储领域，最合适的起步方式是去买一个专门的存储设备，这说起来一点不丢脸，因为这样会省掉你很多的事情，让你的业务变得敏捷，专用的存储设备，这个地方写着传统的是千兆网，这个还有其他的设备便宜一些，虽然说单位成本与我们的方案来说肯定要高很多，但关键问题是从零开始做一个云存储的方案，技术难度非常大。

另外一个选择方案，就是去应用开源，业界用得最多的还是Hadoop，如果我自己推荐，不会推荐Hadoop，不适合于金山快盘，为像Name Node，甚至开源方案会选择DFS，TFS(Taobao FileSystem)不适合做快盘业务。Hadoop两结构，一个是Name Node。再往上走一点，我们业务里面做一个相册，它的文件冷热数据呈现比较高的情况，到这块说实话，去年开玩笑，现在国内百盘大战，我们到目前为止快盘是领先的状态，包括隔壁展厅WPS老朋友，许式伟同学他们也在做。其中这100个里面有95个都是采用买一个存储设备或者搭一个Hodoop，我见过一个最牛的团队是上海韩竹同学，一个人加两个学生，三个人在那儿做，不过他现在拉的融资不做那个了，那个已经停了。

到现在为止，我们刚才已经演进了12版，对于大型的互联网服务，到那个阶段了呢?这个地方给大家分享它在互联网服务的第一阶段，快速应对不断增加的服务压力，从1到12个演进方案，非常可行，很多互联网走过来的，可以直接用，在一个星期完成从这一步到下一步的演进。第二个是服务端的稳定性不断提高，最开始是单服务器架构，很多都放在一台服务器，这个时候服务器稳定性可想而知，随着后面的拆分表，不断的做冗余服务器稳定性达到比较高的程度。其实做云之后，我们之前做Office的时候，那还是2008年初，我们给自己定的目标也很高，服务稳定性做到多少个9，还是做云之后跟业界不停的交流，大家都是从慢慢的减少停机时间特别是维护时间，就像现在国内公认做得比较好的，淘宝、腾讯，他们也会经常维护，第一阶段我们觉得这样做挺好的，随着用户量不断的往上走，第一阶段是验证业务本身可行。第二阶段最主要的是，我如何在比较复杂的系统，比较大的系统里面既能够剥离稳定性，又能够保证业务敏捷性，因为要重新修改我的服务，这个时候自动化的运维系统和中间件的开发就比较重要了。

第三阶段国内大部分互联网公司，这个时候服务成本增加了。

第四阶段大家可以看Facebook。

我们希望快盘和金山云简化这个系统，图的右边可以看到，目前已经上线的应用有金蝶、康佳，没上线还很多。下面这是快盘的开放架构的介绍，一个基础架构图，这图是在照顾小孩的同时手绘的。下面是金山云技术，因为我们这个团队是来自WPS技术气氛比较强，因为WPS是有一个很大的系统架构组，它去负责可从用框架性的技术研究，这个基础架构组两个负责人，我和许式伟，我们做云的时候也是一样，第一个我们希望能够把这个基石打得很坚定，打得比较实的基础，第二个希望业务快速敏捷的变化，总结来说做了五类：

第一个是云存储，这地方跟大家说，云存储和分布式文件系统完全不同的两码事，分布式完全系统可以认为只是云存储里面的十几个子系统的其中一个，云存储会解决更复杂的问题。其实在国内做云存储这个问题非常复杂，通过专线成本非常高，快盘开放系统给大家提供这个上面的帮助。

第二个是数据框架，基本所有互联网服务遇到数据库的问题，特别数据库本身快速响应的，给大家介绍技术演进的时候，大家有没有注意到我跳过来一个领域，因为我们事实上自己做了整套冷热数据，动态扩展一整套的框架。

第三个是虚拟化。

第四个计算框架，可以认为是APP这样的东西。

第五个是运维技术。金山并没有做盛大云的模式，我们云平台更多的是比较倾向于支撑和快盘合作的应用，云平台上面就是快盘平台，OpenAPI，包括快盘所有终端也可以进行合作，我画了三个草图，Windows、安卓，Mac版的快盘在几个星期之后跟大家见面。这个地方示意是个人用户，还有企业用户这条线，企业这条线晚一点推出。快盘云平台架构和其他不同，简单说和大家一起共享用户，共享用户数据这样的方案，更多的是产品，更像产品上的合作。

这地方刚才也介绍过，快盘API包括两个系统，一个是本身合作，另外一个是为很多应外提供平台。合作案例是刚才大家看过的墙，这个地方是关于快盘开放API，这是网址，申请一个帐号，选择SDK可以开始了，如果有云的需求直接和BD邮箱联系，我介绍到这儿，谢谢大家。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友