Wolfram Hempel 是 deepstreamIO 的联合创始人。deepstreamIO 是一家位于德国的技术创业公司,为移动客户端、及物联网设备提供高性能、安全和可扩展的实时通信服务。文本由魏佳翻译,转载译文请注明来自高可用架构。

想要向服务器发送请求并获得响应?直接使用 HTTP 吧!非常简单。但是当需要通过持久的双向连接来通信时,如 WebSockets,当然你也有其它的选择。

这篇文章会简单扼要的解释 MQTT,XMPP,STOMP,AMQP,WAMP 和其它替代品。这里常被引用的 XKCD 漫画[1]之一:

等等,其实没有“实时协议”这种东西!

确实如此,但这里我将该术语(Realtime Protocol)当作一堆协议的代称,这类协议都是设计用于分发消息,同步数据和通过持久双向的连接来进行请求/响应。

我们先来根据它们各自的目的进行分类:

纯消息

底层协议(例如 TCP)是被设计用来将一个消息从一个发送者(sender)传递给一个接收者(receiver)。他们并不关系消息本身应该如何构建,也不关系消息的请求、获取、存储以及如何保证安全可靠。

像 WebSockets 这样在 TCP 之上的协议,添加了一些额外的功能,例如使用头部(header)传输元数据,通过多个数据包分割较大的消息,简单的身份验证,以及路由/重定向相关信息。本质上它们仍然是点对点交换数据的方式。

当涉及到构建更大,更复杂的系统时,你需要一个更高层次的通信范式:

发布-订阅

发布-订阅模式是在大规模系统中被广泛使用的通信方式,用于多对多无状态消息传递。“订阅者”(Subscribers)可以订阅“消息主题”(topics,channels,events,namespaces), “发布者”(Publishers)可以将消息发布到“消息主题”,通过路由,所有的订阅者都将收到。

这种范式是非常灵活,高效和可扩展。它将发送者与接收者隔离开,允许订阅者自由得订阅主题或取消订阅。这和我们日常订阅报纸是一样的。

有许多支持发布-订阅的协议:MQTT,STOMP,WAMP 等等。那么我们应该如何选择呢?

MQTT

MQTT(Message Queue Telemerty Transport)[2]是一种二进制协议,主要用于服务器和那些低功耗的物联网设备(IoT)之间的通信。
它位于 TCP 协议的上层,除了提供发布-订阅这一基本功能外,也提供一些其它特性:不同的消息投递保障(delivery guarantee),“至少一次”和“最多一次”。通过存储最后一个被确认接受的消息来实现重连后的消息恢复。

它非常轻量级,并且从设计和实现层面都适合用于不稳定的网络环境中。

什么时候应使用它?

物联网(IoT)场景中更适合,支持几乎所有语言进行开发,并且浏览器也可通过 WebSocket 来发送和接收 MQTT 消息。

同时,对于MQTT Broker,也有很多选择,如 Mosquitto[3] 或 VerneMQ[4] 以及基于云的 MQTT 平台,如 HiveMQ[5] 或 CloudMQTT[6]。

STOMP

面向流文本的消息传输协议(STOMP,Streaming Text Oriented Messaging Protocol)[7],是 WebSocket 通信标准。在通常的发布-订阅语义之上,它通过 begin/publish/commit 序列以及 acknowledgement 机制来提供消息可靠投递。

由于协议简单且易于实现,几乎所有的编程语言都有 STOMP 的客户端实现。但是在消息大小和处理速度方面并无优势。

什么时候会使用它?

当与 Apache Apollo[8] 这样的多协议代理(multi-protocol broker)中间件结合使用时,可以做许多有趣的集成。比如在浏览器的图表中不断更新 IoT 设备的数据。

选择二进制还是基于文本?

