我面临着一个关于在会话实例化模式下托管WCF的情况,我正在封装实际情况,并提出一个复制it...as的示例。
托管的服务是"MyService“。我正在使用windows服务托管it..with http端点。
它将需要支持500个并发会话。(由于合同是工作流based...Login...Function1、Function2、注销,因此不能执行单例和每次调用。)
我有4台服务器,每台都有支持200个并发会话的硬件能力。
因此,我将一台服务器上的服务配置为具有托管路径的路由器(ServiceHost S=新ServiceHost(RouterService)),例如"http://myserver/MyService"。我设置了一个简单的负载平衡机制,并应用路由器表将传入的请求重定向到托管实际服务副本的其他三个服务器...(“http://myserver/MyService1","http://myserver/MyService2","http://myserver/MyService3")。
当hits go mode 200...communication错误开始时,它仍然不是working...As ...我想是因为当进行500个并发调用时,路由器(能力200)也需要与客户端以及实际的服务服务器保持连接...(在会话呼叫模式中)..Is我的想法正确吗??
我的问题是。
1)我的方法是正确的还是有缺陷的concept...Should我要求硬件团队设置NLB...
2)我们是否应该重新设计合同,以确保请求可以通过某种方式进行PerCall……
3)有人建议这样的系统应该托管在云上(Windows Azure)...will需要考虑成本involved...but是否正确...
4)托管WCF以处理基于会话的调用时,涉及的最佳实践是什么。
我知道我的问题很复杂,不会有一个“正确的”answer...but,任何帮助和见解都会非常感谢。
谢谢
发布于 2012-06-27 12:35:20
“我是否应该要求硬件团队设置NLB...”根据您& Shiraz的"Sticky IP cluster“是最接近于托管给定scnerio的。
问题是,WCF会话是传输based.hence,我们不能像传统的aspnet那样将这些“会话”存储在状态服务器/db上。
WCF4.0已经提出了新的绑定,如NetTcpContextBinding,BasicHttpContextBinding,WSHttpContextBinding,它们可以帮助在跨机器environment.But上重新创建上下文。我没有生产实现知识来提供示例。
This的文章应该会帮助你了解更多...
发布于 2012-06-16 23:55:22
这里有三个独立但又相互关联的问题:
依赖于返回到同一服务器的解决方案在Windows Azure上不会(很好)工作。
您可以实现Sticky IP集群,这将解决您的大多数问题,但它不能保证一台服务器上的连接不超过200个。在大多数情况下,这是可以的。
您可以将缓存存储在Appfabric Cache中,然后将其返回到哪个服务器都无关紧要。
您可以重新设计您的系统,以便所有状态都存储在数据库中。
https://stackoverflow.com/questions/11061262
复制相似问题