如何设计稳定高效的CDN架构

如何设计稳定高效的CDN架构？

如何根据自身场景去设计一个CDN架构，或者如何选择以一个适合自己CDN服务提供商，这里面也有许多问题需要考量。

国内，由于各大通信公司的政策，造成了南北互通的局限性，兼之全国地区的经济发展和互联网建设的不平衡，导致网民的体验往往受限于最后一公里的速度。而随着网络技术的发展，一些无聊或者有目的黑客攻击也开始涌现，无论是渗透还是DDoS攻击都非常频繁，时刻威胁着网站的安全……

上述种种问题，作为应用服务提供商，中国E动网CEO陈明华认为要充分利用好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，就一定要考虑采用，用空间换性能，提升非常明显。

随机读写vs 顺序读写

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

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

硬件红利vs 软件设计

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

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

1. 无法利用多核优势，造成单核CPU压力太高;

2. 鸡肋的DNS进程必须要运行;

3. 无法利用大内存做缓存加速;

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

5. 偶然机器重启，修复的效率非常漫长，慢到让人崩溃。