到目前为止,我们已经讲了两个协议:一个二进制、另一个基于文本。让我们快速比较一下差异:
通过控制线缆中光或电的打开或关闭(逻辑开关),或控制 WiFi 信号的波峰或波谷来实现计算机之间的信息交换。从原理上来说,这是基于二进制的形式。因此,从这个层面来说所有协议都是二进制协议
信息一旦发送,接收方有两个选择:它可以将 0/1 流分组成字节序列,进而获取(解析)信息;或者可以执行额外的步骤,将其转换为文本,然后再解析此文本。
前一种方法称为(基于)二进制的。它节省了一些昂贵的操作,同时是传输任何非文本信息的标准形式。
例如,图像,音频,视频或文件。当然它也可用于发送文本信息。
例如,通过向每个消息增加几个字节来表达元信息,比如描述该消息的长度或类型,这样就只需将实际的消息数据转换为文本。
然而,由于在许多发布-订阅式的架构中,信息交换是基于文本的,所以许多协议选择简单地将整个信息转化为文本,从而降低复杂性并提高了可读性,当然带来的代价就是需要再消息接受后执行额外的计算任务

WAMP

Web 应用消息协议(WAMP,Web Application Messaging Protocol)[9],它尝试开发一种开放的、基于文本的协议标准,并且结合了基于发布-订阅的请求/响应编程模型,同时具备强大的路由和消息投递策略。目前它被广泛用于集成 crossbar.io[10] 路由器和 autobahn 的高速缓存客户端[11]。

Pusher / PubNub&Co

那些实时通信平台即服务(Realtime platform-as-a-service)的产品,例如 Pusher 或 PubNub,通常使用它们自己的专有协议。Pusher 已经公开了它们研发的基于 JSON 协议的详细规范[12],并且鼓励第三方或社区帮助构建不同语言的客户端。Pubnub 虽然更封闭一些,但它们目前支持一系列其它开放协议进行交互,如 MQTT。

队列

有些场景下,简单的发布-订阅模式还不够。这就是队列存在的场合:它支持多种不同的消息和存储的模式。

通过获取/确认策略,消费者接收到队列的一些消息,确认他们的“消费”,处理它们,然后取下一批消息。这是一个强大同时常用的方式。

想象一下,你正在构建一个类似 Instagram 的产品,它允许用户上传图片并添加各种滤镜。应用滤镜的过程是一个计算密集型的操作。因此,不能在上传时直接进行操作,所以接收图像的服务器只是记录下在文件系统中的位置,接着将“什么图像需要使用什么样的滤镜”这个任务添加到任务队列中。

另一台专门用于处理滤镜的机器可以从任务队列中获取这个任务,读取原始图像文件,应用滤镜,并确认这个任务已经消费(完成)。之后为了水平扩展图像处理的能力,只需要添加更多的消费者(处理滤镜的机器)来处理任务队列即可。

这种模式非常易于扩展,可以添加复杂的路由策略,任务分配策略等。

AMQP

高级消息队列协议(AMQP,Advanced Message Queuing Protocol)[13]是各种消息队列协议中的佼佼者。RabbitMQ[14] 和 HornetQ[15] 都是实现该协议的流行中间件。

什么时候会使用它?

当简单的发布-订阅模型不能满足使用要求。AMQP 十分可靠且功能强大。当然它及它的实现并不是足够轻量级。如果你需要一个更轻量级的选择,那接下来的内容可能会更好:

ZeroMQ

ZeroMQ[16] 既是一个协议,也是一套协议实现的组件。提供比 AMQP 更高速同时去中心化的替代方案。

什么时候会使用它?

当你需要海量吞吐以及无单点故障风险的消息队列支撑你的复杂工作流,那么 ZeroMQ 是个不错的选择,当然,你需要对陡峭的学习曲线做好准备。

JMS

Java 消息服务(JMS,Java Messaging Service)[17],是协议同时也是 Java 消息服务规范的标准实现,同时也是 Java 企业版(JEE)规范的一部分。

