Уведомления

Группа в Telegram: @pythonsu

#1 Май 11, 2022 19:25:27

VadimK
Зарегистрирован: 2013-07-03
Сообщения: 199
Репутация: +  16  -
Профиль   Отправить e-mail  

Разделение монолита на микросервисы

Есть достаточно тяжелый проект на джанге 1.6 с питоном 2.7 и кучей древних зависимостей. За 6 лет разработки там накопился огромный функционал и куча модулей.

Условно - пускай будет это магазин, с поставщиками, клиентами, логистикой доставки товаров, сотрудниками и их оборудованием и подобное. Вот взять сразу и переписать это все не реально. Поэтому возникла идея оттуда выдирать куски функционала и делать их как микросервисы.

Но собственно возникает вопрос - а как вообще должен происходить обмен данными ? Все очень плотно связанно и дернув данные клиента нам необходимы его заказы, текущие процессы связанные с ним в логистике, сотрудники его обслуживающие.

Сейчас все лежит в одной базе и собственно проблем нет. А в случае с отдельными микросервисами как ? К примеру таблица пользователей. Реплицировать ее между микросервисами или напрямую переключаться в нужную БД и raw запросами тянуть инфу ?
На API переводить - это пипец сколько запросов гулять будет и огромнейший оверхед.

Пока совсем не понятно куда двигаться. Да и гораздо удобнее к модели за пару минут дописать нужный метод и получать данные за одно движение в дальнейшем.
Может кто делал подобное и может поделиться тут своим видением, в каком направлении двигаться.

Офлайн

#2 Май 12, 2022 02:59:32

py.user.next
От:
Зарегистрирован: 2010-04-29
Сообщения: 9846
Репутация: +  853  -
Профиль   Отправить e-mail  

Разделение монолита на микросервисы

VadimK
Поэтому возникла идея оттуда выдирать куски функционала и делать их как микросервисы.
Это ты хочешь писать новый проект, который будет делать то же самое, что и существующий проект.

VadimK
Вот взять сразу и переписать это все не реально.
Да, нереально, просто затратно и нерезультативно. Поэтому надо писать новый проект.

VadimK
Но собственно возникает вопрос - а как вообще должен происходить обмен данными ?
Надо смотреть на это как на новый проект. Тогда ты спроектируешь базу данных по-новому.

VadimK
Сейчас все лежит в одной базе и собственно проблем нет. А в случае с отдельными микросервисами как ? К примеру таблица пользователей. Реплицировать ее между микросервисами или напрямую переключаться в нужную БД и raw запросами тянуть инфу ?
На API переводить - это пипец сколько запросов гулять будет и огромнейший оверхед.
Эти вопросы появляются из того, что ты пытаешься этот проект переделать. А это не надо делать. Это пустая трата времени. Это как за новичком доделывать его говнокод. Не надо этого делать! Надо ему написать готовый код правильный сразу, без переделываний, без очистки его говна в каком-то там его говнокоде. Не надо на это тратить время.

Поэтому
VadimK
Есть достаточно тяжелый проект на джанге 1.6 с питоном 2.7 и кучей древних зависимостей. За 6 лет разработки там накопился огромный функционал и куча модулей.
Ну вот, он сдох. Потому что его архитектура - это говно, не расчитанное на долгую жизнь. Микросервисная архитектура - тоже не панацея. Может, там вообще несколько программ должно быть. Это первый признак: если у тебя всё лежит в одном месте и превращается в свалку, то это надо разделить на хорошо стыкующиеся отдельные части. И потом для этих частей в отдельности то же самое работает: если у тебя всё лежит в одном месте и превращается в свалку, то это надо разделить на хорошо стыкующиеся отдельные части. То есть это не в микросервисах дело. Это вот кто придумал, что оно должно быть таким монолитным, вот тот не знает нихера. Что в итоге через шесть лет ты и наблюдаешь.



Офлайн

Board footer

Модераторировать

Powered by DjangoBB

Lo-Fi Version