大红鹰葡京会娱乐Windows平台网站图服务器架设的朝三暮四。大型网站图服务器架设的变异。

于主流的Web站点中,图片数是不可或缺的页面元素,尤其以巨型网站面临,几乎都拿面临“海量图片资源”的囤、访问等息息相关技能问题。在针对图片服务器的架构扩展中,也会历经多弯曲甚至是血泪教训(尤其是初设计不足,造成后期架构上十分不便兼容和壮大)。

巨型网站图服务器架设的形成

于主流的Web站点中,图片数是少不了的页面元素,尤其在巨型网站被,几乎都拿面临“海量图片资源”的囤、访问等相关技术问题。在对图片服务器的架构扩展中,也会见历经多弯弯曲曲甚至是血泪教训(尤其是首规划不足,造成后期架构上很为难兼容和扩充)。

正文将坐一个真垂直门户网站的上扬历程,向大家频频道来。

构建以Windows平台之上的网站,往往会于规范多术看生“保守”,甚至会见生出接触。很大部分因,是出于微软技术系统的封和有些技术人员的近视造成的(当然,主要还是丁的问题)。由于绵绵缺开源支持,所以多人数只好“闭门造车”,这样很易形成思维局限性和短板。以图纸服务器也例子,如果头没有容量规划以及可扩大的规划,那么随着图片文件之不停追加及访问量的升,由于在性质、容错/容灾、扩展性等地方的宏图不足,后续将见面吃支付、运维工作带来多题材,严重时还会见影响至网站工作正常运作与互联网企业之开拓进取(这毫无是在震惊)。

不少合作社用选取Windows(.NET)平台来构建网站及图纸服务器,很大部分是因为创始团队之艺背景决定的,早期的技术人员可能更熟悉.NET,或者组织的企业主觉得Windows/.NET的易用性、“短平快”的出模式、人才基金等地方都于可创业初期的团,自然就分选了Windows。后期工作发展到得范围,也酷麻烦轻易拿完全架构迁移到外开源平台及了。当然,对于构建大互联网,更建议首选开源架构,因为起众多秋之案例与开源生态的支持(也会见发生成千上万坑,就看是您协调初去踩坑,还是当他人踩了修复后您更用),避免再次过去轮子和开支高额授权费。对于迁移难度比充分的下,个人于推荐Linux、Mono、Jexus、Mysql、Memcahed、Redis……混搭的架,同样会支持具有高并发访问和运据量等特点之互联网应用。

正文将以一个实垂直门户网站的前行过程,向大家不断道来。

单机时代的图形服务器架设(集中式)

初创一代由于时间紧,开发人员水平为杀单薄等因。所以普通就直接以website文件所在的目下,建立1只upload子目录,用于保存用户上传的图纸文件。如果按照工作又划分,可以在upload目录下再建不同之子目录来区别。例如:upload\QA,upload\Face等。

以数据库表中保存之也是”upload/qa/test.jpg”这看似相对路径。

用户的走访方式如下:

http://www.yourdomain.com/upload/qa/test.jpg

程序及传和描写副法:

程序员A通过当web.config中配备物理目录D:\Web\yourdomain\upload
然后经过stream的方法写副文件;

程序员B通过Server.MapPath等措施,根据相对路径获取物理目录
然后呢通过stream的主意写副文件。

长:实现起来最为简易,无需另复杂技术,就能学有所成将用户上传的文本写副指定目录。保存数据库记录以及看起来可也坏便利。

缺陷:上传方式混乱,严重不便民网站的扩展。

本着上述极端老的架,主要面临着如下问题:

  1. 趁着upload目录中文件越来越多,所于划分区(例如D盘)如果起容量不足,则生为难扩容。只能停机后换又怪容量的存储设备,再用故数据导入。
  2. 于安排新本子(部署新本子前通过需要备份)和日常备份website文件之早晚,需要而操作upload目录中的文本,如果设想到访问量上升,后止部署由多台Web服务器组成的负荷均衡集群,集群节点内一旦做好文件实时同步将凡独难题。

构建以Windows平台之上的网站,往往会让业内多技看很“保守”,甚至会见时有发生硌。很大部分由,是出于微软技术系统的查封和一些技术人员的急功近利造成的(当然,主要还是人的问题)。由于天长日久短缺开源支持,所以广大丁只能“闭门造车”,这样十分爱形成思维局限性和短板。以图表服务器也例,如果早期没有容量规划暨而扩大的计划,那么就图片文件的随地充实及访问量的起,由于在性能、容错/容灾、扩展性等方面的设计不足,后续将会见让出、运维工作牵动众多题材,严重时居然会潜移默化至网站工作正常运作和互联网公司之进步(这并非是当震惊)。

