我现在在杭州的淘宝研发中心，在对康伯做采访。康伯先跟我们大家介绍一下你自己，包括你的团队。 
大家好，我是康伯，这是我花名，我的真名叫高山渊。我的团队是负责整个淘宝的CDN的建设、运维。
我们也知道，这一次淘宝“双十一”事件，其实CDN这一块也面临着非常大的压力。我们想了解一下，在这个事件之前，你做了什么样的预案？在整个的事件发生的过程当中，预案和你整个的一个实际的情况有哪些比较大的差异？ 我们第一时间知道这个活动的时候，就对我们的系统做过一些评估。当时，我们预计流量会增长大概30%左右。在预案中认为我们的系统是有30%的余量的。但是我们觉得30%是不太够的，我们临时采取了一些措施，比如说去扩了一些性能不太好的一些点、内存，又去到上海又去临时建了一个点，包括在杭州的一些地方，我们都去临时增取了一些资源，把整个系统这个能力扩大到了50%左右。
但是还没有到这天活动的时候，我们就发现我们的这个预案做得不够，活动开始前的一天，流量就已经冲到了一个新的高峰，在这基础上，双十一这天流量就会达到我们当时整个设计的一个顶峰值。如果这样就意味着我们的服务质量可能会下降，可能会放弃一些用户。针对这些情况我们又临时调整了预案，比如说是否要临时的放弃一些用户，或者说再增加一些节点等。
在双十一的一早，我们就发现了，情况比我们预想的还要复杂。当时那天早上九点的时候，我们就发现流量就已经窜高到了整个设计的极限值。按照我们的经验来说，晚上比早上的早高峰还要高30%的，那等于说我们整个系统缺少30%的能力来支撑。我们马上采取了很多措施，最主要的简单说来就是开源节流，当时第一反应就是调动的所有资源投入到CDN系统去，保证它不出问题。当然前面介绍到说我们可能会放弃一些用户，但那是我们到了不得已的时候才采取的措施。事实证明我们当天做完一些措施之后，就没有去用这种极端的措施。那我现在来说一下当时我们主要做些什么：第一个在杭州，我们可以调动资源的地方，及时的去增加资源，这样在晚上高峰来临之前，我们能多余出20G的流量；我们又跟各地的运营商去沟通，因为有些运营商我们跟他签了一个协议，比如说是我们只能跑到10个G，或者更少。但是应对这个突发流量的时候，我们去跟这些运营商沟通，说把我们的带宽的能量打开。实际上很多节点到当天都是跑过了10个G的，最高跑到了16个G，这是在我们以之前不敢想象的。实际上这个能够支撑这么大能量也依赖于我们之前对于服务器、对于整个架构的优化，后边我们可能会说到。
另外一个在业务方面我们采取了一些节流的措施，来保证这些压力不要一下子冲到我们CDN上来，比如说我们的活动页面是非常大的，上面有非常多的大图，我们发现这个活动页面给我们的流量压力带来非常大的冲击。我们就及时找UED的同学去做优化，把页面尽量优化缩小又不影响用户感受。比如说延迟加载，当用户打开页面的时候，先显示首屏的一些图片，底下还有六七屏的图片只有在用户往下拖动的时候才会显示出来，这样我们节省了很大的流量；包括在我们一些上线详情页，也是采取了同样的优化措施，保证用户访问感受的同时，保证我们的CDN不被压跨。
再之后呢，我们发现流量的增长还是比较猛，我们又采取了一些其他的措施，比如说我们临时把某些页面的大图换成小图来节省流量，因为大图原来在CATCH前端都是存在的，如果把它换成小图，就涉及到这些图片可能要全部重新生成一次，对于源服务器的压力是非常大的，我们就采取了逐步切换的方式，先切换一个流量比较小频道，然后上线，观察这个对后端的压力，在看到这样对我们后端基本没有什么太大冲击的情况下，我们再逐步的把一些页面全部换成小图。但是我们仍然在我们的搜索的页面保留了大图的功能，用户在需要看大图的时候，还可以切换到大图，这样一方面节省了CDN的流量，保证我们的服务能力，另一方面也保证我们用户仍能得到一个高质量的访问。
在采取过措施之后，晚高峰的流量也是被我们做过这些控制，还保持跟早高峰差不多。实际上等于我们一天节省了30%左右的流量。但在这个过程中还会有很多问题，因为我们的用户的分布不均匀，比如说在大的省市，流量的增长非常迅速，那为了保证这些地方的一些用户，我们可能会使这些地方的用户访问慢一点，但是我们保证了图片的正常显示；我们让他去访问周边的地方，比如说上海可能会到浙江来，广东的我们会让他去到广西这样的一些措施，然后保证整个访问质量不受太大影响，而且保证了我们的服务能力。
那经过这么多优化措施之后呢，我们那天是整体上是承载了一个比我们平常多了50%的流量，或者说在我们不做那些降级的优化措施的情况下是的80%增长的流量，在这样一个突发的情况下我们做到了。
但是还没有到这天活动的时候，我们就发现我们的这个预案做得不够，活动开始前的一天，流量就已经冲到了一个新的高峰，在这基础上，双十一这天流量就会达到我们当时整个设计的一个顶峰值。如果这样就意味着我们的服务质量可能会下降，可能会放弃一些用户。针对这些情况我们又临时调整了预案，比如说是否要临时的放弃一些用户，或者说再增加一些节点等。
在双十一的一早，我们就发现了，情况比我们预想的还要复杂。当时那天早上九点的时候，我们就发现流量就已经窜高到了整个设计的极限值。按照我们的经验来说，晚上比早上的早高峰还要高30%的，那等于说我们整个系统缺少30%的能力来支撑。我们马上采取了很多措施，最主要的简单说来就是开源节流，当时第一反应就是调动的所有资源投入到CDN系统去，保证它不出问题。当然前面介绍到说我们可能会放弃一些用户，但那是我们到了不得已的时候才采取的措施。事实证明我们当天做完一些措施之后，就没有去用这种极端的措施。那我现在来说一下当时我们主要做些什么：第一个在杭州，我们可以调动资源的地方，及时的去增加资源，这样在晚上高峰来临之前，我们能多余出20G的流量；我们又跟各地的运营商去沟通，因为有些运营商我们跟他签了一个协议，比如说是我们只能跑到10个G，或者更少。但是应对这个突发流量的时候，我们去跟这些运营商沟通，说把我们的带宽的能量打开。实际上很多节点到当天都是跑过了10个G的，最高跑到了16个G，这是在我们以之前不敢想象的。实际上这个能够支撑这么大能量也依赖于我们之前对于服务器、对于整个架构的优化，后边我们可能会说到。
另外一个在业务方面我们采取了一些节流的措施，来保证这些压力不要一下子冲到我们CDN上来，比如说我们的活动页面是非常大的，上面有非常多的大图，我们发现这个活动页面给我们的流量压力带来非常大的冲击。我们就及时找UED的同学去做优化，把页面尽量优化缩小又不影响用户感受。比如说延迟加载，当用户打开页面的时候，先显示首屏的一些图片，底下还有六七屏的图片只有在用户往下拖动的时候才会显示出来，这样我们节省了很大的流量；包括在我们一些上线详情页，也是采取了同样的优化措施，保证用户访问感受的同时，保证我们的CDN不被压跨。
再之后呢，我们发现流量的增长还是比较猛，我们又采取了一些其他的措施，比如说我们临时把某些页面的大图换成小图来节省流量，因为大图原来在CATCH前端都是存在的，如果把它换成小图，就涉及到这些图片可能要全部重新生成一次，对于源服务器的压力是非常大的，我们就采取了逐步切换的方式，先切换一个流量比较小频道，然后上线，观察这个对后端的压力，在看到这样对我们后端基本没有什么太大冲击的情况下，我们再逐步的把一些页面全部换成小图。但是我们仍然在我们的搜索的页面保留了大图的功能，用户在需要看大图的时候，还可以切换到大图，这样一方面节省了CDN的流量，保证我们的服务能力，另一方面也保证我们用户仍能得到一个高质量的访问。
在采取过措施之后，晚高峰的流量也是被我们做过这些控制，还保持跟早高峰差不多。实际上等于我们一天节省了30%左右的流量。但在这个过程中还会有很多问题，因为我们的用户的分布不均匀，比如说在大的省市，流量的增长非常迅速，那为了保证这些地方的一些用户，我们可能会使这些地方的用户访问慢一点，但是我们保证了图片的正常显示；我们让他去访问周边的地方，比如说上海可能会到浙江来，广东的我们会让他去到广西这样的一些措施，然后保证整个访问质量不受太大影响，而且保证了我们的服务能力。
那经过这么多优化措施之后呢，我们那天是整体上是承载了一个比我们平常多了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需要重新去被存储，这就减轻我们整个运维的压力。
我们又做了很多其他的优化，比如说对于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左右。
我给大家分享一下，我们在这一年里都做了一些什么样的优化。实际上对于我们整个系统来说，淘宝的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需要重新去被存储，这就减轻我们整个运维的压力。
我们又做了很多其他的优化，比如说对于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左右。
这个数据还是比较惊人的，在简单回顾一下，在整个优化过程中，有没有遇到特别困难的地方？ 特别困难的话，实际上对我们来说，仍然是在这个我刚才提到的，没有热点，数量是非常多的情况。没有热点，就意味着我们要尽量多的把图片存到前端，我们在做URL哈希的时候，实际上是面临了很大的问题，我刚才也提到SSD，现在的规格只有160G，但是SAS或者SATA可以做到600G或者1T，我们现在每台机器要存大概三千万到四千万的文件，这个对存储容量的要求至少要有一个1T空间，用SSD的话成本会比较高，这是我们一直在优化的方向。另外就是流量这一块。
在接下来的两三年的时间，对于CDN团队来讲，主要的工作可能是什么？ 前面我们说到，就说整个一年除了架构以外，我们还做了很多工作。我们流量在涨到可能有四倍到五倍，这个就不光是去优化软件就能实现了，我们还做了很多部署的工作。
下面第一个，我们还是会大力的推进布点的情况。我们现在在全国有30多个点，基本上都分布在一些省会城市，或者说一线城市，比如北京、天津、上海、广州、杭州和其他省会城市。明年我们希望把这个点数量做到100个，这样我们就会覆盖大部分的二线城市，比如说像温州、嘉兴，或者东莞这种流量比较大的城市，后年规模可能会再扩一倍，到两百个点，这当然只是我们现在的一个期望。到时候我们可能说，每一个市我们至少有一个点，当地用户都去访问他本地，达到一个最快的访问速度。
另外一个方面，实际上我们现在在做很多其他内容的CDN尝试，比如动态的或者说HTTPS加速，或者说视频。因为大家知道静态内容，放到每个CDN节点是比较容易的事情，但是我们淘宝的一个业务，整体上所有走交易的流程都是在杭州本地完成的，一些偏远的地区，它到杭州的网络质量还不是特别好，我们希望把这些动态内容也能通过我们的CDN技术去加速，让这些边远的地区也享受到比较快的访问速度； 对于HTTPS的需求，这块我们更多的一些是跟交易相关的流程，我们是希望既享受速度，又享受安全，所以这要就有HTTPS的请求；另外我们现在虽然大力的推广，让卖家把这些图片都放到淘宝本地来，用我们的CDN给卖家提供优质的服务，但是我相信视频还是一个方向，比如说我们去买一件衣服，我们看到有一段视频的话，用户感受跟我去看一个死板的图片，肯定是不一样感受，这也是我们要努力去做到的一个方向。
下面第一个，我们还是会大力的推进布点的情况。我们现在在全国有30多个点，基本上都分布在一些省会城市，或者说一线城市，比如北京、天津、上海、广州、杭州和其他省会城市。明年我们希望把这个点数量做到100个，这样我们就会覆盖大部分的二线城市，比如说像温州、嘉兴，或者东莞这种流量比较大的城市，后年规模可能会再扩一倍，到两百个点，这当然只是我们现在的一个期望。到时候我们可能说，每一个市我们至少有一个点，当地用户都去访问他本地，达到一个最快的访问速度。
另外一个方面，实际上我们现在在做很多其他内容的CDN尝试，比如动态的或者说HTTPS加速，或者说视频。因为大家知道静态内容，放到每个CDN节点是比较容易的事情，但是我们淘宝的一个业务，整体上所有走交易的流程都是在杭州本地完成的，一些偏远的地区，它到杭州的网络质量还不是特别好，我们希望把这些动态内容也能通过我们的CDN技术去加速，让这些边远的地区也享受到比较快的访问速度； 对于HTTPS的需求，这块我们更多的一些是跟交易相关的流程，我们是希望既享受速度，又享受安全，所以这要就有HTTPS的请求；另外我们现在虽然大力的推广，让卖家把这些图片都放到淘宝本地来，用我们的CDN给卖家提供优质的服务，但是我相信视频还是一个方向，比如说我们去买一件衣服，我们看到有一段视频的话，用户感受跟我去看一个死板的图片，肯定是不一样感受，这也是我们要努力去做到的一个方向。
是不是可以畅想在未来的两三年，我们广大的包括农村地方的，或者三线城市的那些人民，他们购物的时候也会更快？ 对，这是我们CDN团队的使命，我们要让全国所有有购物需求的人，在访问淘宝的时候都要最快。
这是非常美好的一个愿景。最后一个问题，在现在淘宝网，当然它的很多方面都走在了前面，包括我们CDN的一些优化，那其他的可能有一些比较小的团队，也在从事电子商务方面的一些工作，也可能有自己的网站，他们也可能面临非常大的问题，你作为一个比较有经验的CDN团队的负责人，能不能给他们提一些建议？ 那我大概说一下，这个建议是我的一面之词，实际上对于每一个网站来说，CDN都是有需求的。做CDN的同行，要更多的去关注业务，因为我们很多做技术的人，会限于这个技术的壁垒里面，他只会去考虑技术，不会考虑业务。通过不管是双十一事件，还是说我们整个一年的CDN优化路程来看，我们了解业务是必要的，包括现在我们对有些业务不清楚的地方，也阻碍着我们CDN的发展。业务非常重要，包括我们双十一的时候做的一些措施，比如图片的延时加载，大图换成小图，又保留大图的功能，这样都是在非常熟悉业务的情况下做出的一个决定。
如果我们不熟悉这些业务，我们当天肯定做不出这些决定来，没法应付这么大的流量；另外你了解了业务，你才能够去做好你的CDN，让你的CDN发挥最大的用途，你知道你的业务需要什么样的CDN；另外一个希望我们淘宝的CDN以后可以为大家服务，我这打个广告，淘宝的CDN现在具备给其他网站提供服务的能力，那我们希望把淘宝的先进技术开源一部分到社区去，我们前面提到的一致性哈希的算法，或者说对于HAproxy的改进，我们都会开源到社区去，希望同行业会用到这些技术。另外一个我们会大力的去建点，我们也希望，到时候我们可以跟这些网站合作，让他们把一些内容放到我们这边来服务。
如果我们不熟悉这些业务，我们当天肯定做不出这些决定来，没法应付这么大的流量；另外你了解了业务，你才能够去做好你的CDN，让你的CDN发挥最大的用途，你知道你的业务需要什么样的CDN；另外一个希望我们淘宝的CDN以后可以为大家服务，我这打个广告，淘宝的CDN现在具备给其他网站提供服务的能力，那我们希望把淘宝的先进技术开源一部分到社区去，我们前面提到的一致性哈希的算法，或者说对于HAproxy的改进，我们都会开源到社区去，希望同行业会用到这些技术。另外一个我们会大力的去建点，我们也希望，到时候我们可以跟这些网站合作，让他们把一些内容放到我们这边来服务。
非常感谢康伯接受我们的采访，我们也希望CDN团队能够再接再厉，给我们广大的网民提供更流畅的服务。 谢谢。
