Azure：使用完整 IIS 的内部 WebRole 通信 (netTcpBinding)

Question

我需要在 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 中。

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

这就是我遇到问题的地方；这在我在开发环境中运行的本地机器上效果很好。一旦我部署到登台，我就开始收到错误电子邮件，说用于连接到服务的通道无法关闭，因为它处于“故障状态”。

问题：

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

跟进：

通过远程桌面我学到了一些有趣的东西：

• 默认情况下，Azure WebRoles 上未安装非 HTTP 激活。我相信这可以通过启动脚本来克服：

  开始 /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/

Answer 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 项目经理 Yavor Georgiev。

---

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

根据我在帖子中的后续跟进，有一些方法可以使这项工作......但它们很复杂且难以实施。

对于 WORKER ROLES，netTcpBinding 可以完美运行。这里没有问题。继续使用它。

对于 WEB ROLES，您遇到了问题。但是您需要使用 netTcpBinding 来公开内部端点。该怎么办？

好吧，这就是我所做的：

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

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

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

显然，YMMV。

Answer 2

我在 staging 中让 HTTP 在实例之间工作时度过了一段痛苦的时光，当我看起来需要弄乱netsh 以允许我的进程通过 HttpListener 进行侦听时就放弃了（天哪！）。所以我通过套接字切换到 TCP。 HTTP 只是在这样的点对点通信场景中增加了开销。