WCF-解决方案体系结构

本文关键字：体系结构 解决方案 WCF- | 更新日期: 2023-09-27 18:24:00

我正在进行一个项目，其中WCF服务将由iOS应用程序使用。在任何给定的时间点，网络服务器上的点击量都在900-1000左右。每个请求可能需要1-2秒才能完成。预计每秒钟全天候都会收到相同数量的请求。

这就是我的计划：

  1. 编写WCF RESTful服务（实例上下文模式将为percall）
  2. 请求/响应将在Json中
  3. 有一些信息需要保存在服务器中——这些信息实际上是从另一个远程系统接收的——在所有请求中共享。由于使用数据库可能不是一个好主意（响应时间非常重要-2秒是客户可以等待的最长时间），因此将其保存在服务器内存中（比如静态字典-假设该字典将是150000个对象的集合-每个对象由5-7个字符串类型及其密钥组成）是否好。我知道，这是不稳定的
  4. 每个请求都会生成一个新线程（通过使用Threading.Timers）来进行一些清理——这个线程也会进行一些数据库读/写

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

我希望你的大师们能帮助我，就整个体系结构、WCF节流、对象状态持久性等提出你的意见/建议。请提供一些关于所需硬件的指针。我们计划使用Windows 2008 Enterprise Edition服务器、IIS和SQL server 2008 Std Edition数据库。

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

WCF-解决方案体系结构

由于您使用的是Windows Server 2008，我肯定会使用Windows Server应用程序结构缓存来存储您的状态：

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

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

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

我不同意#3。在这里使用数据库是正确的做法。为了解决响应时间问题，请实现缓存，并可能实现cache dependency，以便在所有实例之间保持数据同步（假设您是负载平衡的）（另请参阅上面/下面建议的应用程序结构）。在现实世界中，数据经常发生变化，您必须将影响降至最低。

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

如果适用，请考虑使用Lucene对keys/values进行索引。Lucene在读/写方面提供了非常好的性能。不要用它来存储你的全部数据，要仔细阅读。如果使用得当，它是一个救命稻草。请注意，在负载平衡的环境中实现可能会很复杂。

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

相关文章：