Web 文件服务器设计方法

我一直在设计一个文件服务器，它可以减轻主网站的负担，并通过web向客户端提供图像/文件

文件服务器的主要目标：
-从承载站点的主服务器上卸载
-重用现有的web服务器代码库，避免代码/逻辑的重复，以实现更好的可维护性
-可扩展以增加下载量
-对用户隐藏实际下载url路径

通过记住以上内容，我可以想出两种方法。为便于理解，这两种方法的序列图表示法[对序列图的不正确使用表示歉意]。这两种方法都不能满足我的所有目标

考虑到我的目标，您建议采用以下哪种方法？
有更好的第三种方法吗

我可以想到其中的一些差异：
-方法#1将导致重复BL代码，导致可维护性问题
-方法2将重用代码并集中BL，从而减少可维护性问题
-方法1会减少网络呼叫，而方法2会增加网络呼叫

文件服务器的概念、下载的可扩展性、带宽分配都已经存在了一段时间。请分享你的想法

更新：

---

方法1看起来非常有吸引力，因为它完全减轻了主服务器的负载。#1中要解决的唯一问题是代码复制和可维护性问题。这可以通过为BL/DAC提供一个包含web服务和文件服务器所需功能的项目来克服。并且，在web服务和文件服务器项目中引用程序集/库。现在，只有一个BL/DAC代码需要维护，并且避免了方法2中的网络调用

通过向客户端提供图像/文件，我假定您指的是静态文件css、js等

大多数情况下，简单的解决方案是最好的解决方案。只需将它们托管在不同子域名下的不同服务器上，即。您可以将它们托管在专用服务器上的数据中心，以提供性能（靠近主干网），您可以通过url进行负载平衡，并在2+个不同的数据中心拥有2+个服务器，从而提供抗干扰性和可扩展性

---

然后，在将站点升级为live时，您的maintence任务必须找到一个替换项，以将dev/uat内容路径替换为live内容路径（虽然您只需要在css文件中执行此操作，因为您可以将aspx文件中使用的内容路径存储为配置数据）。

@Jaimal:By files，我指的是用户上传的存储在Web服务器/db上的文档。目标是使其以后可扩展到数据中心上的主机。@Pencilslate:Hmm，在上载时，使用guid重写文件名，生成一个难以读取的url和99.99%唯一的url，并将文件写入单独的服务器。将guida作为索引列与其他元数据（文件名大小、类型、上载日期等）一起存储在数据库中。然后在请求文件时，使用guid获取文件。当发送repsonse流时，可以将文件名快速重写为原始文件名。因此，您已经创建了唯一的文件名和唯一的d/l url和don；我们不必在请求时创建一个。