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

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

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

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

在图片较少的情况下,可以直接将上传+图片浏览放在同一个机器中,用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)

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

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


最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 205,236评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 87,867评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 151,715评论 0 340
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,899评论 1 278
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,895评论 5 368
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,733评论 1 283
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,085评论 3 399
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,722评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 43,025评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,696评论 2 323
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,816评论 1 333
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,447评论 4 322
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,057评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,009评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,254评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,204评论 2 352
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,561评论 2 343

推荐阅读更多精彩内容