CDN技术探讨
By 刘晓光@云端智度
背景
CDN是内容分发网络（Content Delivery Network）的简称，通过在靠近用户的地域建立节点，将数据就近缓存和分发，优化用户到互联网资源（多媒体、网页、文件等）的传输质量，从而提升用户的访问效果。传统的CDN服务厂商包括：网宿、蓝汛、帝联、快网等。随着公有云的兴起，CDN作为公有云的重要组成部分，各种云厂商也推出了CDN产品。本文通过探讨CDN技术的一些特点，试图为使用者提供一些评估参考。
CDN系统结构
作用
CDN作用主要有几点：
缓存数据，提升访问效果，为用户提供更优质服务
承载突发流量，用户请求绝大部分由CDN承载，降低源站负载
隐藏和保护源站，对终端用户隐藏真实源站地址
动态加速，对动态内容选择最优路径，对访问进行加速
网络拓扑
CDN厂商通过在全国各地部署缓存节点，为用户提供就近服务。这些缓存节点构成了CDN网络，典型的CDN网络结构示意如下：
Figure 1 CDN网络拓扑示意图
其中，最靠近用户侧的是边缘节点，边缘节点分布在全国各省、运营商中，用户通过DNS解析访问到CDN边缘节点，边缘节点部署Cache服务器将源站数据缓存下来。一般一个边缘节点自身组成集群，不同的边缘节点间各自存储自己的缓存内容。为了收敛回源数量，同时提供更好的服务效果，对部分业务CDN会增加父层，父层是边缘层的源站，一般分大区建立。如果一个文件在边缘层中不存在，边缘会回源到对应父层，若此时父层仍不存在，会继续回源，最终回源到用户的真实源站。
边缘节点
设计因素
边缘节点负责为用户提供直接服务，在设计和选点时需要考虑以下因素：
节点网络质量，考虑因素包括：与真实用户的距离、机房网络是否稳定、离核心网络的距离等；质量影响是否需要TCP加速模块，以及TCP加速模块重传激进程度，对于网络质量一般的节点，TCP加速会比较激进，需要额外的带宽开销；
节点成本：带宽及机房，主要是带宽成本；
节点预估带宽：影响上联带宽以及保底带宽；
结构
Figure 2 边缘节点结构
典型的边缘节点结构如上图所示，主要包括三个方面：
接入层：一般使用LVS，或类LVS自研系统。提供4层负载均衡，对外收敛服务IP数量；
逻辑层：一般使用Nginx+lua：负责7层负载均衡及实现业务控制逻辑，如防盗链等；主要是客户需求多种多样，lua方便快速迭代开发，降低开发成本；
缓存层：一般使用ATS或者自研，负责缓存及回源；cache的功能应尽量保持稳定，涉及业务逻辑的开发需尽可能移至逻辑层；
中控系统：负责辅助进行部分操作，如purge等；
有几点讨论下：
1.接入层方案选择问题
对比如下：
| 模式 | 优势 | 劣势 |
|---|---|---|
| LVS DR模式 | 1. 出流量不走LVS，需要的LVS机器数量少，一般只需2台 2. 对外收敛成固定IP，不需将nginx IP暴露出去，DNS响应中给的IP数量少 3. 利用keepalived对nginx保活，有问题10s左右完成切换 | 1. DR模式不支持防御synflood |
| LVS FULLNAT模式 | 1. 对外收敛成固定IP，不需将nginx IP暴露出去，DNS响应中给的IP数量少; 2. 利用keepalived对nginx保活，有问题10s左右完成切换; 3. 支持防御synflood | 1. 出流量走LVS，带宽是瓶颈，消耗的机器多 |
| 去掉四层接入，直接nginx 7层接入 | 1. 支持防御synflood ;2. 省去LVS的成本 | 1. 将nginx IP暴露出去，需每台机器暴露一个IP，大节点出的IP达几十个，可能会超出DNS报文长度; 2. 7层负载均衡机器故障，切换依赖于DNS切换，故障切换时间长 |
综合考虑，一般选取LVS DR模式做四层接入方案，若成本不考虑，或者有自研40G负载均衡，则选用LVS FULLNAT模式。
2.7层负载均衡是否与cache合并
合并后，能节省一层7层负载均衡到cache的内网带宽，但会将两者逻辑耦合到一起，对扩展和维护产生影响；
不合并，逻辑独立，方便运维和升级，增加消耗了一层内网带宽。在当前10G普及情况下，增加的带宽也基本不是瓶颈；
3. Cache是集群模式还是单机模式
集群模式：多台机器一起对外提供服务，用户请求到7层负载均衡后，根据指定的KEY（URI或URI、HOST、参数组合）进行一致性hash，落到固定的Cache上，由该cache缓存和输出文件。好处是：磁盘资源充足，可以充分利用整个集群的磁盘存储量。缺点是，集群内部需要交互，消耗部分内网带宽。适用于通用的服务模型。
单机模式：每一台机器作为独立的cache，请求按轮询或者加权轮询机制到cache上，多台cache间内容重复率非常高。好处是，少了内网交互，整体输出性能强；缺点也很明显，单机存储量小，能缓存的数量小，不适用作为通用的服务。
4. 大文件、小文件是否区分平台
小文件IO读写频繁，大文件若直接存储会导致IO访问集中。区分平台后，两者互不影响。但会导致管理和维护复杂，资源利用率低。要想做到统一存储，需要对大文件进行切片存储，同时需要支持不同业务使用不同的存储资源，比如小文件SSD，大文件SATA。
父层节点
父层节点，又称为二级节点、中间源节点、中心节点等，用于缓存更多的文件，收敛边缘的回源量。
设计因素
父层节点主要为边缘节点服务，但也可能直接对用户提供服务。在设计和选点时需要考虑以下因素：
优质的网络质量，父层节点需要选择多线机房，近骨干网；
多区域：需要在多个区域均有父层，保证一个边缘节点至少有2个父层可用；
节点带宽：相对于边缘，需要有约1倍的带宽，需要能承载突发流量；
存储资源：相对于边缘节点，父层需要有大量的存储资源，以缓存更多的文件，降低回用户源站的带宽量；
结构
父层结构与边缘结构基本一致。因为是接收的边缘的请求，边缘节点可能对用户请求进行了处理，父层可能需要进行特殊的配置。
CDN系统简介
Cache系统
介绍下cache系统的特点，以及设计中的一些考虑。
（注：这里的cache系统包括逻辑层和缓存层）
缓存配置
在应用中，需要能够支持较灵活的缓存配置，比如：
按文件后缀匹配，设置规则；
按前缀目录，设置规则；
按正则匹配，设置规则；
按URL设置规则；
遵循源站缓存规则；
设置源站及特定策略的缓存优先级；
是否忽略参数缓存；
是否多个域名共用存储；
注意：
缓存规则是有优先级的，根据优先级选择缓存时间；
缓存超时时间最终需要在cache系统中实现，但可以在逻辑层做缓存逻辑控制，通过一定的通信机制，随请求同步到cache系统中，这样就避免了cache自身实现复杂的缓存控制策略。
缓存策略
缓存资源包括：空间、IO能力，这些是有限的，需要对不同的业务有不同的缓存策略，从技术实现上需要考虑以下几点：
1. 缓存资源分配
a) 支持业务组，对业务组内的服务公用存储。目的是最大程度的利用存储资源，各个业务存储此消彼涨，统一接受LRU淘汰；
b) 业务组支持限定缓存空间，包括配额、位置、存储设备类型等。需要通过限制，进行业务间隔离，避免业务相互影响；
2. 缓存淘汰策略，在资源使用率到达门限后，进行缓存淘汰，淘汰一般基于LRU链表进行；
3. 缓存热点均摊，当出现极热文件后，可能会导致单一存储IO跑满，此时需要自动进行热点在多台机器均摊；此处的均摊主要由逻辑层进行，首先逻辑层通过访问频度检测出热点文件，之后调整热点文件的调度策略，比如从一致性hash调整成rr，将请求均分到多台缓存上，从而使请求由多台机器共同承载；
4. 分级缓存，分级缓存有几种实现方式：
a) 由缓存系统控制缓存分级：内存、SSD、SATA，此时依赖代码逻辑进行各层级迁入迁出；
b) 利用操作系统页面高速缓存，基于访问行为，由操作系统页面缓存接管具体的分级策略，降低了复杂度；
5. 缓存存储方式
a) 基于文件系统，利用标准文件系统接口，以文件形式。优点是，便于开发以及维护，缺点是受限于底层文件系统以及分块实现，IO利用率不是最优。
b) 基于裸盘，实现缓存管理功能，优点是，存储行为完全可控，IO利用率可以进行调优，缺点是：管理和维护成本较复杂。 **
- 分片存储**
分片存储是指，将一个大文件拆分成多个小片段进行存储，有几种好处：
a) 将文件分散，使热点文件在多块存储上打散，同时利用多盘的存储性能；
b) 便于应对http-range的随机请求，如请求1M-2M的http-range，文件分片大小为1M，那么只需要回源请求1M-2M的分片，并将该分片存储下来即可。后续请求同样分片不需要再次回源；如果不支持分片存储，此机制实现起来较为麻烦。
回源策略
回源模块负责向源站回源，从功能上主要关注几个指标：
- 正确性：保证回源获取的文件正确；
a) 为什么会产生正确性的问题呢，回源是随用户请求触发的，可能多次回源请求文件还没完全缓存下来，但此时源站的文件内容已发生变化，回源模块需要能识别这种变化，避免缓存下来错误的文件；
b) 针对正确性，在实现回源功能时，必须严格验证源站的头信息和大小信息，保证多次请求的保持一致
- 回源量：尽量降低回源的请求和带宽，避免回源放大；
a) 回源放大包括两方面：回源的大小远远超过用户请求的大小，以及回源的数量与用户请求数量一致；回源放大时，会导致源站压力显著增大；
b) 回源合并：考虑这样的场景，并发的请求同时请求一个文件，这些请求需要能收敛成一个回源，避免并发情况下的回源放大。但要注意收敛时，要保证接收源站一部分数据后，能再分发给正在等待数据的请求，避免请求长期等待导致饿死。
c) 分片回源：考虑这两种情况，用户请求文件中部的http-range，以及 用户请求文件过程中突然中断。在这两种情况下，回源模块已下载的数据，需要能缓存下来，避免重复回源。一种简单有效的方式是分片回源。用户的请求根据边界情况，切分成最相应的分片进行回源，再结合分片存储，将已获取的分片数据存储下来。这样就最大程度的减少重复回源。
从业务功能上，回源模块要支持以下功能：
回源头部的改写：HOST、URL、限速、增加头部等，如回源使用不同的域名、HOST等；
回源Follow 302，支持follow的次数等；
源站保活与选择
用户的源站一般会有多个，这里有两个考虑：
可用性，多源站避免单点故障；
质量，不同运营商不同的源站，提升回源速度；
需要有模块对多个源站进行保活和选择，分别介绍：
1. 保活
a) 随路健康检查：健康检查随着请求触发，一般实现时各进程各自维护状态，好处是不会对源站造成压力，缺点是发现较慢，且依赖触发的请求多（每个进程都需要一个触发的过程）
b) 旁路健康检查：有独立的模块异步定期探测源站状态，好处是快速发现，切换迅速；缺点是额外增加了少量压力（大部分情况不会有问题）
c) 去抖动：健康检查需要去抖动，避免源站状态来回变化，此处依赖于重试和延时机制，通过多次检查去抖动
d) 四层健康检查：进行TCP端口探测，只检验建立连接是否成功，优点是开销小；缺点是有时不能完全代表服务状态；
e) 七层健康检查：进行HTTP探测，一般源站有响应即认为服务存储；
2. 源站IP的选择
a) 主备策略：指定主备源站，回源时优先回主源，当主源异常时会备用源站，主源恢复后继续使用主源；这里一般基于检测和主备的调度算法来实现；
b) 轮询策略：依据rr调度策略，进行负载均衡；
c) 区分运营商策略：此时一般增加一层DNS解析，根据节点的回源IP，通过智能分区域运营商解析找到合适的回源IP。这一层DNS解析也是需要缓存的，避免DNS解析引起的性能降低；
功能策略
下载限速：出于成本考虑，限制用户单连接下载速度；
防盗链：通过与客户协商算法，生成一段时期内或者一定次数内有效的链接，通过此链接限制访问；典型的防盗链有：
a) URL+timestamp+过期时间 组合加密，控制URL的有效期；
b) 回鉴权中心鉴权，全局控制可使用次数；缺点是可能会导致请求速度变慢；
3. 源站保护
a) 对不存在的文件缓存，如源站返回404，则将该URL缓存一定时间；
b) 探测源站负载，若随着压力增大源站响应异常，则对回源请求随机丢弃或限制；
运维考虑
1. 自动配置：对简单业务需求，可以通过自动化系统，自动配置和生效到整个CDN系统。有几种实现方式：
a) 修改逻辑层和缓存层的配置文件，逐批灰度下发和reload生效；
b) 通过逻辑层和缓存层提供的API配置接口，下发和生效；
注意，自动配置必须有灰度和验证的过程，避免系统性异常；
2. 热重启
Cache支持热重启，并保持cache中的内容不丢失，避免重启过程中连接中断。一般采用采用类似nginx的机制，启动新的进程接收新请求，同时使老的进程不再接收新的请求，等待老的连接断开后，再关闭老的进程；
3. 热升级
Cache支持热升级，避免升级时服务中断影响正常服务。
调度系统
CDN调度主要分为几种方式：
1. DNS方式
DNS支持分view解析，可以使用请求IP作为分view的依据，通过将请求IP划分各省、运营商，从而实现分区域解析。
a) 好处：通用、简单，不需要客户端改造，适用性强；
b) 缺点：不精准。权威DNS看到的是local DNS IP而非用户的真实IP，EDNS-client-subnet扩展支持传递用户真实IP网段，但国内绝大部分local DNS不支持该扩展。所以会导致不精准；
c) DNS请求容易被运营商劫持
2. HTTP 302调度
HTTP 302调度，一般与DNS调度结合一起使用，一般会有多个区域302中心，用户请求通过DNS解析到302区域中心的IP，再由302调度中心，结合用户的IP给出实际下载地址；
a) 好处：更精准的调度，便于CDN厂商调度流量；
b) 缺点：多一层302导致用户访问速度下降，同时部分客户端不支持跟踪302功能；
3. HTTP DNS调度
HTTP DNS调度使用HTTP协议进行域名解析请求，类似私有协议，此时依赖于客户端的改造，同时对HTTP DNS的健壮和稳定性有很强的要求。
其他
其他涉及的系统还有很多，比如：数据分析、后台管理、监控系统、自动调度系统等，因时间原因这里不再一一讨论。