集群时代之图样服务器架设(实时同步)

在website站点下面,新建一个称为也upload的虚拟目录,由于虚拟目录的八面玲珑,能在定程度达替物理目录,并配合原有的图纸上污染与看方式。用户之访问方式仍然是:

http://www.yourdomain.com/upload/qa/test.jpg

瑜:配置进一步灵活,也会匹配老版本的上传和看方式。

因虚拟目录,可以对本地任意盘符下的任意目录。这样一来,还得经联网外置存储,来展开单机的容量扩展。

短:部署变为是因为多台Web服务器组成的集群,各个Web服务器(集群节点)之间(虚拟目录下之)需要实时的错过联合文件,由于联合效率及实时性的界定,很为难保证某个同随时各节点上文件是完全一致的。

主导架构使下图所示:

大红鹰葡京会娱乐 1

自达成图可观看,整个Web服务器架设已怀有“可扩大、高可用”了,主要问题同瓶颈都汇集在差不多大服务器之间的文件并上。

上述架构中唯有会以当时几贵Web服务器上竞相“增量同步”,这样一来,就非支持文件的“删除、更新”操作的同了。

头的想法是,在应用程序层面做决定,当用户请求在web1服务器进行上传写入的又,也齐去调整用外web服务器上的上传接口,这明摆着是小题大做的。所以我们挑选用Rsync类的软件来做定时文件共的,从而节省了“重复过去轮子”的本金,也下滑了风险性。

同步操作里面,一般生于经典的有限栽模型,即推拉模型:所谓“拉”,就是恃轮询地失去抱更新,所谓推,就是有变动后主动的“推”给其他机器。当然,也得以应用加高级的风波通报机制来完成此类动作。

以青出于蓝并作写副的观被,同步都见面起频率以及实时性问题,而且大量文件同步啊是老大耗费系统跟牵动富资源的(跨网段则重复引人注目)。

博庄为此选择Windows(.NET)平台来构建网站以及图片服务器,很大部分出于创始团队的技术背景决定的,早期的技术人员可能更熟悉.NET,或者组织的主管认为Windows/.NET的易用性、“短平快”的开销模式、人才基金等方面都于符合创业初期的集团,自然就分选了Windows。后期工作发展到得范围,也甚麻烦轻易拿圆架构迁移至其他开源平台及了。当然,对于构建大互联网,更建议首选开源架构,因为有多秋之案例与开源生态的支持(也会见起广大坑,就看是若协调初去踩坑,还是当人家踩了修复后您重新用),避免重复过去轮子和支付高额授权费。对于迁移难度比充分的用,个人于推荐Linux、Mono、Jexus、Mysql、Memcahed、Redis……混搭的架,同样会支持具有高并发访问和天数据量等特色之互联网应用。

集群时代之图服务器架设改进(共享存储)

套用虚拟目录的方,通过UNC(网络路径)的法实现共享存储(将upload虚拟目录指向UNC)

用户之访问方式1:

http://www.yourdomain.com/upload/qa/test.jpg

用户之拜访方式2(可以安排独立域名):

http://img.yourdomain.com/upload/qa/test.jpg

支撑UNC所在server上配备独立域名对,并安排轻量级的web服务器,来实现独立图片服务器。

瑜:
通过UNC(网络路径)的点子来拓展读写操作,可以避多服务器之间同步相关的问题。相对来讲很利索,也支撑扩容/扩展。支持配置成独立图片服务器和域名访问,也圆兼容旧本子的看规则。

缺点
:但是UNC配置有些麻烦,而且会招一定之(读写及安)性能损失。可能会见起“单点故障”。如果存储级别没有raid或者又高级的灾备措施,还会见招致数据丢失。

基本架构使下图所示:

大红鹰葡京会娱乐 2

当初的好多基于Linux开源架构的网站受,如果非思一起图片,可能会见使用NFS来实现。事实证明,NFS在大并发读写及海量存储方,效率达存在必然问题,并非最佳的选料,所以大部分互联网企业还无见面用NFS来促成此类应用。当然,也得经过Windows自带的DFS来兑现,缺点是“配置复杂,效率未知,而且少资料大量的其实案例”。另外,也闹有庄利用FTP或Samba来实现。

