企业移动应用程序有望在多种情况下运行，并且必须考虑其目标平台的功能。 与后端服务进行通信时，他们可能必须提供解决方案以应对挑战，包括：
信息保密 低带宽连接的协议开销 容忍不稳定的网络连接 电池消耗低 多个客户端平台（iOS，Android等） 机密的“推送”通信，包括后台通知。此外，后端服务可能需要处理数百万个客户端的同时连接。
根据mqtt.org的定义， “ MQTT是一种机器到机器（M2M）/'物联网'连接协议。它被设计为一种极其轻量级的发布/订阅消息传递。它对于与远程位置的连接非常有用。只需要很小的代码占用空间和/或网络带宽是非常重要的……由于其体积小，功耗低，数据包最少以及有效地将信息分配给一个或多个接收器，因此它也是移动应用的理想选择。”
本教程说明如何将MQTT和IBM MessageSight独特地放置，以向移动设备提供可靠的企业消息传递。 它还将概述采用这种方法的风险，并说明如何仔细配置IBM MessageSight可以为这些应用程序实现可靠性，安全性和客户机机密性。
本文假定您熟悉HTTP和MQ技术。
让我们首先评估与后端服务进行通信的以下协议，并研究区别标准：
HTTP IBM MQ MQTT（IBM MessageSight）MQTT的独特之处在于它的每个消息头可以低至2个字节。 MQ和HTTP均具有更高的按消息开销。 在使用HTTP的情况下，为每个新请求消息重新建立HTTP连接会导致大量开销。 MQ和MQTT使用的永久连接可以大大减轻这种情况。
网络容差不稳定MQTT和MQ具有从断开连接等中恢复的能力，而无需进一步的代码要求。 但是，HTTP无法本机执行此操作，需要客户端重试编码，这可能导致幂等性问题增加。
低功耗MQTT专为低功耗而设计。 HTTP在设计时并未考虑到这一点，因此增加了功耗。
数百万连接的客户维持数百万个并发连接需要大量的精力来支持HTTP堆栈。 尽管有可能 ，但大多数商业产品并未经过优化以处理这种数量的永久连接。 IBM提供了IBM MessageSight，这是一台机架式服务器，经过测试可通过MQTT处理多达一百万个并发连接的设备。 相反，MQ不是为大量同时存在的客户而设计的。
推送通知您需要能够及时将通知传递给客户。 为此，必须采用定期轮询或推送方法； 从电池，系统负载和带宽的角度来看，push是最佳解决方案。
我们的企业可能要求没有第三方中介机构才能发送敏感信息。 这打折了特定于操作系统的解决方案（例如Apple iOS，Google Play通知）作为主要传输机制。
HTTP仅允许使用长期持有的HTTP请求的称为COMET的方法进行推送。 从客户端和服务器的角度来看，这种方法都很昂贵。 MQ和MQTT都支持推送作为该技术的基本功能。
客户平台差异HTTP和MQTT客户端都已在多种平台上实现。 MQTT的简便性使您可以以最小的努力在其他客户端上实施。
防火墙容忍某些公司防火墙将出站连接限制为某些定义的端口。 这些通常仅限于HTTP（端口80），HTTPS（端口443）等。 在这些情况下，HTTP显然可以运行。 MQTT可以封装在WebSockets连接中，并显示为HTTP升级请求，从而允许在这种情况下进行操作。 MQ不允许这种模式。
MQTT协议的固有品质是我们许多必需的特性，例如不稳定的网络容限和低功耗。 因此，此处将不介绍它们。 取而代之的是，我们将重点放在需要配置的区域，并说明正确理解此概念所需的概念。
我们将使用IBM MessageSight提供客户端连接到的MQTT代理组件。 它以设备和可云部署的虚拟映像形式提供，可以与我们的企业系统集成，并提供网络边缘连接层。
“IBM MessageSight能够支撑100万个并发传感器或智能设备，并且可以扩展到每秒13000000个消息。 ”
IBM新闻发布，2013年4月29日
通常，IBM MessageSight设备将提供与主要企业JMS / MQ服务总线（例如IBM Integration Broker）的向前连接。 但是，企业应用程序有可能通过IBM MessageSight MQTT代理直接与客户端进行通信。
您需要考虑MQTT通信的三个主要用例：请求-响应调用模式，流和通知。
在大多数应用程序中，与企业服务的大多数交互遵循经典的请求-响应模式：
客户端通过MQTT发出请求消息。 然后，MessageSight代理将它们传递到后端服务。 响应消息通过逆过程传递，从服务通过MessageSight代理传递，然后通过MQTT传递给客户端。客户端应用程序通常使用带有临时响应队列的短期订阅来执行此操作。 必须在请求消息中为每个请求-响应交互指定唯一的响应主题。 通常，这是指定的“特定于用户”的响应主题空间的子主题。
流式传输信息的典型示例是股票行情自动收录器信息，货币汇率，新闻等。 流式传输的信息很可能是公开的。 客户将选择（隐式或显式）遵循某些流。
这种用例需要客户端应用程序维护主题的中期订阅； 通常，只有当客户端应用程序的界面位于“前景”中时，这些选项才处于活动状态。
通知可以是用户机密信息（例如医疗结果的帐户更改），也可以是公共信息（例如计划的停机时间或市场状况通知）。 此用例要求客户端应用程序维护对主题的长期订阅。 此外，预计客户端应用程序将处于后台状态，可能会关闭客户端设备的屏幕。
尽管某些移动操作系统允许与MQTT的永久连接 ，但许多不允许。 在这些情况下，或者由于任何原因导致后台连接失败的情况下，都需要一种专门的方法。
从v1.1开始，IBM MessageSight提供了断开连接的客户端通知 -通知客户端应用程序（通过特定于操作系统的推送通知服务，例如Apple的iOS通知服务）消息正在等待客户端。 收到此类通知后，客户端应用程序应重新连接到MQTT代理以接收这些消息。
要实现断开连接的客户端感知解决方案，需要开发单独的服务，该服务将实现IBM MessageSight的断开连接的客户端通知API。
任何企业MQTT解决方案都需要仔细考虑配置，以考虑到安全性（包括客户端机密性）和性能的非功能性需求。
除了保护MessageSight实例的管理界面（在IBM MessageSight 知识中心中介绍 ）之外，您还需要考虑以下安全方面：
传输级安全性：所有通信的加密。在我们的方案中，必须对通过Internet与IBM MessageSight进行的所有通信进行加密。 除了行业标准的SSL功能外，IBM MessageSight还提供FIPS 140-2和NIST 800-131a级别的加密功能。
身份验证：仅允许授权的客户端进行连接。可以选择使用客户端证书身份验证来增加额外的安全性。 您可以使用它来确保只有批准的客户端应用程序才能连接到您的MessageSight代理。 用户身份验证应该是强制性的。 IBM MessageSight通过使用企业LDAP服务器检查其凭证来认证用户。
授权： MQTT的发布-订阅模型默认为打开状态。 您需要确保各级信息的机密性； 例如，企业级，用户级和设备级。您需要锁定主题树，以确保用户只能访问他们应有的信息。 您可以通过为IBM MessageSight配置许多消息传递策略来实现此目的（表2）。 此处概述的示例主题结构说明了风扇在 IBM MessageSight知识中心的按设备请求-答复场景中提出的建议。
IBM MessageSight通过在消息传递策略中执行自动变量替换来实施这些授权规则。
主题名称中替换变量的顺序很重要。 如果使用，则应将ClientID变量指定为主题名称的最后一部分以进行替换。 客户端ID由客户端在连接时指定，并且可以包含任何字符，因此，攻击者可以使用该ID来访问子主题。 但是，您的客户端应用程序和服务必须通过手动替换变量以获得正确的主题名称来订阅/发布正确的主题。
您的使用模式-请求-响应，流传输和通知-对您应该使用的消息服务质量（QoS）级别有独特的要求。
指定比您的消息/订阅所需的更高的QoS可能很诱人。 但是，随着QoS的提高，MessageSight代理上的资源成本也随之增加。 如果要最大化性能，则必须为每个消息选择最合适的QoS级别。
以上信息仅是建议。 您的特定企业应用程序可能具有会改变这些建议的要求。
本教程研究了MQTT在企业通信中的适用性，包括对潜在风险的了解，并概述了有助于减轻这些风险的配置策略。
翻译自: https://www.ibm.com/developerworks/websphere/techjournal/1501_maynard/1501_maynard.html
相关资源：微信小程序源码-合集6.rar