Хорошая ли стратегия разбивать монолит джанго на микросервисы джанго?

Question

[0ralo]

Здравствуйте, у меня вопрос.
У меня на работе на джанго написан большой проект, он состоит из двух логически малозависимых сервисов(сервис продажи курсов и сервис найма типа хх). Пересечение логики там в пользователях и навыках(типа прошел курс - получил навык - получил плюс во внутреннем резюме), попутно подрабатывая сисадмином я столкнулся с проблемой: этот монолит очень тяжело поддерживать, обновлять код и дебажит. Есть мысль разбить этот монолит, пока он не разросся до неба, на 2 сервиса. Но на бумаге уже возникают проблемы. Оба сервиса достаточно большие и на джанго написано очень много и качественно (переписывать на другие фреймы - не вариант), но джанговская защита сама вставляет палки в колеса.
1. Если 2 приложения будут на одном сервере, запросами будет управлять нгинкс - это не проблема. Но вот взаимодействие между самими сервисами - уже под вопросом. Если у 2х сервисов будут разные секретные ключи между ними возникнут проблемы при csrf и сессиях? Если да есть ли вариант это починить? Если будут одинаковые ключи - безопасно ли это?
2. В моментах пересечения логики сервисов будет повторение кода(модельки юзеров в обоих сервисах, навыки и тд) это нарушает принцип DRY, страшно ли это, можно ли избежать?
3. В джанго можно подключить несколько бд к одному сервису. Как быть при двух сервисах? У каждого проекта есть свои вспомогательные модельки, названия таблиц которых я не уверен что возможно изменить. Есть ли вариант технически разделить бизнес бд с сервисной бд?

Comments

[maksam07]

Мне кажется, что здесь нужно 3 сервиса, хотя я могу очень ошибаться. Третий - полноценный профиль пользователя, с его навыками и т.д., которые будет заполняться и использоваться через два других (курсы/найм).

Взять тот же хабр:
qna - вопрос/ответ
habr - новости
карьера - найм
... - ...
На каждом сервисе есть свои некоторые настройки профиля
У всех сервисов можно завести отдельный аккаунт, или же... связать все единым аккаунтом хабра - https://account.habr.com/

Answer 1

[mayton2019]

Смотри. Уже прошло время когда все пилили монолиты на микросервисы. Щас пошло переосмысление.
Объективно есть 2 причины пилить. Первое - организационная. Команда по какой-то причине не хочет
или не может поддерживать приложение. Или там что-то с бизнесом. Слияние. Поглощение. Передача
проекта другой команде в поддержку. Тогда берут и ставят задачу раздела отвественностей.
Конвей про это писал еще.

И второе - это баланс нагрузки и децентрализация. Про failover тут еще даже речи нет. Это
тяжелая тема и распилить монолит так чтобы его части были отказоустойчивы очень трудно. Более
того в случае синхронных взаимодействий между частями микросервисов может быть даже падение
перформанса. Да. Теоретики которые там пишут восторженные отзывы - совершенно игнорируют
накладные на RPC. И не упоминают что в монолите цена RPC была равна нулю. Иногда RPC заменяют
на MQ - но это новая архитектура и это надо полностью переделывать бизнес.

И что делать с базой данных? Это тот еще вопрос. Я почти готов спорить что вы базу пилить не будете.
И что в результате будет? Иммитация микро-сервисов? Где слабая связность?

Тоесть если у вас нет таких кричащих ситуаций что оргазниация требует или нужно баланс
нагрузки как-то разнести - то тебе вообще-вообще нет смысла ходить ни в какие микросервисы.

Но имеет смысл сделать модуляризацию монолита. Например что там...

application
- sales
- hiring
- userprofiles

Тоже очень полезно для управления сложностью. И пускай себе будет монолит зато будет сильный
контроль за изменениями.

Comments

[Uno]

интересно
получается, раз сильная связность в виде бд это имитация микросервисов, верно ли утверждение что настоящая микросервисная архитектура это по сути децентрализация?

[mayton2019]

Uno, ну ... в качестве лакмуса. Если ты можешь сделать shutdown одному микросервису
и при этом другие работают и бизнес не сильно страдает - то у тебя правильная архитектура.
А если все попадало или повисло в блокировках то значит фигня это.

