Blob SAS WCF 和性能

Question

这个link 谈论性能并绕过门户。对我来说，进行身份验证的 WCF 服务类似于门户。

轻量级服务根据需要对客户端进行身份验证，然后 生成一个 SAS。一旦客户收到 SAS，他们就可以访问 存储帐户资源直接具有由定义的权限 SAS 和 SAS 允许的时间间隔。 SAS 减轻了 需要通过前端代理服务路由所有数据。

该应用程序是一个厚实的 .NET WPF 客户端，它与托管在 Azure 应用程序中的 WFC 服务进行通信，使用 Azure AD 进行身份验证。

它是一个文档管理应用程序，因此可以传输大量文件。搜索和搜索结果是相对少量的流量。需要搜索响应。

使用SAS进行文件上传和下载是否过度优化？
另一种选择是通过 WCF 服务上传和下载文件。
其中一个有什么问题？

我的想法是我希望将文件从 WCF 服务中移除，以使其保持响应。

如果这应该是一个单独的问题，那很好。客户端一次得到1000个搜索结果。即使 SAS 的过期时间很长，如果他们把结果留了几个小时，它也可能过期。如果 SAS 是属性绑定，我如何检测过期的 SAS？每个文件在应用程序中都有一个唯一的 ID。只在 get 中请求 SAS 会更好吗？

在某些情况下，用户可以访问搜索结果中的几乎所有文件，而在其他情况下，根据搜索结果中的信息，他们只能访问 100 个文件中的 1 个。他们可能正在运行一些大型搜索以仅获取计数并访问零个文件。

Answer 1

使用SAS进行文件上传和下载是否过度优化？

我不这么认为。使用 SAS 上传/下载文件对我来说完全有意义。

另一种选择是通过 WCF 上传和下载文件 服务。其中一个有什么问题？

使用基于 SAS 的方法的最大优势是您可以直接与 Azure 存储进行交互，而无需通过 WCF 服务进行数据路由。因此，您可以保持您的服务真正轻量级，并且不会为了扩展目的而在其后面放置太多基础设施。对于 SAS，WCF 服务将简单地获取一个对 blob 的 SAS 请求，并返回您的客户端应用程序可用于上传文件的 blob 的 SAS URL。

对于 SAS，一个问题可能是共享 SAS URL 和链接到非目标受众手中。但是，您可以通过保留短期 SAS 令牌并在 SAS 上应用 IP ACL 来缓解这种担忧。

---

关于您的应用程序（尤其是搜索部分）没有共享太多信息，但我猜测有关文件的信息保存在某种关系数据库中，而实际文件保存在 blob 存储中。我会远离生成 SAS 令牌作为搜索结果的一部分，并且只按需生成它们。如果用户尝试上传文件，您会在实际上传过程之前获得一个用于上传的 SAS URL。同样，当用户下载文件时，您会在那时获得该文件的 SAS URL 并进行下载。