RabbitMQ, REST API, Docker и вопрос о передовой практике Kubernete - PullRequest
Новая
       13

RabbitMQ, REST API, Docker и вопрос о передовой практике Kubernete

1 голос
/ 10 июля 2020

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

Сценарий: У меня есть. Net Core REST API который будет получать запросы от внешнего приложения. Эти запросы будут отправлены в экземпляр RabbitMQ. Эти уведомления будут отправлены на обмен, а затем разветвлены по нескольким очередям для нескольких потребителей.

Есть один потребитель, за которого я буду нести ответственность, и мне нужен совет по передовым методам. В конечном итоге появится REST API, который в конечном итоге должен будет реагировать на эти сообщения, помещенные в очередь. Этот REST API представляет собой контейнерное (Docker) приложение, работающее в кластере Kubernetes. Он будет получать много запросов c за пределами этих уведомлений (сообщения очереди), делать SQL звонков и т.д. c.

Мой вопрос: должен ли я иметь внешний микросервис (размещенный service / background service), который подписывается на эту очередь с намерением вызвать указанный REST API. Вроде как трафик c полицейский; маршрутизация сообщений к соответствующему методу API на основе определенных точек данных.

Или

Можно ли поместить этого потребителя непосредственно в рассматриваемый c REST API с высоким трафиком?

Есть какие-нибудь советы по этому поводу? Заранее спасибо!

1 Ответ

1 голос
/ 11 июля 2020

Нет правильного или неправильного. Это целая дилемма вокруг монолитных микросервисов и синхронно-асинхронных.

Если вы хотите использовать микросервисы и более асинхронные, вы можете начать со следующих вопросов:

  • Do you хотите, чтобы ваша система имела разные кодовые базы?
  • Хотите разделить обязанности между разными командами?
  • Хотите использовать разные языки / проекты для разных компонентов?
  • Делать вы хотите, чтобы некоторые компоненты системы быстрее реагировали на запросы пользователя?
  • Может ли ваше приложение быть в порядке с тем фактом, что один развязанный компонент может полностью выйти из строя?

я должен иметь внешний микросервис (размещенный сервис / фоновый сервис), который подписывается на эту очередь с намерением вызывать указанный REST API. Вроде как трафик c полицейский; маршрутизация сообщений к соответствующему методу API на основе определенных точек данных.

Да, если вы больше думаете о маршруте микросервисов и ответ «да» на большинство из приведенных выше вопросов (и даже больше вопросы, связанные с микросервисами, не упоминаются).

Если вы больше думаете о маршруте монолита:

  • Вы согласны с одной и той же базой кода, совместно используемой разными командами?
  • Вы согласны с более унифицированным программированием язык?
  • Хотите монорепозиторий? (хотя вы можете делать микросервисы с монорепозиториями)
  • Будет ли кодовая база работать в основном несколькими людьми, которые ее хорошо знают?
  • Легко ли обеспечить избыточность внутри приложение? то есть, если один компонент выходит из строя, приложение не обрабатывает sh.

Можно ли поместить этого потребителя непосредственно в рассматриваемый c REST API с высоким трафиком?

Да, если ваш код может с этим справиться и вы больше согласны с «да» в ответах выше.

...