首页 > 代码库 > 看大数据时代下的IT架构(1)图片服务器之演进史
看大数据时代下的IT架构(1)图片服务器之演进史
柯南君的公司最近产品即将上线,由于产品业务对图片的需求与日俱增,花样百出,与此同时,在大数据时代,大流量的冲击下,对图片服务器的压力可想而知,那么今天,柯南君结合互联网的相关热文,加上自己的一点实践经验,与君探讨,与君共勉!
一、图片服务器的重要性
当前,不管哪一家网站(包括 电商行业、O2O行业、互联网行业等),不管哪一种渠道 (包括 web端,APP端甚至一些SNS应用),在大数据时代下,在内容为王的前提下,对图片的需求量越来越大,柯南君的公司是一家O2O公司,也不例外,图片服务在满足目前业务的前提下,有必要对图片服务器的前瞻性,要做好规划,现在客户对图片的功能性要求越来越多的个性化需求,不仅仅是图片的上传、下载,甚至对场景的选择,图片要有相应的应急策略。
当然这并不代表,我一上来,就弄一个特别NB的框架,花费昂贵,利用率低,至少要具备一定扩展性、稳定性。
二、图片服务器解决方案
对于图片服务器来说,我想性能方面是我们最关注的,在这里儿,我简要介绍几点:
- IO对与图片服务器的性能来说,至关重要,对于大型web应用来说,图片服务器一定要做分离(非常有必要将图片服务器和应用服务器进行分离 比如imag.***.com),比如集群化或者读写分离,否则服务器的应为IO的负载严重,而导致应用崩溃,现在让我们谈谈这样做的优点吧:
- 分担Web服务器的IO负载,将耗费资源的图片服务分离出来,提高服务器的性能和扩展性;
- 能够专门对图片服务器进行优化,针对性进行缓存优化方案(比如传统的三层缓存),减少网络带宽成本,提高访问速度;
- 提高网站的可扩展性,增加图片服务器,来提高图片的吞吐力;
- 图片服务器可以根据需求进行云化,迁移方便,随时迁到云端;
- 对与运维监测人员甚至监测工具来说,方便容易切入;
从传统的互联网的web1.0阶段,经历了Web2.0时代,发展到现在的Web3.0阶段,随着图片服务器的增加,图片服务器的架构变化,也在随之变化。
首先介绍一下web阶段的演进,便于我们理解:
搞软件开发互联网策划人员经常会谈论Web2.0的话题,虽然说Web2.0已经出来很久了,那么Web2.0到底是什么呢?其实Web2.0代表了一个新的网络阶段,或者说是互联网建设的一种新的模式,它本身并没有特别的标准来进行描述,一般我们将促成这个阶段的各种技术和相关的产品服务统称为web2.0,这一新概念带动了技术和社会的新变革,例如BLOG的热潮。
Web2.0与Web1.0的比较:
- Web2.0是相对Web1.0的新的一类互联网应用的统称。由Web1.0单纯通过网络浏览器浏览html网页模式向内容更丰富、联系性更强、工具性更强的Web2.0互联网模式的发展已经成为互联网新的发展趋势。
- Web1.0的主要特点在于用户通过浏览器获取信息,web2.0则更注重用户的交互作用,用户既是网站内容的消费者(浏览者),也是网站内容的制造者。
- Web1.0到Web2.0的转变,具体的说,从模式上是单纯的由“读”向“写”、“共同建设”发展。所以互联网下一步,是要让所有的人都忙起来,用全民力量共同织出贴近生活的网。到目前为止,对于web2.0概念的说明,通常采用 web2.0典型应用案例介绍,加上对部分Web2.0相关技术的解释。
下面从知识生产、内容生产、交互性和技术等角度比较两者的区别:
从知识生产的角度看,Web1.0的任务,是将以前没有放在网上的人类知识,通过商业的力量,放到网上去。Web2.0的任务是,将这些知识,通过每个用户的浏览求知的力量,协作工作,把知识有机的组织起来,在这个过程中继续将知识深化,并产生新的思想火花;
从内容产生的角度看,Web1.0是商业公司为主体把内容往网上搬,而WEB2.0则是以用户为主,以简便随意方式,通过blog/podcasting方式把新内容往网上搬;
从交互性看,Web1.0是网站对用户为主;Web2.0是以P2P为主;
从技术上看,Web客户端化,出现富客户端模式,比如GoogleMAP/Gmail技术。
Web2.0时代,用户在互联网上的作用越来越大。他们贡献内容,传播内容,而且提供了这些内容之间的链接关系和浏览路径。在SNS里面,内容是以 用户为核心来组织的。Web2.0是以用户为核心的互联网。伴随着Web2.0的诞生,互联网进入了一个更加开放、交互性更强、有用户决定内容并参与共同 建设的可读写网络阶段。
Web2.0相关技术介绍:
1、P2P技术
P2P即Peer to Peer,称为对等连接或对等网络,P2P技术主要指由硬件形成连接后的信息控制技术,其代表形式是软件。
目前互联网主要技术模式是,此方式要在互联网上设置拥有强大处理能力和大带宽的高性能计算机,配合高档的服务器软件,再将大量的数据集中 存放在上面,并且要安装多样化的服务软件,在集中处理数据的同时可以对互联网上其他PC进行服务,提供或接收数据,提供处理能力及其他应用。对于一台与服务器联机并接受服务的PC机来说,这台PC机就是客户机,其性能可以相对弱小。而P2P技术的特征之一就是弱化了服务器的作用,甚至取消服务器,任意两台PC互为服务器,同时又是客户机,即对等。
下面是P2P与C/S方式的一些比较:
- C/S方式造成互联网络上的集中,无论信息资源还是成本资源均向同一方向集中,这样的模式符合一对多、强对弱的社会关系形式,如政府对个人、对企 业,大企业对小企业,学校对学生,企业对职工等等关系。所以C/S方式是符合市场需求的。
- P2P方式将导致信息数量、成本资源都向互联网各点均匀分布,也 就是所谓“边缘化”的趋势。此模式符合“一对一”的特点,以及彼此相当的社会关系形式,如个人对个人,规模相当的企业之间,等等,这也是符合市场需求的 (如ICQ)。所以这两种方式会共存,有关P2P即将替代S/C模式的说法是不成立的。P2P有其独特的市场空间,是现有互联网应用的补充,这一点应该是毫无疑问的。
2、Blog技术
作为Web 2.0 时代的互联网新应用,Blog 在2005 年获得了突破。在相继成为网络、报纸、杂志和电视等众多媒体的热门词汇之后,Blog从一种很少涉及的专家应用发展成了基础的互联网应用。
3、Ajax技术
Ajax 是“Asynchronous JavaScript and XML”英文缩写,综合了XHTML/CSS(层叠式页面)、DOM(文档对象模型)、XMLHttpRequest 和JavaScript 等多项网络技术与服务。Ajax 的工作原理是通过在用户和服务器之间添加一个中间层来实现用户操作与服务器响应的异步化。应用Ajax 后,原本服务器承担的一些简单工作被转移到客户端,由客户端在闲置时完成。这样不但可以减轻服务器的工作压力,还可以实现节约带宽的双重目的。由于 Ajax具有的这些优点,它被广泛地应用于Web 2.0 的众多应用中。
4、XML技术
XML 是“eXtensible Markup Language”的英文缩写,中文译做“可扩展标记语言”。在XML 出现之前,几乎所有的Web 页面都是使用HTML编写。XML 将SGML 的丰富功能与HTML 的易用性结合到了Web 应用中,它允许定义数量不限的标记来描述文档中的资料,同时允许嵌套的信息结构。HTML 主要用于描述Web 页的显示格式,而XML着重描述Web 页面的内容。XML 的广泛应用直接促成了Web2.0 时代的到来,开辟了Web 应用的新天地。
5、RSS技术
…
最后我想再聊聊Web3.0,仅仅是随便说说的,通过上面我们了解了Web1.0和Web2.0,其实假如说Web1.0的本职是联合,那么Web2.0的本质就是互动,它让网民更多地参与信息产品的创造、传播和分享,而这个过程是有价值的。web2.0的缺点是没有体现出网民劳动的价值,所以2.0很脆弱,缺乏商业价值。web2.0是脆弱的,纯粹的2.0 会在商业模式上遭遇重大挑战,需要跟具体的产业结合起来才会获得巨大的商业价值和商业成功。web3.0是在web2.0的基础上发展起来的能够更好地体现网民的劳动价值,并且能够实现价值均衡分配的一种互联网方式
总体而言,web3.0更多的不是仅仅一种技术上的革新。而是以统一的通讯协议,通过更加简洁的方式为用户提供更为个性化的互联网信息资讯定制的一种技术整合。将会是互联网发展中由技术创新走向用户理念创新的关键一步
web2.0虽然只是互联网发展阶段的过渡产物,但正是由于2.0的产生,让人们可以更多地参与到互联网的创造劳动中,特别是在内容上的创造,在这一点上,web2.0是具有革命性意义的。人们在这个创造劳动中将获得更多的荣誉、认同,包括财富和地位。正是因为更多的人参与到了有价值的创造劳动,那么 “要求互联网价值的的重新分配”将是一种必然趋势,因而必然催成新一代互联网的产生,这就是web3.0。
web3.0到来的三个前提:
- 1、博客技术为代表,围绕网民互动及个性体验的互联网应用技术的完善和发展。
- 2、虚拟货币的普及和普遍,以及虚拟货币的兑换成为现实。
- 3、大家对网络财富的认同,以及网络财务安全的解决方案。
web3.0跟web2.0一样,仍然不是技术的创新,而是思想的创新,进而指导技术的发展和应用。web3.0之后将催生新的王国,这个王国不再以地域和疆界进行划分,而是以兴趣、语言、主题、职业、专业进行聚集和管理的王国。到时候真可谓是“皇帝轮流做,明年到我家”,你有机会打造出一个新的互联网王国而成为一个国王,也有可能会在互联网王国的民主竞选中成为总统,到时,你将拥有来自地球各个角落的网络公民。
四、互联网web时代下的图片服务器的演进史
- 初始阶段
在介绍初始阶段的早期图片架构服务器的时候,
4. 1.1 让我们先了解一下NFS技术:
《百度百科》给了NFS概括性的特点如下:
- 概念:
安装配置NFS服务器,具体步骤如下:
- 查看系统是否已经装NFS
- 安装
- 配置
- 启动服务
用户命令:
useradd –d /usr/sam -m sam 此命令创建了一个用户sam,
其中-d和-m选项用来为登录名sam产生一个主目录/usr/sam(/usr为默认的用户主目录所在的父目录)。
# userdel sam 此命令删除用户sam在系统文件中(主要是/etc/passwd, /etc/shadow, /etc/group等)的记录,同时删除用户的主目录。
用户权限提升:
$su -
(注意有- ,这和su是不同的,在用命令"su"的时候只是切换到root,但没有把root的环境变量传过去,还是当前用户的环境变量,用"su -"命令将环境变量也一起带过去,就象和root登录一样)
然后 :
$visudo //切记,此处没有vi和sudo之间没有空格
- 1、移动光标,到最后一行
- 2、按a,进入append模式
- 3、输入 your_user_name ALL=(ALL) ALL
- 4、按Esc
- 5、输入“:w”(保存文件)
- 6、输入“:q”(退出)
这样就启动服务:sudo service nfs start
停止服务: sudo service nfs stop
重启服务: sudo service nfs restart 把自己加入了sudo组,可以使用sudo命令了。
查询共享目录:exportfs
showmount -a //显示已经与客户端连接上的目录信息
showmount -e 210.5.1.138
- 客户端挂载NFS服务器中的共享目录
挂载命令:
sudo mount
210.5.1.138:/home/wenhao/tomcat/apache-tomcat-6.0.36/webapps/brandworld/uploadFile/ /home/wenhao/webfile
查看命令:
mount |grep nfs
取消挂载:sudo umount /home/wenhao/testfile
好,到这里就可以开始检查2个目录文件是否是完全一致了。
4.1.2. 具体实现思路:
- 所有前端web服务器都通过nfs挂载3台图片服务器export出来的目录,以接收web服务器写入的图片。然后[图片1]服务器挂载另外两台图片服务器的export目录到本地给apache对外提供访问。
- 用户上传图片 :用户通过Internet访问页面提交上传请求post到web服务器,web服务器处理完图片后由web服务器拷贝到对应的mount本地目录。
- 用户访问图片: 用户访问图片时,通过[图片1]这台图片服务器来读取相应mount目录里边的图片。
- 性能:现有结构过度依赖nfs,当图片服务器的nfs服务器有问题时,可能影响到前端web服务器。NFS的问题主要是锁的问题. 很容易造成死锁, 只有硬件重启才能解决。尤其当图片达到一定的量级后,nfs会有严重的性能问题。
- 高可用:对外提供下载的图片服务器只有一台,容易出现单点故障。
- 扩展性:图片服务器之间的依赖过多,而且横向扩展余地不够。
- 存储:web服务器上传热点不可控,造成现有图片服务器空间占用不均衡。
- 安全性:nfs方式对于拥有web服务器的密码的人来说,可以随意修改nfs里边的内容,安全级别不高。
2.发展阶段
当网站达到一定规模后,对图片服务器的性能要求越来越高,上述的NFS图片服务器架构面临着挑战,严重的依赖NFS,而且系统容易出现单点压力,容易出现故障,需要在整体架构上进行升级,于是出现了分布式图片服务器架构,如上图所示:
4.2.1 其实现的具体思路如下:
- 用户上传图片到web服务器后,web服务器处理完图片,然后再由前端web服务器把图片post到到[图片1]、[图片2]…[图片N]其中 的一个,图片服务器接收到post过来的图片,然后把图片写入到本地磁盘并返回对应成功状态码。前端web服务器根据返回状态码决定对应操作,如果成功的 话,处理生成各尺寸的缩略图、打水印,把图片服务器对应的ID和对应图片路径写入DB数据库。
- 上传控制: 我们需要调节上传时,只需要修改web服务器post到的目的图片服务器的ID,就可以控制上传到哪台图片存储服务器,对应的图片存储服务器只需要安装 nginx同时提供一个python或者php或者java 服务接收并保存图片,如果不想不想开启python或者php或者java 服务,也可以编写一个nginx扩展模块。
- 用户访问流程: 用户访问页面的时候,根据请求图片的URL到对应图片服务器去访问图片。
如: http://imgN.xxx.com/image1.jpg
此阶段的图片服务器架构,增加了负载均衡和分布式图片存储,能够在一定程度上解决并发访问量高和存储量大的问题。负载均衡在有一定财力的情况下可以 考虑F5硬负载,当然也可以考虑使用开源的LVS软负载(同时还可开启缓存功能)。此时将极大提升访问的并发量,可以根据情况随时调配服务器。当然此时也 存在一定的瑕疵,那就是可能在多台Squid上存在同一张图片,因为访问图片时可能第一次分到squid1,在LVS过期后第二次访问到squid2或者 别的,当然相对并发问题的解决,此种少量的冗余完全在我们的允许范围之内。在该系统架构中二级缓存可以使用squid也可以考虑使用varnish或者 traffic server,对于cache的开源软件选型要考率以下几点:
- 性能:varnish本身的技术上优势要高于squid,它采用了“Visual Page Cache”技术,在内存的利用上,Varnish比Squid具有优势,它避免了Squid频繁在内存、磁盘中交换文件,性能要比Squid高。 varnish是不能cache到本地硬盘上的。还有强大的通过Varnish管理端口,可以使用正则表达式快速、批量地清除部分缓存。nginx是用第 三方模块ncache做的缓冲,其性能基本达到varnish,但在架构中nginx一般作为反向(静态文件现在用nginx的很多,并发能支持到2 万+)。在静态架构中,如果前端直接面对的是cdn的话或者前端了4层负载的话,完全用nginx的cache就够了。
- 避免文件系统式的缓存,在文件数据量非常大的情况下,文件系统的性能很差,像squid,nginx的 proxy_store,proxy_cache之类的方式缓存,当缓存的量级上来后,性能将不能满足要求。开源的traffic server直接用裸盘缓存,是一个不错的选择,国内大规模应用并公布出来的主要是淘宝,并不是因为它做的差,而是开源时间晚。Traffic Server 在 Yahoo 内部使用了超过 4 年,主要用于 CDN 服务,CDN 用于分发特定的HTTP 内容,通常是静态的内容如图片、JavaScript、CSS。当然使用leveldb之类的做缓存,我估计也能达到很好的效果。
- 稳定性:squid作为老牌劲旅缓存,其稳定性更可靠一些,从我身边一些使用者反馈来看varnish偶尔会出现crash的情况。 Traffic Server在雅虎目前使用期间也没有出现已知的数据损坏情况,其稳定性相对也比较可靠,对于未来我其实更期待Traffic Server在国内能够拥有更多的用户。
3.云存储阶段
4.3.1 传统存储服务器的缺陷:
如上图所示,
- 1) 业务扩张,存储需求激增
- 2) 数据丢失
- 3) 权限泄露
- 4) 资金短缺
- 5) 配置维护设备
4.3.2 云存储的优势:
如上图所示,
- 1) 安全、可靠
- 2) 通用、便捷
- 3) 存储容量可扩展
- 4) 任何人都可以使用
- 5) 架构低廉按需付费
真正意义上的“云存储”,不是存储而是提供云服务,使用云存储服务的主要优势有以下几点:
- 1)用户无需了解存储设备的类型、接口、存储介质等。
- 2)无需关心数据的存储路径。
- 3)无需对存储设备进行管理、维护。
- 4)无需考虑数据备份和容灾
- 5)简单接入云存储,尽情享受存储服务。
4.3.3 阿里云存储OSS实例(仅仅是例子,其他家云也有类似的服务)
阿里云存储服务(OpenStorageService,简称OSS),是阿里云对外提供的海量,安全,低成本,高可靠的云存储服务。用户可以通过 简单的 REST接口,在任何时间、任何地点上传和下载数据,也可以使用WEB页面对数据进行管理。同时,OSS提供Java、Python、PHP SDK,简化用户的编程。基于OSS,用户可以搭建出各种多媒体分享网站、网盘、个人企业数据备份等基于大规模数据的服务。在以下图片云存储主要以阿里云 的云存储OSS为切入点介绍,上图为OSS云存储的简单架构示意图。
OSS SLA保障 如下:
- 数据冗余 :3数据冗余份,存储于同一机房不同交换机的不同NC中,机房无自然灾害下,数据不会丢失。
- 身份认证:OSS提供对称加密验证,数据不会被窃取。
- 备份:OSS 具备异地备份能力。
- 查看、添加、删除Bucket,设置Bucket访问权限。
- 按用户指定条件查看Bucket中的 Object列表。
- 添加、删除、读取Object,或者只读它的源信息。
- 支持If-Modified-Since和If-Match之类的HTTP过期验证。
待续...
看大数据时代下的IT架构(1)图片服务器之演进史