Windows平台网站图片服务器架构的演进

标签: windows 网站 图片 | 发表时间:2014-05-14 12:41 | 作者:
分享到:
出处:http://kb.cnblogs.com/

  构建在Windows平台之上的网站,往往会被业内众多架构师认为很“保守”。很大部分原因,是由于微软技术体系的封闭和部分技术人员的短视造成的。由于长期缺乏开源支持,所以只能“闭门造车”,这样很容易形成思维局限性和短板。就拿图片服务器为例子,如果前期没有容量规划和可扩展的设计,那么随着图片文件的不断增多和访问量的上升,由于在性能、容错/容灾、扩展性等方面的设计不足,后续将会给开发、运维工作带来很多问题,严重时甚至会影响到网站业务正常运作和互联网公司的发展(这绝不是在危言耸听)。

  之所以选择Windows平台来构建网站和图片服务器,很大部分由创始团队的技术背景决定的,早期的技术人员可能更熟悉.NET,或者负责人认为Windows/.NET的易用性、“短平快”的开发模式、人才成本等方面都比较符合创业初期的团队,自然就选择了Windows。后期业务发展到一定规模,也很难轻易将整体架构迁移到其它平台上了。当然,对于构建大规模互联网,更建议首选开源架构,因为有很多成熟的案例和开源生态的支持,避免重复造轮子和支出授权费用。对于迁移难度较大的应用,比较推荐Linux、Mono、Mysql、Memcahed……混搭的架构,同样能支撑高并发访问和大数据量。

   单机时代的图片服务器架构(集中式)

  初创时期由于时间紧迫,开发人员水平也很有限等原因。所以通常就直接在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服务器组成的负载均衡集群,集群节点之间如果做好文件实时同步将是个难题。

   集群时代的图片服务器架构(实时同步)

  在website站点下面,新建一个名为upload的虚拟目录,由于虚拟目录的灵活性,能在一定程度上取代物理目录,并兼容原有的图片上传和访问方式。用户的访问方式依然是:

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

  优点:配置更加灵活,也能兼容老版本的上传和访问方式。

  因为虚拟目录,可以指向本地任意盘符下的任意目录。这样一来,还可以通过接入外置存储,来进行单机的容量扩展。

  缺点:部署成由多台Web服务器组成的集群,各个Web服务器(集群节点)之间(虚拟目录下的)需要实时的去同步文件,由于同步效率和实时性的限制,很难保证某一时刻各节点上文件是完全一致的。

  基本架构如下图所示:

  从上图可看出,整个Web服务器架构已经具备“可扩展、高可用”了,主要问题和瓶颈都集中在多台服务器之间的文件同步上。

  上述架构中只能在这几台Web服务器上互相“增量同步”,这样一来,就不支持文件的“删除、更新”操作的同步了。

  早期的想法是,在应用程序层面做控制,当用户请求在web1服务器进行上传写入的同时,也同步去调用其它web服务器上的上传接口,这显然是得不偿失的。所以我们选择使用Rsync类的软件来做定时文件同步的,从而省去了“重复造轮子”的成本,也降低了风险性。

  同步操作里面,一般有比较经典的两种模型,即推拉模型:所谓“拉”,就是指轮询地去获取更新,所谓推,就是发生更改后主动的“推”给其它机器。当然,也可以采用加高级的事件通知机制来完成此类动作。

  在高并发写入的场景中,同步都会出现效率和实时性问题,而且大量文件同步也是很消耗系统和带宽资源的(跨网段则更明显)。

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

  沿用虚拟目录的方式,通过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或者更高级的灾备措施,还会造成数据丢失。

  基本架构如下图所示:

  在早期的很多基于Linux开源架构的网站中,如果不想同步图片,可能会利用NFS来实现。事实证明,NFS在高并发读写和海量存储方面,效率上存在一定问题,并非最佳的选择,所以大部分互联网公司都不会使用NFS来实现此类应用。当然,也可以通过Windows自带的DFS来实现,缺点是“配置复杂,效率未知,而且缺乏资料大量的实际案例”。另外,也有一些公司采用FTP或Samba来实现。

  上面提到的几种架构,在上传/下载操作时,都经过了Web服务器(虽然共享存储的这种架构,也可以配置独立域名和站点来提供图片访问,但上传写入仍然得经过Web服务器上的应用程序来处理),这对Web服务器来讲无疑是造成巨大的压力。所以,更建议使用独立的图片服务器和独立的域名,来提供用户图片的上传和访问。

   独立图片服务器/独立域名的好处

  • 图片访问是很消耗服务器资源的(因为会涉及到操作系统的上下文切换和磁盘I/O操作)。分离出来后,Web/App服务器可以更专注发挥动态处理的能力。
  • 独立存储,更方便做扩容、容灾和数据迁移。
  • 浏览器(相同域名下的)并发策略限制,性能损失。
  • 访问图片时,请求信息中总带cookie信息,也会造成性能损失。
  • 方便做图片访问请求的负载均衡,方便应用各种缓存策略(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方式)访问的站点,并加入缓存策略。这样实现旧图片服务器的分离和缓存,兼容了旧图片的访问规则并提升旧图片访问效率,也避免了实时同步所带来的问题。

  整体架构如图:

  基于FastDFS的独立图片服务器集群架构,虽然已经非常的成熟,但是由于国内“南北互联”和IDC带宽成本等问题(图片是非常消耗流量的),我们最终还是选择了商用的CDN技术,实现起来也非常容易,原理其实也很简单,我这里只做个简单的介绍:

  将img域名cname到CDN厂商指定的域名上,用户请求访问图片时,则由CDN厂商提供智能DNS解析,将最近的(当然也可能有其它更复杂的策略,例如负载情况、健康状态等)服务节点地址返回给用户,用户请求到达指定的服务器节点上,该节点上提供了类似Squid/Vanish的代理缓存服务,如果是第一次请求该路径,则会从源站获取图片资源返回客户端浏览器,如果缓存中存在,则直接从缓存中获取并返回给客户端浏览器,完成请求/响应过程。

  由于采用了商用CDN服务,所以我们并没有考虑用Squid/Vanish来重复构建前置代理缓存。

  上面的整个集群架构,可以很方便的做横向扩展,能满足一般垂直领域大型网站的图片服务需求(当然,像taobao这样超大规模的可能另当别论)。经测试,提供图片访问的单台Nginx服务器(至强E5四核CPU、16G内存、SSD),对小静态页面(压缩后的)可以扛住上万的并发且毫无压力。当然,由于图片本身体积比纯文本的静态页面大很多,提供图片访问的服务器的抗并发能力,往往会受限于磁盘的I/O处理能力和IDC提供的带宽。Nginx的抗并发能力还是非常强的,而且对资源占用很低,尤其是处理静态资源,似乎都不需要有过多担心了。可以根据实际访问量的需求,通过调整Nginx参数,Linux内核调优、缓存策略等手段做更大程度的优化,也可以通过增加服务器或者升级服务器配置来做扩展,最直接的是通过购买更高级的存储设备和更大的带宽,以满足更大访问量的需求。

  值得一提的是,在“云计算”流行的当下,也推荐高速发展期间的网站,使用“云存储”这样的方案,既能帮你解决各类存储、扩展、备灾的问题,又能做好CDN加速。最重要的是,价格也不贵。

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

  1. 容量规划和扩展问题。
  2. 数据的同步、冗余和容灾。
  3. 硬件设备的成本和可靠性(是普通机械硬盘,还是SSD,或者更高端的存储设备和方案)。
  4. 文件系统的选择。根据文件特性(例如文件大小、读写比例等)选择是用ext3/4或者NFS/GFS/TFS这些开源的(分布式)文件系统。
  5. 图片的加速访问。采用商用CDN或者自建的代理缓存、web静态缓存架构。
  6. 旧图片路径和访问规则的兼容性,应用程序层面的可扩展,上传和访问的性能和安全性等。

   作者介绍

  丁浪,技术架构师。擅长大规模(高并发、高可用、海量数据)互联网架构,专注于打造“高性能,可扩展/伸缩,稳定,安全”的技术架构。 热衷于技术研究和分享,曾分享和独立撰写过大量技术文章。

