Комментарии 22
А зачем на самой первой картинке нужен RabbitMQ? Почему нельзя сразу на бэк запросы прикидывать?
Самая главная причина изложена в заголовке — такая поставлена задача.
Это я понял, зачем через Rabbit все гнать? В чем плюс использования Rabbit вместо проксирования на бэк без очереди?
вероятно если инстансов какого-то сервиса несколько, то что бы не заниматься балансировкой (и вообще не знать сколько их там и в какой момент времени) - проще так. А там кто первый взял сообщение - тот и пашет. Но в статье про это ничего и нет :(
Инстансы чего, RPC? Он на схеме один. Инстансы идут уже за RPC и gunicorn
Справедливо. На схеме нет вариантов что бы тех же RPC было несколько. Прошу прощения - не внимательность :)
Вопрос изоляции частей архитектуры. Наружу микросервисная часть не смотрит вообще и может быть максимально изолирована. В случае получения доступа за шлюз, доступа к критической инфраструктуре не будет. Ну и да — балансировки нагрузки.
Вопрос изоляции частей архитектуры. Наружу микросервисная часть не смотрит вообще и может быть максимально изолирована. В случае получения доступа за шлюз, доступа к критической инфраструктуре не будет.
Ничего не изменится, если API Gateway будет сам проксировать на RPC
Ну и да — балансировки нагрузки.
Балансировать нагрузку может API Gateway, у брокера другая задача
У вас по сути за всё это и должен отвечать API Gateway. Сейчас же RabbitMQ используется ради того, чтобы был RabbitMQ, каких-то плюсов в такой реализации нет, более того, сильно увеличивается время ответа
Вы всё-таки решаете какую-то проблему и публике очень хочется понять: какую именно? Вместо этого вы предлагаете туториал, как решать неизвестную проблему.
Проблема проста - решение поставленной задачи. Мой интерес организовать заявленную архитектуру. В общем-то, статья об этом.
Давайте тогда разберем Вашу задачу
тимлид поставил передо мной задачу реализовать механизм взаимодействия пользователя через веб-интерфейс с микросервисами через единую точку входа с использованием FastAPI и RabbitMQ.
В задаче не было указано, для каких целей использовать RabbitMQ? Какие будут преимущества от этого? У Вас банковское приложение или биржевое, где необходимо сохранить запросы на случай падения и вернуться после восстановления к их обработке?
Вообще, это было тестовое задание. В общих чертах рассказано об архитектуре и предложено реализовать свое видение. Это прототип, лежащий лишь в репозитории GitHub-а. Приложение не банковское, но реализуется для достаточно крупной организации.
У меня бы возникло множество вопросов к такой постановке задачи. Если это какой-то сервис в вакууме - ну ок.
1. Почему приложению искусственно ограничивают возможность использовать доступные ядра на 100%? (Если gunicorn такое умеет, конечно, я не знаю), т.к. rabbitmq будет передавать сообщения значительно медленнее, чем утилизируются ресурсы процессора.
2. Почему именно rabbitmq, а не kafka?
3. Что будет, если сервис за rabbitmq откажет, что получит пользователь и когда?
4. Что будет в случае отказа rabbitmq?
Вообще, если мы используем очереди, мы предполагаем, что ответ на запрос поступит "когда-нибудь", а в вашей схеме пользователь отправляет, по всей видимости, синхронный запрос. Это повлечёт очень большие задержки, если кто-то в беке затупит. Следовательно, на фронте тоже должен будет стоять какой-то листенер, который будет обрабатывать "ответы" из очереди - ещё одна точка отказа
Я понял, что не вы такую схему придумали, но всё же было бы здорово выяснить у того, кто такую задачу поставил: зачем вообще порождать такого монстра?
Нифигасе тестовые задания пошли... Ну только если на архитектора, но тогда это должно было звучать не так, а "по тз необходимо чтобы приложение обеспечило нагрузку Н, и при этом работали фичи а, б и ц. Опишите архитектуру пригодную для этого на ваш взгляд. ". А тут сразу дали ответ, но на половину... Архитектору (если собес на эту должность) предлагается выполнить недоделанную работу и ещё покодить за разраба. А простому разрабу зачем иметь какое-то "своë видение"? Сказали что на бэке будет x, y и z - ну ок, а теперь подробнее пусть сам архитектор и распишит , что куда и зачем придумано. Не должно быть у исполнителя излишних полномочий, иначе лебедь рак и щука получатся. Ведь вы в этом проекте будете не один. А значит у каждого может быть своё видение... Так что в этом задании вас поставили на место архитектора, потому на вас и сыпятся вопросы по принятым решениям. Потому стоило написать что это тестовое и на какую должность. Если вы разраб, то с вас и спросу нет, а если архитектор, то вопрошающие вполне обоснованно спрашивают. Преимущества rabbitmq (и вообще очередей в "голом" виде) на фронте сомнительны. Если нужно просто работать с АПИ, то для веб простой рест-подобный АПИ остаётся в не конкуренции. Если там какие-то длящиеся процессы, то лучше реализовать некий сервис-декоратор для очереди, который позволит смотреть загруженность, степень выполнения задачи и т д. А так складывается впечатление, что очередь ради очереди...
А про нормальные апи гейтвеи не слышали? Тот же kong, krakend и тд. У того же кракена есть интеграция с кроликом. Более того в вашем примере рейтлимит, проверку авторизации и прочие ништяки апи гейтвеев реализовывать будет адски геморройно, что есть из коробки у решений которые под это заточены.
В чем необходимость наличия RpcServer? Почему бы на RabbitMq не сделать отдельные очереди для каждого сервиса?
Публикации
Работа с микросервисами через API-gateway