Chinaunix首页 | 论坛 | 博客
  • 博客访问: 809482
  • 博文数量: 167
  • 博客积分: 7173
  • 博客等级: 少将
  • 技术积分: 1671
  • 用 户 组: 普通用户
  • 注册时间: 2009-08-04 23:07
文章分类

全部博文(167)

文章存档

2018年(1)

2017年(11)

2012年(2)

2011年(27)

2010年(88)

2009年(38)

分类: 系统运维

2017-03-20 09:14:31

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

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

集中式-单机模式-本地存储
在图片较少的情况下,可以直接将上传+图片浏览放在同一个机器中,用web server(apache httpd或nginx)提供浏览服务。
优点:实现简单,无需复杂技术。
缺点:没冗余特性,不易于扩容。
现阶段磁盘容量1t+都非常普通,对于小型网站,容量可以是忽略的点,但冗余性可以绕不开的点。
这种模式可以在公司还没步入正轨,产品还在试水(或者个人玩玩的时候)使用,当有一定量的用户,可以直接淘汰。

集中式-多机冗余-本地存储-实时同步
针对第一种情况,将图片上传分离,加入图片实时同步系统,从而达到冗余和用户访问的负载均衡。
Web Server:Nginx (apache httpd)
缓存:Apache traffice Server(Squid-由于其当时不具有支持CPU多核特性,所以用了traffice server替代)
架构如下



从架构图中可以了解,到这个时候已经具备了高可用特性。但对于容量的可扩展还是一个定时炸弹。
优点:实现难度一般,高可用。
缺点:最大容量取决于单机可支持的最大容量,需要构建健壮的实时同步系统。
新增技术点:inotify rsync
本人帮忙朋友筹建的创业公司图片体系多选用该种架构,因为初创公司一段时间内图片的量有限,更注重高可用,数据不丢失特性。

集中式-服务多机冗余-共享存储-实时同步(机房间)
在以上两种的架构中,容量的扩展还是不能解决的难题,在分布式块存储和对象存储还没那么大行其道的时候,存储可是我们不二之选,存储有两种拓扑模式:IP SAN和FC SAN。

FC SAN架构
设备:存储、FC交换机。
技术特点:浏览服务和存储服务分离。


优点:高可用基础上兼顾扩容,传输稳定。
缺点:成本高(存储、HBA卡、FC交换机及其模块);如果只投入一台存储则,也会存在存储服务的单点。

IP SAN架构
设备:存储、普通千兆或万兆交换机
技术特点:浏览服务和存储服务分离。



优点:高可用基础上兼顾扩容,传输没什么意外都稳定。
缺点:成本高(存储);如果只投入一台存储则,也会存在存储服务的单点。

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

分布式-服务多机冗余-分布式(块或对象)存储-实时同步(机房间)
随着图片体积越大,所需的存储空间就越大,但存储配套的磁盘容量在一定时间内没太多增长(5年+前),所以,不断加柜,但这就带来了成本大大增加。由于成本的压力,寻求代替存储想法日益增加,当时,分布式文件系统开始普遍使用,经过调研、测试,最终敲定了已分布式文件系统代替传统的存储架构。
设备投入的转变:存储变为高性能机器。

融入分布式后的架构


对象存储接口或块存储挂载:分布式文件系统被外界访问的接口。
本团队在使用的分布式文件系统:mogilefs、moosefs、ceph。
优点:高可用,容量可轻松扩展。
缺点:人力成本高(对运维同事需要求有所提升;需要掌握分布式文件系统能并能对其做简单适应性修改),继承各分布式文件系统的短板。
头痛问题:存储中图片转移到分布式文件系统-耗时长(当年几十t数据的转移,那酸爽的感觉)、事情零碎。

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

这时候有两个方法可以尝试:
1.加前端图片浏览服务机器,分担用户图片的访问量;
2.能不能有一样东西为机械硬盘分担一下工作。

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


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

总结
有关图片服务架构的“打怪升级”路程,基本的战斗思路是:
1、容量的扩展;
2、服务的高可用;
3、硬件设备的成本和性能(存储、高性能机器、ssd盘、flash卡);
4、人力成本。
5、机器中服务提供图片浏览的速度。
(文中省了一个问题,就是缓存服务的升级,Web Server从apache httpd到nginx、缓存层从无到有、从squid到apach traffice server)
文中的多个架构方式其实不能说哪个最优,只是公司所处的状态,选用该状态下最适合方案。另外,值得一提,在“公有云”云存储流行的当下,初创期或高速发展期的公司不妨考虑云存储方案,能帮你解决各种存储、扩展、高可用等问题,帮助你产品更快落地。

本文相关架构的落地,离不开团队努力(图片掌舵手小余哥哥、硬件达人华总)。

更多信息,请关注微信订阅号:轻量运维













阅读(438) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~