淘宝CDN大规模并发优化学习和点评

说明：本文内容来自门户taobao团队，为老男孩linux运维实战培训[/b]教学案例之一
我现在在杭州的淘宝研发中心，在对康伯做采访。康伯先跟我们大家介绍一下你自己，包括你的团队。
大家好，我是康伯，这是我花名，我的真名叫XXX。我的团队是负责整个淘宝的CDN的建设、运维。
我们也知道，这一次淘宝“双十一”事件，其实CDN这一块也面临着非常大的压力。我们想了解一下，在这个事件之前，你做了什么样的预案？在整个的事件发生的过程当中，预案和你整个的一个实际的情况有哪些比较大的差异？
我们第一时间知道这个活动的时候，就对我们的系统做过一些评估。当时，我们预计流量会增长大概30%左右。在预案中认为我们的系统是有30%的余量的。但是我们觉得30%是不太够的，我们临时采取了一些措施，比如说去扩了一些性能不太好的一些点、内存，又去到上海又去临时建了一个点，包括在杭州的一些地方，我们都去临时增加了一些资源，把整个系统这个能力扩大到了50%左右。
老男1孩点评：[/b]上面内容是对即将到来的流量的预估，未雨绸缪，这是我们做运维的要特别注意的，预留资源，不要可丁可卯，在预估的流量基础上又加了很多服务点，比预估的流量多20%-50%的流量准备，赞！那么是不是够用了呢，我们继续往下看。
但是还没有到这天活动的时候，我们就发现我们的这个预案做得不够，活动开始前的一天，流量就已经冲到了一个新的高峰，在这基础上，双十一这天流量就会达到我们当时整个设计的一个顶峰值。如果这样就意味着我们的服务质量可能会下降，可能会放弃一些用户。针对这些情况我们又临时调整了预案，比如说是否要临时的放弃一些用户，或者说再增加一些节点等。
老男孩点评：[/b]当预估不足时，就考验网站的架构健壮和团队的临危应变处理能力了。在高并发高流量时，放弃一些用户是不得以的做法，但有时也是必要的，否则整个服务质量会极度下降，甚至发生雪崩。壮士解腕虽不可取，但有时是不得以而保全大局的办法。当然，正确预估提前做好准备是最重要的，临时的加点（后备资源）能力也是需要具备的。注* 成语：壮士解腕 勇士手腕被蝮蛇咬伤，就立即截断，以免毒性扩散全身。比喻作事要当机立断，不可犹豫不决。“壮士解腕”的措施要提前请示相关领导，以免造成其它饿果。
这里老男\孩举个战争的例子，也许关系不大，但还是想说下。话说大将军卫青带领大兵深入匈奴腹地寻找匈奴主力打击匈奴，汉武帝在甘泉宫（远离国都的一地名）指挥作战，原投降汉朝的将领赵信部又再次投降匈奴老大依志斜单于。由于卫青的军队都是精锐，很牛，匈奴不敢正面作战，正无计可施，赵信想起来一条通往甘泉宫的小路（老鹰涧，曾经和卫青一起走过），只能一人一骑通过。于是建议依志斜单于派兵3000，他来偷袭甘泉宫活捉汉武帝。从此路走，一夜即可到达甘泉宫。
这一招非常要命，幸好卫青提前获得了赵信部队奔袭老鹰涧的消息（一个猎人汇报的），但是，回师是不可能了，因为，大部队辎重人数多，距离又远，无论如何一夜赶不回去，而且，大军回师，匈奴主力会乘胜追击，也非常危险。
于是，卫青采取了一个不得以的被动方案，大兵原地不动，把兵权交给身边的将军，只带着飞将军李广两人快速返回。两人回去怎么能抵挡匈奴3000大兵呢，皇帝的身边就几百人护卫。
这是因为卫青知道唯一能救驾的的军队就是，距离甘泉宫比较近的烈士后代组成的还未上战场的娃娃军，约3万人，但是这部分人必须有汉武帝的亲昭才可以调动。
卫青星夜赶到娃娃军驻扎地，说明紧急情况，皇帝危在旦夕，仍然调不动这部分军队。情急之下，卫青拿出了当年太后调兵的虎符（这是调兵的最高信物），结果调动了这3万大军。于是，赵信匈奴部马上奔到甘泉宫时，正被卫青堵个正着，赵信一看汉军早有准备而且人多，灰溜溜的撤走了。
这时卫青赶到甘泉宫见到汉武帝说明情况，结果被汉武帝一顿质问：
a.不在前方指挥军队，为什么不打招呼，而擅离值守？---> 这在汉代是重罪。
b.你是怎么调动朕的娃娃军队的--->前面已叙述，这个军队必须皇帝亲自下昭才能调动。
结果，卫青虽然救了驾，却被汉武帝收回了调兵虎符，有意无意削夺了兵权，冷落了好几年。
临危时，最能考验一个人的水平和魄力了，从卫青的思想看，这次救驾是无可指责的，是有功劳的；可在老大看来，却是另一个想法。救驾虽好，但让老大看到了权利危机。卫青今日能调动军队救驾，明日就有能力调动军队造反。是不是很可怕，如果你是老大，你觉得是不是？
本例意在说明：[/b][/b]
a.[/b]重大事情考验一个人的真正能力和魄力。[/b][/b]
b.[/b]事前要先申请，事后要回报，这个是做下属必须要遵守的，否则，后果不堪设想。[/b][/b]
c.[/b]面对最紧急的问题，你觉得做的很好，但老大未必满意。相反，也许老大的反应也许不是你想得到的结果。[/b][/b]
d.[/b]知己知彼，未雨绸缪是重中之重，是成败的关键，兵法里是，网站运维也是一样的。[/b][/b]
e.[/b]很多事情只能有舍有得，无法兼得，卫青冒着丢失性命的危险，去救老大了。是个好员工。运维工作也有很多这样的情况（如网站宕机了，需要做调整，是先搞定还是先申请？），人生何尝不是如此。会做的也要会表现才更好，方式方法要得当。不是对的就能做的对。在培训中老[/b]\[/b]男孩老师特别在意给中心的学生介绍这些经验，这些也许比技术本身重要的多。[/b][/b]
在双十一的一早，我们就发现了，情况比我们预想的还要复杂。当时那天早上九点的时候，我们就发现流量就已经窜高到了整个设计的极限值。按照我们的经验来说，晚上比早上的早高峰还要高30%的，那等于说我们整个系统缺少30%的能力来支撑。我们马上采取了很多措施，最主要的简单说来就是开源节流，当时第一反应就是调动的所有资源投入到CDN系统去，保证它不出问题。当然前面介绍到说我们可能会放弃一些用户，但那是我们到了不得已的时候才采取的措施。事实证明我们当天做完一些措施之后，就没有去用这种极端的措施。那我现在来说一下当时我们主要做些什么：第一个在杭州，我们可以调动资源的地方，及时的去增加资源，这样在晚上高峰来临之前，我们能多余出20G的流量；我们又跟各地的运营商去沟通，因为有些运营商我们跟他签了一个协议，比如说是我们只能跑到10个G，或者更少。但是应对这个突发流量的时候，我们去跟这些运营商沟通，说把我们的带宽的能量打开。实际上很多节点到当天都是跑过了10个G的，最高跑到了16个G，这是在我们以之前不敢想象的。实际上这个能够支撑这么大能量也依赖于我们之前对于服务器、对于整个架构的优化，后边我们可能会说到。
老男|孩点评：[/b]在选CDN时，除了质量等关键信息外，要求机房能临时快速增加带宽也是谈判的内容（合同里要有，平时流量不太高时就请机房开带宽演示下，不要让合同成了废纸，到用时没资源或者不理你），很多同学问我DDOS如何解决？让机房临时加带宽就是个办法，当然，自身的架构也要能顶的住。这点taobao做的确实很棒。能短时间调动10几G的带宽。可能你会说，taobao是大客户受重视，这是一方面，他们调用这么大的带宽资源，不光是客户大小，事先在各种准备上也一定做到了位。2赞。
补充3篇DDOS解决相关文章，
1）DDOS攻防17条经验 /article/4128305.html
2）轻松应对IDC机房带宽突然暴涨问题 /article/4225393.html
3）千万级PV/IP规模高性能高并发网站架构/article/4130410.html
另外一个在业务方面我们采取了一些节流的措施，来保证这些压力不要一下子冲到我们CDN上来，比如说我们的活动页面是非常大的，上面有非常多的大图，我们发现这个活动页面给我们的流量压力带来非常大的冲击。我们就及时找UED的同学去做优化，把页面尽量优化缩小又不影响用户感受。比如说延迟加载，当用户打开页面的时候，先显示首屏的一些图片，底下还有六七屏的图片只有在用户往下拖动的时候才会显示出来，这样我们节省了很大的流量；包括在我们一些上线详情页，也是采取了同样的优化措施，保证用户访问感受的同时，保证我们的CDN不被压跨。
老[/b]|[/b]男孩点评：[/b]平时给大家培训讲课时，大家想不到这样的场景，这么大的门户还会去找UED压缩图片，今天大家相信了吧。优化高访问量图片和延迟加载是很好的手段。小平同志说，黑猫白猫，抓到耗子的就是好猫；老男孩也说，黑方案白方案，能解决问题的就是好方案。在老男孩曾经的运维生涯中，也多次遇到过类似的问题，一张图片几百K，不到一日就产生近20T的流量，带宽占用过G，后来把图片优化为10K，流量瞬间骤减数十倍。
这里也顺便提下，前端优化都网站来说非常重要，如：apache和nginx的expires功能
优点：
1)提升用户体验（用户访问速度快了）。
2节省网站的带宽流量。
结果：既提升用户体验了，公司也少花钱了！
当使用了expires功能后，当用户访问了一次资源后，在expires时间过期之前，
就不会在去服务器下载该资源了，除非用户浏览器端主动清空浏览器缓存。
那么就会有一个问题存在，如果网站更新文件后，用户再访问时的内容还是旧的（上面已提到不会在下载了），怎么解决这个问题？
解答：
1)首先，对于大多公司业务来说，图片等资源一般很少会去修改。因此，taobao,360buy等公司可以肆无忌惮的把expires设置为10年。一年节省费用可能是上亿人民币。最重要的还有提供用户体验。
2)对于js,css偶尔会变化的资源，一般expires设置时间会比较短。如1-30天，或则，在更新上采取策略， 如，更新后以新的文件名发布，这样对于用户又是新的资源了。
3）特殊缓存，google首页expires一日（经常会变更图片），网站的js统计代码不会设置缓存，
如http://www.baidu.com/js/bdsug.js?v=1.0.3.0
当然其他模块也有同样的功效：如apache的压缩模块mod_deflate。
更多的前端优化，参考老男孩的培训视频或相关文档，大的方向可以参考yslow的14条。
再之后呢，我们发现流量的增长还是比较猛，我们又采取了一些其他的措施，比如说我们临时把某些页面的大图换成小图来节省流量，因为大图原来在CATCH前端都是存在的，如果把它换成小图，就涉及到这些图片可能要全部重新生成一次，对于源服务器的压力是非常大的，我们就采取了逐步切换的方式，先切换一个流量比较小频道，然后上线，观察这个对后端的压力，在看到这样对我们后端基本没有什么太大冲击的情况下，我们再逐步的把一些页面全部换成小图。但是我们仍然在我们的搜索的页面保留了大图的功能，用户在需要看大图的时候，还可以切换到大图，这样一方面节省了CDN的流量，保证我们的服务能力，另一方面也保证我们用户仍能得到一个高质量的访问。
老[/b]|[/b]男孩点评：[/b]这些是更细致的图片细节上优化。讲的非常好。老男孩曾经就这样干过。这是被逼无奈了。曾经一个朋友蹲拘留所了，后来我拖了关系把他搞出来了，跟我说，里面的窝头真好吃。汤也好喝。原来硬的象石头一样的窝头，和芥水一样的汤，都说很好吃好喝。因为，在里面饿的没得吃，就是这些还抢着吃。还带回来一个窝头当给大家展示，让我哭笑不得。
在采取过措施之后，晚高峰的流量也是被我们做过这些控制，还保持跟早高峰差不多。实际上等于我们一天节省了30%左右的流量。但在这个过程中还会有很多问题，因为我们的用户的分布不均匀，比如说在大的省市，流量的增长非常迅速，那为了保证这些地方的一些用户，我们可能会使这些地方的用户访问慢一点，但是我们保证了图片的正常显示；我们让他去访问周边的地方，比如说上海可能会到浙江来，广东的我们会让他去到广西这样的一些措施，然后保证整个访问质量不受太大影响，而且保证了我们的服务能力。
老男孩点评：[/b]中等规模以上的网站，架构的好的，都要具备全局调度的能力，简单就是一个机房一个地区的调度，复杂的就是全局的DNS全国各个市调度，就象指挥千军万马打仗一样，将“敌人”的大股力量分化瓦解到不同的城市节点，逐一“消灭”，那才叫爽。虽然切换到非用户所在地，牺牲了一些用户体验，但换来了，整体“战争”的胜利。3赞！
那经过这么多优化措施之后呢，我们那天是整体上是承载了一个比我们平常多了50%的流量，或者说在我们不做那些降级的优化措施的情况下是的80%增长的流量，在这样一个突发的情况下我们做到了。
其实这个事件的背后也是和其他的团队同力协作最终达到一个的结果，假设当初不和UED部门去协作的话，那你可能没有办法把这一块的流量给降下来。另外一个感触就是谢天谢地，总算双十一事件没有出现宕机等情况。那其实根据我们的了解，这也和整个CDN优化团队在过去一年的技术积累是非常相关的？
对，是这样的，在2010年初，我们CDN的流量还是比较小。那到了今天这个流量已经增长了四倍。双十一那天，与年初相比增长了大概六倍左右，这在我们以前是不可想象的。因为面对这样一个增长，可以说是一个爆发。如果我们不做优化，系统可能今天就会出现各种各样的问题，特别是面对双十一这种高压的情况下。
我给大家分享一下，我们在这一年里都做了一些什么样的优化。实际上对于我们整个系统来说，淘宝的CDN可能跟其他公司它的CDN面临的问题不一样，淘宝面临的是一个我们有巨大的商品数，和随之而来的巨大的图片量。这些图片量的访问热度又不像一般的CDN那样非常集中，因为有很多的商品，只有用户访问了十来次，几十次，这样对于CDN本身效果是不太明显的。
我们年初的时候有一个很大的挑战，我们旧的架构下边 CDN的命中率越来越低，最低的时候都已经降到了85%左右。实际上这样的话，带来的难题就是，我们的源服务器和二及CACHE的服务器能力要求非常高，那投入会非常大；另外就是，我们本身是希望CDN能加速用户的访问，但是一旦命中率比较低的时候，大量的回源反而会拖慢整个页面的访问速度，这样是我们不可接受的。
我们采取了一些优化手段：比如说我们原来对于图片的大小是没有预期的，年初我们的CDN开发团队，加上我们运维，对我们的访问做了一些详细分析，分析出到底现在这些图片它是多大，占多大的流量比例，预估了一下，如果我们要求命中率提高到96%、97%，会需要多大的存储空间。之后我们对架构做了一些改变，我们发现我们做到了命中率基本在96%、97%左右，这对于我们整个前端页面的响应速度是一个非常大的提升。
另外一个就是我们在之前用的是Netscaler或者F5这种硬件的这种负载平衡设备。这些硬件负载平衡设备有一个很明显的瓶颈，就是性能可能一般只跑到六个G或者七个G，那就不会再增长了。如果要再增长，就需要再加一套设备，这是一个非常大的投资。
还有一个问题是它们的一些算法有问题，我刚才介绍说，我们有非常多的图片的，在这种情况下，一台机器存的图片量不可能特别多，比如说我们只能存到三千万张图片。但是对于整个淘宝的图片来说，我们有两百亿张。那三千万张对于两百亿张这是很小的一个基数，而且我们又没有热点，那基本上来说这个命中率就降的非常多。那我们怎么应对这个问题？我们就需要做一些七层的URL 哈希的动作，就是说同一份图片我们只存在一台机器上，这样每个节点有30或者40台机器的话，就等于我们有可能存了有12个亿，那我们就占整体量可能有10%或者20%的图片来提高命中率。
但在这种情况下，硬件的一些算法又会有一些问题，最常见的比如说原来有30台机器，我现在要加10台机器进去扩容的时候，会发现原来所有的图片都失效了，全部要重新去缓存一遍，这对我们是一个非常大的冲击；另外一个情况正好相反，就是说我坏了一台机器时，也会发现同样的问题，这是我们不可接受的。我们的CDN开发团队就创新性的用了一个软件来解决这个问题，在整个架构中，把硬件负载平衡减掉，去掉了硬件的性能瓶颈，然后用LVS这一套开源的负载均衡来做这个调度，使我们的整个节点的性能一下子提升了一倍。
就像我刚才前面说到的，某一个节点在活动的时候跑到过16G、17G，在这个流量在以前用硬件负载平衡的时候是我们不敢想象也不可能做到的事情。我们用了LVS之后，在后端又用了一个叫HAproxy的软件，并上面做开发实现了一套，叫做一致性哈希的算法。在这个算法之下，像我前面提到的机器增减的问题都不会影响已有的内容的波动。比如说我们加了机器，它新的Object会到新的机器上去，但是旧的还是会分配到旧的，如果坏了一台机器也是同样的情况，只是坏了的那台机器所存在的Object需要重新去被存储，这就减轻我们整个运维的压力。
老男孩点评：[/b]这部分讲的非常好，虽然很多公司也是这么做的。4赞。在2009年初的时候，老男孩linux培训课程中就开始加入了lvs/haproxy 4-7层架构，这是一套非常不错的架构。L4DR模式支持大并发，L7层可以横向扩展，对于象taobao的CDN，可以采取多个图片域，多VIP（可在DNS层控制），然后采用多组L4-L7，而不是大家想象的就两台LVS而已。一致性哈希是大规模CDN的重要算法，尤其是解决宕机机器和新加机器的问题，在2009-2010期间，好多老男孩的学生去taobao面试都被考了同一个问题。大规模的百亿张图片数量如何存储类似的问题。
比较遗憾的是该篇内容没有透漏技术细节。有兴趣的可以加老男孩一起交流。
特别说明：哈希或一致性哈希是前端CACHE负载均衡常用的手段。

