Azure 中继摆脱了 WCF 的桎梏，走向跨平台

Azure 服务总线中继（Azure Service Bus Relay）支持把内网 Web 服务暴露给外网用户，不过时至今日，开发者只能通过 Windows Communication Foundation（WCF）来构建这些服务。微软刚刚发布了 Azure Relay Hybrid Connections 的公共预览版，开发人员现在可以使用任何 WebSocket 友好的平台将本地服务连接到这个中继代理上。

Azure 中继通过双向 socket 把发送给 Azure 端点的请求中继到与 Azure 相连的远程服务上。因为中继连接是由主机发起的，并且网络流量走的是传统的 Web 端口，所以不需要对防火墙或内部网络基础设施做任何改动。截至目前，只有 WCF、.NET 和 Windows 开发者可以使用这项特性。Azure 消息系统的首席架构师 Clemens Vasters 在其最近的一篇博文中宣布了一项叫作 Hybrid Connections 的新开放协议，它让 Azure 中继具备了跨平台能力。

Azure 中继的演化版 Hybrid Connections 完全基于 HTTPS 和 WebSocket，我们因此可以安全地把本地防火墙后面的资源和服务与云端的服务或其他任何地方的资产连接起来。

Hybrid Connections 基于 WebSocket 协议，提供了一个安全的、双向的且跟第三方框架无关的二进制通信通道，可以很容易地与许多已存的现代 RPC 框架集成，如 Apache Thrift、Apache Avro、Microsoft Bond 等。

根据最新微软官方文档所述，Azure 中继对开发人员来说不仅仅是一个中转（pass-through）代理，它还提供了很多特性，如“TCP 风格的节流（TCP-like throttling）、端点发现（endpoint discovery）、连接状态（connectivity status）和多层端点安全（overlaid endpoint security）”。微软指出Azure 中继与传统的基于VPN 的解决方案不同，因为Azure 中继可以被绑定到单独的应用端点上，而无需对网络做任何侵入式的改动。

用户在使用基于WCF 的功能时对后端的变化一无所知。而且，Azure 中继现在同时支持传统的WCF 中继和Hybrid Connections。微软在Azure 中继的产品文档中指出，Hybrid Connections 与WCF 中继不同之处在于，它支持.NET Core、Javascript/Node.js、Java、标准的开放协议以及多种RPC 编程模型。协议本身包含了四个“监听器”交互动作——listen、accept、renew 和ping，以及一个“发送器”交互动作——connect。所有的通信都是基于WebSocket，使用443 端口。

定价取决于使用的是WCF 中继还是Hybrid Connections。如果选择了Hybrid Connections，就按照监听器数量和传输的流量计费（每月超过5GB 的部分）。WCF 中继则按照中继时间（每次打开中继时开始计算）和每万条消息进行计费。Azure 中继并不是为支持高并发监听器而设计的，因此并不一定适用于移动设备广播。不过，该服务有个合理的限额，包括单个中继25 个并发监听器（监听器间有负载均衡），每月50 亿条消息和每月2 百万小时中继时长。

作为本次公开预览版的一部分，微软分享了两个Hybrid Connections 样例。 .NET 样例使用了部署在Nuget 上的一个预览包（ Microsoft.Azure.Relay ）。 Node.js 样例使用了一个新的 npm 包（ hyco-ws ），简化了 JavaScript 开发人员建立连接的操作。

为了更多地了解有关本次发布会的细节，InfoQ 对 Clemens Vasters 进行了一次简要的采访。

InfoQ：第一版的服务总线中继（Service Bus Relay）可以追溯到 2010 年。为什么消除对 WCF 和 Windows 的依赖需要花这么长时间？最近对跨平台服务的需求是否很强烈吗？

Vasters：第一版是从 2010 年 1 月开始的，但是 Azure 中继在那之前已经孵化了 3 年时间。它最初依赖 WCF 是因为它是两个 WCF 组员在准备发布 WCF 时无心插柳的作品。虽然从表面上看 API 和协议这些年来一直相当稳定，但是自从第一版发布以来我们做了很多底层的工作。要让该服务与各种客户网络环境协调工作比外人想象的要难得多。协议接口太过稳定，以至于我们发现有一位客户仍然在使用我们 2010 年发布的 1.0 初始版本客户端。对中继跨平台的需求多年来不断上升，我们一直忙得焦头烂额，直到现在才有时间处理它。在这期间，该团队发布了队列 / 主题消息代理（Queues/Topics Messaging broker）、事件中心（Event Hub）、通知中心（Notification Hub），并主导了物联网中心的启动工作。我们运营的云资产负载达到了每月万亿级别的消息传输事务和 PB 级别的数据量。我们一直都很忙。

InfoQ：你认为 Azure 中继理想的使用场景是怎样的？

Vasters：对客户来说，Azure 中继一直是一个惊艳的产品。它为一组难以单独解决的网络通信问题提供了解决方案。首先，它为可以连接到外部网络（或 Azure）的应用或机器提供了反向的应用层连接（inbound application-layer connectivity）。这意味着你的服务器可以接收来自任何地方的连接，包括那些不在管辖范围内的网络。第二，它隐藏了该服务器的位置，这样它在 Internet 上是私密的；当你关闭了主机，IP 地址和端口无法再被使用。第三，中继服务器提供了稳定的网络名，无需使用 DNS 来管理端点。第四，它允许采用 ARM 通过编程的方式发现现有的端点和它们的状态。第五，它为已连接的服务器提供自动的负载均衡。最后，它提供了额外的客户端授权边界，保证所有的通信都是使用 TLS 保护的，服务器不需要判断证书。

