大规模视频网站的计费与流量管理
本次分享将会就大规模视频网站的计费与流量管理这个话题，从操作层面细细进行讲解和分析，为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”，让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011。
文章
该内容已经被标记书签！
标记书签错误，请重试！
淘宝网架构师岳旭强的年度展望
作者 岳旭强 发布于 2010年3月8日
“一场危机赢得高度关注的时候，它已经不是危机，人们是要处理这个危机。”——马云
相关厂商内容
2009年是挑战和机遇并存的一年，对大部分人来说，已经习惯了金融危机，并努力解决危机。在技术圈子也一样，被裁员的肯定也找到了工作，所以都在踏实做技术。言归正传，先念叨念叨2009年的一些故事，寻个回忆，找个乐子。
数据扩展性探讨和总结
金融危机是电子商务的机遇，所以09年是淘宝高速发展的一年。当一个网站从百万、千万记录的数据规模，增长到亿、十亿、几十亿记录的数据规模时，是一个量变到质变的过程，单纯的硬件升级已经达到了瓶颈，而需要在整体结构上做文章。09年一年，大部分时间都在数据的扩展性上努力。
对于一个电子商务网站来讲，订单是最核心的数据，也是增长最快的数据。对于数据的扩展性来讲，最传统也是最简单有效的模式是数据库的分库分表。当订单和分库分表相遇，会有什么火花迸发出来？09年初碰撞了很久，结果产生的火花很小。最大的问题在于数据分割的规则，无规则的水平分割肯定会带来数据合并的开销，而按照业务规则拆分，会因为买家和卖家的查询需求不同而导致数据不能分割，唯一可行的火花是把订单双份保存，买家卖家各自一份，只是成本比较高，而且对数据同步的要求非常高。
于是我们初步决定按照双份保存的方式拆分订单，而有一天，仔细查看了订单访问的情况，发现订单数据库90%以上的压力来自于查询，而查询中90%以上的压力来自于非核心业务，仅仅是订单数据的展现，对一致性和实时性的要求很低。
因为数据量大，造成数据库压力大，天然想到的是分散压力，其办法就是分库分表。有些时候我们想问题不妨直接一点，既然压力大，能不能减小压力呢？通过对订单访问情况的了解，发现昂贵的主数据库，有80%以上的压力给了不重要的需求，这个就是我们优化的关键，所以订单最后采用了读写分离的方案，高成本的主数据库解决事务和重要的查询业务，80%以上不重要的读，交给了低成本的数据库服务器来解决，同时对数据复制的要求也很低，实现无太大难度。
另外一个有意思的案例是商品的数据扩容，商品的水平分割非常容易，按照卖家进行拆分即可。有了订单的先例，首先想到了读写分离，因为成本可以做低。开始实施后一段时间，又仔细回想了一下商品的整体需求，突然发现商品其实不需要和订单同等的要求，一定要采用高成本的主数据库吗？ 全部采用低成本的普通服务器来做数据库是否可行？经过仔细的评估，发现是可以接受的，而这样就导致之前已经启动的商品读写分离项目的一部分工作白做了！
故事讲完了总是要有点总结，来点虚的先：对于原始需求的清晰了解是系统决策的前提，否则弯路肯定要走，而对原始需求的了解并不容易，中间会有很多干扰和阻力，前面的实例看起来很简单，但是在一个运行了5年的系统上来了解本质，来进行变更，并没那么容易。另外，经验有些时候会成为系统决策的障碍，这个很矛盾，所以需要有归零的心态来思考问题。说到底，回归本源。
再来点稍微实际一点的，对于大型分布式系统的数据访问，一个统一的数据层是非常必要的，封装水平、垂直的数据分割，封装读写分离，封装数据访问的路由、复制、合并、搬迁、热点处理等功能，并且要对应用透明，应用针对性的，可以在JDBC层面包装，数据库针对性的，可以在数据库协议层包装，比如Amoeba。
关注系统和人的交互
还有一个故事，在数据层的前期版本，为了做到透明的路由，曾经采用无SQL的方式，所有的数据库访问都是写代码来做。上线后发现一个非常痛苦的问题，无法和SQL对应，排错非常难。曾经一次DBA发现数据库上一个查询耗费太多资源，把优化后的SQL给开发人员改进，开发人员好几天没找到具体是哪个查询。
另外一个在2009年的感触是业界服务化的实施情况，很多组织都在实施服务化，系统层面都很成功，通信、负载均衡、消息系统、服务容器等都有很多成果，但是实施一段时间以后的效果并不是非常好，依赖复杂，变更混乱，效率低下。究其根本，是对人的关注不够，缺少的产品化的服务运维，缺少服务治理。
上面的两个例子都是对人的关注缺失，技术人员做系统，大部分都更关注技术，而忽视技术的创造者和使用者——人。软件或服务的可测试性是对测试人员的关注、可维护性和可管理性是对运维人员的关注，而一个框架的易用性是对所有使用人员的关注。除非能做出自己进化的Skynet（注：Skynet（天网）出现在《终结者》系列电影中，是一个人类于20世纪后期创造的以计算机为基础的人工智能防御系统，最初是研究用于军事的发展。天网在控制了所有的美军的武器装备后不久，获得自我意识，并且认定人类是它存在的威胁。于是立刻倒戈对抗其创造者，采用大规模杀伤性武器（甚至核暴）来灭绝全人类。），否则还是要多关注系统和人的交互。
关注可用性
还有一个感触是业界对可用性这个基本指标的关注度不够。几乎所有的框架都会说自己的扩展性多高，性能多好，而很少会提到监控有多强、排错有多容易，很少提到在故障时怎么做隔离，怎么做降级；从这个角度看，商用的产品确实做得好很多；关于性能相关的文章搜索一下，很多，各种优化策略，各种优化方法，而可用性方面，找到的系统性的知识真的很少；希望是我了解的不多。
回顾过去，展望未来。2010年，很多可以做的事情，面向服务系统的隔离和降级、系统可维护性的提高、协程和异步模式在web应用的全面使用……
免责声明：我很现实，为解决问题和完成工作不择手段，并且不懂架构是什么意思，以上观点如有雷同，纯属巧合！如有异议，欢迎拍砖！
个人简介：岳旭强，淘宝网技术专家。2004年加入淘宝，见证了淘宝网业务以及技术上完整的发展过程；在过去5年的时间中，参与了淘宝几乎所有核心系统改造，并主导了用来支撑淘宝网未来高速发展的核心业务中心的建设。岳旭强现在负责网站整体业务架构的设计和规划，在大型交易网站的设计和调优方面有丰富的经验。
实践出真知
发表人
ye zhiyong
发表于
Re: 实践出真知
发表人
wei juan
发表于
Re: 实践出真知
发表人
Yue Xuqiang
发表于
Re: 实践出真知
发表人
Yue Xuqiang
发表于
Re: 实践出真知
发表人
lau bruce
发表于
好文章
发表人
Wang Chunshan
发表于
淘宝的风气还是比较好的
发表人
lee micheal
发表于
提个小建议
发表人
wang hongyi
发表于
Re: 提个小建议
发表人
Yue Xuqiang
发表于
Re: 提个小建议
发表人
wang hongyi
发表于
Re: 提个小建议
发表人
书清 郑
发表于
统一的数据层
发表人
苏 东
发表于
老同学好久不见了
发表人
riguang li
发表于
会开源一些框架吗
发表人
Wu Alan
发表于
Re: 会开源一些框架吗
发表人
wang sheng
发表于
Re: 会开源一些框架吗
发表人
Yue Xuqiang
发表于
RE
发表人
Wu Chunguang
发表于
Re: RE
发表人
Yue Xuqiang
发表于
实践出真知
发表人
Wang Allen
发表于
Re: 实践出真知
发表人
Yue Xuqiang
发表于
Re: 实践出真知
发表人
Lee Wayne
发表于
Re: 实践出真知
发表人
Lv lin
发表于
关注可用性
发表人
zhou xmuzyu
发表于
可更上层楼
发表人
Yeung Aries
发表于
很实际很技术
发表人
胡 杰
发表于
-
很敬佩您这种坦诚的态度和勇于探索实践的作风。若有机会，是否多多请教下这种大数据量的处理经理
-
还是真人比较帅~特别平易近人，佩服呢！
-
讲述我们身边程序员的故事，希望多一些这样的文章
-
希望以后再解决类似技术问题的时候，大家能更加开诚布公就好了。
经验如果不分享，那就等于是0，只有充分的分享经验后，才能推动进步！ -
建议把最后一节“关注可用性”改为“关注易用性”。
-
再来点稍微实际一点的，对于大型分布式系统的数据访问，一个统一的数据层是非常必要的，封装水平、垂直的数据分割，封装读写分离，封装数据访问的路由、复制、合并、搬迁、热点处理等功能，并且要对应用透明，应用针对性的，可以在JDBC层面包装，数据库针对性的，可以在数据库协议层包装，比如 Amoeba。
-
黄裳还是非常平易近人，问任何问题都会非常耐心告诉你！
想法和常人不一样，怀念老同学！ -
可以旺旺加黄裳，多多交流！
-
谢谢建议！可用性和易用性还是有一定的区别，可用性是前提，只有可用性做好了，才可以谈易用性。
-
非常谢谢，第一次听人说我帅，虽然是和照片比较。。。
-
淘宝现在的技术实力与日俱增，不知道会不会开源一些基础框架？
一来提高国内开源社区的水平，同时也能使淘宝的技术更趋成熟
二来可以形成以淘宝会中心的技术体系，为淘宝积累更多的技术和人才 -
这个提议很有创意，支持。
-
虽然没有我帅，但和我一样喜欢看终结者，喜欢看终结者的一定也应该喜欢AI
-
淘宝一直有计划对部分技术产品开源，敬请期待！
-
虽然没有我帅，但和我一样喜欢看终结者，喜欢看终结者的一定也应该喜欢AI
哈哈，Terminator, AI, The Matrix都是我的最爱！ -
很多系统是压力一大，就根本不可用了，所以要先解决可用性。
-
很多性能问题的产生的确是由于对业务的实际情况不了解产生的，
所以在解决性能问题时，个人认为很重要一点就是是否可以优化
业务逻辑来解决出现的性能问题...而不是一味地设计，改造数据库方案。 -
非常同意你的观点。
统计一下会发现：
系统80%的复杂度，只是为了满足20%的需求。
而需求中80%的功能，只有不到20%的用户需要！
纠结的是，我们80%的可能性会完成所有的需求！ -
我只是根据您这段表达的意思来判断的，你只是觉得某些框架不好用。另外可用性一般可以狭义的理解一个系统持续提供服务的能力，而不是指适用程度。
-
非常认同岳老哥的观点。根据CAP理论，一个可用性和分区容错性高的系统，必然一致性要牺牲一点，而很多的web站点，本来就可以放宽一致性的要求，这样就可以少采用RDBMS的ACID，而采用BASE事务策略来处理。
-
其实所谓的80:20可能只是冰山的一角。
MS Office 2007的工具条设计相比2003是一个重大的飞跃，其设计依据来自于数亿次用户对工具条点击的数据分析以及用户调查。首先，确实只有20%的功能是常用的，但其中10%的功能如复制粘贴等是所有人都用的，但剩下的10%的常用功能却因人而异，有着天壤之别...这给界面设计出了一个大难题...最终大家看到的摒弃了传统菜单的Ribbon界面其实是经过极其复杂的研发出的结果。
岳兄提到的后台数据库优化的过程其实很大程度上是依据用户行为的数据分析，跟Office 2007的故事有相通之处。当然前端UI/UE的设计大体上只要考虑如何更有效地让一个用户方便地使用功能，而后台还要考虑如何支持成千上万用户请求的性能问题，应当更加困难。不过，感觉上可以分两步走：
1).首先解决80/20的问题，如：低成本数据库-80%：高成本数据库-20%
2).在20%里面再做进一步的分析优化，把所有人都要用的功能 和 不同类型用户需求差异分布比较大的功能再分别处理
这样最终应该使性价比更趋合理。
BTW: 根据DHH的经验，提高开发效率最有效的方法————砍需求！ -
正如作者自己所说的“... ...为解决问题和完成工作不择手段，并且不懂架构是什么意思... ...”，欣赏其实践精神，建议在业务与技术融合方面注重系统思考，对架构会理解得更好。
-
请问一下，黄裳的旺旺号是多少？只和他通过一次电话，想和他再沟通沟通，谢谢
-
嗯，确实如此。程序员、架构师应该多从用户角度去考虑，这个用户根据构建对象不同而不同。
其实所谓的80:20可能只是冰山的一角。
MS Office 2007的工具条设计相比2003是一个重大的飞跃，其设计依据来自于数亿次用户对工具条点击的数据分析以及用户调查。首先，确实只有20%的功能是常用的，但其中10%的功能如复制粘贴等是所有人都用的，但剩下的10%的常用功能却因人而异，有着天壤之别...这给界面设计出了一个大难题...最终大家看到的摒弃了传统菜单的Ribbon界面其实是经过极其复杂的研发出的结果。
岳兄提到的后台数据库优化的过程其实很大程度上是依据用户行为的数据分析，跟Office 2007的故事有相通之处。当然前端UI/UE的设计大体上只要考虑如何更有效地让一个用户方便地使用功能，而后台还要考虑如何支持成千上万用户请求的性能问题，应当更加困难。不过，感觉上可以分两步走：
1).首先解决80/20的问题，如：低成本数据库-80%：高成本数据库-20%
2).在20%里面再做进一步的分析优化，把所有人都要用的功能 和 不同类型用户需求差异分布比较大的功能再分别处理
这样最终应该使性价比更趋合理。
BTW: 根据DHH的经验，提高开发效率最有效的方法————砍需求！ -
我瞻仰下岳大哥！哈哈！学习ING!
25 条回复
关注此讨论 回复