Основное преимущество, которое вы получаете, — это простота, а в случае с HiveMQ — масштабируемость.
Позвольте мне объяснить эти преимущества:
Простота
В случае с HiveMQ вы просто запускаете сервер, и все готово. Все веб-приложения, которые используют библиотеку MQTT через веб-сокеты, могут подключаться к серверу, даже не зная, что веб-сокеты используются в качестве транспорта. Для самого HiveMQ это просто еще один клиент MQTT. Таким образом, не имеет значения, подключены ли клиенты через веб-сокеты или через классическое TCP-соединение. Я думаю, вы уже упомянули другие аргументы в своем вопросе. И, конечно, последнее, но не менее важное: ребята из эксплуатации будут вам благодарны, если им придется обслуживать на одну систему (в вашем случае «Сервер») меньше.
Масштабируемость
Программное обеспечение, такое как HiveMQ, очень масштабируемо и может обрабатывать до сотен тысяч одновременно подключенных клиентов. Высока вероятность того, что дополнительный слой («Сервер» в вашем случае) может стать узким местом. Кроме того, такие вещи, как балансировка нагрузки с помощью балансировщика нагрузки HW или SW, становятся намного проще, если вы можете выбросить ненужные уровни. В общем, архитектура вашей системы станет намного проще, если вам не нужны эти дополнительные уровни (которые не сервисы, которые можно повторно использовать для других приложений, как микросервисы).
И последнее, но не менее важное: стоит отметить, что сам HiveMQ часто интегрируется с классическим промежуточным ПО/ESB. Это означает, что люди пишут собственные плагины для интеграции HiveMQ в существующее промежуточное ПО. Для этого часто используются вызовы JMS или веб-сервисов (REST, SOAP).
Отнеситесь к этому ответу с долей скептицизма, так как я занимаюсь разработкой HiveMQ :-)
person
Dominik Obermaier
schedule
17.05.2014