相关 [windows 网站 图片] 推荐:

Windows平台网站图片服务器架构的演进

- - 博客园_知识库
  构建在Windows平台之上的网站,往往会被业内众多架构师认为很“保守”. 很大部分原因,是由于微软技术体系的封闭和部分技术人员的短视造成的. 由于长期缺乏开源支持,所以只能“闭门造车”,这样很容易形成思维局限性和短板. 就拿图片服务器为例子,如果前期没有容量规划和可扩展的设计,那么随着图片文件的不断增多和访问量的上升,由于在性能、容错/容灾、扩展性等方面的设计不足,后续将会给开发、运维工作带来很多问题,严重时甚至会影响到网站业务正常运作和互联网公司的发展(这绝不是在危言耸听).

6张Windows 8 Metro风格界面图片欣赏

- Nanqi - 36氪
今天,在全球开发者大会上微软发布了一组Windows 8 Metro界面风格的图片,我们一起来看一下:. 经过个性化定制的lock screen可以显示你的未读邮件和其他应用通知. 在启动界面时预览应用及其大体内容. 还开着 Windows ,关掉它吧:又一个潜伏在微软的俄罗斯间谍被捕. 三星Windows 8平板电脑将采用英特尔芯片.

7张图片带你走进Windows 8 应用商店

