Распределение узлов MassTransit RabbitMQ

Я исследую возможность использования MassTransit с RabbitMQ в нашем приложении в качестве ESB. Основное преимущество, которое я ищу, - это добавление устойчивой асинхронной обработки сообщений к входящему потоку данных.

Профиль нашего приложения состоит из двух частей:

Входящий поток данных

  • Односторонний обмен сообщениями
  • Обрабатывается асинхронно
  • 10k + сообщений в минуту

Активность на сайте

  • Двусторонний
  • В идеале используйте функции языка C # async await, но требуются данные в обоих направлениях
  • ‹100 в минуту

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

Вопросы:

Из того, что я читал; узел ESB не должен знать или заботиться о каком-либо другом узле на шине, он должен просто выполнять свою работу и отправлять сообщения на шину, ожидая ответов, если / когда это необходимо. Для меня это означает, что каждый веб-сервер / сервер приложений будет иметь собственную локальную кластерную очередь. Верно ли это предположение?

Если это правильно; как мне программно добавить машины в кластер? Есть ли какие-то подводные камни, о которых мне нужно знать?

Если это не так; как мне управлять кластером очередей? Создание выделенного кластера имеет свои собственные проблемы, такие как записи DNS, балансировка нагрузки для избыточных / автономных узлов и т. Д.

Мне не хватает функциональности, которую ESB могут добавить вместе с реализацией MassTransit, однако меня немного затуманивает логистика передовых практик о том, где и как настроить ее в надежной конфигурации.

Спасибо за любые отзывы и советы

Обновление. Мы используем EC2 для машинной инфраструктуры, в частности мы используем зоны доступности, чтобы минимизировать перебои в работе центра обработки данных. В этой конфигурации у нас есть 3 зоны, каждая зона имеет веб-сервер, сервер приложений и сервер базы данных (Couchbase). Мы также используем балансировщики нагрузки EC2 для распределения нагрузки между зонами.

@Travis: Есть ли у вас какой-либо опыт / советы по использованию MT / RMQ в Amazon EC2?


rabbitmq masstransit esb
person Mike    schedule 17.09.2013    source источник
comment
У меня нет опыта работы с EC2 и RabbitMQ. У нас есть частный дата-центр для нашего программного обеспечения. Кластерные экземпляры RabbitMQ звучат как то, что вам нужно. Тогда ваше приложение будет заботиться только о центральном расположении вашего кластера RabbitMQ. Части приложения не заботятся о том, где они живут.   -  person Travis    schedule 17.09.2013
comment
Да, это то же самое, что и я. Я буду рассматривать зеркальную кластерную конфигурацию, чтобы использовать стойкость сообщений высокой доступности. Мне нужно выяснить, стоит ли попробовать сеточный подход, при котором RabbitMQ будет установлен на каждой машине, на которой будет размещаться процесс, взаимодействующий с кластером, или если подход концентратора и луча с выделенными серверами обмена сообщениями за балансировщиком нагрузки (как ваш пример ) было бы лучше всего. Спасибо за ваш вклад @Travis.   -  person Mike    schedule 18.09.2013

Ответы (2)


arrow_upward
3
arrow_downward

Итак, в масштабе, значительно превышающем ваш, у нас есть кластер RabbitMQ, который размещается за балансировкой нагрузки (F5). Все процессы, использующие MT, ссылаются на адрес с балансировкой нагрузки. Единственное, что нужно каждому процессу - это собственная очередь для получения.

Кластеризация в RabbitMQ (3.0+) обрабатывается в конфигурации RabbitMQ. Процессы / код ничего не знают о кластеризации.

Я не совсем понимаю, что вы подразумеваете под «узлом» в этом вопросе, поэтому трудно быть уверенным, что я отвечаю на правильный вопрос. Но как только вы добавите процесс к тому же виртуальному хосту (по умолчанию или иначе) в RabbitMQ, MT подключит все необходимые ему части (обмены, очереди и привязки).

person Travis    schedule 17.09.2013
comment
Привет Трэвис - Спасибо за информацию. - person Mike; 17.09.2013
comment
Я слишком долго редактировал, и мне пришлось сделать еще один комментарий. Я обновил свой вопрос, добавив еще несколько деталей, чтобы попытаться дать вам более четкое представление о моей среде. - person Mike; 17.09.2013
comment
Привет, Майк, ты остановился на примере с локальными узлами кластера, который предложил Адам, или на кластере с балансировкой нагрузки, который использует Трэвис? Трэвис, не могли бы вы взвесить предложение Адама и почему вы выбрали кластер с балансировкой нагрузки? Я предполагаю уменьшить трафик синхронизации кластера на все узлы, что даст лучший масштаб, верно? - person JesseP; 15.11.2013
comment
Настройка Майка работает. Но если у машины потеряна связь с кластером, это все равно бесполезно - по крайней мере, для нас. Кроме того, у нас есть веб-сайты, которые мы хотим максимально облегчить, вместо того, чтобы иметь RMQ на этих машинах. - person Travis; 16.11.2013

arrow_upward
1
arrow_downward

У нас другой подход к Трэвису. Каждая машина, на которой есть служба, которая потребляет / обрабатывает или публикует сообщения, также является узлами в кластере RabbitMq. Тогда каждая машина должна обращаться к RabbitMq только через localhost.

Каждая служба находится на нескольких машинах. Для этого мы используем конкурирующих потребителей (т.е. несколько машин будут читать из одной кластерной очереди (но через localhost)). Таким образом, ваша архитектура должна позволять параллельную обработку сообщений.

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

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

person Adam Mills    schedule 26.09.2013
comment
Привет, Адам - ​​спасибо за ответ. Я придумал очень похожий шаблон, поскольку мне нравится позволять моим сервисам взаимодействовать с сервисной шиной через локальный хост. - person Mike; 30.09.2013
comment
Я знаю, что это довольно старый вопрос, но потратив несколько месяцев, пытаясь использовать этот подход, я обнаружил, что разделов кластера было очень трудно избежать при таком большом количестве узлов, работающих на производственных машинах. Вы тоже это видите, или у вас просто исключительно надежная сеть между машинами? - person OlduwanSteve; 04.02.2015
comment
у нас было только 4 узла. Разве для нас не было проблемой, что все они находятся в одном центре обработки данных? Т.е. не через VPN или что-то в этом роде. - person Adam Mills; 05.02.2015
comment
У нас было 2 дисковых узла на выделенных машинах и 8 узлов оперативной памяти для различных серверов. Все в одном центре обработки данных. Мне никогда не удавалось найти вескую причину, по которой одни узлы теряли видимость других, и это происходило не очень часто. Но когда это действительно происходило, восстановление часто оказывалось намного сложнее, чем я ожидал, и все время мои живые приложения не имели шины сообщений. Мы вернулись к использованию небольшого количества основных дисковых узлов, и сейчас я собираюсь настроить балансировщик нагрузки, поэтому я снова столкнулся с этим вопросом. - person OlduwanSteve; 05.02.2015