上面提到的几种架构,在上传/下载操作时,都由此了Web服务器(虽然共享存储的这种架构,也堪安排独立域名及站点来提供图片看,但上传写入仍然得经过Web服务器上的应用程序来处理),这对Web服务器来讲确实是致使巨大的压力。所以,更建议用独立的图形服务器和单独的域名,来供用户图片的上传和做客。

单机时代之图纸服务器架设(集中式)

初创一代由于时日燃眉之急,开发人员水平为不行简单等由。所以普通就径直在website文件所在的目下,建立1独upload子目录,用于保存用户上传的图样文件。如果按照工作再次分割,可以在upload目录下再次树不同之子目录来区别。例如:upload\QA,upload\Face等。

于数据库表中保存之也是”upload/qa/test.jpg”这类相对路径。

用户之拜访方式如下:

http://www.yourdomain.com/upload/qa/test.jpg

次上传和描写副道:

程序员A通过当web.config中布置物理目录D:\Web\yourdomain\upload 
然后经过stream的艺术写副文件;

程序员B通过Server.MapPath等方法,根据相对路径获取物理目录 
然后为经过stream的法子写副文件。

可取:实现起来最简易,无需任何扑朔迷离技术,就能成功用用户上传的文本写副指定目录。保存数据库记录以及看起来也也甚便利。

缺陷:上传方式混乱,严重不便民网站的扩张。

本着上述极端老的架,主要面临着如下问题:

  1. 随着upload目录中文件越来越多,所于划分区(例如D盘)如果起容量不足,则好不便扩容。只能停机后变又不行容量的存储设备,再用旧数据导入。
  2. 以安排新本子(部署新本子前通过需要备份)和一般备份website文件之时光,需要以操作upload目录中的文本,如果考虑到访问量上升,后止部署由多台Web服务器组成的负载均衡集群,集群节点内如果做好文件实时同步将是个难题。

 

独立图片服务器/独立域名之益处

  1. 图表看是可怜耗费服务器资源的(因为见面波及到操作系统的上下文切换和磁盘I/O操作)。分离出来后,Web/App服务器可以再次专注发挥动态处理的能力。
  2. 独自存储,更有利做扩容、容灾和数目迁移。
  3. 浏览器(相同域名下的)并发策略限制,性能损失。
  4. 访图片时,请求信息遭受到底带cookie信息,也会见招致性能损失。
  5. 便宜做图片看请求的载荷均衡,方便用各种缓存策略(HTTP
    Header、Proxy Cache等),也越有益迁移到CDN。

……

俺们好行使Lighttpd或者Nginx等轻量级的web服务器来架构独立图片服务器。

集群时代的图形服务器架设(实时同步)

每当website站点下面,新建一个称作吧upload的虚拟目录,由于虚拟目录的油滑,能于自然水准达替物理目录,并配合原有的图样上污染与看方式。用户之访问方式仍然是:

http://www.yourdomain.com/upload/qa/test.jpg

优点:配置进一步灵活,也会匹配老版本的上传和看方式。

为虚拟目录,可以针对本地任意盘符下的轻易目录。这样一来,还可以通过交接外置存储,来进展单机的容量扩展。

短:部署变为由多台Web服务器组成的集群,各个Web服务器(集群节点)之间(虚拟目录下之)需要实时的去一起文件,由于联合效率及实时性的限定,很麻烦保证某平时刻各节点上文件是完全一致的。

骨干架构使下图所示:

大红鹰葡京会娱乐 3

自从高达图可见到,整个Web服务器架设已怀有“可扩大、高可用”了,主要问题跟瓶颈都汇集在多雅服务器中的文件共上。

上述架构中单单会以即时几乎令Web服务器上互“增量同步”,这样一来,就非支持文件的“删除、更新”操作的旅了。

初期的想法是,在应用程序层面做决定,当用户请求在web1服务器进行上传写入的同时,也一头去调整用别样web服务器上的上传接口,这明摆着是小题大做的。所以我们选取采取Rsync类的软件来做定时文件共的,从而省去了“重复过去轮子”的成本,也回落了风险性。

同步操作里面,一般有较经典的有限种植模型,即推拉模型:所谓“拉”,就是靠轮询地去得到更新,所谓推,就是发生反后积极的“推”给任何机器。当然,也足以以加高级的风波通报机制来就此类动作。

