我們正在考慮刪除ASP.NET 2.0 Web應用程序中的所有靜態資源（主要是圖片），並將它們移動到他們自己的單獨服務器上。主要的設計要求是速度（所以高速緩存將很重要）和最低級別的安全性（以便人們不能直接下載或剝離圖像）。使用純淨的.net 2.0 Web服務立即衝刺，但我擔心可能的性能問題和緩存？這是一個有效的關注嗎？靜態資源（圖像）Web服務器的體系結構思路？
那麼什麼樣的建築設置適合這項法案呢？
其他一些需要考慮的要點：
編輯 - 爲了進一步澄清我們的立場：
我並不真的需要一個關鍵任務，超高負荷，異步RPC服務器祭出了大量的數據。我需要的僅僅是某種外觀，以便在我們的主站點上爲單獨的Web服務器上的圖像提出請求（並利用IIS緩存），並且能夠簡單地驗證請求以防止基本的盜竊案件。
只需使用在IIS中配置爲虛擬文件夾的靜態文件夾即可。這將提供你需要的一切。緩存，速度等。
使用隨機文件夾/文件名可以實現最小的僞安全性。或者注入Pipline處理程序。當然，你應該禁用文件夾列表等等。
對於高速靜態Web服務，山丘之王是異步I/O，至少是最後一次看起來。有一次，有一個名爲'宙斯'的網絡服務器使用這種類型的體系結構。它專門爲服務大容量靜態內容而設計 - 猜測哪個行業。
線程和同步比您想象的要貴。異步體系結構在服務器中使用相當廣泛，可以非常節約資源。通常單線程速度非常快，以至於它可以在很大程度上超出多線程服務器。
使用asynccore（一個Python異步服務器框架）我可以創建一個可以連接到數據庫的單線程XML-RPC服務器，發出一個簡單的查詢，找到連接並以比多線程服務器更快的速度回覆請求與一個線程池。在一臺CPU上，速度提高了2.5倍。
滾動你自己的異步服務器並不困難。我已經看到他們被分配爲二年級計算機科學作業。您可能可以找到大多數語言的異步Web服務器庫 - Python在標準庫中隨附一個。
最後，我沒有太多時間讓人們說'這樣做，但必須在兩週內完成「。如果你的商業案例只能證明兩個星期的開發時間是正確的，那麼考慮不要打擾 - 商業案例太小，除非它真的是低下的成果。我機械地將一個邊際商業案例轉化爲沒有商業案例。如果這很重要，請給我時間去實現。如果不重要，就不要這樣做。
我們走了 - 剛剛爲您節省了兩週時間和所有持續的維護成本。
你可以開發簡單的HttpHandler（+ MVC路由爲用戶友好的網址）。但是這需要手動處理壓縮，緩存標題，內容部分等。
但是有了這個解決方案，您可以自由地實現任何事情，如跟蹤異常下載，正確的用戶身份驗證，圖像大小調整，圖像優化等等。
+1猜*哪個行業* – 2009-07-20 09:30:59
對不起，我應該更清楚地表明我們正在尋找自己的產品，而不是爲第三方解決方案提供支持。 – mwjackson 2009-07-20 09:34:16