WCF -解决方案架构

Question

我正在从事一个项目，在这个项目中，iOS应用程序将使用WCF服务。在任何给定的时间点，预期900服务器上的点击率约为900-1000次。每个请求可能需要1-2秒才能完成。预计每秒钟24/7就有同样数量的请求。

这就是我的计划：

percall).

• Request/Response

1. WCF RESTful服务(实例上下文模式为Json)。
2. 中有一些信息需要持久化在服务器上--这些信息实际上是从另一个远程系统接收的--在所有请求之间都是共享的。由于使用数据库可能不是一个好主意(响应时间非常重要-2秒是客户可以等待的最大时间)，将其保存在服务器内存中(比如静态字典-假设此词典将包含150000个对象-每个对象由5-7个字符串类型和它们的键组成)。我知道，这是不稳定的！
3. 每个请求都会生成一个新线程(通过使用Threading.Timers)来进行一些清理--这个线程也会执行一些数据库的读写操作。

现在，如果稍后引入了负载均衡器，内存中存储的对象不能在通过另一个节点路由的请求之间共享--有什么想法吗？

我希望你能帮助我，提出你的意见/建议对整个架构，WCF节流，对象状态持久化等。请提供一些指点所需的硬件以及。我们计划使用Windows 2008企业版服务器、IIS和SQL server 2008 Std版本数据库。

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

Answer 1

由于您使用的是Windows 2008，所以我肯定会使用缓存来存储您的状态：

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

它是免费使用，良好的支持和集成，并是(或多或少) API兼容Windows应用程序织物缓存，如果您每次转移您的服务到Azure。在我们的公司(免责声明:不是我的团队)，我们曾经使用MemCache，但是更改为，并且不后悔。

Answer 2

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

我不同意第三条。在这里使用数据库是正确的做法。为了解决响应时间问题，实现缓存和可能的cache dependency，以便在所有实例之间保持数据同步(假设您是负载平衡的)(还请参见上面/下面建议的App )。在现实世界中，数据经常会发生变化，您必须将影响降到最低。

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

考虑索引 keys/values和Lucene (如果适用的话)。Lucene在读/写方面表现极佳。不要用它来存储你的全部数据，在上面阅读。如果正确使用的话，救生器。请注意，在负载平衡环境上实现可能比较复杂。

基本上，缓存可能是对体系结构的唯一必要更改。