想要向服务器发送请求并获得响应?直接使用 HTTP 吧!非常简单。但是当需要通过持久的双向连接来通信时,如 WebSockets,当然你也有其它的选择。 等等,其实没有“实时协议”这种东西!确实如此,但这里我将该术语(Realtime Protocol)当作一堆协议的代称,这类协议都是设计用于分发消息,同步数据和通过持久双向的连接来进行请求/响应。
纯消息底层协议(例如 TCP)是被设计用来将一个消息从一个发送者(sender)传递给一个接收者(receiver)。他们并不关系消息本身应该如何构建,也不关系消息的请求、获取、存储以及如何保证安全可靠。 发布-订阅发布-订阅模式是在大规模系统中被广泛使用的通信方式,用于多对多无状态消息传递。“订阅者”(Subscribers)可以订阅“消息主题”(topics,channels,events,namespaces), “发布者”(Publishers)可以将消息发布到“消息主题”,通过路由,所有的订阅者都将收到。 MQTTMQTT(Message Queue Telemerty Transport)[2]是一种二进制协议,主要用于服务器和那些低功耗的物联网设备(IoT)之间的通信。
什么时候应使用它?物联网(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 设备的数据。 选择二进制还是基于文本?到目前为止,我们已经讲了两个协议:一个二进制、另一个基于文本。让我们快速比较一下差异: WAMPWeb 应用消息协议(WAMP,Web Application Messaging Protocol)[9],它尝试开发一种开放的、基于文本的协议标准,并且结合了基于发布-订阅的请求/响应编程模型,同时具备强大的路由和消息投递策略。目前它被广泛用于集成 [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 十分可靠且功能强大。当然它及它的实现并不是足够轻量级。如果你需要一个更轻量级的选择,那接下来的内容可能会更好: ZeroMQZeroMQ[16] 既是一个协议,也是一套协议实现的组件。提供比 AMQP 更高速同时去中心化的替代方案。 什么时候会使用它?当你需要海量吞吐以及无单点故障风险的消息队列支撑你的复杂工作流,那么 ZeroMQ 是个不错的选择,当然,你需要对陡峭的学习曲线做好准备。 JMSJava 消息服务(JMS,Java Messaging Service)[17],是协议同时也是 Java 消息服务规范的标准实现,同时也是 Java 企业版(JEE)规范的一部分。 什么时候应使用它?当你使用 Java 栈,同时也为 Java Enterprise Platform 付费了,那 JMS 是最佳选择。如果没有,那就优先考虑上述那些方案。 请求/响应有时我们只需要发送单个请求,并等待收到一个响应,这完全可以使用HTTP请求完成 / 。 但是既然你已经建立了一个与服务器的持久连接 ,那为什么不利用它呢? DataSyncDataSync 是实现实时通信的最新可选方案。 目前 DataSync 已可以在几个 PaaS 平台上使用,如 deepstreamHub[18],Firebase[19] 或 Realm[20]。 总结一下利用 deepstream[21] 的分布式实时协议(DRP,Distributed Realtime Protocol),我们有信心找到一种方法,将所有上述概念组合成一个协议,同时确保消息大小,可扩展性和互操作性方面的效率最大化。 参考
|
|