此link讨论了性能并绕过门户网站。对我来说，验证的WCF服务类似于门户。
轻量级服务根据需要对客户端进行身份验证 生成一个SAS。客户端收到SAS后，即可访问 存储帐户资源直接与权限定义的权限 SAS以及SAS允许的时间间隔。 SAS缓解了这个问题 需要通过前端代理服务路由所有数据。
该应用程序是一个密集的.NET WPF客户端，使用Azure AD与Azure应用程序中托管的WFC服务进行通信以进行身份验证。
这是一个文档管理应用程序，所以文件传输很多。搜索和搜索结果是相对较少的流量。需要搜索才能做出响应。
使用SAS进行文件上传和下载是否过度优化？ 另一种选择是通过WCF服务上传和下载文件 一个或另一个会有什么问题？
我的想法是我希望将文件保留在WCF服务之外以保持响应。
如果这应该是一个单独的问题，那么很好。客户端一次获得搜索1000的结果。即使SAS过期，如果他们将结果延长了几个小时，它也可能会过期。如果SAS是属性绑定，我如何检测过期的SAS？每个文件在应用程序中都有唯一的ID。在get中请求SAS会更好吗？
如果用户可以访问搜索结果中的几乎每个文件，而其他人只能根据搜索结果中的信息访问其中的1个文件。他们可能正在运行一些大型搜索以获取计数并访问零文件。
答案 0 :(得分：1)
使用SAS进行文件上传和下载是否过度优化？
我不这么认为。使用SAS上传/下载文件对我来说非常有意义。
另一种选择是通过WCF上传和下载文件 服务。一个或另一个会有什么问题？
使用基于SAS的方法的最大优势是，您可以直接与Azure存储进行交互，而无需通过WCF服务进行数据路由。因此，您可以保持您的服务非常轻量级，而不是为了扩展目的而放置太多基础设施。对于SAS，WCF服务只需在blob上获取SAS请求，并返回blob的SAS URL，客户端应用程序可以使用该URL来上载文件。
对于SAS，一个值得关注的问题可能是SAS URL的共享以及链接落入了非预期的受众手中。但是，您可以通过保留短期SAS令牌并在SAS上应用IP ACL来缓解这种担忧。
关于您的应用程序（尤其是搜索部分）没有太多信息共享，但我猜测有关文件的信息保存在某种关系数据库中，实际文件保存在blob存储中。作为搜索结果的一部分，我会远离生成SAS令牌，只能按需生成它们。如果用户尝试上传文件，您将在实际上传过程之前获得用于上传的SAS URL。同样，当用户下载文件时，您将获得该文件的SAS URL并进行下载。