任何需要通过 socket 进行端到端连接的场景都是 Azure 中继的用武之地，比如数据库、远程桌面、Shell、RPC。如果连接的双方都在各自的防火墙内，那么需要用到站点到站点的连接方式。如果仅有一方在防火墙内，那么要使用云到站点的连接方式。有些商用打印机通过中继进行打印，有些自动贩卖机通过中继相互连接，有些本地数据库和 CRM 系统通过中继连接到云端。今天人们通过它能做到很多事情，我们希望新的版本能从根本上扩大人们应用它的范围。

近来，Azure 中继被作为连接容器的工具来使用，因为它提供了上面列举的那些功能。

InfoQ：随着时间的推移，架构发生了什么样的变化？在保持服务接口稳定的同时，服务内部的结构是否发生了变化？

Vasters：我们不会过多地讨论服务的内部细节，因为我们发现人们容易断章取义。不过确实，在最开始的 3 年里，我们对服务进行了定期的更新和至少两次大规模的重写。构建超大规模的云平台服务是一门艺术，特别是要在性能、可靠性和成本方面达到均衡更是难上加难。为了让服务内部的重写对外部不可见，我们需要花费额外的精力，有时甚至是一个人月，来保证系统能在保持负载和维持 SLA 的情况下顺利地从一个版本升级到另一个版本。在升级过程中，我们有可能还需要在不同架构的机器间进行切换。

Relay Hybrid Connections 虽然是一个全新的组件，但它是基于那些现有的组件创建的，并和 WCF 中继部署在一起。所以我们可以这么说，那些从一开始就被广泛部署的组件就是 Hybrid Connections 的公共预览版。它内部完全基于 AMQP 栈和 Service Fabric，并不依赖 WCF。WCF 中继和 Hybrid Connections 现在依赖同样的底层基础。

InfoQ：使用像 Azure 中继这类分布式消息解决方案的用户该如何保证系统可用性和对通道的监控能力？用户在什么情况下应该转向使用队列 / 主题这类解决方案？

Vasters：基于队列 / 主题的消息系统和 Azure 中继之间有很大的差别。Azure 中继主要解决连接点之间的连接和定位问题。基于队列 / 主题的消息系统旨在解耦消息的发布者和订阅者，它不要求参与通信的各方同时在线。这两种服务解决的是不一样的通信问题，并且我们相信中继领域尚有非常大的探索空间。

针对监控，我们有一个一直在改进的工具集，这个工具集通过 Azure Portal 的方式提供出来。我们刚刚为中继、队列 / 主题、事件中心对该工具集进行了显著的改进。所有这些数据都可以通过编程的方式访问。有一些第三方解决方案可以帮助我们对那些使用了 Azure Portal API 的服务总线进行监控。

InfoQ：让人感到惊讶的是，这些年来 Azure 中继在行业中一直独占鳌头。你认为为什么会这样呢？

Vasters：市面上也有一些相似的解决方案，但是 Azure 事实上是唯一一个提供了上述服务的云产品。如果把 Hybrid Connections 看作纯粹的 WebSocket 解决方案，它可以运行在任何支持 WebSocket 的平台和设备上，那么可以说它已经是同类服务中的佼佼者，因为它已经被部署到全球范围的 Azure 数据中心和中继集群上，并为数以百万计的连接提供服务。

关于为什么其他大型云服务平台没有提供上述功能，我很难给出答案。从技术方面来说，有可能是因为我们的一些竞争者在架构上太过依赖 HTTP，以至于很难在他们的基础设施上运行有状态的连接服务。CloudFoundry 直到今年才具备了基于 TCP 的路由能力。我们发现在物联网和消息系统技术方面也存在同样的情况。我们运营着最庞大的基于 AMQP/HTTP 多协议的企业级云代理，它的规模无出其右。AWS SQS 仅仅包含这些特性中的一小部分，而且只支持 HTTP，效率要低得多。构建大规模基于高效协议的消息中间件是一件很困难的事情。

InfoQ：既然它面向广泛的用户开放，那么你在它被如何使用方面是否存在一些遐想？你希望看到它与哪些现有产品集成？

Vasters：我们相信，只要我们保持协议的简单性，比如只使用 WebSocket 五个基本的操作手势，就可以在用户和社区中间开辟出很多机会。当然，这种方式也直接影响着定价模型，而定价又是影响产品是否被接受的因素。对 WCF 中继来说，只有部分用户使用了定价较高的功能，而他们居然还觉得他们为此付出的费用简直不值一提。与此同时，还有一些需要使用大量连接或监听器的用户，他们都是毫不迟疑地直接买下我们的产品。我们计划推出一个专门的中继，它的定价模型跟我们的消息系统高级版和事件中心类似。

至于说到它跟现有哪些产品集成，我们认为它可以跟任何一款基于 Socket 和流的产品集成起来。我们将会在如何与编程语言运行时和协议栈集成方面做一些工作。可以与我们的产品集成的软件真的是太多了，比如数据库、OpenSSH、远程桌面、RPC 框架，传感数据流。通过与这项消除网络边界的技术集成，这些框架或产品将从中获得极大好处。

之前我们已经说过，对于躲在那些复杂网络背后的容器组件来说，Azure 中继是一剂解除痛苦的良药。我们的产品在这块有很大潜力。

查看英文原文： Azure Relay Freed from WCF Shackles, Goes Cross-Platform

感谢薛命灯对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。