Как правильно мигрировать приложение с монолитной архитектурой на микросервисное приложение на Django
Сегодня я пришел с этим вопросом, вероятно, к тому, кто имеет большой опыт в этом.
В основном то, что указано в заголовке. У нас есть приложение, и мы должны перевести его на микросервисы.
Мы не нашли никакого надежного подхода (или нам так показалось) по этому поводу. В итоге мы создали 1 проект на микросервис (одна функциональность, связанная с модульным приложением, в общем), но потом у нас возникли проблемы, потому что у нас уже была база данных для работы, так как это уже функционирующее приложение.
У нас были проблемы со связью с существующими моделями, поэтому в основном мы делали так: в каждом settings.py проекте мы указывали на существующую БД, а с python3 manage.py inspectdb мы захватывали существующую models. Этот подход в итоге сработал, но мы считаем, что это не лучший подход. У нас было много проблем с циклическим импортом и многое другое.
Есть ли хорошие практики о микросервисах с Django, и как правильно это сделать, как в большинстве случаев, когда мы хотим создать что-то с помощью фреймворка?
Если кто-то знает или имеет что-то, мы будем очень признательны!
Вы можете использовать Django для микросервисов. В этом случае у вас есть только несколько приложений, и вы запускаете каждый сервис на собственном порту:
первый проект Django
генератор pdf + виды генерируют маленький pdf
второй проект Django.
генератор pdf + представления генерируют большой pdf (код может наследоваться другим проектом)
оркестр:
Третий проект Django: Авторизация + вызов большого или маленького сервиса генератора pdf
настройки
settings.py для первого и второго очень прост и позволяет звонить только с внутренних ip. здесь нам не нужны middleaware, template, cache, admin и другие настройки.
settings.py для оркестра также очень прост и использует только auth и делает звонок по внутреннему ip ant отправляет ответ пользователю. Здесь нам не нужно много middlaware, и не нужно много других настроек.
прирост:
- Все независимо. если один сервер падает, другие могут работать.
- Обновления просты. Обновление одного небольшого сервера всегда проще, чем обновление монолита.
- Разработка проста: три небольшие команды работают над собственными небольшими проектами.
- Тестирование модулей легко и быстро.
- Для сложных бизнес-целей вся система быстрее.
боли:
- после 100 микросервисов работать с этим всем становится совершенно сложно.
- стиль кода от многих команд всегда отличается. Неважно, насколько строго вы определяете styleleguide или настройки для black-linter.
- Интегрированное тестирование затруднено - Если что-то не работает, трудно найти, где именно.
- Экосистема Auth/services/messaging действительно сложна .
- Для простых бизнес-целей вся система переусложнена.
summary
Не имеет значения, сколько БД вы хотите использовать. это может быть монолит или множество сервисов.
я не вижу никакой проблемы импортировать в один микросервис что-то из другого проекта: это может быть модель / администратор или другой персонал. это работает. возможно, вам нужно умно разделить монолит, но это тоже легко, для этого у нас есть много опыта (моего собственного и в интернете или книгах)