필자는 새로운 대규모 프로젝트, 즉 하나의 도메인의 자체 서브 도메인에서 각각 작업하는 많은 도시 기반 웹샵 (예 : citydomain.webshop.com)을 만들기 시작했습니다. 이 웹 사이트 중 40 개가 동시에 실행을 시작해야합니다.동일한 백엔드 로직을 기반으로하는 여러 사이트가있는 Django 프로젝트에 가장 적합한 구조는 무엇입니까?
프로젝트의 백엔드 비즈니스 로직 및 템플릿 스타일은 모든 사이트에서 동일합니다. 일부 정적 파일 및 데이터베이스 데이터는 모든 사이트에서 일반적이며 특정 사이트 (로그, 이미지, 판매 품목, 주문 등) 일 수 있습니다.
내 질문은 다른 하위 도메인에서 동일한 URL을 방문하는 특정 사용자가 동일한 백엔드 로직에 의해 처리되는 해당 하위 도메인의 특정 데이터를 가져 오는 방식으로 최상의 아키텍처를 구현하는 방법입니다.
나는 가능한 아키텍처의 다음과 같은 옵션을 가정
1) 장고 프로젝트 인스턴스 : 각 사이트에 대해 모든 사이트 또는 많은 경우에 하나 개의 인스턴스?
첫 번째 방법은 DRY 원리면에서 두 번째 방법보다 훨씬 논리적 인 것처럼 보입니다. 이상적으로 각 사이트의 특정 이미지, 로그 등을위한 하위 도메인 이름을 가진 하나의 프로젝트 인스턴스가 있어야한다고 생각합니다.
2) 데이터베이스 : 모든 사이트에 대해 하나의 데이터베이스 또는 각 사이트에 대해 많은 데이터베이스가 있습니까?
동일한 DRY 원리 때문에 하나의 데이터베이스가 너무 많습니다. 엄청난 양의 데이터가 다른 사이트 별 데이터베이스에서 반복 될 수 있으며, 또한 온더 플라이 (on-the-fly) 방식으로 전환하는 작업은 번거로울 수 있습니다 (데이터베이스 라우터는 문서에 따라 도구로 보입니다).
데이터베이스가 하나 뿐이므로 다양한 테이블에 사이트 특정 데이터를 저장하려면 sites framework을 사용해야합니까 (외래 키가 Site 모델 인 경우 알고 있습니다). 어떻게하면 현재 하위 도메인에 따라 SITE_ID를 변경해야합니까? a) 맞춤형 미들웨어 또는 중 하나를 사용해야합니다. b) django-subdomains, django-multisite, Airavata과 같은 일부 애드온을 사용할 수 있습니까?
아니면 sites framework을 구현하는 용도는 없습니까?
3) 설정 : 저장 settings.py 파일 (주 한 많은 사이트 별 것들의 설정) 또는 데이터베이스에 저장된 사이트 별 옵션 전용 (어쩌면 Site 테이블 내에서 또는 다른 테이블의 주요 settings.py 파일을 결합하는 그것을 확장 할 것인가?)
4) 가상 호스트 : 메인 도메인 전용 또는 각 사이트의 많은 가상 호스트? 두 번째 옵션은 여러 개의 작은 사이트 별 settings.py 파일 (각각 하나의 메인 settings.py을 상속 한 SITE_ID)을 각 하위 도메인에 대한 많은 사이트 별 WSGI 파일과 연결하여 설정할 수 있습니까?
위에서 설명한 프로젝트에 대한 권장 사항을 알려주십시오. 이러한 "교차로"와 같은 옵션에 대해 올바른 결정을 내리려면 무엇을 권하고 싶습니까?