ZMQ pub / sub надежный / масштабируемый дизайн

Question

Я проектирую архитектуру паба / юга с использованием ZMQ. Мне нужна максимальная надежность и масштабируемость, и я как бы теряюсь в адских возможностях.

На данный момент я получил набор издателей и подписчиков, связанных брокером. Брокер - это простое устройство пересылки, открывающее интерфейс для издателей и сервер для подписчиков.

Мне нужно разобраться со случаем, когда брокер дает сбой или отключиться, и улучшить общую масштабируемость.

Хорошо, поэтому я подумал о добавлении нескольких брокеров, издатели закроют робота для отправки сообщений, а подписчики просто подпишутся на всех этих брокеров.

Тогда мне нужен был способ получить список возможных брокеров, поэтому я написал службу имен, которая предоставляет список брокеров по запросу. Издатели и подписчики спрашивают эту услугу, к каким брокерам подключаться.

Я также написал своего рода «ленивый пират» (то есть попробуйте / повторите попытку один за другим) надежную службу имен на случай, если основная служба имен упадет.

Я начинаю думать, что я проектирую это неправильно, так как кодовая база не перестает увеличиваться в размере и сложности. Я потерян в джунглях возможностей, предоставляемых ZMQ.

Может быть, здесь можно было бы использовать что-нибудь на основе роутера / дилера?

Любой совет с благодарностью!

Answer 1

Невозможно ответить на ваш вопрос напрямую, потому что он основан на очень многих предположениях, многие из которых, вероятно, ошибочны.

Вы заблудились, потому что используете неправильный подход.Рассмотрим 0MQ как язык, который вы еще не очень хорошо знаете.Если вы начнете с попытки написать «максимальная надежность и масштабируемость», вы закончите рвотой Годзиллы.

Итак: используйте подход, который я использую в Руководстве.Начните с минимального решения основного потока сообщений и настройте его правильно.Тщательно продумайте правильные розетки для использования.Затем вносите постепенные улучшения, каждый раз проводя полное тестирование, чтобы убедиться, что вы понимаете, что на самом деле происходит.Рефакторинг кода регулярно, по мере роста.Продолжайте до тех пор, пока у вас не будет стабильной минимальной версии 1. Не стремитесь к «максимальному» чему-либо в начале.

Наконец, когда вы лучше поняли проблему, начните снова с нуля и снова создайте рабочуюМодель в несколько этапов.

Повторяйте, пока вы полностью не доминируете над проблемой и не научитесь лучшим способам ее решения.

Answer 2

Похоже, что большая часть сложности связана с попыткой сохранить посредническую службу в случае сбоя. Решение этого на уровне приложений дает вам высочайшую степень гибкости, но требует больше усилий, если вы начинаете с нуля.

Вместо того, чтобы обрабатывать это на уровне приложения, вы могли бы обрабатывать это на уровне сети. Обращайтесь со своими брокерами так же, как и с любой другой простой сетевой службой, и используйте механизм отработки отказа IP (например, кардиостимулятор / corosync, UCARP и т. Д.) Для переключения виртуального IP-адреса на вторичную службу, если первичная становится недоступной.

Это значительно упрощает ваших издателей и подписчиков, потому что вам не нужна служба имен. Им нужно знать только один виртуальный IP-адрес. ZMQ позаботится о повторном подключении к сервису при необходимости (т. Е. При возникновении сбоя).