服务好“最后一千米”，高效CDN架构经验

国内，随着互联网的高速发展，由于各大通讯公司的政策，形成了南电信北联通互通有局限性，再加上大小且质量良莠不齐的运营商，在这特殊的氛围的互联互通下号称“八线合一”的机房开始崭露头角。互联网的普遍性使得网民分散在全国各地，因为全国地区的经济发展和互联网建设的不平衡，实际网民的体验每每受限于最后一千米的速度。在技术大喷井的年代，一些无聊或者有目的******也开始涌现，不管是***仍是DDoS***都很是频繁，时刻威胁着网站的安全……

上述种种问题，做为应用服务提供商，咱们要如何解决此类问题呢？归根结底就是要充分利用好CDN（Content Delivery Network，即内容分发网络）。

CDN做用

缓存代理

缓存代理相似内容提供商源数据中心的一个透明镜像，这些内容能够在边缘服务器中缓存和分发，对于普通的网络用户来说，它经过智能DNS的筛选，用户的请求被透明地指向离他最近的省内骨干节点，最大限度的缩短用户信息的传输距离。在任什么时候间、地点或者不一样的运营商之间（尤为在中国），快速响应用户请求。

它是经过在网络各处放置节点服务器，因此无需更改源站的网络拓扑，而是根据智能路由和用户就近原则匹配，从而确保了内容快又稳定的传输，大大提升了用户访问网站的响应速度。

路由加速

CDN服务初衷是确保快速可靠地分发静态内容，相对于动态内容来讲，因为动态内容必须长链接来操持链接和通信，只是用户到服务商之间的链路和质量都没法控制。所以为了提供快速的网络体验，有必要事先设置一些最佳路由。如省内骨干网，双线机房，以改善用户的网络体验。在中国典型的互联互通问题上，网络游戏加速就是一些最佳实践。

安全防御

利用好了CDN网络，不管面对是***仍是DDoS***，***的目标大都会被指向到了CDN，进而保护了用户源站。由于CDN是分布式的，因此即便遭受DDoS***，也具有分散性，大大减小了源站收到毁灭打击的可能性。在架构的前期，还能够经过CDN作一些前置的安全保护工做，如拦截SQL注入、XSS跨站、网站挂马、篡改等******。

节省成本

CDN节点机房只须要在当地运营商的单线机房，或者带宽相对便宜的城市，采购成本低。因为经过CDN减轻了源站压力，节点越多，源站面对任什么时候间高峰时的带宽峰值会被平均拉低。从而下降了后端服务器硬件规模和带宽的采购成本。 因为源站服务器规模的减小，后期运维成本也大大减小，可谓是一举多得。 

因而可知，为了可以知足全国乃至世界各地和多线路运营商的不一样用户都有最好的体验，构建CDN的分布式服务其重要性不言而喻。可是，在面对如何根据自身场景去设计一个CDN架构，或者如何选择以一个适合本身CDN服务提供商，这里面也有许多问题须要考量。

CDN架构

存储介质 vs IO的关系

这里先简单的介绍一下SSD介质的一些考量。SSD做为采用电子存储介质进行数据存储和读取的一种技术，突破了传统机械硬盘的性能瓶颈，固态硬盘的全集成电路化、无任何机械运动部件的革命性设计，拥有极高的读取性能。 

此环节，基本上不须要与传统的SATA、SAS做性能上的比较，SSD的胜出毫无悬念。而在总体方案中，只须要考虑承受的价格、容量大小（如120GB，160GB，300GB等规格）、是否可以知足设计需求这些问题。

做者建议：若是容许， 能使用SSD，就必定要考虑采用，用空间换性能，提高很是明显。 

这里给几个SSD实战的小贴士：

• 选择EXT4文件系统+TRIM模式（mount -o defaults,noatime,nodiratime,barrier=0,discard），Btrfs建议少冒险
  

