2015年1月31日，阿里云课堂第六期在北京开课，“大型互联网应用架构之存储与分发”主题分享在众多朋友的期待下精彩上演，现场观众再次爆满。本次活动中，姚伟斌（花名：文景）和李文兆两位讲师为大家献上了精彩演讲，并在OpenSpace环节与观众展开讨论，积极互动。应广大用户要求，我们将云课堂讲师现场分享内容全文整理出来，供大家参考。阿里云课堂会继续在全国各地陆续开课，欢迎大家继续支持！
以下为讲师姚伟斌（花名：文景）的分享内容：
我前面会讲一下CDN的用途，也会讲一些CDN产品，在后面我会讲CDN的架构和设计。
一、CDN的用途
目前，CDN主要是分几个方向发展，比如静态内容的分发、视频流媒体的分发、动态资源的加速、源站保护等，其中最基本的是用来做静态内容分发。阿里CDN现在最大的用途是用作淘宝所有图片的分发。视频流媒体的分发功能使用，发展速度也非常之快。CDN一些特色功能的应用，如动态资源的加速，还有SSL的接入、SPDY的接入等。CDN还有一个功能是源站保护，它可以通过各种安全防御，实现源站流量的减少。
二、CDN的加速原理
CDN最大的特色在于加速。那么，CDN是如何实现各种“加速”，发挥“加速”功用呢？如下图所示，CDN有很多节点，通过域名实现就近接入。当用户发起一个请求后，CDN会回源取，然后把文件就近缓存在那个节点的服务器上。假设北京的用户到北京节点只需4毫秒，后面写了一个90%的请求其实都直接命中到了服务器，那么还有10%的流量回到了二级cache节点。而二级cache节点也是同样的缓存服务器，假设它的命中率也是90%，那么最终只有1%的流量到源站。如果纯粹回到源站可能需88毫秒，而通过访问CDN就会大大缩短时间，甚至4毫秒就可以让用户拿到一个文件。这是CDN实现加速的基本原理。
三、阿里CDN分布
CDN加速的载体在于节点，阿里CDN节点分布可谓星罗棋布，如下图所示。阿里CDN服务器原先主要用于淘宝图片的分发，在全国32省（市、区）均有服务器，有200多个节点，在一线城市运营商均有机房，甚至在外国也有30余个节点分布，以提供国外用户的加速服务。
四、阿里CDN应用
这两天，我去拜访了一些客户。他们把我们的CDN与业界其他一些比较有名的商业CDN进行比较统计，得出的结论是：我们CDN的平均延迟大概能有10%到20%的下降。
阿里从2008年开始，就着手自建CDN。不知不觉我们已成为世界上最大的图片CDN。这可能跟中国的网上购物习惯有关-- 一个商品需要几十张图片进行介绍。这使得我们图片CDN可能跟某些视频CDN流量有的一拼。从2014年3月起，阿里CDN正式开启商业化运营模式。商业化运营对阿里云CDN的需求，跟图片CDN区别是非常大的，这对于我们有很多的挑战。原来的图片CDN，对于我们来说，主要是每年大促期间带来的压力，至少到2012年，我们CDN唯一任务就是为了“双十一”。那时，我们会做很多预案以应对疯狂的流量。下面这一张是CDN的流量图，就可以看到我们2009到2012年，我们整个水位是非常满的。这对于我们CDN来说，主要的挑战在于：做到良好的均衡性。比如这个节点要把流量定量切到另外一个节点，我们做了很多的工作。另外，我们在节点内对软件稳定性和性能等方面也做很多优化。比如说现在一个节点能服务40G，但是有时候节点面对突然涌过来的大流量时，你甚至来不及调度。这就要求你的软件至少需要扛过大于40G的能力。每年我们会做5次以上的压测。在跑满40G的情况下面，连续跑一个星期，检验以保障我们CDN节点不会挂掉，能够继续提供比较可靠的服务。这对于软件的可靠性方面，压力也是非常大的。
从去年开始，我们整个团队的开发方向就转向做对外服务。从2013年开始，我们CDN的服务能力已经远超我们自用的能力。就像我们一些PE所说，我们CDN团队基本上可以坐在那里喝着茶看着双十一的流量就可以了。
现在阿里CDN的目标是：做到能够快速、安全、易用，能帮用户减少成本。
下面是CDN的一些关键组件：
- IP库
- 调度系统
- 缓存系统
- 刷新系统
- 日志系统
CDN需要知道用户从哪里来，才能调度， IP数据库我们已经做了好几年。如果你们想去查一下某个IP是从哪里来的，ip.taobao.com这个外部的接口可以用。为了提高准确性，我们还会拿淘宝的收货IP做对比，查是否这个IP是属于这个地区的。现在在市一级的准确率能做到96%左右。ECS用户应该可以免费调用我们IP库的接口。
现在CDN有两个维度可以进行调度。一是地域的概念，比如说你去浏览器里面输一个www.taobao.com，域名查询请求会提交到运营商本地的DNS服务器，DNS服务器有一个迭代查询的过程，最后到了调度中心。调度服务器会根据源IP。比如你是北京电信的DNS的IP，就将你调度到北京电信的机房去。二是CDN是有高可用性的，调度中心在不停的监控所有节点的健康状况，一旦发现这个节点有问题，会将用户切换到另外一个节点。
上图是CDN节点的缓存系统，LVS是4层的代理，Tengine主要进行并进行负载均衡，swift是一个高效的缓存服务器，作静态文件的缓存用。Tengine和Swift进行一致性hash，可以提高命中率。其他还有一些控制机器，做刷新和配置这些功能。
上图是Swift的缓存架构淘汰逻辑。现在我们能做到内存、SSD、SATA三级缓存、可以适应各种尺寸的文件。我们的服务器既能做图片的缓存，也能做视频大文件缓存，热对象会自动上升到内存，冷对象会被淘汰到SATA。为了提高IO性能，我们没有使用文件系统，直接使用整个裸磁盘。在裸盘上，我们实现了Squid的COSS文件系统。COSS文件系统中都是一个Stripe进行IO写操作。我们使用8M一个Stripe，新来的文件就append在Stripe里面，每次都是8M的写，这样就可以提高IOPS。当Stripe满以后，写SSD时，看原有的内容是否热的，如果是热点，就放到内存。如果是冷的，就淘汰到内存。
去年阿里CDN开始对外应用以后，用户增加非常迅速。原来以配制文件的形式管理的配置系统，已经不能满足业务需求。于是，我们开发了一个加载配制模块，它是lazy的。它的局部性效果非常明显，虽然我们线上有几万个域名，但在一个节点上，我们发现也就一两千个域名在服务，所以按需加载的方式较好。另外我们也做了很多优化，10万域名只占500兆内存，非常高效。同时，我们也能做到全网分钟级别配置分发，总体来说，我们的配制可以做到高可靠、可运维。
有时，CDN上的缓存文件更新了，我要把它删掉。刷新需要全网分发，而全网的每一台机器，每一个cache节点全部要刷，因为我不知道文件存在哪里，都是广播的，而现在，我们按调度频道来刷，就能减少一定量的刷新。另外，我们增加了合并功能。比如，现在有100个URL过来刷新，可以合并为一次提交到Cache服务器，从而减少刷新的QPS。此外，Swift支持正则和目录刷新，只需提交一个请求就可以刷很多内容。现在从统计数据上看，全球节点99%以上能做到1分钟的刷新。
目前，我们阿里内部已经实现了海量日志搜集与分析系统。原来我们也是用syslog来搜集日志，在40G跑满时，syslog丢包非常严重。特别是在对外商用以后，日志需要计费，对可靠性要求非常高，所以后来就开发了一个传输日志和实时分析系统。同时，内部也做了一些优化，比如合并功能，多条日志合并后再发到日志服务器上，使用LZO进行流式压缩，最终收集到中心。现在我们可以做到产生的日志10分钟传到OSS上以供下载。这个速度在业界来说是非常快的。现在，我们整个CDN的量级大概每天有几百T的访问日志，最终都会导入到阿里云ODPS上进行大数据分析，比如用户行为分析。
阿里CDN针对TCP协议栈的做了优化，比如说我们做了基于时间序的丢包发现机制，TCP的包是有序号的，我们按照序号来查看，如果发现高序号的TCP的ACK，但是低的没有发过来。我们会以更快的一个重传机制来确保我们低序丢失的包能够快速发过来。结合自适应的初始窗口等单边优化措施，最终我们将小对象的平均RT降低20%以上。
这个功能是页面内容优化，就是按照前端优化准则进行自动化的内容调整。比如说减少页面中请求的数量。我们会做一些静态资源文件合并。还有就是尽可能减少页面大小，我们会主动删除页面空白符，还有一个智能Gzip，通过主动发起JS异步请求，进行探测，即使没有Accept-Encoding头也会主动做压缩。CDN这边也在跟前端的同学一起来做，比如做一个UA的数据库，去保存每一个User Agent对应的分辨率，不同的分辨率选择不同尺寸的图片。
CDN其实不仅仅是静态内容的HTTP加速，还可以做TCP协议的加速。如上图所示案例显示，我们最近发现台湾用户访问淘宝页面非常慢，特别是从国内到国外这个链路是比较差的。我们在台湾有节点，香港有节点，上海有节点，台湾到上海延时有200毫秒，台湾到香港是20毫秒，香港到上海60毫秒。我们发现，从台湾、香港再回来反倒更短，所以做了CDN之间的路由优化，对TCP连接进行加速。这个图最终会有很多节点，就是一个有向图，我们在每一个CDN节点上做相互节点之间的网络探测，检测整个网络的丢包率和延时，构建出一个有权值的表格，然后我们去计算最短路径。
流媒体这个业务跟图片有很大的区别。图片的文件大小只有30到50K，但是视频的平均文件大小可能会到500K到2M。首先，流媒体对于CDN节点的流量冲击会非常大，基于传统的DNS调度有缓存时间，一般有5到10分钟的延时，甚至有一些节点都调不走。我们这边就设计了一个中心式的，基于HTTP协议的调度方法。当请求某个URL的时候，CDN根据节点的负载会直接返回资源或者302重定向，作精确调度。几乎就没有延时时间，甚至可以在每个节点的机器间相互调度。
最近阿里云这边在做无线加速的产品，我们现在使用了HTTP DNS。无线APP有自己的客户端，HTTP DNS集成在APP SDK中，当APP启动时会发起一个定期异步的请求，去中心请求域名解析，然后把IP保存下来。当下次发起真实请求时，可以直接去请求了。所以HTTP DNS可以节省域名解析的时延，也可以避免国内的一些运营商作的域名劫持。
另外一个就是做了SPDY的优化，多路优化有什么好处呢，一个是复用连接，减少连接数，提高页面打开的速度，就手机淘宝这边的经验来看，做SPDY链路复用最终是能有20%到30%加载页面时间的降低。
最后一个是安全功能，现在CDN提供了4、7层的DDoS安全防御和WAF，可以使用户免于攻击，并提供一站式解决方案。CDN可以提供源站保护功能，静态资源CDN可以缓存，最终落到源站的流量都会合并，流量是非常小的。现在安全服务是不额外收费的。
这是7层攻击的一个案例，经常有一些用户说，你们怎么防攻击的流量算我钱，实际上防攻击不是免费的。这是我昨天截的图，这是7层的攻击，突然间针对原来那个小站有15万QPS的攻击流量，它的响应大小是15KB。可以看到只要打开安全功能，CDN已经挡了99%以上的攻击，并保证它的正常服务，帮用户节省了17Gbps的流量费用。
