饿了么原来有一个机房，差不多有两三百台机器。但是每个月的业务都在涨，所以运维部门很头疼，每个月都要采购设备、上架设备。机房满了再部署一个机房，整个周期又很强，最后不得已把服务部署在云机房。
氧分子网讯 上周，腾讯云举办了“最强应用，由你智造”的沙龙活动。 腾讯云的商务合作负责人王志永表示，腾讯云开始做应用的时候，有许多血的教训。尤其是服务的微信、QQ空间、还有手Q这种过亿级的应用，踩过很多坑，有很多血和泪的教训。这次是希望把经验分享出来，一来是让创业者和互联网公司少走些弯路，二来希望以此吸引更多的客户。
以下是腾讯云主要工程师的干货分享：
腾讯云研发总监郑立峰：打造一款亿级应用会碰到什么问题？
每年应用数都在不断地增长。我前两天向我们开放平台的同事要了一个数据，注册的开发者有一两百万，然后活跃的开发者，也就是一个月内还在经常地不断上传应用的这些的厂商，也有达到了20多万。由此可见，整个行业新的应用是非常非常多的。
那么大家在创业的过程当中，也遇到了各种各样的挑战。有产品上的挑战，产品同质化，然后流量成本也很高，大家可能要去各个电子市场买流量。然后运营成本也很高，比如说你去拉一个新用户，新用户的成本是越来越高。技术上的挑战，往往会被忽视。
问题一：流量突然暴增，扩展性不足
有一家客户，他在一周内流量暴涨，连自己都没有想到在一周内从一个基本上没有什么人用的应用，突然变成了全国人民都非常喜爱用的一个应用。然后一周内dau就突破了两百万。他们的服务器可能就几台，他们的程序员可能就几个人。那么面对着突然到来的流量暴增，技术人员压力非常大。
我去访谈的时候我坐在他们旁边，跟技术人员去聊，他说我都好几天没有睡觉了，然后因为流量暴涨所带来的各种各样的技术问题，在一两天里面集中地爆发出来，流量暴涨、程序的bug，被无数人使用之后各种程序bug也会出来。那么性能问题、架构可扩展性问题等等的暴露出来了。
我把第一个问题列成是业务访问短时间内暴涨、技术架构弹性不足，导致服务器压跨。一个是说高性能的设计不足，另外是扩展性不足。还有就算扩展性是足的，那么几天里面的流量暴涨，面临的一个问题是说我采购服务器也没有那么快。按照我们常规的采购服务器的流程的话，可能我去买服务器、下单，就算按照快的，我在中关村里面去买一个服务器、下单，等把它能够上架可能也需要几天工夫，但是在这几天里面已经是挡不住了。
另外一个情况，还有一类企业是这样的。就是每个月的访问数据都在涨，也就是说每个月都涨dau涨个10万。然后这样的一些公司的运维的同事也很苦逼，每个月都在采购设备、上架设备，采购设备、然后上架设备，不断地做着重复性的劳动。这样的劳动对他来说，一方面是感受到公司快速发展带来的喜悦，另外一方面也是在不断地重复性的劳动，他本身的自我的价值认知是不高的，因为一直在做这样的一些事情。
解决办法：部署高质量的云主机
高质量的云主机。云的一个普遍的特性，就是鼠标点几下、机器就拿到了。可能是500台，也可能是1000台。这样对于移动应用的好处不言而喻。你的业务量涨了，你马上可以把机器部署出来，为了达到快速部署，我们有一个镜像的能力。比如说你是web服务的话，我可以把第一台的web而做个镜像，然后买一百台机器，然后一百台快速的进行部署，整个部署的速度也是非常快的。
“饿了么”的实例，它原来有一个机房，差不多有两三百台机器吧。但是每个月的业务都在涨，所以运维部门很头疼，就像我刚才说的每个月都要采购设备、上架设备。然后那个机房容量还有限，可能快满了。那再部署一个机房，整个周期又很强，所以我们跟他说，你把服务部署在腾讯云机房吧，我们第一可以给你非常高的安全防护，第二我们的性能又非常好。在这样一种情况下，两个机房如何打通，我们建设了一个VPN，是一条加密的隧道，那么从它的自有的机房能够同步到我们腾讯云的机房，通过数据库同步，把数据同步过来。
实际的情况呢，从北京的机房到我们上海的云机房，通过VPN打通之后，数据库的延时是60毫秒，远远超出大家对这个事情的预期。
问题二：安全问题，总有几个“友商”不太喜欢你的应用
社会很大，总有几个厂商不太喜欢你们的应用。那么这样的情况下，DDOS的攻击，目前的情况来看是越来越频繁地在出现，而且花样也越来越多。以前说的最多的是DDOS攻击，现在CC攻击、主机入侵、木马植入这种情况越来越多。
还有新的一种情况，在我们O2O里面是比较明显的，就是O2O的这些信息平台都很关注它的上面的商家的信息。那么同类应用出来的时候，总是想把这样的商家的信息给扒过来，这样的情况对于O2O的应用来说也是不太能忍，他们也会来求助我们有没有防扒的一些手段。
还有安全防护。尤其举办重大活动的时候，比如说饿了么要举行一个美食街，举办重大活动的时候被攻击、被打趴下，那这个业务基本上没有办法干了。
在安全层，腾讯云有全方位的安全防护体系——宙斯盾+大禹、洋葱、WAF防护。
“宙斯盾”是安全防护非常重要的一个组件，腾讯所有自己的业务也都在用这个服务。它有几个特性，当有用户打击你，对你这个应用进行攻击的时候，这个“宙斯盾”会在几秒内探测出来，马上开启防御，几秒就开启防御了。然后它会把攻击流量转移到另外一个地方去，进行流量清洗，以保证正常的流量能够正常的进来，大概是这样的。
它整个的反应是很快的。刚开始也没有这么快，我们已经打磨挺长时间了，现在可以做到几秒内马上就可以进行响应。前阵子，有一次大的攻击，是500G流量，对我们的一个机房进行攻击，它快速作出了响应，几秒内就把攻击流量转移到另外的一个地方去了。那么其他的流量都能够正常进来，我们所有的业务都能够正常的去运作。像这样一个问题，如果说你不是放在云机房的话，可能碰到这样的情况还是挺棘手的。
自己去应对、去解决这样的一个问题是非常棘手的。我们也碰到很多客户，也包括游戏的客户，也包括应用的客户，那会被打的开不了门，一下子就被打趴下了，这样的话其实业务就没有办法正常开展了。那腾讯对安全一直向来都非常重视，我们的QQ业务也在用它，我们的微信业务也在用它。
“大禹”，“大禹”这个防御体系跟“宙斯盾”有点不太一样。“宙斯盾”是在机房前头加了一个防御盾，谁来打我，我就把流量干掉。那么“大禹”是说我在全国有400多个接入点，我在域名解析的时候就是就近解析到某一个节点去的。那么再通过那些节点再到我们的云机房。
当有用户来打击的时候，域名解析、我可能把它解析到某个OC节点上，它打趴下一个节点，我其他的节点都还是正常的。它打趴下哪一个节点都没有关系。那么我们这套的“大禹”的分布式的防御系统，最高可以支持2T的DDOS攻击，所以这个容量已经是非常高了。
腾讯云工程师蔡璞：从35万到600万订单，滴滴打车差点崩溃
2014年，移动应用排行榜上排名前10个APP几乎都是BAT的，但是这个原因肯定有很多。其中一个很重要的原因，就是BAT在这么多年长期的运营积累的海量运营的经验，为他们旗下的这些APP是添上了翅膀。
那么日订单35万的APP和日订单600万的APP应用有什么区别？大家知道APP应用其实是客户端和服务器端共同来完成的功能。那么对于客户端来说，可能就是一些界面进行优化，然后功能有些叠加。但是在服务器端，那就真的是要做到性能、架构有质的提升，上的不是一个台阶，可能是很多个台阶。
今天要讲的从35万到600万订单的应用其实就是滴滴打车。
滴滴打车，2014年和快的死磕的时候，其实拼的、烧的是钱。但是拼的是他们的后台的服务器。当时的情况就是谁扛不住、那谁就输了。
滴滴打车，目前2014年全国使用滴滴打车的用户超过1亿，那2014年平安夜单日全国用滴滴打车出行人数超过了3000万人。对比2013年，滴滴打车月活跃用户增长了600多倍，而打车成功率是高于90%。这个数字看起来是很客观的。但是现在滴滴打车在腾讯云上的架构，我们是评估过的，日订单量再翻一倍也是没有问题的，我们能扛住的。
那么这种架构是怎么实现出来的，罗马不是一天建成的，但是滴滴打车这种架构也不是一下子就做成了的。
2014年初，腾讯云开始和滴滴打车接触。腾讯云开始接触滴滴打车的时候，滴滴打车当时是流量上去了，但是用户体验是快速下降了的。这个反映就是在用户下单的时候下不了单，司机抢不到单，然后这个应用可能就会出现整个应用就卡在那里，或者是干脆用户就关掉、退出。这么差的用户体验的根本原因就是它的后台架构上的问题，它的后台当时已经扛不住了。
比如说出现个LVS单机故障，也就是单点，整个一个系统的关键节点出现问题，一个主件挂掉、那么整个路径就全部挂掉。还有一个就是存储系统的故障，然后还有网络故障，交换机流量满了。因为当时不是BGPIP的，所以说在不是BGPIP的，在跨网、跨运营商的时候，在流量高的时候就会出现丢包率高、延时高，用户体验就下降了。
还有一个就是Webserver扛不住，他们当时Webserver用了很多，有状态的，就导致它需要扩容的时候根本没有短期内把它扩上去，就机器都加不上去。还有就是Mysql扛不住，链接数上限这些问题。
滴滴打车是有三个主要的问题，一个是用户的下单，第二个是司机抢单，第三个就是系统分单。其中用户下单的时候，用户下了单会不停地看这个单的情况，而司机抢单的时候，他抢了单会不停地上报他的坐标，还有就是系统分单、它会有很大的计算量来匹配司机和用户。所有的应用的关键点都落实到他们的数据上，都是到Mysql上面来。所有的大量的数据读取，都是他们的Mysql来扛。当订单量大的时候就扛不下去了，很多的应用最后就卡在数据库这里了。
对于这些问题，腾讯云给出了解决方案。LVS大家都很熟了，就是对于这种开源软件，创业者其实很喜欢用，非常简单，方便快捷地部署起来就能用。但是开源软件有个问题，就是当上量商业化之后，会出现很多你意想不到的奇奇怪怪的问题出来，那么没法解决的，这不是说写开源软件的一些大牛们没法解决这些问题，说是他当时写这些开源软件的时候，他都不知道当你的量上去之后会有这么复杂的情况需要你来处理。
腾讯，其实也是经历了从开源软件的这种过程过来的。我们以前也用过LVS，现在发展到了我们自己的外网负载更换系统，我们内部叫TGW，它是多个集群来组成的，而每个集群目前标配是4台机器，但是这4台是可扩容的。就是说这个集群里的单机的pps可以达到120万，但是我们通常到80万的时候就开始进行扩容了，就跑到120万，集群链接数可以到1.2个亿。
还有就是腾讯云有百G出口带宽，它有BGPIP，那么就解决了跨网、跨容量、跨运营商的网络之间的这种问题。
分系统解耦，其实这就是解决你有机器、你架不上去的这些问题，来让你的设备、你的系统能够平行的扩。
Nosql高速缓存，把它的那些常用的热数据用Mysql这种可以高并发的、内存很快的速度来把它扛下来。
高性能的CDB。其实高性能的CDB，目前就是我前两天和我们做数据库的总监谈过一次，他说我们现在测出来的我们实际的高性能CBD马上推出来，可以到4W+qps。
最后就是机房保障。
腾讯在这么多年的海量运营过程中，其实是积累了一套很完善的机房建设标准的，只要你的业务放在腾讯云上面，要么你的机房保障，其实是和QQ、微信这些应用的机房保障条件是完全一样的。
