Мне интересно, как решить разделение структуры модели между несколькими (отдельными) проектами django/microservices. Например:Модели Django для нескольких проектов/микросервисов. Как?
Каждый из того, что проекты используют одни и те же модели Джанго. Есть ли один, правильный способ решить это?
Два возможных варианта:
Вариант 1 - Использовать общую кодовую и развернуть несколько экземпляров (по одному для каждого microservice). Вы можете следовать методологии приложений 12factor и просто загружать другой набор переменных среды для каждого развернутого экземпляра. http://12factor.net/
Вариант 2 - Разделите свой код django на автономные приложения, затем выполните проект для каждого микросервиса, который включает только эти проекты и конфигурацию url.
Я могу расширить его, если это будет полезно?
Модели Django - это всего лишь модуль Python, конечно Django делает много «магии» в других модулях (например, формы, админ), используя интроспекцию, но сами модели можно использовать по отдельности, если это необходимо.
Итак, нет проблем ... Если вы используете разные «проекты Django» для каждого проекта, который вы назвали (на том же компьютере или другом), просто сделайте ваши модели отдельным «приложением Django» и установите для каждого проекта его использование , Если каждый указанный вами проект - это «приложение Django» (в данном случае на той же машине, очевидно), то просто импортируйте модуль моделей в каждый «проект» и используйте его. Даже если вы не используете Django, скажите, что ваш «проект API» основан на Flask, вы все равно можете импортировать модели Django в модули Flask.
За сценой моделей Django есть база данных, которая не заботится о том, где она запрашивается, а Django просто предоставляет удобный способ использования БД через классы Python. Поэтому, если модели из разных приложений или проектов настроены на использование одного и того же БД, тогда они будут «разделяться».
Это хорошо работает. Также кажется, что вы осуществили что-то подобное в каком-то месте. –
Я хотел бы узнать больше о том, как вы сделали полномасштабную архитектуру микросервиса, используя Django под капотом. –
Основная идея Django состоит в объединении всей функциональности приложения, но это не выполняется в вашем случае. Это вопрос стиля и мнения, вот что я сделал в подобной ситуации.
Сплит функциональность приложения на два логова проекта:
mysite
|
| - db_access
| | --- app1
| | ---- models.py
| | ---- db_api.py
| | --- app2
| | ---- models.py
| | ---- db_api.py
| - service
| | --- app1
| | ---- urls.py
| | ---- views.py
| | --- app2
| | ---- urls.py
| | ---- views.py
db_access часть имеет модели, и db_api.py имеет запросы, получить объекты и т.д., так что вы не опрашивать модели, но db_api.
Вместо
item = app1.models.Items.objects.get(user=request.user)
Использование
item = app1.db_api.get_first_item(user=request.user)
Этот стиль позволяет разделить дб & модели доступа вместе, в то время как каждая служба потребляет то, что ему нужно, а затем использовать его для API, веб-сайт и т.д. ,Если служба использует некоторые данные таким образом, что другие сервисы не используются (и не будут), тогда поместите этот запрос в код службы, иначе в db_api.py.
Это больше похоже на традиционное приложение, но оно работает.
Другое дело, что в одном проекте можно использовать два репозитория git, один для db_access (который все сервисы вытягивают), и один для конкретного сервиса. Поэтому каждый проект django на самом деле является репозиторией db_access, а служба repo-wsgi не заботится, конечно, если код проекта исходит из двух репозиториев.
Если вы хотите использовать те же модели в разных приложениях python (а не в модулях, но приложениях, с разными экземплярами uwsgi и т. Д.), То я думаю, что очень распространенное и удобное решение - обеспечить интерфейс для этих моделей через некоторый API :
, пожалуйста, используйте это! –