什么时候应使用它?

当你使用 Java 栈,同时也为 Java Enterprise Platform 付费了,那 JMS 是最佳选择。如果没有,那就优先考虑上述那些方案。

请求/响应

有时我们只需要发送单个请求,并等待收到一个响应,这完全可以使用HTTP请求完成 / 。 但是既然你已经建立了一个与服务器的持久连接 ,那为什么不利用它呢?

这种通过持久连接进行的请求/响应模式的通信过程,通常被称为远程过程调用(RPC,Remote Procedure Calls)或远程方法调用(RMI,Remote Method Invocation)。AMQP 或 ZeroMQ 可以通过响应队列(response-queue)来实现这种模式,JMS 可以直接支持 Java RMI。

DataSync

DataSync 是实现实时通信的最新可选方案。

DataSync 将数据存储中的数据同步给客户端。客户端对数据的变更都将同步给所有的订阅者。DataSync 隐藏了实时通信类应用中维护数据状态的细节,降低了复杂性,并极大加快了开发速度,但它目前仍然是一种没有开放的协议标准。

目前 DataSync 已可以在几个 PaaS 平台上使用,如 deepstreamHub[18],Firebase[19] 或 Realm[20]。

总结一下

利用 deepstream[21] 的分布式实时协议(DRP,Distributed Realtime Protocol),我们有信心找到一种方法,将所有上述概念组合成一个协议,同时确保消息大小,可扩展性和互操作性方面的效率最大化。

参考

  1. https://xkcd.com/

  2. http://mqtt.org/

  3. https://mosquitto.org/

  4. https://vernemq.com/

  5. http://www.hivemq.com/

  6. https://www.cloudmqtt.com/

  7. https://stomp.github.io/

  8. https://activemq.apache.org/apollo/

  9. http://wamp-proto.org/

  10. http://crossbar.io/

  11. http://crossbar.io/autobahn/

  12. https://pusher.com/docs/pusher_protocol

  13. https://www.amqp.org/

  14. https://www.rabbitmq.com/

  15. http://hornetq.jboss.org/

  16. http://zeromq.org/

  17. http://docs.oracle.com/javaee/6/tutorial/doc/bncdq.html

  18. https://deepstreamhub.com/

  19. https://firebase.google.com/

  20. https://realm.io/

  21. https://deepstream.io/

推荐阅读

https://mp.weixin.qq.com/s/IyvKMTQY3Nzt719Bs09uyg

