Полностью согласен, но реализация повторных запросов с фронтенда — это уже уход от темы, я считаю. По моему опыту и по тому, как я пишу микросервисы, я предпочитаю возлагать на фронтенд минимум всего и делать важные вещи на бэкенде (тот же повтор запросов).
По поводу проксирования у нас с вами разные мнения: вы хотите реализовывать хранение сессии в микросервисе, а я в гейтвее. В вашем случае нджиникс действительно будет эффективнее.
По поводу прокси через экспресс — я с вами полностью согласен, это плохой вариант. Я рассматриваю вариант поднятия нескольких гейтвеев и проксирования их через апстрим нджиникса: nginx -> gateway upstream -> rabbitmq
Если я правильно вас понял, то вы предлагаете оставить монолит, разделив контроллеры, хотя так и должно быть изначально.
Когда у вас в проекте (репозитории) будут несколько языков, начнется каша. Микросервисы, по моему мнению, это абстракция. Если джуниору дать задачу изменить какой-то эндпоинт, расширить его функционал, то уверен, это будет гораздо сделать легче в микросервисе, где всего 6 эндпоинтов, чем в большом монолите, где намешано несколько языков.
Если компания захочет взять другой язык для определенного сервиса? Другую версию языка? Что насчет изоляции того же редиса, к примеру? Поднимать несколько штук на разных портах?
Насчет проксирования нджиниксом — это сильно зависит от проекта. На проекте может быть существующий монолит, в котором написана авторизация, разделение ролей пользователей и многое другое. Начинать распил с авторизации, как по мне, не самый лучший вариант. Я предпочитаю CAS, сессию хранить в гейтвее.
Мне не нравится вариант хранения сессии не в гейтвее потому, что нужно куда больше шагов, чтобы понять, что пользователь невалидный/неавторизованный/забаненный.
Вариант с проксированием через NGINX и сессии в микросервисе:
request -> nginx -> microservice #1 -> microservice #2 (получаем сессию) -> microservice #1 (обрабатываем ответ согласно бизнес-логике) -> response
Шагов куда больше, чтобы понять, что пользователь неавторизован.
Что касаемо деплоя микросервисов, об этом я планирую написать в следующей статье.
По поводу разных ЯП — согласен, это слишком очевидно. Питон сюда не приводится потому, что эти микросервисы написаны на библиотеке, которая разработана только для ноды. Думаю, если добавить сюда код на другом языке, это только больше запутает новичков.
>на легаси проектах переписывать микросервисы на другой роутинг и мидлвары может оказаться дороже
Смотря на каких легаси, если это легаси на экспрессе, то никаких проблем не будет. Роутинг, миддлвари обратно совместимые в моей библиотеки с экспрессом.
>можно ли как-то организовать общение между 2-ся гейтвеями
Да, можно. Здесь неважно — гейтвей это или микросервис. Существует метод ask, который отправляет запрос в микросервис по реббиту. Можно сделать какую угодно цепочку делегирования.
> система загружена слабо то у нас может одна реплика выбрать три запроса а другая простаивать в это время
Это может быть задано в логике гейтвея, написать веерную балансировку. Например, запускаем три микросервиса пользователей, очереди для запросов: users:requests-1, users:requests-2, users:requests-3. И, соответственно, отправляем первый запрос в первый микросервис, второй во второй, третий в третий, четвертый в первый и т.д.
Необязательно делегировать именно контроллеры, все зависит от бизнеса, с которым вы работаете. Монолит можно дробить по-разному.
Нджиниксом не проксируется потому, что иногда могут понадобятся какие-то данные (авторизации, к примеру). Гейтвей может делегировать запрос с дополнительной информацией в микросервис. Конечно, с нджиниксом можно сделать так же (nginx lua, к примеру), но здесь разница в удобстве большая.
> пишешь API — которого тебе должно хватить, и используешь только его, без попыток «хакнуть внутрянку»
Касаемо этого, не совсем понял. Вы действительно пишете микросервисы, которые могут общаться с собой через внешнее API (обычные эндпоинты, RPC), согласно микросервисной архитектуре. Гейтвей выступает лишь в качестве прокси, его можно заменить нджиниксом, как я и сказал выше.
> Подними с той стороны такой же монолит — и ничего не поменяется.
Нет, поменяется. Ваша бизнес-сущность (например, пользователи) будут изолированы от другой бизнес-сущности (например, товары). Каждый микросервис будет иметь свою базу и общаться только с ней, а в монолите же база единая для всего приложения.
Обычно, в микросервисной архитектуре пользователь отправляет запрос только на один домен, его принимает гейтвей, дальше отправляет микросервису через раббит, ждет ответа и отправляет его клиенту.
В случае, если вы реализовываете микросервисную архитектуру на экспрессе, тогда вам необходимо на клиенте понимать, куда обращаться: какой эндпоинт для какого микросервиса, это неудобно и непрактично, как показывает мой опыт.
Если вы хотите на экспрессе строить микросервис, ставя его за гейтвей, тогда непонятен выбор именно экспресса. В библиотеки MicroMQ есть нужный роутинг (как в экспрессе), миддлвари на промисах (лучше, чем в эскпрессе).
Ограничение запросов и ответов вы можете указать самостоятельно, если нужно. Возможно, эта фича будет в будущих обновлениях. Из ограничений это, конечно, использование только локальной базы данных. Теперь вы не можете, к примеру, получить баланс пользователя из микросервиса пользователей, отправив запрос к базе. Для этого вам придется отправлять запрос по рэббиту в микросервис баланса (см. метод ask).
Стриминг невозможен, насколько я знаю. Если вы реализовываете сервис, который будет раздавать очень большие файлы или ответы, то здесь будет проигрыш, скорее всего.
Если я правильно вас понял про стратегию обработки ошибок, то можете посмотреть пример из документации по обработке ошибок. Миддлвары реализованы на промисах, поэтому можно удобно жонглировать ими, как вам удобно.
Бесшовный деплой и надежность, как минимум. Если микросервис отключится на небольшое время, тогда запросы останутся в очереди. Запросы, которые обрабатывались во время отключения микросервиса (но они не отправились в гейтвей), тоже останутся в очереди.
Как микросервис включится, клиент получит запрос, так как его запрос не потерялся нигде. Но это зависит от таймаута настроенного (по дефолту он 15 секунд).
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
По поводу проксирования у нас с вами разные мнения: вы хотите реализовывать хранение сессии в микросервисе, а я в гейтвее. В вашем случае нджиникс действительно будет эффективнее.
Когда у вас в проекте (репозитории) будут несколько языков, начнется каша. Микросервисы, по моему мнению, это абстракция. Если джуниору дать задачу изменить какой-то эндпоинт, расширить его функционал, то уверен, это будет гораздо сделать легче в микросервисе, где всего 6 эндпоинтов, чем в большом монолите, где намешано несколько языков.
Если компания захочет взять другой язык для определенного сервиса? Другую версию языка? Что насчет изоляции того же редиса, к примеру? Поднимать несколько штук на разных портах?
Мне не нравится вариант хранения сессии не в гейтвее потому, что нужно куда больше шагов, чтобы понять, что пользователь невалидный/неавторизованный/забаненный.
Вариант с проксированием через NGINX и сессии в микросервисе:
request -> nginx -> microservice #1 -> microservice #2 (получаем сессию) -> microservice #1 (обрабатываем ответ согласно бизнес-логике) -> response
Шагов куда больше, чтобы понять, что пользователь неавторизован.
Вот схема с gateway:
Неавторизованный пользователь: request -> gateway -> response
Авторизованный пользователь: request -> gateway -> microservice #1 -> response
С такой схемой, если пользователь не авторизован, мы сразу отвечаем ему и не отправляем сообщение в раббит (микросервис).
По поводу разных ЯП — согласен, это слишком очевидно. Питон сюда не приводится потому, что эти микросервисы написаны на библиотеке, которая разработана только для ноды. Думаю, если добавить сюда код на другом языке, это только больше запутает новичков.
Смотря на каких легаси, если это легаси на экспрессе, то никаких проблем не будет. Роутинг, миддлвари обратно совместимые в моей библиотеки с экспрессом.
>можно ли как-то организовать общение между 2-ся гейтвеями
Да, можно. Здесь неважно — гейтвей это или микросервис. Существует метод ask, который отправляет запрос в микросервис по реббиту. Можно сделать какую угодно цепочку делегирования.
> система загружена слабо то у нас может одна реплика выбрать три запроса а другая простаивать в это время
Это может быть задано в логике гейтвея, написать веерную балансировку. Например, запускаем три микросервиса пользователей, очереди для запросов: users:requests-1, users:requests-2, users:requests-3. И, соответственно, отправляем первый запрос в первый микросервис, второй во второй, третий в третий, четвертый в первый и т.д.
Нджиниксом не проксируется потому, что иногда могут понадобятся какие-то данные (авторизации, к примеру). Гейтвей может делегировать запрос с дополнительной информацией в микросервис. Конечно, с нджиниксом можно сделать так же (nginx lua, к примеру), но здесь разница в удобстве большая.
> пишешь API — которого тебе должно хватить, и используешь только его, без попыток «хакнуть внутрянку»
Касаемо этого, не совсем понял. Вы действительно пишете микросервисы, которые могут общаться с собой через внешнее API (обычные эндпоинты, RPC), согласно микросервисной архитектуре. Гейтвей выступает лишь в качестве прокси, его можно заменить нджиниксом, как я и сказал выше.
> Подними с той стороны такой же монолит — и ничего не поменяется.
Нет, поменяется. Ваша бизнес-сущность (например, пользователи) будут изолированы от другой бизнес-сущности (например, товары). Каждый микросервис будет иметь свою базу и общаться только с ней, а в монолите же база единая для всего приложения.
В случае, если вы реализовываете микросервисную архитектуру на экспрессе, тогда вам необходимо на клиенте понимать, куда обращаться: какой эндпоинт для какого микросервиса, это неудобно и непрактично, как показывает мой опыт.
Если вы хотите на экспрессе строить микросервис, ставя его за гейтвей, тогда непонятен выбор именно экспресса. В библиотеки MicroMQ есть нужный роутинг (как в экспрессе), миддлвари на промисах (лучше, чем в эскпрессе).
Стриминг невозможен, насколько я знаю. Если вы реализовываете сервис, который будет раздавать очень большие файлы или ответы, то здесь будет проигрыш, скорее всего.
Если я правильно вас понял про стратегию обработки ошибок, то можете посмотреть пример из документации по обработке ошибок. Миддлвары реализованы на промисах, поэтому можно удобно жонглировать ими, как вам удобно.
Как микросервис включится, клиент получит запрос, так как его запрос не потерялся нигде. Но это зависит от таймаута настроенного (по дефолту он 15 секунд).