服务好“最后一公里”,高效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来实现可用性和可靠性的保证。

原文发布于微信公众号 - 马哥Linux运维(magedu-Linux)

原文发表时间:2014-08-30

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏FreeBuf

这款安卓后门GhostCtrl可能是“史上功能最多”的后门

这个世界上从来都不缺Android恶意软件,但我们却很少能够遇到像GhostCtrl后门这种功能如此之多的Android安全威胁。 ? 根据趋势科技的研究人员透...

3427
来自专栏Golang语言社区

Go语言发布1.5版本:彻底告别C代码

在经历了6年6次更新之后,Google的自家编程语言“Go”终于迎来了1.5版本。Google在本次更新中移除了“最后残余的C代码”,因为运行时(runtim...

3089
来自专栏java一日一条

大型网站架构体系的演变(下)

在做扩展满足了基本的性能需求后,我们会逐渐关注“可用性”(也就是我们通常听别人吹牛时说的SLA、几个9)。如何保证真正“高可用”,也是个难题。

691
来自专栏北京马哥教育

做Linux背锅2年,我总结了这六类好习惯和30个血的教训

一、线上操作规范 1.测试使用 当初学习Linux的使用,从基础到服务到集群,都是在虚拟机做的,虽然老师告诉我们跟真机没有什么差别,可是对真实环境的渴望日渐上升...

43112
来自专栏美团技术团队

美团数据库运维自动化系统构建之路

美团点评技术沙龙由美团点评技术团队主办,每月一期。每期沙龙邀请美团点评及其它互联网公司的技术专家分享来自一线的实践经验,覆盖各主要技术领域。 目前沙龙会分别在北...

6258
来自专栏P2P传输

BT软件系统包含哪些部分?BT技术如何突破运营商的封锁?

BT技术已经被很多个人和企业用来在互联网上发布各种资源,其好处是不需要资源发布者拥有高性能服务器,就能迅速有效地把发布的资源,传向其他的BT客户软件使用者,可以...

1560
来自专栏沃趣科技

Gitlab删库事件回顾,备份手段还停留在“原始社会”?

作者简介:孙朝阳 沃趣科技高级产品经理。 Gitlab简介 Gitlab是大家很熟悉的开源Git代码托管工具,国内公司大多使用社区版自行搭建私有化的内部代码托...

3556
来自专栏微服务

全面解读NoSQL数据库Redis的核心技术与应用实践

互联网和Web的蓬勃发展正在改变着我们的世界,随着互联网的不断发展和壮大,企业数据规模越来越大,并发量越来越高,关系数据库无法应对新的负载压力,随着Hadoop...

3896
来自专栏SAP最佳业务实践

SAP最佳业务实践:SD–售前活动(920)-4数量合同

一、 VA41创建数量合同文档 数量合同是客户在指定期间订购一定数量产品的协议。此合同包括基本数量与价格信息,但不包含具体的交货日期或数量计划。客户通过根据协议...

3086
来自专栏云计算D1net

云应用程序性能管理的四大金刚

应用程序一旦迁移到了云端,管理起来就变得更困难重重了。云应用程序性能管理和性能监控工具则可以帮助识别瓶颈及其他性能度量指标。 优秀的工具有助于确定是否可以将瓶颈...

2904

扫码关注云+社区

领取腾讯云代金券