Ответы пользователя по тегу Проектирование программного обеспечения
  • Что использовать для реализации EDA в микросервисной архитектуре?

    @yarkin
    RabbitMQ это про очереди, если у вас есть очередь задач, то не думаю, что захотите чтобы все воркеры выполняли одно и тоже действие. Если нужно, чтобы каждый сервис получал копию сообщения, они должны иметь независимые очереди, которые могут быть подписаны на один эксчендж.
    Если у вас может быть по N инстансов одного сервиса, то все N подписываются на одну и ту же очередь (иначе см. выше что будет), но каждый сервис должен иметь свою очередь.
    Почитайте базовые мануалы по RabbitMQ - https://www.rabbitmq.com/getstarted.html - там много полезного найдёте (на хабре есть переводы на русский, если надо)

    Например, для простоты возмём что эксчендж всего один - events. Есть два сервиса - S1 и S2. У каждого из них по 3 инстанса. Сервисы хотят получать все сообщения которые публикуются в events.
    Получаем (допусти ещё ничего нет):
    - создаём эксчендж events (лучше до запуска всего) с типом fanout
    - первый инстанс S1 при запуске создаёт очередь - events-s1; создаёт биндинг этой очереди на эксчендж events; подписывается на эту очередь
    - второй и третий инстансы S1 при запуске видят, что очередь есть и просто подписываться на неё
    - всё тоже самое повторяется для S2

    При росте сервисов, одного эксченджа может не очень хватить, тогда одна очередь может имеет более одного биндинга к нужным ей эксченджам. Или тип эксченджа можно поменять на topic и управлять тем кто получит сообщения уже через ключи биндингов и заголовки сообщений, а не имена эксченджей.
    Ответ написан
    Комментировать
  • Как правильно организовать очереди?

    @yarkin
    Если клиент не закрывает соединение с конкретным инстансом (или если закрыл, то ответ не должен получить), то посмотрите в сторону RPC, вот с помощью чего оно работает, вот примеры.
    Если результат требует много вычислительных ресурсов и повторять нежелательно, то либо создавать очереди под каждого клиента, либо где-то кэшировать результат (например, в СУБД).
    Ответ написан
  • Есть ли Стратегия борьбы со сбросом состояния RabbitMQ?

    @yarkin
    1) Разработчики RabbitMQ ко всем потерям данных на стороне самого RabbitMQ относятся критично, так что, если в какой-то момент будете уверены, что теряет данные именно он, то смело создавайте баг (с подробностями как повторить).
    2) Если админы не умеют настраивать стейтфул приложения в контейнерной среде или куча ручных операций, то это больше административная задача, чтобы научиться и, например, использовать шаблоны/чарты/т.п. для предотвращения сюрпризов. Но также RabbitMQ в контейнере нужно настраивать, чтобы не получать деградации и дампов.
    3) Со стороны самого RabbitMQ есть зеркалирование очередей (queue mirroring) для дублирования данных, что позволит внезапно терять ноды (но восстановление может обойтись высоким потреблением процессора).
    4) Также рекомендую логировать и идентифицировать каждое отправленное и полученное сообщение, чтобы оценивать проблему. Для большей достоверности можно включить логирование ещё и на уровне RabbitMQ (если позволяют ресурсы). На прошлой работе у нас был свой плагин для RabbitMQ, который получал копию всех полученных и отправленных сообщений, выгребал из них нужную метаинформацию и отправлял в Graylog.
    5) Ну и конечно нужно делать отправку и приём с подтверждением, но это, я думаю, Вы и без меня уже делаете.
    Ответ написан
    4 комментария
  • Как организовать достраивание сообщения несколькими сервисами?

    @yarkin
    Какой-то сложный алгоритм, имхо.
    Заранее известно определение "полноты" объекта? Если известен список сервисов, почему не обратиться к ним напрямую и по итогу ответов от каждого сформировать "полный" объект?
    В общем нужен какой-то "редьюсер" ответов, из коробки у RMQ не знаю каких-то подходящих механизмов для этого.
    Ответ написан