Развертывание брокера сообщений для варианта использования IoT представляет некоторые новые проблемы для масштабируемости брокера. Сейчас мы говорим о тысячах соединений, потребителей и направлений, что заставляет нас задуматься о том, как мы предоставляем, настраиваем и контролируем нашу инфраструктуру обмена сообщениями гораздо более тщательно. В этой статье я попытаюсь обобщить некоторые методы, которые можно использовать с текущим Apache ActiveMQ, с точки зрения его лучшего масштабирования для развертывания IoT. Я также опишу некоторые новые функции, которые мы разработали для выпуска 5.12.0, чтобы сделать его более подходящим для этого нового мира. И, наконец, я попытаюсь объяснить, куда мы можем пойти отсюда и над чем мы можем работать в будущем.
ActiveMQ вертикальное масштабирование
Двумя наиболее распространенными протоколами обмена сообщениями, используемыми для IoT, являются MQTT и AMQP, и мы приложили значительные усилия, чтобы сделать их надежными в последних выпусках. Но протоколы — это еще не все, и каждый раз, когда кто-то начинает играть с брокером, возникает один и тот же вопрос: как я могу получить максимальную масштабируемость от одного экземпляра брокера? Итак, вот несколько советов:
- Всегда начинайте с общих методов масштабирования брокера . По сути, это означает, что вы должны стараться использовать как можно меньше потоков независимо от того, сколько соединений и назначений обрабатывает ваш брокер. Так что используйте транспорт NIO и настройку потока по назначению.
- Первая реализация протокола MQTT для ActiveMQ предполагала, что подписчики QoS1 и QoS2 сопоставляются внутренне с устойчивыми подписчиками JMS. У постоянных подписчиков JMS тяжелое состояние, и они плохо масштабируются. В более поздних версиях вы можете выбрать другую реализацию, которая вместо этого использует виртуальные темы и должна масштабироваться намного лучше.
<transportConnectors> <transportConnector name="mqtt+nio" uri="mqtt+nio://0.0.0.0:1883&transport.subscriptionStrategy=mqtt-virtual-topic-subscriptions"/> </transportConnector> - Еще одна причина попробовать новую версию 5.12.0 — это новые улучшения хранилища сообщений KahaDB, которые теперь могут предварительно распределять файлы журнала. Вы можете найти больше информации об этом в этом посте , но эти изменения в некоторых файловых системах могут значительно улучшить производительность
Все эти небольшие изменения конфигурации суммированы в новом примере файла конфигурации, который вы можете найти в
examples/conf/activemq-mqtt.xmlфайл в новом дистрибутиве 5.12.0.
Вертикальное масштабирование брокера — это только одна часть уравнения. Есть еще пара важных вопросов, которые необходимо решить для успешного развертывания IoT.
SSL
Многие устройства IoT зависят от SSL-сертификатов в целях аутентификации. Это не что-то новое, и мы увидели это и в традиционных настройках обмена сообщениями (и поддержали это), но разница опять же в масштабе. Хранилище ключей легко поддерживать с несколькими сертификатами. Это совсем другая история, когда количество сертификатов начинает расти.
В 5.12.0 мы добавили несколько новых функций, чтобы помочь людям справиться с этим. Есть несколько инструментов, которые стандартизированы для решения этих проблем и поддерживаются в JDK. Так что теперь вы можете использовать список отзыва сертификатов , который обеспечивает простой способ отзыва недействительных сертификатов во время выполнения.
Вы также можете использовать OCSP (онлайн-протокол статуса сертификата), который обеспечивает еще более автоматизированный способ связи с вашим центром сертификации. Вы можете найти больше информации об этих функциях здесь .
Я думаю , что сертификат SSL выделение ресурсов намного больше истории для развертывания ВГДА (и облака в целом) , и уже есть некоторые интересные проекты возникающих решить, как pki.io . Мы постараемся поддерживать все, что люди используют в этом пространстве, и прямо сейчас с поддержкой CRL и OCSP вы можете иметь немного больше гибкости при работе с вашими сертификатами.
Мониторинг под стрессом
Одна из тем, с которой я часто сталкиваюсь, когда говорю о развертываниях IoT, — это как контролировать брокера, который находится в пределах вертикального масштабирования (какими бы они ни были). Мы обычно следим за поведением брокера, используя JMX или консультативные сообщения. Хотя это идеальный инструмент, когда брокер находится в пределах его возможностей, ситуация становится менее оптимальной, когда вы находитесь на грани.
Поскольку большое количество адресатов и соединений приходят и уходят, регистрация MBean и запуск консультативных сообщений могут стать очень дорогостоящими, особенно когда это делается в большом объеме. Это может помешать реальной работе, которую должен сделать брокер.
Люди, которые хотят получить максимум от своего брокера, обычно просто выключают все, например
<broker useJmx="false" advisorySupport="false" ...>но это оставляет нас без понимания состояния брокера, за исключением пика в журналах.
Одно из решений, которое мы придумали, — сделать регистрацию Mbean более избирательной.
Начиная с 5.12.0, вы можете определить имена mbean, которые вы хотите запретить при регистрации, определив их в контексте управления, например:
<managementContext>
<managementContext
suppressMBean="endpoint=dynamicProducer,endpoint=Consumer,
connectionName=*,destinationName=ActiveMQ.Advisory.*"/>
</managementContext>
Используя эту функцию, вы можете настроить, какой вид брокера вам нужен, и подавив регистрацию / отмену регистрации высокочастотных эфемерных mbeans, вы можете помочь вашему брокеру справиться с нагрузкой. Таким образом, даже в сценарии высокой загрузки / загрузки вы можете получить базовые показатели брокера. В этом пространстве мы можем сделать гораздо больше, определяя пользовательские представления и тому подобное, так что следите за обновлениями.
Legacy MQTT
Apache ActiveMQ реализует спецификацию MQTT 3.1.1, но MQTT не является новым протоколом, и уже развернуто огромное количество устройств, которые используют более старые (3.1) клиенты. Мы предприняли попытку включить известные случаи использования, когда более старые клиенты ожидают поведения, отличного от того, что указано в спецификации 3.1.1. Например, вы можете включить публикацию в «долларовых темах» и увидеть разницу в поведении при неудачных попытках подписки. Мы постараемся охватить все эти важные случаи и предоставить поддержку устаревшим клиентам, если это целесообразно.
ActiveMQ Артемида
В случае, если вы не обращали внимания, произошла небольшая консолидация в среде брокеров сообщений Java. Брокер HornetQ был пожертвован Apache и теперь является частью проекта ActiveMQ. Его асинхронное ядро дает нам хорошую базу для следующего поколения ActiveMQ, которое должно масштабироваться лучше и иметь лучшие характеристики, чем текущий брокер. Уже есть начальная поддержка протоколов AMQP и MQTT. С учетом того, что эти протоколы усилены и функции, реализованные выше, полностью реализованы, он должен стать очень хорошим брокером сообщений для основы вашей инфраструктуры IoT.
Помощь от друзей
Наличие хорошего сообщения, брокер, несомненно, является важной частью головоломки. Но для действительно больших развертываний IoT нам потребуется нечто большее. Нам нужна более сложная инфраструктура, которая позволит нам разделять наш трафик (с точки зрения соединений, назначения и т. Д.), Обеспечивать отказоустойчивость и возможности высокой доступности. Есть пара интересных проектов, которые могут помочь создать гибкую инфраструктуру обмена сообщениями для нужд IoT.
Qpid Dispatch Router обеспечивает маршрутизацию сообщений без посредников между клиентами, брокерами и другими конечными точками на основе AMQP. Это помогает строить оптимальные топологии и маршрутизировать сообщения от клиентов до их конечного пункта назначения. Например, диспетчерский маршрутизатор может служить в качестве шлюза между клиентами и брокером, помогая сконцентрировать и распределить большое количество соединений или назначений между несколькими брокерами без уведомления клиента. Это только один из примеров, где может помочь добавление маршрутизатора в вашу сеть обмена сообщениями. Это интересная тема, и вы услышите гораздо больше интересных вещей в этом пространстве в будущем.
С другой стороны, Fabric8 и OpenShift предоставляют нам простой способ предоставления и управления этой инфраструктурой обмена сообщениями. Вы можете использовать их для простого развертывания новых брокеров, маршрутизаторов, шлюзов и обнаружения существующих компонентов. Fabric8 также предоставляет шлюз, который можно использовать для разделения трафика между конечными точками.
Существует много способов решения этой проблемы, и окончательное решение, безусловно, зависит от конкретного варианта использования. Но чтобы все эти компоненты были надежными и хорошо работали вместе, крайне важно создать окончательное решение.
Вывод
В этом посте я попытался дать представление о том, где мы находимся и куда движемся в случае поддержки IoT. Я надеялся, что вам понравилось, и вы нашли это полезным. Я расскажу об этой теме более подробно на Voxxed Days Belgrade и ApacheCon в октябре. В конце взгляните на потрясающую демонстрацию IoT Red Hat Summit , которая демонстрирует некоторые из этих вещей на практике.