[Станислав Макаров]

mayton2019 золотые слова... А то всё попилят на 8000 сервисов по 500 строк кода каждый, а про graceful degradation и прочие полезные штуки как-то и не подумали.

[Василий Банников]

Uno, нет. Децентрализация - это когда нет центра, а в каком-нибудь сборище микросервисов вполне могут быть мастер-системы, которые владеют данными.

Тут скорее речь о том, чтобы не иметь общих ресурсов.

[Uno]

Василий Банников, Мастер-системы (хотя в данном контексте вернее - подсистемы) центром не являются, если без них периферия не работает?
Так что в этой формулировке это одно и то же. Но мысль правильная, если не придираться, mayton2019 и подтвердил

[Василий Банников]

Uno,

Мастер-системы (хотя в данном контексте вернее - подсистемы) центром не являются, если без них периферия не работает?

Ну если "периферия" не закэшировала нужные ей данные, то да - не будет работать.

Answer 2

[Jack444]

Вообще на самом деле джанго можно сделать аля-микросервисным если рассматривать каждое приложение как отдельный микросервис.
В Джанго можно подключить для любой модели отдельную базу данных которая может находится на отдельном сервере или другом порту.
Всё что требуется добавить в модель следующие:

class MyModel(Model):
    class Meta:
        using = 'default'  # дефолтная база из DATABASES из settings.py

Использование отдельных баз данных это дело одно, но вам скорее всего хотелось бы чтобы каждое приложение работало на отдельном порту, это тоже не проблема, в каждом приложении создайте systemd.service который запустит экземляр на другом порту и делайте жесткую ссылку в systemd/system, после через nginx проксируйте по location на порт приложения.
Чисто так технически можно перенести экземпляры на разные серверы и поправить конфиги.
Важно чтобы секретный ключ был один и тот же везде, иначе будет много проблем, по безопасности всё ок если не раскрывать его третьим лицам.
Как вариант секретный ключ и другие данные можно хранить в .env и подгружать их в settings.py.
Если хотите сохранить чистоту коду, то экземляры можно раскидать по папкам, в каждой из них набросать по минималке README.txt с инфой на каком порту запущено, какие команды для остановки и перезапуска, какие паки нельзя трогать а какие можно, можно только ту в которой висит приложение а все остальные папки которые не взаимодействуют из этого приложения можно снести.

В общем какой-то такой вариант можно реализовать, но я бы рекомендовал оставить как есть и по возможности старые сервисы переписывать на микросервисы FastAPI а новые эндпоинты сразу пилить на нём.

Answer 3

[Василий Банников]

этот монолит очень тяжело поддерживать, обновлять код и дебажит.

Распилив его на два микросервиса ты получишь два микросервиса, которые ещё тяжелее поддерживать, обновлять, и дебажить.

В твоём случае будет лучше разобраться с первопричиной, тк монолитность сама по себе очень редко приводит к описанным проблемам.

Дело пахнет скорее масштабным рефакторингом, чем разделением.

Comments

[Roman K]

Проблема в том, что ТС не хочет слушать того, что ему не нравится:) Хрестоматийный пример

Answer 4

[Roman K]

"Разбивать" монолит на сервисы хорошая идея только если у вас больше 500 разработчиков. Никаких плюсов кроме независимого деплоя микросервисы не имеют, зато минусов — перечислять не хватит недели

Answer 5

[romaro]

Касательно дублирования моделей.

В свое время я сталкивался с такой же проблемой: одни и те же модели описаны в реляционной БД, в серверном коде и даже на клиенте. Соответственно, если меняем БД, нужно вносить изменения в остальные части проекта.

В итоге остановился на том, что моделей вообще не должно быть нигде, кроме как в БД. Сейчас БД содержит метаданные, в которых описаны таблицы бизнес-логики (доменная область) и по этим метаданным клиент и сервер создают объекты, для которых раньше приходилось вручную декларировать классы моделей.

То есть мне комфортнее работать с database first архитектурой. Но часто наоборот: модели описываются в серверном коде и переносятся в базу при помощи ORM.