WCF - 解決方案體系結構

Question

我正在研究iOS應用程序將使用WCF服務的項目。網絡服務器在任何特定時間點的點擊次數大約爲900-1000次。每個請求可能需要1-2秒才能完成。預計每24/7每秒都會有相同數量的請求。

這是我的計劃：

1. 寫WCF RESTful服務（實例上下文模式將percall）。
2. 請求/響應將在Json中。
3. 有一些信息需要在服務器中保存 - 這些信息實際上是從另一個遠程系統接收的 - 它在所有請求之間共享。由於使用數據庫可能不是一個好主意（響應時間非常重要 - 客戶可以等待最長時間爲2秒），將它保存在服務器內存中會更好嗎（比如靜態字典 - 假設這個字典是一個收集150000個對象 - 每個對象由5-7個字符串類型及其鍵組成）。我知道，這是不穩定的！
4. 每個請求會產生一個新的線程（通過使用Threading.Timers）來做一些清理 - 這個線程也會做一些數據庫讀寫。

現在，如果稍後推出負載均衡器，那麼內存中存儲的對象不能在通過另一個節點路由的請求之間共享 - 任何想法？

我希望你的大師能夠通過在整個架構上拋出你的意見/建議，WCF節流，對象狀態持久等來幫助我。請提供一些關於所需硬件的指針。我們計劃使用Windows 2008 Enterprise Edition服務器，IIS和SQL Server 2008 Std版本數據庫。

添加更多t＃3： 正如我所說的，我們從遠程系統獲得一些信息給服務。在託管WCF的Web服務器上，將安裝遠程系統的客戶端，並且WCF引用其中一個客戶端DLL以哈希表的形式獲取信息（該方法返回哈希表 - 約150000個對象將在這裏收集）。您是否建議將此信息寫入數據庫，並且到達該服務的iOS請求（每秒）會直接從數據庫中檢索此信息？如果它是靜態的，它會比直接從這個散列表中消耗更好嗎？

Answer 1

由於您使用的是Windows Server 2008中我肯定會使用Windows Server應用程序面料緩存來存儲您的狀態：

http://msdn.microsoft.com/en-us/library/ff383813.aspx

它是免費使用，很好的支持和集成，是（更多或更少）與Windows Azure應用程序結構緩存兼容的API，如果您每次都將您的服務轉移到Azure。在我們的公司（免責聲明：不是我的團隊），我們過去使用MemCache，但更改爲App Fabirc Cache並不後悔。

Answer 2

讓我根據我在WCF框架下服務於類似數量或請求的經驗，3.5在當時的經驗，拋出一些意見/建議。

我不同意＃3。在這裏使用數據庫是正確的事情。爲了解決響應時間，實施緩存和可能的cache dependency爲了保持跨所有實例的數據同步（假設您是負載平衡的）（也參見上面/下面建議的應用結構）。在現實世界的場景中，數據經常發生變化，您必須將影響降至最低。

據我所知，我們使用梭子魚硬件和軟件來處理可擴展性。

考慮索引keys/values與Lucene如果適用。當涉及到讀/寫時，Lucene提供了非常好的性能。不要用它來存儲你的整個數據，閱讀它。如果使用正確，救生員。請注意，在負載平衡的環境中實現可能會很複雜。

基本上，緩存可能是您的體系結構唯一必要的更改。