我面临着在会话实例化模式下托管WCF的情况。我正在封装实际情况并提出一个复制它的示例......如下所示。
要托管的服务是“MyService”。我正在使用Windows服务来托管它...使用http端点
它需要支持500个并发会话。（Singleton＆amp; Percall无法完成，因为合同是基于工作流的......登录...功能1，功能2，注销...）
我有4个服务器，每个服务器具有支持200个并发会话的硬件功能
所以我将一台服务器上的服务配置为路由器（ServiceHost S = new ServiceHost（RouterService）），其主机路径为“http：// myserver / MyService”。我已经设置了一个简单的负载平衡机制，并应用了Router表将传入的请求重定向到托管实际服务副本的其他三个服务器...（“http：// myserver / MyService1”，“http：// myserver / MyService2 “，”http：// myserver / MyService3“）
它仍然不能正常工作......一旦命中率超过200 ......通信错误就会开始...我想因为当进行500次并发呼叫时，路由器（能力200）也需要保持连接客户端以及实际服务服务器...（在会话呼叫模式下）..我的想法是否正确？
我的问题是......
1）我的方法是否正确或有缺陷......我是否应该要求硬件团队设置NLB ...
2）我们是否应该专门重新设计合同以确保以某种方式使请求成为PerCall ...
3）有人建议这样的系统应该托管在云端（Windows Azure）......需要考虑所涉及的成本......但是它是否正确...
4）托管WCF以处理基于会话的呼叫时涉及的最佳实践是什么。
我知道我的问题很复杂，并且没有一个“正确”的答案......但任何帮助和见解都会非常感激。
由于
答案 0 :(得分：0)
这里有三个单独但相关的问题：
依赖于返回同一服务器的解决方案在Windows Azure上无法正常工作。
您可以实现一个Sticky IP群集，它可以解决您的大部分问题，但不保证一台服务器上的连接数不超过200个。在大多数情况下，这是可以的。
您可以将缓存存储在Appfabric Cache中，然后返回哪个服务器无关紧要。
您可以重新设计系统，以便将所有状态存储在数据库中。
答案 1 :(得分：0)
“我应该要求硬件团队设置NLB ......” Shiraz的“Sticky IP cluster”是最接近给定的scnerio的人。
问题是WCF会话是基于传输的。因此我们无法将这些“会话”存储在状态服务器/ db上，就像传统的aspnet一样。
WCF4.0已经提出了新的绑定，例如NetTcpContextBinding，BasicHttpContextBinding，WSHttpContextBinding，它可以帮助在跨机器环境中重新创建上下文。但是我没有生产实现知识来提供示例。
This文章可以帮助您了解更多...