Однако для случая «передать все запросы на несколько контроллеров на другой upstream» — вполне хватит и nginx(а у вас именно такой случай). И без rabbitmq. Без rabbitmq вы конечно не сможете быстро переподнимать бекенд при падении прозрачно для пользователя ( они лишь будет ожидать ответ дольше ), но логику повторного запроса требуемых данных с фронта вроде не так уж и сложно организовать?
Я лишь выступаю против написания балансировщика на node(просто хотя бы потому что express весьма слабо для такого приспособлен, и возможности у того же nginx в плане производительности выше). А у вас пока именно он и описан — вы прозрачно передаете управление по контроллерам.
Если в проекте есть документация, явно видны связи, явно видно где находится endpoint, который надо поправить — то даже у джуна не возникнет особых проблем его поправить. В случае с микросервисами — у джуна могут возникнуть проблемы плана «а как получить некоторую информацию». Как обработать ошибки при получении этой информации? Надо ли повторять запрос в микросервис? Если надо — то через какое количество времени и сколько раз? Хотя я не спорю что бывают такие проекты, в которых и сениер схватится за голову.
Простите, но вы же не утверждаете что из языка в язык общение с redis как-то меняется? Смена языка в данном случае ваще ни на что не влияет. Оно влияет лишь на то — как будет передан запрос. Будет ли это обычный proxy_pass или ваш rabbitmq. Да и то — вопрос удобства, не более.
И просто взять и захотеть сменить язык — это требует кадров, которые умеют работать с этим языком как минимум. Если компания имеет специалистов разного уровня и с разным набором языков, почему она не может найти человека, который допишет конфиг в nginx?
Вариант с проксированием через NGINX и сессии в микросервисе:
request -> nginx -> microservice1 ( -> microservice{2,3...} ) -> response
Ведь никто не говорит вам запрашивать синхронно только с одного микросервиса нужные данные? К тому же безопасность — если у вас появляется где-то уязвимость инжекта запросов, вы ничего не потеряете, потому что ваш микросервис имеет проверки допустимости и не полагается на то, что его вызывают правильно. И если кто-то проникает в вашу сеть, он не сможет без валидной сессии что-то сделать с вашими данными. И отлаживать приятнее — если у вас возникает вопрос — а почему сервис N не отрабатывает — вы ищите проблему только в логах сервиса N ( ну и опционально, если нам ответили ошибкой — тогда идем в нужный микросервис, и соответственно в 1-м месте видим все требования к запросам, и что не было выполнено ).
С такой схемой, если пользователь не авторизован, мы сразу отвечаем ему и не отправляем сообщение в раббит (микросервис).
Для оптимизации — без вопросов. Но так ли высоки издержки если мы через rabbitmq пошлем запрос и он в самом начале обработки скажет нам 403? По моему опыту — это больше «преждевременная оптимизация», и это в крайне редких случаях является узким местом. А там, где является — там уже highload, и действуют уже немного другие законы ( и естественно ваша библиотека там наверняка не работает ).
Нджиниксом не проксируется потому, что иногда могут понадобятся какие-то данные
Великолепно проксируется — глобальный session id у вас великолепно пробрасывается через cookie с помощью nginx( в вашем случае все данные по запросу как я понимаю приходится запрашивать отдельно ). А так же вы можете сгенерировать request id для лучшего чтения логов по разным микросервисам — но это уже тонкости логирования. По глобальному session id — вы прекрасно получаете всю информацию об авторизации и прочим параметрам, сохраненных в сессии. Здесь прекрасно подойдет redis или любое подобное key-value решение. Тем более никто не мешает вам из микросервиса обратиться к микросервису. Не в публичный endpoint — а напрямую к требуемому микросервису.
Ваша бизнес-сущность (например, пользователи) будут изолированы от другой бизнес-сущности (например, товары).
А кто вам мешает их разделить в монолите? Кто вам навязывает только 1 соединение с базой данных в монолите? К примеру я в монолите великолепно создавал ещё одно соединение, и использовал его после в моделях. Очень многие фреймворки позволяют переопределить в моделях используемую бд.
Автор, если вы собираетесь делегировать полностью контроллеры, почему вы не хотите использовать nginx для этого? Или у вас в ТЗ была поставлена задача обрабатывать все запросы независимо от нестабильности бекенда? Или бекенд был настолько нестабилен что такое решение было самым правильным?
Мне всегда казалось что микросервисная архитектура отличается от монолита тем, как именно ты получаешь доступ к нужным данным. Т.е. ты выделяешь отдельные компоненты, пишешь API — которого тебе должно хватить, и используешь только его, без попыток «хакнуть внутрянку» и подробно документируя все составляющие твоего проекта. Но здесь же — просто балансировка. Подними с той стороны такой же монолит — и ничего не поменяется. Напиши перенаправление по всем контроллерам, подними нужное количество «микросервисов» ( в данном случае просто экземпляры вашего монолита ) — и получите «микросервисную архитектуру»?
Насколько я помню — проблемы лицензий. Поэтому стандартно нету поставки со статической линковкой. В любом случае если вам требуется такая поставка — вы должны обладать достаточным скилом чтобы собрать Qt самостоятельно и добиться нужного результата.
А работу с контекстом в QJSEngine так и не сделали? Интегрирование в скриптовую машину всяких QList<Class*>, где Class — наследник QObject? На QtSctipt такие задачи решались 1-й функцей…
Была изначально идея связать все это с QtScript, но в силу специфики проекта отказался от такой реализации, чтобы меньше тянуть зависимостей.
Однако идея динамического метаобъекта отброшена не была.
Ну это пока именно исследование и разбор. Как эту информацию использовать я хотел показать в следующей части. А то статья вышла бы крайне большой.
А где использовать динамические метаобъекты? Да не знаю. Хотел я использовать в 1-м проекте, чтобы создавать сигналы объектам, но потом решил пойти по другому пути. Это скорее больше для общего развития.
Если в проекте есть документация, явно видны связи, явно видно где находится endpoint, который надо поправить — то даже у джуна не возникнет особых проблем его поправить. В случае с микросервисами — у джуна могут возникнуть проблемы плана «а как получить некоторую информацию». Как обработать ошибки при получении этой информации? Надо ли повторять запрос в микросервис? Если надо — то через какое количество времени и сколько раз? Хотя я не спорю что бывают такие проекты, в которых и сениер схватится за голову.
И просто взять и захотеть сменить язык — это требует кадров, которые умеют работать с этим языком как минимум. Если компания имеет специалистов разного уровня и с разным набором языков, почему она не может найти человека, который допишет конфиг в nginx?
request -> nginx -> microservice1 ( -> microservice{2,3...} ) -> response
Ведь никто не говорит вам запрашивать синхронно только с одного микросервиса нужные данные? К тому же безопасность — если у вас появляется где-то уязвимость инжекта запросов, вы ничего не потеряете, потому что ваш микросервис имеет проверки допустимости и не полагается на то, что его вызывают правильно. И если кто-то проникает в вашу сеть, он не сможет без валидной сессии что-то сделать с вашими данными. И отлаживать приятнее — если у вас возникает вопрос — а почему сервис N не отрабатывает — вы ищите проблему только в логах сервиса N ( ну и опционально, если нам ответили ошибкой — тогда идем в нужный микросервис, и соответственно в 1-м месте видим все требования к запросам, и что не было выполнено ).
Для оптимизации — без вопросов. Но так ли высоки издержки если мы через rabbitmq пошлем запрос и он в самом начале обработки скажет нам 403? По моему опыту — это больше «преждевременная оптимизация», и это в крайне редких случаях является узким местом. А там, где является — там уже highload, и действуют уже немного другие законы ( и естественно ваша библиотека там наверняка не работает ).
Великолепно проксируется — глобальный session id у вас великолепно пробрасывается через cookie с помощью nginx( в вашем случае все данные по запросу как я понимаю приходится запрашивать отдельно ). А так же вы можете сгенерировать request id для лучшего чтения логов по разным микросервисам — но это уже тонкости логирования. По глобальному session id — вы прекрасно получаете всю информацию об авторизации и прочим параметрам, сохраненных в сессии. Здесь прекрасно подойдет redis или любое подобное key-value решение. Тем более никто не мешает вам из микросервиса обратиться к микросервису. Не в публичный endpoint — а напрямую к требуемому микросервису.
А кто вам мешает их разделить в монолите? Кто вам навязывает только 1 соединение с базой данных в монолите? К примеру я в монолите великолепно создавал ещё одно соединение, и использовал его после в моделях. Очень многие фреймворки позволяют переопределить в моделях используемую бд.
Мне всегда казалось что микросервисная архитектура отличается от монолита тем, как именно ты получаешь доступ к нужным данным. Т.е. ты выделяешь отдельные компоненты, пишешь API — которого тебе должно хватить, и используешь только его, без попыток «хакнуть внутрянку» и подробно документируя все составляющие твоего проекта. Но здесь же — просто балансировка. Подними с той стороны такой же монолит — и ничего не поменяется. Напиши перенаправление по всем контроллерам, подними нужное количество «микросервисов» ( в данном случае просто экземпляры вашего монолита ) — и получите «микросервисную архитектуру»?
Однако идея динамического метаобъекта отброшена не была.
А где использовать динамические метаобъекты? Да не знаю. Хотел я использовать в 1-м проекте, чтобы создавать сигналы объектам, но потом решил пойти по другому пути. Это скорее больше для общего развития.