• 若是是使用三星的固态硬盘，能够尝试它贡献给开源的针对固态硬盘优化的F2FS文件系统，至关不错的选择
  

• I/O Schedulers调度算法，可使用CFQ或者Deadline算法
  

• 内核参数调整，SSD所在硬盘，echo 0 > /sys/block/sda/queue/rotational

随机读写 vs 顺序读写

机械硬盘的连续读写性很好，但随机读写性能不好。这是由于磁头移动至正确的磁道上须要时间，随机读写时，也就须要磁头和探针频繁的转动，而机械结构的磁头和探针的位置调整是十分费时的，这就严重影响到硬盘的寻址速度，进而影响到随机写入速度。

在存储小文件（图片）、OLTP数据库应用时，随机读写性能（IOPS）是最重要指标。因为固态硬盘没有普通硬盘的机械结构，也不存在机械硬盘的寻道问题，所以系统可以在低于1ms的时间内对任意位置存储单元完成输入/输出操做。

做者经验笔记：

1. BIOS里务必开启AHCI模式（能支持SATA热插拔和NCQ寻址方式，提速→300%，固然内核也要支持AHCI模式）
   

2. SSD的主控芯片至关于大脑中枢，很是重要，建议用Intel、Samsung、Marvell等知名品牌
   

3. SSD更适合应用在随机读写场景，所以须要认真思考什么场合应用

大文件 vs 小文件

大多数的存储系统都是针对大文件而设计的，对小文件而言，大文件的存储系统没法适应小文件的存储需求，它形成元数据管理、数据布局和I/O管理、Cache管理、网络开销等方面性能和存储效率下降。 

并且，文件系统的inode是线性存储的，所以，咱们遍历一个目录下的文件，须要读取的磁盘的位置是来回跳跃的。不连续的读取意味着磁盘要不断的进行寻道，那么性能天然可想而知。

做者经验笔记： 

1. 不管大小文件，首选EXT4文件系统，Reiserfs/Btrfs不要轻易尝试（虽然B-tree设计先进）
   

2. EXT4针对小文件有所改进，使用了inode预分配，这使得inode具备很好的局部性特征，同一目录文件inode尽可能放在一块儿，加速了目录寻址与操做性能。
   

3. EXT4针对大文件使用了extent/delay/multi的数据块分配策略。这些策略使得大文件的数据块保持连续存储在磁盘上，数据寻址次数大大减小，显著提升I/O吞吐量。

4. XFS在大文件方面，表现得不错，可使用。
   

5. SSD尽可能应用在随机小文件读写的应用场景，毕竟容量宝贵，在有限的空间保存更多的文件是个明智之选。
   

6. 有开发实力的能够选用基于LevelDB或其它的KV存储做底层文件系统，此为后话。

硬件红利 vs 软件设计

随着时间的推移，硬件升级已经突破了摩尔定律，在硬件不断升级带来的红利下，咱们从最初的双核到四核、六核、八核心&超线程，从2G、4G内存到 8G、16G甚至128G内存的状况下，一样的价格所带来的硬件升级，性能提高也是很是可观的，所以，设置合适的硬件淘汰时间点也很重要，当老旧服务器超过3～5年的服役期，务必考虑作新陈代谢式的升级，充分利用好硬件潜力，保证架构设计平滑有序稳定的升级。 

反观软件设计，相对硬件升级，可谈的话题就比较多了，举个反例：好比说 Squid软件的缺点（固然，诞生于1996年的Squid与Apache一样的古老，昔日的时代也是立下了汗马功劳，但时代进步就不能固步自封必须考虑革新）：

1. 没法利用多核优点，形成单核CPU压力过高；
   

2. 鸡肋的DNS进程必需要运行；
   

3. 没法利用大内存作缓存加速；

4. COSS设计上的先天缺陷，初始化甚至重启后重建索引慢；

5. 偶然机器重启，修复的效率很是漫长，慢到让人崩溃；
   