我们又做了很多其他的优化，比如说对于HAproxy我们去做客户端的keep alive，也就说长连接来减少用户建立连接的时间，这样平均每个请求可能会减少几百个毫秒，还有一些优化，就是说我们前面说的我们Object非常多，大家都知道，做Cache的时候，实际上很重要的就是命中率的提升。如果说热点相对集中，我们是可以直接把它放在内存里边的，如果内存放不下，我们就会到硬盘上去找。但是传统的硬盘性能非常差，比如说传统的SAS盘，我只能撑到一百多到两百的IOPS。对于整个节点，一两百的IOPS是不能满足要求的。所以我们就引入了SSD，但是SSD的成本又非常高，我们的开发团队发明了一套算法，把那些访问很集中的一些东西放在那个SSD盘上，因为SSD提供很好的一个读性能，我们就让这些80%左左右的这种读从SSD上产生，剩下的图片我们把它放在传统那种SAS或者更低廉的一些SATA盘上，这样我们整个节点的性能非常好，单机可以支撑三千到四千IO，这是我们系统没有任何显示出访问慢，或者其他不好的表现。
因为每台机器的成本又降得非常低，如果可以，比如说追求一个大的存储，我可以用全SSD，但是我SSD的成本相对要高很多，我可以用比较廉价的SAS或者SATA来存一些访问频度不是很高的，用SSD存访问频度高的文件，这样整体上的性能就协调的非常好，成本也非常低。整体上可以这么说，我们通过这样一年的优化，在原来硬件基础上投资50%实现了性能是原来两倍的一个架构。现在我们总体的这种TCO是原来的1/4左右。
老[/b]|[/b]男孩点评：[/b]热点数据存储的思路非常好，我在培训时讲到磁盘组成及原理的课程时和存储问题时，有关热点数据，必须要举的一个案例就是taobao的这个热点存储思路。现如今看来，对很多中小型公司还是很新颖的存储方式。顺便说下，大公司无论做什么都要考虑性价比问题，而不光是要把问题解决，因为，设备的奇数太大，做一点点就会节省非常多的成本。阿里，联想的大规模的云计算其实归根结底都在解决性价比问题，否则，就无法推向市场，真正的应用到商业市场中。
这个数据还是比较惊人的，在简单回顾一下，在整个优化过程中，有没有遇到特别困难的地方？
特别困难的话，实际上对我们来说，仍然是在这个我刚才提到的，没有热点，数量是非常多的情况。没有热点，就意味着我们要尽量多的把图片存到前端，我们在做URL哈希的时候，实际上是面临了很大的问题，我刚才也提到SSD，现在的规格只有160G，但是SAS或者SATA可以做到600G或者1T，我们现在每台机器要存大概三千万到四千万的文件，这个对存储容量的要求至少要有一个1T空间，用SSD的话成本会比较高，这是我们一直在优化的方向。另外就是流量这一块。
在接下来的两三年的时间，对于CDN团队来讲，主要的工作可能是什么？ 前面我们说到，就说整个一年除了架构以外，我们还做了很多工作。我们流量在涨到可能有四倍到五倍，这个就不光是去优化软件就能实现了，我们还做了很多部署的工作。
下面第一个，我们还是会大力的推进布点的情况。我们现在在全国有30多个点，基本上都分布在一些省会城市，或者说一线城市，比如北京、天津、上海、广州、杭州和其他省会城市。明年我们希望把这个点数量做到100个，这样我们就会覆盖大部分的二线城市，比如说像温州、嘉兴，或者东莞这种流量比较大的城市，后年规模可能会再扩一倍，到两百个点，这当然只是我们现在的一个期望。到时候我们可能说，每一个市我们至少有一个点，当地用户都去访问他本地，达到一个最快的访问速度。
另外一个方面，实际上我们现在在做很多其他内容的CDN尝试，比如动态的或者说HTTPS加速，或者说视频。因为大家知道静态内容，放到每个CDN节点是比较容易的事情，但是我们淘宝的一个业务，整体上所有走交易的流程都是在杭州本地完成的，一些偏远的地区，它到杭州的网络质量还不是特别好，我们希望把这些动态内容也能通过我们的CDN技术去加速，让这些边远的地区也享受到比较快的访问速度； 对于HTTPS的需求，这块我们更多的一些是跟交易相关的流程，我们是希望既享受速度，又享受安全，所以这要就有HTTPS的请求；另外我们现在虽然大力的推广，让卖家把这些图片都放到淘宝本地来，用我们的CDN给卖家提供优质的服务，但是我相信视频还是一个方向，比如说我们去买一件衣服，我们看到有一段视频的话，用户感受跟我去看一个死板的图片，肯定是不一样感受，这也是我们要努力去做到的一个方向。
是不是可以畅想在未来的两三年，我们广大的包括农村地方的，或者三线城市的那些人民，他们购物的时候也会更快？
对，这是我们CDN团队的使命，我们要让全国所有有购物需求的人，在访问淘宝的时候都要最快。
这是非常美好的一个愿景。最后一个问题，在现在淘宝网，当然它的很多方面都走在了前面，包括我们CDN的一些优化，那其他的可能有一些比较小的团队，也在从事电子商务方面的一些工作，也可能有自己的网站，他们也可能面临非常大的问题，你作为一个比较有经验的CDN团队的负责人，能不能给他们提一些建议？
那我大概说一下，这个建议是我的一面之词，实际上对于每一个网站来说，CDN都是有需求的。做CDN的同行，要更多的去关注业务，因为我们很多做技术的人，会限于这个技术的壁垒里面，他只会去考虑技术，不会考虑业务。通过不管是双十一事件，还是说我们整个一年的CDN优化路程来看，我们了解业务是必要的，包括现在我们对有些业务不清楚的地方，也阻碍着我们CDN的发展。业务非常重要，包括我们双十一的时候做的一些措施，比如图片的延时加载，大图换成小图，又保留大图的功能，这样都是在非常熟悉业务的情况下做出的一个决定。
如果我们不熟悉这些业务，我们当天肯定做不出这些决定来，没法应付这么大的流量；另外你了解了业务，你才能够去做好你的CDN，让你的CDN发挥最大的用途，你知道你的业务需要什么样的CDN；另外一个希望我们淘宝的CDN以后可以为大家服务，我这打个广告，淘宝的CDN现在具备给其他网站提供服务的能力，那我们希望把淘宝的先进技术开源一部分到社区去，我们前面提到的一致性哈希的算法，或者说对于HAproxy的改进，我们都会开源到社区去，希望同行业会用到这些技术。另外一个我们会大力的去建点，我们也希望，到时候我们可以跟这些网站合作，让他们把一些内容放到我们这边来服务。
非常感谢康伯接受我们的采访，我们也希望CDN团队能够再接再厉，给我们广大的网民提供更流畅的服务。谢谢。
老[/b]|[/b]男孩点评：[/b]感谢马云，感谢康伯，感谢为此文付出的所有的朋友们，没有你们就没有这篇优秀文章的诞生。
阿里集团的团队在国内是非常棒的，在很多技术领域都走在了前列，更可贵的是把自己的技术经验开源，在此，我代表广大的国内技术朋友们，对你们（阿里集团团队）表示真挚的感谢！希望你们能开源更多的技术和产品。这是利国利民的好事。

有的朋友问CDN的原理，可以看下老男孩的相册，有原理图。

本文出自 “老男孩的linux博客” 博客，请务必保留此出处http://oldboy.blog.51cto.com/2561410/926983