优化篇-后端图片服务的“打怪升级”

原文再续,书接上一回,上一篇主要分享了移动端上传优化,同时也指出图片在互联网应用中的重要性;本章节主要分享后端图片服务架构不断变迁过程。

图片架构整体的演进过程大致分两个阶段:集中式、分布式。

集中式-单机模式-本地存储

在图片较少的情况下,可以直接将上传+图片浏览放在同一个机器中,用web server(apache httpd或nginx)提供浏览服务。

优点:实现简单,无需复杂技术。

缺点:没冗余特性,不易于扩容。

现阶段磁盘容量1t+都非常普通,对于小型网站,容量可以是忽略的点,但冗余性可以绕不开的点。

这种模式可以在公司还没步入正轨,产品还在试水(或者个人玩玩的时候)使用,当有一定量的用户,可以直接淘汰。

集中式-多机冗余-本地存储-实时同步

针对第一种情况,将图片上传分离,加入图片实时同步系统,从而达到冗余和用户访问的负载均衡。

Web Server:Nginx (apache httpd)

缓存:Apache traffice Server(Squid-由于其当时不具有支持CPU多核特性,所以用了traffice server替代)

架构如下


优化篇-后端图片服务的“打怪升级”_第1张图片


从架构图中可以了解,到这个时候已经具备了高可用特性。但对于容量的可扩展还是一个定时炸弹。

优点:实现难度一般,高可用。

缺点:最大容量取决于单机可支持的最大容量,需要构建健壮的实时同步系统。

新增技术点:inotify rsync。

本人帮忙朋友筹建的创业公司图片体系多选用该种架构,因为初创公司一段时间内图片的量有限,更注重高可用,数据不丢失特性。

集中式-服务多机冗余-共享存储-实时同步(机房间)

在以上两种的架构中,容量的扩展还是不能解决的难题,在分布式块存储和对象存储还没那么大行其道的时候,存储可是我们不二之选,存储有两种拓扑模式:IP SAN和FC SAN。

FC SAN架构

设备:存储、FC交换机。

技术特点:浏览服务和存储服务分离。


优化篇-后端图片服务的“打怪升级”_第2张图片

优点:高可用基础上兼顾扩容,传输稳定。

缺点:成本高(存储、HBA卡、FC交换机及其模块);如果只投入一台存储则,也会存在存储服务的单点。

IP SAN架构

设备:存储、普通千兆或万兆交换机

技术特点:浏览服务和存储服务分离。


优化篇-后端图片服务的“打怪升级”_第3张图片

优点:高可用基础上兼顾扩容,传输没什么意外都稳定。

缺点:成本高(存储);如果只投入一台存储则,也会存在存储服务的单点。

IP SAN 比FC SAN成本要低,但传输的可靠性上没FC那么高,建议IP SAN的网络需要与业务网隔离。

分布式-服务多机冗余-分布式(块或对象)存储-实时同步(机房间)

随着图片体积越大,所需的存储空间就越大,但存储配套的磁盘容量在一定时间内没太多增长(5年+前),所以,不断加柜,但这就带来了成本大大增加。由于成本的压力,寻求代替存储想法日益增加,当时,分布式文件系统开始普遍使用,经过调研、测试,最终敲定了已分布式文件系统代替传统的存储架构。

设备投入的转变:存储变为高性能机器。

融入分布式后的架构


优化篇-后端图片服务的“打怪升级”_第4张图片

对象存储接口或块存储挂载:分布式文件系统被外界访问的接口。

本团队在使用的分布式文件系统:mogilefs、moosefs、ceph。

优点:高可用,容量可轻松扩展。

缺点:人力成本高(对运维同事需要求掌握分布式文件系统能并能做简单适应性修改),继承各分布式文件系统的短板。

头痛问题:存储中图片转移到分布式文件系统-耗时长(当年几十t数据的转移,那酸爽的感觉)、事情零碎。

分布式文件系统的引入,基本已经宣告图片存储的问题可以进入相当长一段时间的稳定期。解决完这个存储问题后,当用户图片上传和访问量上来后,你会发现,图片前端浏览服务会出现io高、cpu高等性能问题;顺着这点问题点,会进行web server优化、也会进行缓存层(ATS)的优化,但提高还有有限,因为机械硬盘的io瓶颈就摆在面前。

这时候有两个方法可以尝试:

1.加前端图片浏览服务机器,分担用户图片的访问量;

2.能不能有一样东西为机械硬盘分担一下工作。

我们团队当时先走加机器保服务,同时也进行ssd盘的引入工作,功夫不负有心人,经测试,ssd盘的引入确实提高不少性能,因此架构变为:


优化篇-后端图片服务的“打怪升级”_第5张图片

经过引入ssd盘,前端图片浏览服务的机器数量降了一半。再过了一段时间,我们团队测试了flash卡,又发现单机性能继续提高,所以,最后ssd盘也被flash卡进行替换,机器数量继续下降。

总结

有关图片服务架构的“打怪升级”路程,基本的战斗思路是:

1、容量的扩展;

2、服务的高可用;

3、硬件设备的成本和性能(存储、高性能机器、ssd盘、flash卡);

4、人力成本。

5、机器中服务提供图片浏览的速度。

(文中省了一个问题,就是缓存服务的升级,Web Server从apache httpd到nginx、缓存层从无到有、从squid到apach traffice server)

文中的多个架构方式其实不能说哪个最优,只是公司所处的状态,选用该状态下最适合方案。另外,值得一提,在“公有云”云存储流行的当下,初创期或高速发展期的公司不妨考虑云存储方案,能帮你解决各种存储、扩展、高可用等问题,帮助你产品更快落地。

更内容请关注,微信订阅号:轻量运维


优化篇-后端图片服务的“打怪升级”_第6张图片

你可能感兴趣的:(优化篇-后端图片服务的“打怪升级”)