在胜并作写副的气象中,同步都见面冒出频率及实时性问题,而且大量文件同步啊是大耗费系统及带动富资源的(跨网段则再次明了)。

时下的图形服务器架设(分布式文件系统+CDN)

每当构建当前之图服务器架设之前,可以先彻底抛弃web服务器,直接配置单独的图片服务器/域名。但面临如下的问题:

  1. 原有图数怎么惩罚?能否延续配合旧图路径访问规则?
  2. 独的图片服务器上欲提供单身的上传写入的接口(服务API对外公布),安全问题怎么保证?
  3. 同理,假如有差不多雅独立图片服务器,是应用可扩大的共享存储方案,还是利用实时同步机制?

以至于应用级别之(非系统级) DFS(例如FastDFS HDFS MogileFs
MooseFS、TFS)的流行,简化了这题目:执行冗余备份、支持电动同步、支持线性扩展、支持主流语言的客户端api上传/下载/删除等操作,部分支持文件目录,部分支持提供Web的法门来访问。

考虑到每DFS的特色,客户端API语言支持情况(需要支持C#),文档和案例,以及社区的支持度,我们最终选项了FastDFS来布局。

唯的问题是:可能会见不般配旧本子的拜访规则。如果用原来图一次性导入FastDFS,但由老图看路径分布存储于不同工作数据库的逐一表中,整体创新起来呢十分困难,所以要得相当旧本子的看规则。架构升级往往比较做全新架构更发生难度,就是为还要配合之前版本的题材。(给飞机在半空换引擎可于造架飞机难以得几近)

集群时代的图服务器架设改进(共享存储)

套用虚拟目录的办法,通过UNC(网络路径)的点子贯彻共享存储(将upload虚拟目录指向UNC)

用户之拜访方式1:

http://www.yourdomain.com/upload/qa/test.jpg

用户的拜会方式2(可以安排独立域名):

http://img.yourdomain.com/upload/qa/test.jpg

支持UNC所在server上配备独立域名对,并安排轻量级的web服务器,来实现独立图片服务器。

可取:
通过UNC(网络路径)的方式来拓展读写操作,可以避免多服务器之间同步相关的题目。相对来讲很灵巧,也支撑扩容/扩展。支持配置成单身图片服务器和域名访问,也整体兼容旧本子的顾规则。

缺点
:但是UNC配置有些麻烦,而且会促成一定之(读写及安康)性能损失。可能会见并发“单点故障”。如果存储级别没有raid或者又高级的灾备措施,还会招数据丢失。

骨干架构使下图所示:

大红鹰葡京会娱乐 4

当初的过剩基于Linux开源架构的网站中,如果无思量一起图片,可能会见以NFS来兑现。事实证明,NFS在胜并发读写及海量存储方,效率上有必然问题,并非最佳的精选,所以大部分互联网商家还不见面使用NFS来兑现此类应用。当然,也可经过Windows自带的DFS来贯彻,缺点是“配置复杂,效率未知,而且少资料大量底实际案例”。另外,也来一部分商行利用FTP或Samba来兑现。

 

上面提到的几乎栽架构,在上传/下载操作时,都通过了Web服务器(虽然共享存储的这种架构,也可安排独立域名和站点来提供图片看,但上传写入仍然得经过Web服务器上的应用程序来拍卖),这对Web服务器来讲确实是导致巨大的下压力。所以,更建议利用独立的图纸服务器和单独的域名,来供用户图片的上传和走访。

化解方案如下:

首先,关闭旧本子及污染入口(避免后续采取导致数据不一样)。将原本图数经过rsync工具一次性迁移到独的图样服务器上(即下图中描述的Old
Image
Server)。在太前端(七层代理,如Haproxy、Nginx)用ACL(访问规则控制),将原图对诺URL规则的乞求(正则)匹配到,然后用请直接转接指定的web
服务器列表,在拖欠列表中之服务器上部署好提供图片(以Web方式)访问的站点,并加入缓存策略。这样实现旧图服务器的诀别及缓存,兼容了原本图的访问规则并提升原有图看效率,也避免了实时同步所带来的题材。

整架构使图:

大红鹰葡京会娱乐 5

基于FastDFS的单独图片服务器集群架构,虽然已经十分的秋,但是由于国内“南北互联”和IDC带富成本等题材(图片是老耗流量之),我们最后还是挑选了商用的CDN技术,实现起来吧非常容易,原理其实也大粗略,我此才做个简单的牵线:

用img域名cname到CDN厂商指定的域名及,用户请求访问图片时,则是因为CDN厂商提供智能DNS解析,将多年来的(当然为可能产生其它更扑朔迷离的国策,例如负载情况、健康状态等)服务节点地址返回给用户,用户请求到达指定的服务器节点上,该节点上提供了近似Squid/Vanish的代理缓存服务,如果是率先破呼吁该路线,则会打源站获取图片资源归客户端浏览器,如果缓存中留存,则直打缓存中获取并返回给客户端浏览器,完成请求/响应过程。

由用了商用CDN服务,所以我们连从未设想用Squid/Vanish来自实践构建前置代理缓存。

点的满集群架构,可以很方便的举行横向扩张,能满足一般垂直领域被巨型网站的图片服务要求(当然,像taobao这样超大规模的可能另当别论)。经测试,提供图片看的单台Nginx服务器(至强E5季核查CPU、16G内存、SSD),对小静态页面(压缩后约只有出10kb左右的)可以扛住几千单连发且毫无压力。当然,由于图片本身体积比纯粹文本的静态页面大群,提供图片看的服务器的抗并发能力,往往会受限于磁盘的I/O处理能力和IDC提供的牵动富。Nginx的抗并发能力或者十分大的,而且本着资源占用很没有,尤其是拍卖静态资源,似乎还无待发出了多操心了。可以根据实际访问量的需求,通过调整Nginx的参数,对Linux内核做调优,加入分级缓存策略等手法能够做重新甚程度的优化,也得以透过加服务器或者升级服务器配置来做扩展,最直接的是通过打又尖端的存储设备和更要命的牵动富,以满足再不行访问量的需要。

值得一提的是,在“云计算”流行的立即,也援引高速发展之间的网站,使用“云存储”这样的方案,既能帮您解决各类存储、扩展、备灾的题材,又能够搞好CDN加速。最关键的凡,价格也未贵。

总结,有关图片服务器架设扩展,大致围绕这些问题展开:

  1. 容量规划及扩展问题。
  2. 多少的联手、冗余以及容灾。
  3. 硬件装置的老本及可靠性(是惯常机械硬盘,还是SSD,或者再次高端的存储设备和方案)。
  4. 文件系统的选项。根据文件特性(例如文件大小、读写比例等)选择是用ext3/4还是NFS/GFS/TFS这些开源的(分布式)文件系统。
  5. 图片的增速访问。采用商用CDN或者自建的代理缓存、web静态缓存架构。
  6. 故图路径和做客规则的兼容性,应用程序层面的不过扩大,上传和看的特性及安全性等。

http://www.bkjia.com/Linuxjc/1026759.htmlwww.bkjia.comtruehttp://www.bkjia.com/Linuxjc/1026759.htmlTechArticle大型网站图片服务器架构的演进
在主流的Web站点中,图片数是必备的页面元素,尤其在大型网站遭遇,几乎都用面临海量图片资源的存…

单独图片服务器/独立域名之裨益

  1. 图形看是非常耗费服务器资源的(因为见面涉及到操作系统的上下文切换和磁盘I/O操作)。分离出来后,Web/App服务器可以再专注发挥动态处理的能力。
  2. 单身存储,更便宜做扩容、容灾和数量迁移。
  3. 浏览器(相同域名下的)并发策略限制,性能损失。
  4. 访问图片时,请求信息遭受究竟带cookie信息,也会见招致性能损失。
  5. 好做图片看请求的载重均衡,方便用各种缓存策略(HTTP
    Header、Proxy Cache等),也愈发便宜迁移到CDN。

……

 

咱们得采取Lighttpd或者Nginx等轻量级的web服务器来架构独立图片服务器。

眼前底图服务器架设(分布式文件系统+CDN)

当构建当前底图片服务器架设之前,可以优先彻底废除web服务器,直接配置单独的图服务器/域名。但面临如下的问题:

  1. 原图数怎么处置?能否延续配合旧图路径访问规则?
  2. 独自的图形服务器上得提供单身的上传写入的接口(服务API对外发表),安全问题怎么管?
  3. 同理,假如有差不多宝独立图片服务器,是动可扩大的共享存储方案,还是利用实时同步机制?

 

直至应用级别之(非系统级) DFS(例如FastDFS HDFS MogileFs
MooseFS、TFS)的流行,简化了是题目:执行冗余备份、支持活动同步、支持线性扩展、支持主流语言的客户端api上传/下载/删除等操作,部分支持文件目录,部分支持提供Web的点子来访问。

考虑到各级DFS的性状,客户端API语言支持情况(需要支持C#),文档和案例,以及社区的支持度,我们最终选项了FastDFS来部署。

唯一的题目是:可能会见无匹配旧本子的拜访规则。如果拿原有图一次性导入FastDFS,但出于原图看路径分布存储在不同工作数据库的一一表中,整体创新起来吧十分困难,所以必须得相当旧本子的顾规则。架构升级往往比较做新架构更产生难度,就是以还要配合之前版本的问题。(给飞机在半空中换引擎可于造架飞机难以得差不多)

釜底抽薪方案如下:

先是,关闭旧本子及传入口(避免后续采取导致数据未平等)。将旧图数通过rsync工具一次性迁移至独门的图形服务器上(即下图中描述的Old
Image
Server)。在绝前端(七层代理,如Haproxy、Nginx)用ACL(访问规则控制),将原来图对承诺URL规则的伸手(正则)匹配到,然后用请求直接转化指定的web
服务器列表,在该列表中之服务器上安排好提供图片(以Web方式)访问的站点,并加入缓存策略。这样实现原图服务器的分离及缓存,兼容了原来图的走访规则并提升原有图看效率,也避免了实时同步所带动的题材。

 

一体化架构使图:

大红鹰葡京会娱乐 6

基于FastDFS的独门图片服务器集群架构,虽然曾杀的成熟,但是由国内“南北互联”和IDC带富成本等题材(图片是异常耗流量之),我们最终还是选了商用的CDN技术,实现起来吧非常容易,原理其实呢大简单,我这里就做个简易的牵线:

以img域名cname到CDN厂商指定的域名及,用户请求访问图片时,则由于CDN厂商提供智能DNS解析,将近年来之(当然为或出另更扑朔迷离的策略,例如负载情况、健康状态相当)服务节点地址返回给用户,用户要到达指定的服务器节点上,该节点上提供了仿佛Squid/Vanish的代办缓存服务,如果是率先蹩脚呼吁该路线,则会于源站获取图片资源归客户端浏览器,如果缓存中在,则直打缓存中赢得并赶回给客户端浏览器,完成请求/响应过程。

鉴于采取了商用CDN服务,所以我们并不曾考虑就此Squid/Vanish来自实践构建前置代理缓存。

面的凡事集群架构,可以老有利之做横向扩张,能满足一般垂直领域受到大型网站的图样服务需求(当然,像taobao这样超大规模的或是另当别论)。经测试,提供图片看的单台Nginx服务器(至强E5季核CPU、16G内存、SSD),对小静态页面(压缩后大约就来10kb左右底)可以扛住几千个连发且毫无压力。当然,由于图片本身体积比较纯文本的静态页面大群,提供图片看的服务器的抗并发能力,往往会受限于磁盘的I/O处理能力以及IDC提供的拉动富。Nginx的抗并发能力还是老高的,而且对准资源占用很没有,尤其是拍卖静态资源,似乎都非需出了多操心了。可以因实际访问量的求,通过调整Nginx的参数,对Linux内核做调优,加入分级缓存策略等手法能够做重新老程度的优化,也可以由此加服务器或者升级服务器配置来做扩展,最直白的是经过打又高级的存储设备和还不行之带来富,以满足再可怜访问量的需要。

值得一提的凡,在“云计算”流行的当即,也引进高速发展中的网站,使用“云存储”这样的方案,既会帮你解决各类存储、扩展、备灾的题材,又能够抓好CDN加速。最重点的是,价格也未贵。

总结,有关图片服务器架设扩展,大致围绕这些问题展开:

  1. 容量规划以及扩张问题。
  2. 数量的一块儿、冗余和容灾。
  3. 硬件配备的老本及可靠性(是平凡机械硬盘,还是SSD,或者另行高端的存储设备和方案)。
  4. 文件系统的取舍。根据文件特性(例如文件大小、读写比例等)选择是用ext3/4要么NFS/GFS/TFS这些开源之(分布式)文件系统。
  5. 图片的增速访问。采用商用CDN或者自建的代办缓存、web静态缓存架构。
  6. 故图路径和做客规则的兼容性,应用程序层面的不过扩大,上传和访问的特性及安全性等。

相关文章

admin

网站地图xml地图