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

　　构建在Windows平台之上的网站，往往会被业内众多架构师以为很“守旧”。很大部门缘故原由，是由于微软手艺系统的关闭和部门手艺职员的短视造成的。由于恒久缺乏开源支持，以是只能“凭空捏造”，这样很容易形成头脑局限性和短板。就拿图片服务器为例子，若是前期没有容量计划和可扩展的设计，那么随着图片文件的不停增多和会见量的上升，由于在性能、容错/容灾、扩展性等方面的设计不足，后续将会给开发、运维事情带来许多问题，严重时甚至会影响到网站营业正常运作和互联网公司的生长（这绝不是在危言耸听）。

　　之以是选择Windows平台来构建网站和图片服务器，很大部门由首创团队的手艺配景决议的，早期的手艺职员可能更熟悉.NET，或者卖力人以为Windows/.NET的易用性、“短平快”的开发模式、人才成本等方面都比力切合创业初期的团队，自然就选择了Windows。后期营业生长到一定规模，也很难容易将整体架构迁徙到其它平台上了。固然，对于构建大规模互联网，更建议首选开源架构，由于有许多成熟的案例和开源生态的支持，制止重复造轮子和支出授权用度。对于迁徙难度较大的应用，比力推荐Linux、Mono、Mysql、Memcahed……混搭的架构，同样能支持高并发会见和大数据量。

　　单机时代的图片服务器架构（集中式）

　　初创时期由于时间紧迫，开发职员水平也很有限等缘故原由。以是通常就直接在website文件所在的目录下，建设1个upload子目录，用于生存用户上传的图片文件。若是按营业再细分，可以在upload目录下再建设差别的子目录来区分。例如：uploadQA,uploadFace等。

　　在数据库表中生存的也是”upload/qa/te制作软件st.jpg”这类相对路径。

　　用户的会见方式如下：

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

　　程序上传和写入方式：

　　程序员A通过在web.config中设置物理目录D:Webyourdomainupload 然后通过stream的方式写入文件；

　　程序员B通过Server.MapPath等方式，凭据相对路径获取物理目录 然后也通过stream的方式写入文件。

　　优点：实现起来最简朴，无需任何庞大手艺，就能乐成将用户上传的文件写入指定目录。生存数据库记载和会见起来倒是也很利便。

　　弱点：上传方式杂乱，严重倒霉于网站的扩展。

　　针对上述最原始的架构，主要面临着如下问题：

随着upload目录中文件越来越多，所在分区（例如D盘）若是泛起容量不足，则很难扩容。只能停机后替换更大容量的存储装备，再将旧数据导入。在部署新版本（部署新版本前通过需要备份）和一样平常备份website文件的时间，需要同时操作upload目录中的文件，若是思量到会见量上升，后边部署由多台Web服务器组成的负载平衡集群，集群节点之间若是做好文件实时同步将是个难题。

　　集群时代的图片服务器架构（实时同步）

　　在website站点下面，新建一个名为upload的虚拟目录，由于虚拟目录的天真性，能在一定水平上取代物理目录，并兼容原有的图片上传和会见方式。用户的会见方式依然是：

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

　　优点：设置越发天真，也能兼容老版本的上传和会见方式。

　　由于虚拟目录，可以指向当地恣意盘符下的恣意目录。这样一来，还可以通过接入外置存储，来举行单机的容量扩展。

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

　　基本架构如下图所示：

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

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

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

 1/3    1 2 3 下一页 尾页