Blob SAS WCF和性能

Question

此link談論性能和繞過門戶。對我來說，進行身份驗證的WCF服務與門戶類似。

輕量級服務根據需要驗證客戶端，然後 生成SAS。一旦客戶端接收到SAS，他們就可以直接使用 SAS定義的權限訪問 存儲帳戶資源，並在SAS允許的時間間隔內訪問。 SAS減輕了通過前端代理服務路由所有數據的需求。

該應用程序是一個厚的.NET WPF客戶端，與使用Azure AD進行身份驗證的Azure應用程序中承載的WFC服務進行通信。

這是一個文件管理應用程序，所以很多文件傳輸。搜索和搜索結果是相對較少的流量。需要搜索來響應。

使用SAS進行文件上傳和下載是否過度優化？
另一種選擇是通過WCF服務上傳和下載文件。
對於其中一個會有什麼問題？

我的想法是我想保持文件關閉WCF服務，以保持響應。

如果這應該是一個單獨的問題然後罰款。客戶一次獲得搜索1000的結果。即使SAS在很長時間內到期，如果他們將結果延長几個小時，也可能會過期。如果SAS是屬性綁定，我該如何檢測已過期的SAS？每個文件在應用程序中都有唯一的ID。在請求中請求SAS會更好嗎？

有些情況下，用戶幾乎可以訪問搜索結果中的每個文件，而其他用戶則只能訪問基於搜索結果中信息的100個文件中的一個。他們可能正在運行一些大型搜索來獲取計數並訪問零個文件。

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網址。同樣，當用戶正在下載文件時，您當時會獲得該文件的SAS URL並進行下載。