更多详情参考： 

Varnish Cache 的架构笔记，为何一些古老的软件正在被新的设计思想所淘汰，如Nginx替代Apache，ATS替代Squid，Postfix替代Sendmail等等。 

建议：

1. 负载均衡技术应用得当，如haproxy、lvs。一方面能够互援互备，另外一方面也能够方便轮流升级；

2. 要尝试新的软件开发思路和网络模型，如epoll、aio、内存加速，链接复用和事件驱动机制；

系统优化

1. 系统服务精简瘦身；
   

2. 文件系统性能调优；
   

3. 提升磁盘IO性能；
   

4. 优化网络性能；
   

5. 优化路由策略；
   

6. 数据库的优化；
   

……这里就不展开详述了，之后有机会再介绍。 

CDN开源

开源世界里可以担当反向代理及缓存的软件很多，并且各有优劣。在这里，我就不一一介绍每一个软件的介绍了，你们能够自行参考相关连接了解。

CDN架构上要充分体现出抗***能力和灵活应变的原则。所以，咱们将CDN节点分解成反向代理+缓存加速+***防护这三个不一样层次的功能结构。 

• 反向代理功能（做用：路由加速，隐藏主节点，负载均衡）

• 缓存加速功能（做用：静态推送，节省后端主节点带宽）
  

• ***防护功能（做用：快速解析，匹配过滤恶意***）

做为一个架构师，就必需要考虑如何选型，咱们从性能、功能、配置上来进行比较筛选。

软件名称	性能	功能	过滤规则配置
Squid	不能多核是硬伤； 磁盘缓存容量有优点； 性能中等	多； 支持ACL角色控制； 支持ICP缓存协议	支持外部文件读取及热加载； 支持热启动
Varnish	多核支持； 内存缓存； 性能强	够用； 支持集群，但不支持ICP集群； 支持后端存活检查	不支持外部文件读取； 须要转义； 支持热启动
Nginx	多核支持； 支持代理插件； 性能较强	多； 支持集群，但不支持ICP集群； 支持后端存活检查； 经过插件能够充当多角色服务器	不支持外部文件读取； 须要转义； 支持热启动
Apache TS	多核支持； 磁盘/内存缓存； 性能强	够用； 支持后端存活检查； 支持ICP协议，Cluster不稳定； 支持插件开发；	支持外部规则文件读取及热加载； 支持热启动
HAProxy	多核支持； 无缓存； 支持HTTP头部解析； 性能强	少，只专一HTTP头部解析和转发功能； 支持ACL角色控制； 支持后端存活检查	支持外部规则文件读取及热加载； 支持热启动； 支持会话粘滞和长链接

如今，咱们对这三层功能结构充分了解，在测试调优及生产线的实践检验中，咱们发现：

• HTTP防护性能：HAProxy在应对大流量CC***时，作正则匹配及头部过滤时，CPU消耗只占10%~20%。其它软件均狂占CPU资源约90%以上，容易成瓶颈致使整个系统无响应。
  

• 反向代理性能：单纯转发效率之内存缓存型的Varnish性能最强，ATS和Nginx次之，考虑大容量缓存因素，ATS也是个不错的选择。Nginx是专门针对C10K的产物，性能不错，配合本身编写插件，业务可塑性很强。
  

• 过滤规则的可配置性：HAProxy，ATS，Squid均支持规则文件读取、ACL定制和热加载、热启动。Nginx则不支持外部文件正则匹配，略差一点，但可塑性强。

负载均衡——高可用性:LVS

LVS是个重量级、高效稳定的四层转发，虽然不能做七层HTTP协议的识别，但彻底能够架设在七层以前，与上述的各类软件搭配使用。

因此，LVS的使用并不会影响网络结构，后续仍然能够想上就上，前提是要兼顾到LVS的单点故障，这个咱们能够经过Keepalived/Heartbeat来实现可用性和可靠性的保证。

               -----The End-----