2022年大型Windows平台网站图片服务器架构的演进 .pdf

《2022年大型Windows平台网站图片服务器架构的演进 .pdf》由会员分享，可在线阅读，更多相关《2022年大型Windows平台网站图片服务器架构的演进 .pdf（4页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

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

2、NET，或者负责人认为Windows/.NET的易用性、“短平快”的开发模式、人才成本等方面都比较符合创业初期的团队，自然就选择了Windows 。后期业务发展到一定规模，也很难轻易将整体架构迁移到其它平台上了。当然，对于构建大规模互联网，更建议首选开源架构，因为有很多成熟的案例和开源生态的支持，避免重复造轮子和支出授权费用。对于迁移难度较大的应用，比较推荐Linux 、Mono 、Mysql、Memcahed ,混搭的架构，同样能支撑高并发访问和大数据量。单机时代的图片服务器架构（集中式）初创时期由于时间紧迫，开发人员水平也很有限等原因。所以通常就直接在website 文件所在的目录下， 建

3、立 1个 upload 子目录，用于保存用户上传的图片文件。如果按业务再细分， 可以在 upload 目录下再建立不同的子目录来区分。例如：uploadQA,uploadFace等。在数据库表中保存的也是”upload/qa/test.jpg”这类相对路径。用户的访问方式如下：名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 1 页，共 4 页 - - - - - - - - - http:/upload.chinaz/2015/0731/1438326331263.jpg 程序上传和

4、写入方式：程序员 A通过在 web.config 中配置物理目录 D:Webyourdomainupload 然后通过 stream 的方式写入文件；程序员 B通过 Server.MapPath 等方式，根据相对路径获取物理目录然后也通过 stream 的方式写入文件。优点：实现起来最简单，无需任何复杂技术，就能成功将用户上传的文件写入指定目录。保存数据库记录和访问起来倒是也很方便。缺点：上传方式混乱，严重不利于网站的扩展。针对上述最原始的架构，主要面临着如下问题：随着 upload 目录中文件越来越多， 所在分区（例如 D盘） 如果出现容量不足，则很难扩容。只能停机后更换更大容量的存储设备，

5、再将旧数据导入。在部署新版本（部署新版本前通过需要备份）和日常备份website 文件的时候，需要同时操作 upload 目录中的文件， 如果考虑到访问量上升， 后边部署由多台 Web服务器组成的负载均衡集群，集群节点之间如果做好文件实时同步将是个难题。集群时代的图片服务器架构（实时同步）在 website 站点下面，新建一个名为 upload 的虚拟目录，由于虚拟目录的灵活性，能在一定程度上取代物理目录，并兼容原有的图片上传和访问方式。用户的访问方式依然是：http:/upload.chinaz/2015/0731/1438326331844.jpg 优点：配置更加灵活，也能兼容老版本的上传

6、和访问方式。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 2 页，共 4 页 - - - - - - - - - 因为虚拟目录，可以指向本地任意盘符下的任意目录。这样一来，还可以通过接入外置存储，来进行单机的容量扩展。缺点：部署成由多台Web服务器组成的集群，各个Web 服务器（集群节点）之间（虚拟目录下的）需要实时的去同步文件，由于同步效率和实时性的限制，很难保证某一时刻各节点上文件是完全一致的。基本架构如下图所示：从上图可看出，整个Web服务器架构已经具备“可扩展、高可用”了，

7、主要问题和瓶颈都集中在多台服务器之间的文件同步上。上述架构中只能在这几台Web服务器上互相 “增量同步”，这样一来，就不支持文件的“删除、更新”操作的同步了。早期的想法是，在应用程序层面做控制， 当用户请求在 web1服务器进行上传写入的同时，也同步去调用其它web服务器上的上传接口， 这显然是得不偿失的。所以我们选择使用Rsync类的软件来做定时文件同步的，从而省去了“重复造轮子”的成本，也降低了风险性。同步操作里面，一般有比较经典的两种模型，即推拉模型：所谓“拉”，就是指轮询地去获取更新，所谓推，就是发生更改后主动的“推”给其它机器。当然，也可以采用加高级的事件通知机制来完成此类动作。在高

8、并发写入的场景中，同步都会出现效率和实时性问题，而且大量文件同步也是很消耗系统和带宽资源的（跨网段则更明显）。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 3 页，共 4 页 - - - - - - - - - 数字域名http:/www.73.tt/ wvoprt57d 名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 4 页，共 4 页 - - - - - - - - -