Azure:具有完整IIS的Intra-WebRole通信(netTcpBinding)

时间:2011-05-22 02:11:57

标签: c# wcf azure nettcpbinding azure-web-roles

我需要在Windows Azure项目中即时更改某些配置设置 - 它们需要通过Web服务调用进行更改(通过平台API或Azure管理站点更新应用程序的配置)这是一个选项)。

该项目有多个Web和辅助角色 - 所有这些角色在更改时都需要了解新配置。

配置持久存储到持久存储,并且它还在运行时在静态变量中缓存。

我的解决方案是在我的角色上创建一个内部(tcp)端点,并使用它来遍历这些角色中的所有角色和实例,动态创建客户端,并告诉实例有关新设置的信息。 (几乎与:http://msdn.microsoft.com/en-us/gg457891

相同

起初我在WebRole的RoleEntryPoint中启动了一个ServiceHost ......我很困惑为什么当我通过通信(静态变量设置正确)时一切似乎都工作正常 - 但是当我做其他的时候webservice调用,静态变量似乎“忘记了”我设置的内容。

本地和Azure登台环境都是如此。

此时我意识到,由于我们使用的是完整的IIS模式,因此RoleEntryPoint和Web服务在两个独立的进程中运行 - 一个在Azure的存根中,另一个在IIS中。

“不成问题”我说过,我只是将从ServiceEntryPoint启动ServiceHost的代码行移动到global.asax中 - 此时ServiceHost将在与其余部分相同的过程中启动网站 - 和静态变量将是相同的。

这是我遇到问题的地方;这在我在dev环境中运行的本地机器上运行良好。一旦我部署到暂存,我就开始收到错误电子邮件,说明用于连接服务的频道无法关闭,因为它处于“故障状态”。

问题:

  • 导致此问题的Azure与Dev环境有什么不同?
  • 如何修复或解决问题?
  • 有没有人对如何获取更具描述性的错误有任何一般性建议...我是否必须在Azure中启用完整的wcf诊断才能获得此功能,或者是否有其他方法可以获得异常详细信息?

跟进:

通过远程桌面我学到了几件有趣的事情:

  • Azure WebRoles上默认未安装非HTTP激活。我相信这可以通过启动脚本来解决:

    start / w pkgmgr / iu:WCF-NonHTTP-Activation;

  • Web角色在IIS中创建的网站默认情况下未启用net.tcp协议。我也相信这可以通过启动脚本来克服:

    %systemroot%\ system32 \ inetsrv \ appcmd.exe设置应用“网站名称在这里”/enabledProtocols:https,http,net.tcp

我没有时间采取这种方式,因为截止日期迫使我暂时实施一些解决方法。

与此主题相关的一些有用链接:

http://msdn.microsoft.com/en-us/magazine/cc163357.aspx

http://forums.iis.net/t/1160443.aspx

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

http://labs.episerver.com/en/Blogs/Paul-Smith/Dates/2008/6/Hosting-non-HTTP-based-WCF-applications-in-IIS7/

2 个答案:

答案 0 :(得分:1)

更新(2011年6月27日):

令人惊讶的是,微软(我评论过的博客)的某个人实际上得到了我的回答。

Azure& WCF团队更新了这篇文章:

http://blogs.msdn.com/b/windowsazure/archive/2011/06/27/hosting-services-with-was-and-iis-on-windows-azure.aspx

该链接包含您使用此功能所需的所有信息。

非常感谢YFT Georgiev,MSFT PM获胜。


我问了这个问题已经有一段时间了,没有答案,所以让我离开这个:

根据我在帖子中的后续行动,有很多方法可以完成这项工作......但它们很复杂且难以实施。

对于WORKER ROLES,netTcpBinding非常有效。没问题。继续使用它。

对于WEB ROLES,你遇到了问题。但是netTcpBinding是你需要用来暴露内部端点的东西。该怎么办?

嗯,这就是我的所作所为:

  • 使用ServiceHost在RoleEntryPoint中启动netTcpBinding服务。
  • 使用SOAP / JSON /随意创建Web角色中的标准WCF服务。
  • 当您通过netTcpBinding接收请求时,将它们代理到环回适配器上的WCF服务。
  • 使用SSL客户端证书正确保护您的“内部”WCF服务。

它并不完美......但它有效,而且并不可怕。

我怀疑需要做这种事情并不是很常见,而且我真的想不出为什么你需要除了在运行时动态修改设置之外的任何理由...这意味着你'不要像疯了一样抨击这些服务。

显然,YMMV。

答案 1 :(得分:0)

我有一个悲惨的时间让HTTP在分段中的实例之间工作,并且在看起来我需要使用netsh来让我的进程通过HttpListener(sheesh!)获得监听的权限时放弃了。所以我通过套接字切换到TCP。 HTTP只会增加像这样的点对点通信场景的开销。