Azure: Intra-WebRole Communication (netTcpBinding) with Full

本文关键字：with Full netTcpBinding Intra-WebRole Communication Azure | 更新日期: 2023-09-27 17:57:06

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

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

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

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

起初，我在WebRole的RoleEntryPoint中启动了一个ServiceHost。我很困惑为什么当我逐步完成通信（正确设置的静态变量）时一切似乎都工作正常 - 但是当我进行其他 Web 服务调用时，静态变量似乎已经"忘记"了我设置的内容。

本地和 Azure 过渡环境中都是这种情况。

在这一点上，我意识到，因为我们使用的是全IIS模式，所以RoleEntryPoint和Web服务在两个单独的进程中运行 - 一个在Azure的存根中，一个在IIS中。

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

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

问题：

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

跟进：

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

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

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

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

    %

    systemroot%''system32''inetsrv''appcmd.exe set app "Website Name Here"/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/

Azure: Intra-WebRole Communication (netTcpBinding) with Full

更新 （6/27/2011）：

令人惊讶的是，Microsoft的某个人（我评论了他们的博客）实际上给了我一个答案。

Azure和WCF团队更新了这篇文章：

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

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

非常感谢Yavor Georgiev，MSFT总理获胜。

自从我提出这个问题以来已经有一段时间了，没有答案，所以让我离开这个：

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

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

对于 WEB 角色，您遇到了问题。但是 netTcpBinding 是用于公开内部终结点所必需的。怎么办？

好吧，这是我所做的：

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

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

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

显然，YMMV。

我有一个痛苦的时期，让HTTP在暂存的实例之间工作，当看起来我需要弄乱netsh时放弃了，以授予我的进程通过HttpListener监听的权限（嘘！ 所以我通过套接字切换到TCP。 HTTP 只会在这样的点对点通信方案中增加开销。

相关文章：