MQTT, XMPP, WebSockets还是AMQP?泛谈实时通信协议选型 good的更多相关文章

  1. 物联网通信协议——比较-MQTT、 DDS、 AMQP、XMPP、 JMS、 REST、 CoAP

    物联网通信协议——比较-MQTT. DDS. AMQP.XMPP. JMS. REST. CoAP   AMQP & MQTT & DDS (https://www.youtube.c ...

  2. Crazyflie笔记五: CRTP 实时通信协议(一)(转)

    源:Crazyflie笔记五: CRTP 实时通信协议(一) 这里详细介绍了 Crazyflie 的 CRTP实时通信协议的相关内容,由于内容很长,分几篇博文来讲述.这里是第一节内容.欢迎交流:301 ...

  3. Android推送方案分析(MQTT/XMPP/GCM)

    本文主旨在于,对目前Android平台上最主流的几种消息推送方案进行分析和对比,比较客观地反映出这些推送方案的优缺点,帮助大家选择最合适的实施方案. 方案1. 使用GCM服务(Google Cloud ...

  4. 【转载】Android推送方案分析(MQTT/XMPP/GCM)

    http://m.oschina.net/blog/82059 本文主旨在于,对目前Android平台上最主流的几种消息推送方案进行分析和对比,比较客观地反映出这些推送方案的优缺点,帮助大家选择最合适 ...

  5. [转]Android推送方案分析(MQTT/XMPP/GCM)

    资源描述: 方案1. 使用GCM服务(Google Cloud Messaging)简介:Google推出的云消息服务,即第二代的G2DM.优点:Google提供的服务.原生.简单,无需实现和部署服务 ...

  6. 【架构】MQTT/XMPP/GCM 等参考资料

    https://www.zhihu.com/question/29138530 https://segmentfault.com/q/1010000002598843/a-10200000026014 ...

  7. 采用MQTT协议实现android消息推送(2)MQTT服务端与客户端软件对比、android客户端示列表

    1.服务端软件对比 https://github.com/mqtt/mqtt.github.io/wiki/servers 名称(点名进官网) 特性 简介 收费 支持的客户端语言 IBM MQ 完整的 ...

  8. 海鑫智圣:物联网漫谈之MQTT协议

    什么是MQTT协议 MQTT(消息队列遥测传输协议)是IBM在1999年专门针对物联网等应用场景来制订的轻量级双向消息传输协议,它主要是为了解决物联网上使用到的设备的互相通信的问题,以及这些设备与后端 ...

  9. 云巴:基于MQTT协议的实时通信编程模型

    概要 有人常问,云巴实时通信系统到底提供了一种怎样的服务,与其他提供推送或 IM 服务的厂商有何本质区别.其实,从技术角度分析,云巴与其它同类厂商都是面向开发者的通信服务,宏观的编程模型都是大同小异, ...

随机推荐

  1. js实现复选框全选

    HTML代码如下: <div> <label><input type="checkbox" name="aAll">全选&l ...

  2. kmeans算法c语言实现,能对不同维度的数据进行聚类

    最近在苦于思考kmeans算法的MPI并行化,花了两天的时间把该算法看懂和实现了串行版. 聚类问题就是给定一个元素集合V,其中每个元素具有d个可观察属性,使用某种算法将V划分成k个子集,要求每个子集内 ...

  3. Mysql Index、B Tree、B+ Tree、SQL Optimization

    catalog . 引言 . Mysql索引 . Mysql B/B+ Tree . Mysql SQL Optimization . MySQL Query Execution Process 1. ...

  4. 《奥威Power-BI销售计划填报 》精彩回顾

    我们经常遇到这样的问题:业务单据是来自ERP系统,销售计划是EXCEL做的,想把两者整合在一起做分析,怎么办? 单据大,导出EXCEL太费劲,也很难分析到历史数据,但又不能动ERP系统 (自己也不会改 ...

  5. 【Java 基础篇】【第六课】接口interface

    Java提供的这个interface的语法,目的就是将接口从类中剥离出来,构成独立的主体. 首先加入我们定义了这个杯子接口: interface Cup { void addWater(int w); ...

  6. HDOJ 5000 Clone

    所有的属性,以满足一定的条件,是,财产和等于sum/2结果最大. Clone Time Limit: 2000/1000 MS (Java/Others)    Memory Limit: 65536 ...

  7. web-storage-cache 使用JS数据缓存

    https://github.com/WQTeam/web-storage-cache 使用WebStorageCache,只要在页面上引入下面代码即可. <script src="s ...

  8. Spring源码情操陶冶#task:executor解析器

    承接Spring源码情操陶冶-自定义节点的解析.线程池是jdk的一个很重要的概念,在很多的场景都会应用到,多用于处理多任务的并发处理,此处借由spring整合jdk的cocurrent包的方式来进行深 ...

  9. Spring Cloud Alibaba Nacos 入门

    概览 阿里巴巴在2018年7月份发布Nacos, Nacos是一个更易于构建云原生应用的动态服务发现.配置管理和服务管理平台.并表示在6-8个月完成到生产可用的0.8版本,目前版本是0.9版本. Na ...

  10. 【原创】大数据基础之Flink(1)简介、安装、使用

    Flink 1.7 官方:https://flink.apache.org/ 一 简介 Apache Flink is an open source platform for distributed ...