Comments 14
нагрузка на монолит существенно возросла.
Поэтому мы начали перестраивать монолитную архитектуру на микросервисы
Всегда интересовал логический переход между этими двумя агрегатными состояниями
Коротко: разные части монолита, по-разному нагружены. Вынос таких частей в сервисы позволяет их масштабировать отдельно. Обработка запроса в сервисе почти всегда "короче" и "легче" чем в монолите - отрабатывает только то, что нужно. Никакого общего "бутстрепа", на запрос не влияет и не мешается "соседняя логика".
Да и сам сервис проще и чище по коду чем монолит, хотябы ввиду размера кодовой базы.
ну и зачем? явно видно работы не было , делали ради чтобы сделать
О! Вот кто мне нужен! Доколе ваш сервис (веб-клиент) будет терять продукты из корзины?! Ты сидишь, вспоминаешь, всё, что нужно, забиваешь корзину на 25 позиций, заказываешь доставку, доставка приезжает и ты внезапно обнаруживаешь, что некоторых позиций нет, а ты их точно добавлял! В чеке их нет, то есть они теряются или в момент заказа или еще до него. Написал в саппорт, меня попросили прислать скриншот ошибки [facepalm.jpg], по итогам переписки мне сообщили, что в корзине этих позиций не было, а то я и так не знаю. Еще часто бывает, что заказываешь, например, полтора кило груш, а привозят одну (одну!!!) грушу, потому что вес не сохранился в корзине. Сейчас я опытный покупатель, дважды просматриваю корзину перед отправкой, но, тем не менее иногда еще накалываюсь. У меня сильное подозрение, что у вас где-то сидит race condition, как минимум, потеря количества по заказываемой позиции может быть с этим связано -- когда кликаешь несколько раз на плюсик, иногда цифры меняются непредсказуемо.
Если есть кейс с локализацией, советую отправить в саппорт с шагами тогда.
У меня например, была похожая ситуация с Куулклевер, там терялась одна позиция на моменте заказа. Приняли баг-репорт, фикс выкатили через два дня, поблагодарили)
Вообще, мне кажется хорошим тоном, нашел багу - зарепорть, как если бы репортил в своей компании.
Я конечно не великий специалист))))
НО. В мире high-load и BigData о которых нам кричат на каждом углу и которые анонсирую в дата центрах сбера, мтс и прочих крупных игроков, жалкие 100к записей даже за данные не считают. Это семечки.
Зачем было такой огород городить, любая бд на более ли менее живом железе с мигрирует записи за несколько секунд.
Мы поднимали реплики между совершенно не совмесимыми БД, и они прокачивали гигабайтные базы данные в оба направления практически не имея нагрузок.
Что и зачем делали эти 15 человек? Почему было не взять готовое, проверенно решение? Или свой велосипед всегда лучше?
Хотя да, наверное у таких серьёзных продуктов есть и серьёзное финансирование, поэтому работа ради работы это в порядке вещей.
Какие решения для api gateway рассматривали и на чём в результате остановились?
Можете пояснить предназначение хидеров GATEWAY_JWT_PAYLOAD и GATEWAY_SECRET? Почему не просто Authorization?
Вообще не понятно, в одной части эти заголовки чистят, в другой добавляют, плюс куча синхронизации туда-сюда, вместо того, чтобы добавить одно поле в базу данных
Добрый день!
Зачем поля GATEWAY_JWT_PAYLOAD и GATEWAY_SECRET
api-gateway:
получает JWT, парсит его, проверяет время жизни, подпись и прочее.
на основе JWT-пейлоада формирует заголовок GATEWAY_JWT_PAYLOAD и отдает его дальше в запросе на бэк + заголовок GATEWAY_SECRET
бэк шоппера:
проверяет, что в GATEWAY_SECRET передан правильный ключ (про правильное значение знает только api-gateway и бэк шоппера)
берет нужные данные из заголовка GATEWAY_JWT_PAYLOAD, например, user_uuid
В целом, заголовок GATEWAY_SECRET был нужен больше на переходном этапе, когда бэк был еще параллельно открыт для старой аутентификации.
Может я чего не понимаю, но вроде как аутентификация это один запрос к базе данных. Зачем тут микросервис? Чтобы объединить пользователей двух баз данных? Поле в базе добавить, не?
В микросервис были вынесены как минимум генерация JWT, его рефреш, обновление ключей. Это позволило во-первых, снять с монолита эти функции, во-вторых, ходить в другие микросервисы авторизовавшись в одном месте. Полный отказ от монолита в пользу микросервисов - это долгий процесс, включающий множество шагов. И сервис аутентификации в нашем случае был лишь одним из таких шагов, который для части функционала является подготовительным. Это не просто функциональная единица, а довольно гибкий инструмент, который встроен в новую архитектуру.
Меня одного смутило в БД таблицы
Номер телефона
Номер+ЛД
Активная учетка
Может я сильно отстал в БД, заранее прошу прощения за вопрос, это все разные таблицы? Если да, зачем хранить в разных таблицах одно и тоже значение, или Вы используете телефон как индекс?
200K и столько мороки. По всей видимости проблема была в самом механизме обработки JWT, так как для Postgres это вообще не нагрузка.
15человек делали )))
Мне кажется авторизация go+Jwt+redis+postgres+nats тянет на текстовое задание при найме в такую компанию
p.s. Судя по комментам, вроде тех где теряются товары в корзине и проблемы с миграцией, думаю пора смотреть в сторону CQRS, Event sourcing
Как перевести 100 000 учеток на микросервис и ничего не сломать