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标准版数据库。

添加更多t＃3： 正如我所说，我们从远程系统获取服务的一些信息。在托管WCF的Web服务器上，将安装远程系统的客户端，并且WCF引用此客户端dll之一以获取信息，以哈希表的形式（该方法返回哈希表 - 大约150000个对象将在这个集合中）。您是否建议将此信息写入数据库，并且到达服务的iOS请求（每秒一次）直接从数据库中检索此信息？如果这是静态的，它会比直接从这个哈希表中消费更好吗？

Answer 1

让我根据我在WCF框架下提供类似金额或请求的经验，提出一些意见/建议，以及当时的3.5。

我不同意＃3。在这里使用数据库是正确的做法。要解决响应时间，请实施缓存以及可能cache dependency，以便在所有实例中保持数据同步（假设您负载均衡）（另请参阅上面/下面建议的App Fabric）。在现实世界的场景中，数据经常会发生变化，您必须尽量减少影响。

据我所知，我们使用Barracuda硬件和软件来处理可扩展性。

如果适用，请考虑使用Lucene 索引 keys/values。 Lucene在读/写方面表现出色。不要用它来存储你的整个数据，阅读它。如果使用正确，可以节省生命。请注意，在负载平衡环境中实现它可能很复杂。

基本上，缓存可能是您架构的唯一必要更改。

Answer 2

由于您使用的是Windows Server 2008，我肯定会使用Windows Server App Fabric Cache来存储您的状态：

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

如果您将服务转移到Azure，它可以免费使用，得到良好支持和集成，并且（或多或少）与Windows Azure App Fabric Cache兼容。在我们公司（免责声明：不是我的团队），我们曾经使用过MemCache但改为App Fabirc Cache而且不后悔。