物联网的消息传递
为一个物联网用例部署消息代理模块，对于broker接口的可延展性而言会带来新的挑战。我们现在谈论的物联网涉及到数千个连接，消费者和目的，这让我们必须思考如何更仔细地配置和监控我们消息传递的基础设施。在本文中，我将尝试总结一些可用于当前Apache ActiveMQ的技术，以便更好地进行物联网部署。我还将介绍为5.12.0版本开发的一些新功能，以便更好地适应这个新世界。最后我会试着阐释我们的发展方向，以及我们未来可以做些什么。
ActiveMQ垂直缩放
用于物联网的两种最常用的消息传递协议是MQTT和AMQP，我们花了大量时间精力来让着两个协议在新版本中变得更稳定。但协议不是一切，每次有人开始调用broker接口时，都会出现同样的疑惑：如何从单个broker接口获得最大的可扩展性？所以，这里有一些提示：
- 每一次都从broker扩展技术开始。这基本上意味着无论您的broker接口需要处理多少连接和目的地，都尽可能使用最少的线程。因此，建议使用NIO传输并转换每个目标线程的设置。
- ActiveMQ的第一个MQTT协议的实现是假定QoS1和QoS2的订阅者在内部会被映射到JMS持久订阅者。JMS持久订阅者会有太多的信息堆积，并且不能很好地扩展。在以后的版本中，您会有其他的协议实现方式，如使用虚拟主题，这应该能更好的扩展信息。
- 试用新5.12.0版本的另一个原因是这个版本对于预先分配日志文件的KahaDB消息存储的改进。你可以在这篇文章中找到关于这方面的更多信息，但是在某些文件系统上的这些调整可以显着提高性能
所有这些小小的配置调整总结在新的示例配置文件中，你可以在这里找到
examples/conf/activemq-mqtt.xml文件在新的5.12.0发行版中。
对broker进行垂直扩展只是一部分。一个成功的物联网应用平台需要解决几个更重要的问题。
SSL
许多物联网设备依靠SSL证书进行身份验证。这不是什么新的设置，我们在传统的消息传递设置中也是这么操作的，但差异在于传输的规模。手动维护包含少量证书的密钥存储库很容易。但当证书数量开始增加时，情况就完全不同了。
在5.12.0版本中，我们增加了一些新功能来帮助人们处理这个问题。有几个标准化工具可以解决这些问题，并在JDK中得到支持。所以现在，您可以使用证书吊销列表，该列表提供了一种在运行期间撤销无效证书的简单方法。
您还可以使用OCSP（联机证书状态协议），它提供了更加自动化的方式与您的证书颁发客户端进行通信。您可以在这里找到关于这些功能的更多信息。
我认为，SSL证书配置对于物联网部署（和一般的云服务器）来说是一个更大的问题，对此已经有新兴的有趣项目试图解决它，如pki.io。我们将尝试支持所有人们在这个领域中进行的工作，现在在CRL和OCSP的支持下，在处理证书时您可以有更大的灵活性。
在压力下监测
在谈论物联网部署时，我经常遇到的一个主题是如何监视处于垂直缩放限制（无论它们是什么）的broker。我们通常使用JMX或"通知消息"机制来监视broker行为。尽管这些都是broker处于限制时的理想工具，但当broker处于临界时，情况会变得不那么理想。
随着大量目的地和连接的进出，登记MBeans和取消“通知消息”机制的成本可能会变得非常昂贵，特别是需要处理大量数据的时候。这可以阻碍broker需要做的实际工作。
想要从broker实例中获得最大收益的人通常只会关掉所有的东西，比如说
< broker useJmx = “false” advisorySupport = “false” ... >但这让我们对broker的状态一无所知，在日志中也无法获取信息。
我们提出的一个解决方案是使mbean注册更具选择性
从5.12.0开始，您可以定义要禁止注册的mbean名称，方法是在管理上下文中定义它们
<managementContext> <managementContext suppressMBean="endpoint=dynamicProducer,endpoint=Consumer, connectionName=*,destinationName=ActiveMQ.Advisory.*"/></managementContext>使用此功能，您可以自定义您需要的broker视图，并通过抑制注册/注销高频短暂的mbeans，您可以帮助您的broker处理负载。因此，即使在高规模/负载情况下，您也可以获取broker的基本指标。我们可以在这个领域做更多的事情如通过定义自定义视图等，敬请期待。
旧版MQTT
Apache ActiveMQ实现了MQTT 3.1.1规范，但MQTT不是一种新协议。同时我们已经部署了大量使用旧（3.1）客户端的设备。我们努力启用已知的使用案例中，老客户期望与3.1.1规范中的不同的部分。例如，您可以启用“美元主题”的发布，并看到在不成功的订阅尝试中的行为差异。我们将尽力涵盖所有这些角落案例，并为传统客户提供支持，而明智的做法是为这些客户提供支持。
ActiveMQ Artemis
您可能没有注意到，在Java message broker中有一些合并。HornetQ代理已经捐赠给Apache，现在是ActiveMQ项目的一部分。它的异步核心为下一代ActiveMQ提供了一个良好的基础，它应该比当前的broker更有伸缩性和更好的性能。它已经对AMQP和MQTT协议有了初步的支持。随着这些协议的加强和以上功能的完全实现，它应该成为您的物联网基础架构的主干的一个非常好的message broker。
来自朋友的帮助
来解决这个难题中，关于broker优化的部分一定是非常重要的一部分。但对于真正的大型物联网部署，我们需要的不仅仅是这些。我们需要有一个更复杂的基础设施，使我们能够分割我们的流量（连接，目的地等），提供容错和高可用性功能。有一些有趣的项目可以帮助为物联网需求构建弹性消息传递基础架构。
Qpid Dispatch Router为客户端，代理和其他基于AMQP的端点之间的消息提供无代理路由。它有助于构建最佳的拓扑结构，并将消息从客户端路由到最终目的地。例如，调度路由器可以作为客户端和代理之间的网关，帮助将大量连接或目的地集中并分散到多个代理，而无需客户端认知。这只是将路由器添加到消息传递网络可以提供帮助的示例之一。这是一个有趣的话题，未来你会在这个领域听到更多有趣的话题。
另一方面，Fabric8和OpenShift为我们提供了一种配置和管理此消息传递基础架构的简单方法。您可以使用它们轻松部署新broker，路由器，网关并探索现有组件。Fabric8还提供了一个网关，可用于在端点之间分配流量。
有很多方法来解决这个问题，最终的解决方案肯定取决于实际的用例。但是，将所有这些组件都集成在一起，并在最终解决方案的架构设计中发挥良好的作用是至关重要的。
结论
有了这篇文章，我试图对我们的现状以及支持物联网案例的方向给出一些看法。我希望你喜欢它，并发现它很有用。我将在十月份的Voxxed Days Belgrade和ApacheCon上详细介绍这个话题。