- Henry Lee - 36氪
微软在今晨召开的Build 2011开发者大会上首次揭晓了Windows8应用商店的界面,公布了有关Windows8应用商店的更多信息. Windows8应用商店采用Metro UI,开发者在Visual Studio 11开发环境中编写应用程序后,可以直接发布到Windows8应用商店. Windows8应用商店将允许开发者设定软件售价,产品描述和试用期等参数.

Windows 8 Hosts文件无法屏蔽某些网站方法

- - 无名小卒
        Hosts文件的用途主要用于加快域名解析、屏蔽网站、域名重定向等. 微软在 Windows 8中修改了Hosts的屏蔽机制,默认情况下不允许你屏蔽Facebook和在Hosts文件中将任何域名指定向某IP地址,在浏览器打开后,域名指向会从Hosts中自动删除了,但是有办法可以绕过这个限制.

设计案例研究:将网站搬上Windows应用商店

- - WPDang
几十年来,设计网站已成为常规惯例. 对于 Windows 8,设计人员和开发人员可以使用他们熟悉的 Web 技术(包括 HTML5、级联样式表 Level 3 (CSS3) 以及 JavaScript)来构建 Windows 应用商店应用. 下面,我们将探讨如何显示网站的功能从而使 Windows 应用商店应用更出色,并介绍一些使用 Windows 8 平台功能提供附加值、个性化以及更丰富体验的方法.

广东警方抓捕Windows XP盗版商,百度向盗版网站支付千万元

- ArmadilloCommander - Solidot
《信息时报》和《中国日报》报导,广东公安厅在打击侵犯知识产权和制售伪劣产品专项行动新闻发布会上称,共逮捕2429人,摧毁提供售假服务网站70个. 其中一个案件与软件巨人有关,猪猪猫网站破解微软Windows XP后,在里面捆绑广告,上传到网站提供给网民下载,从中赚取第三公司的巨额广告费用. 网站站长王志坚秘密与近二十家网络公司及广告商签订了软件、广告推广的协议,并通过捆绑大量的第三方合作软件非法传播盗版Windows XP,以此牟取暴利.

Windows 8就是Windows 6.2

- Darth Noctis - cnBeta.COM
Windows Vista内核版本号为Windows 6.0,Windows 7为Windows 6.1,微软近日也证实,Windows 8就是Windows 6.2,尽管这个消息已经是尽人皆知了. 想必微软在Vista身上受到了惨痛的教训,以至于今后很长一段时间都无法痊愈. 如果Windows 8下一代的内核版本号采用Windows 6.3,你也不必太过惊讶.

网站推荐:11个相似图片搜索网站(以图找图)

- slackware - FeedzShare
来自: 有意思吧 - FeedzShare  . 发布时间:2011年03月06日,  已有 6 人推荐. 你想凭着一张现有图片找出它的原始图片,或者是凭着一张小的缩略图找出原始大图吗. 下面的十款搜索引擎可以帮你实现,以图找图,以图搜图,以图片搜索相似的图片. 一:http://tineye.com/.

Windows工具集

- - 互联网 - ITeye博客
参考: https://community.rapid7.com/servlet/JiveServlet/downloadBody/2881-102-2-6389/Mitigating%20Service%20Account%20Credential%20Theft%20on%20Windows.pdf.

32个使用大图片为背景的网站设计

- Kione - 创意悠悠花园
在以前带宽不充足的情况下,网站的背景尽量会使用纯色或者小图,但目前带宽在不断的增加,那使用大图作背景的网站也越来越多了,今天就分享:32个使用大图片为背景的网站设计,希望其中有你喜欢的,或者可以给你带来灵感的. Read the rest of 32个使用大图片为背景的网站设计 (20 words).