打造一款亿级应用你会碰到哪些问题?

标签: 产品经理 产品运维 | 发表时间:2015-04-22 22:08 | 作者:小核桃
出处:http://www.woshipm.com

饿了么原来有一个机房,差不多有两三百台机器。但是每个月的业务都在涨,所以运维部门很头疼,每个月都要采购设备、上架设备。机房满了再部署一个机房,整个周期又很强,最后不得已把服务部署在云机房。

A11

上周,腾讯云举 办了“最强应用,由你智造”的沙龙活动。 腾讯云的商务合作负责人王志永表示,腾讯云开始做应用的时候,有许多血的教训。尤其是服务的微信、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、微信这些应用的机房保障条件是完全一样的。

来源: 钛媒体   作者:


互联网从业者必备微信公众号:woshipm,如果你已经关注了,证明你已经很牛逼了。

相关 [应用 问题] 推荐:

背包问题应用

- Shengbin - 董的博客
背包问题不单单是一个简单的算法问题,它本质上代表了一大类问题,这类问题实际上是01线性规划问题,其约束条件和目标函数如下:. 自从dd_engi在2007年推出《背包问题九讲》之后,背包问题的主要精髓基本已道尽. 本文没有尝试对背包问题的本质进行扩展或深入挖掘,而只是从有限的理解(这里指对《背包问题九讲》的理解)出发,帮助读者更快地学习《背包问题九讲》中的提到的各种背包问题的主要算法思想,并通过实例解释了相应的算法,同时给出了几个背包问题的经典应用.

苹果iOS 5限制应用本地存储问题

- linsen - 月光博客
  苹果 iOS 5 系统增加了一个新的机制——在设备容量空间不足的情况下自动清除高速缓存文件或临时目录的内容. 这意味着,如果你设备的容量快到极限了,应用存储的很多离线内容,包括文章、杂志、图书、漫画以及其他数据都将被清空. 如果用户需要,将不得不重新下载这些内容.   关于苹果 iOS 5 的这次“变革”,困扰了不少开发者.

thrift 应用以及一些已知的问题

- - Taobao QA Team
thrift 是由facebook贡献,目前由apache在推进的一个开源项目. 它主要是作为一个可靠的RPC 框架来使用,当然它也包含了序列化与反序列化的功能. 对比其他的具备类似功能的开源工具,thrift在语言支持、性能、可靠性、易用性上具有相当的优势. C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, Smalltalk, and OCaml等,十分方便在不同的语言或组件之间交互和协作.

眼动研究介绍:应用价值与问题

- - 所有文章 - UCD大社区
随着用户体验的兴起与技术设备的进步,眼动研究已经越来越为人熟知,国内更多的研究咨询机构或企业自身开始配备了眼动仪. 但对于眼动技术与研究方法,许多朋友们仍然是雾里看花水中望月,希望进一步了解眼动研究的作用,学习分析使用的方法. 其中大家最关心的问题之一是眼动研究有什么特殊作用. 本文的目的是对眼动研究做一个浅显的介绍,并回答是什么与为什么的问题.

文章: GUI应用的若干问题和模式

- - InfoQ cn
我们所开发的应用程序大多都需要提供一个图形用户界面(GUI). 模式可以帮助我们建立优雅的架构, 但前提是弄清楚模式的应用场景. 这些模式自然不是凭空产生的, 都是为了解决具体的问题. 模式在实现上的差别, 通常都体现了在约束间的不同取舍, 以及问题的差别. 弄清楚GUI应用面临的设计上的问题, 有助于我们正确的挑选设计方案.

LBS应用货币化面临的四个问题

- - 雷锋网
有人说,2013年LBS应用该考虑货币化问题了. 美国市场研究公司ABI Research发布报告指出,在应用内广告和游戏化策略的共同推动下, LBS应用整个2012年所创营收约为40亿美金. 对开发者和营销人员来说,这听起来是个不错的财路. 但事实上,LBS应用的货币化仍面临严峻挑战. LBS应用自打面世以来就引发了许多关于隐私和安全问题的讨论,媒体针对某些LBS应用泄露用户数据也有诸多报道,而用户因使用LBS应用导致人财两失的新闻也不在少数,各方原因更加深了用户对这类应用的不信任.

Java Web应用Web层异步化应该考虑的问题

- - 企业架构 - ITeye博客
        之前做了一个项目,要用到web层的异步化技术,在实际实现中,遇到了很多问题,作为教训简单罗列下. 1、app 容器/J2EE框架对异步的支持.         在tomcat5、jboss4的时候,每一个请求都用了一个app容器线程来执行,app线程必须一直处理完或者等待别的线程处理完,才能拿着请求的链接把结果写回到客户端.

关于android应用退出的问题(转)

- - 移动开发 - ITeye博客
看到很多关于应用退出的问题,今天在这里为大家简单总结一下,如果说的不对还望大家见谅. 方法一:System.exit(0) 和android.os.Process.killProcess(android.os.Process.myPid()),我想很多人都尝试过,当关 闭多个Activity的时候这两个方法根本不起作用,原因当然和Activity的堆栈管理有关.

打造一款亿级应用你会碰到哪些问题?

- - 人人都是产品经理
饿了么原来有一个机房,差不多有两三百台机器. 但是每个月的业务都在涨,所以运维部门很头疼,每个月都要采购设备、上架设备. 机房满了再部署一个机房,整个周期又很强,最后不得已把服务部署在云机房. 上周,腾讯云举 办了“最强应用,由你智造”的沙龙活动. 腾讯云的商务合作负责人王志永表示,腾讯云开始做应用的时候,有许多血的教训.

预示应用性能问题的十大征兆

- - ITeye资讯频道
一年一度的双11、双12全民网购节已经过去,淘宝、天猫及其他电商都迎来了大量用户,但是,你的基础架构能否承载突如其来的流量. 面对预期而至的大量用户,容量规划是否到位. 线上商城以及后端系统是否经受住了性能的考验. 对于任何互联网电子商务的成功,有两件事至关重要:创新与性能. 创新是打入市场的通行证,而性能则决定了能否在市场中长久立足,如果网站性能差强人意,那么就没有用户会愿意再次访问.