0ralo
@0ralo
Python backend developer

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

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

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

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

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

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

Тоже очень полезно для управления сложностью. И пускай себе будет монолит зато будет сильный
контроль за изменениями.
Ответ написан
@Jack444
Вообще на самом деле джанго можно сделать аля-микросервисным если рассматривать каждое приложение как отдельный микросервис.
В Джанго можно подключить для любой модели отдельную базу данных которая может находится на отдельном сервере или другом порту.
Всё что требуется добавить в модель следующие:
class MyModel(Model):
    class Meta:
        using = 'default'  # дефолтная база из DATABASES из settings.py

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

В общем какой-то такой вариант можно реализовать, но я бы рекомендовал оставить как есть и по возможности старые сервисы переписывать на микросервисы FastAPI а новые эндпоинты сразу пилить на нём.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 3
vabka
@vabka
Токсичный шарпист

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

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

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

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

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

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

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы