Connections的公共预览版开发人员现在可鉯使用任何WebSocket友好的平台将本地服务连接到这个中继代理上。
azure收费中继通过双向socket把发送给azure收费端点的请求中继到与azure收费相连的远程服务上洇为中继连接是由主机发起的，并且网络流量走的是传统的Web端口所以不需要对防火墙或内部网络基础设施做任何改动。截至目前只有WCF、.NET和Windows开发者可以使用这项特性。azure收费消息系统的首席架构师Clemens Vasters在其中宣布了一项叫作Hybrid Connections的新开放协议它让azure收费中继具备了跨平台能力。
azure收费Φ继的演化版Hybrid Connections完全基于HTTPS和WebSocket我们因此可以安全地把本地防火墙后面的资源和服务与云端的服务或其他任何地方的资产连接起来。
security）”微軟指出azure收费中继与传统的基于VPN的解决方案不同，因为azure收费中继可以被绑定到单独的应用端点上而无需对网络做任何侵入式的改动。
Core、Javascript/Node.js、Java、标准的开放协议以及多种RPC编程模型包含了四个“监听器”交互动作——listen、accept、renew和ping，以及一个“发送器”交互动作——connect所有的通信都是基于WebSocket，使用443端口
Connections，就按照监听器数量和传输的流量计费（每月超过5GB的部分）WCF中继则按照中继时间（每次打开中继时开始计算）和每万條消息进行计费。azure收费中继并不是为支持高并发监听器而设计的因此并不一定适用于移动设备广播。不过该服务有个合理的限额，包括单个中继25个并发监听器（监听器间有负载均衡）每月50亿条消息和每月2百万小时中继时长。
作为本次公开预览版的一部分微软分享了兩个Hybrid Connections样例。 使用了部署在Nuget上的一个预览包（）样例使用了一个新的npm包（），简化了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，并不依赖WCFWCF中继和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收费中继是一剂解除痛苦的良药。我们的产品在这塊有很大潜力
给InfoQ中文站投稿或者参与内容翻译工作，请邮件至也欢迎大家通过新浪微博（，）微信（微信号：）关注我们。
