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

Ste*_*eve 5 c# wcf azure nettcpbinding azure-web-roles

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

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

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

我的解决方案是在我的角色上创建一个内部(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/

Ste*_*eve 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

该链接包含您进行此操作所需的所有信息。

非常感谢 MSFT 的 PM Yavor Georgiev 获胜。


自从我问这个问题以来已经有一段时间了,但没有答案,所以让我留下这个:

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

对于工作者角色,netTcpBinding 工作得很好。这里没有问题。继续使用它吧。

对于 WEB 角色,您会遇到问题。但是 netTcpBinding 是您需要用来公开内部端点的。该怎么办?

好吧,这就是我所做的:

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

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

我怀疑需要做这种事情并不常见,而且我真的想不出除了在运行时动态修改设置之外您还需要这样做的任何原因......这意味着您不会猛击这些服务简直太疯狂了。

显然,YMMV。