服务好“最后一公里”，高效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来实现可用性和可靠性的保证。 作者简介： 邵海杨，UPYUN（又拍云）联合创始人兼运维总监，来自杭州Linux用户组，新浪微博@海洋之心-悟空 ，资深系统运维架构师，业余撰稿人，致力于开源软件及前沿科技的研究和探索。

The post 服务好“最后一公里”，高效CDN架构经验 appeared first on 神刀网.