Distruggi il monolito di django in microservizi

Question

Distruggi il monolito di django in microservizi

#1 da (1 voti)

0

Al momento disponiamo di una grande applicazione web Django: tutti i dati sono gestiti centralmente dalla webapp, tramite i modelli supportati da Postgres.

Vogliamo offrire l'accesso ai dati in modo più decentralizzato, e la soluzione alla quale miriamo è fornire piccoli uServies che si occupino dei diversi domini applicativi. Cioè, da questa architettura:

Django + singolo DB

Vogliamo passare alla seguente architettura:

Django (senza dati)
uServizio 1 + DB1
uService 2 + DB2
...

Quindi avremo un percorso di transizione agevole: la webapp continuerà a funzionare come prima, ma ora avremo la possibilità di offrire l'accesso ai dati in maniera dettagliata, con requisiti diversi (per la scalabilità, ... ) per ciascuno dei nostri domini applicativi.

Il refactoring deve essere eseguito nel modo seguente:

La webapp di Django deve rimanere invariata (ad eccezione dei modelli). In particolare, le visualizzazioni e i modelli devono rimanere invariati.
Ciascun uService gestirà un sottodominio problematico e sarà completamente autonomo, offrendo accesso ai dati tramite REST. La tecnologia per ogni uService non è definita: potrebbe essere DRF, o Flask, o Scala, o Java, non ha molta importanza; questo è in realtà uno dei punti di forza della nuova architettura: ogni problema può essere risolto con lo strumento giusto per il lavoro.
L'accesso tramite la webapp django alla fine OTTIENE / POST / DELETE / PUT dai servizi u.

Come si può usare Django in questo modo? Idealmente avremmo ancora dei modelli nella webapp, ma invece di essere supportati dal database, dovrebbero accedere agli endpoint REST per ottenere / modificare i dati.

Esistono applicazioni di esempio che utilizzano questo tipo di architettura nel mondo di Django?

rest python django

posta dangonfast 25.06.2018 - 07:15

fonte

1 risposta

Leggi altre domande sui tag rest python django

Come viene eseguita la distribuzione su più piattaforme e diversi linguaggi di programmazione? Enum come parte del dominio - enum + estensione o consolidamento in una classe?

score 1 · Answer 1

Sì, Django può certamente essere usato in questo modo: le viste possono chiamare i tuoi nuovi servizi (uService1 e uService2) per recuperare i dati di cui hanno bisogno per il rendering dei modelli o per mediare le interazioni dell'utente in PUT / POST / DELETE con i tuoi nuovi servizi .

Ma vedo molti potenziali attriti contro il progetto fondamentale di Django: i modelli sono pensati per essere supportati da un datastore SQL, non dai propri servizi aziendali a monte. Le interazioni dell'utente sono pensate per essere mediate attraverso forme, che sono strettamente integrate con i modelli ...

Dipende davvero dai tuoi esatti requisiti di scalabilità, dalle dimensioni del tuo team e dalla natura dei problemi che stai cercando di risolvere. Tuttavia, in superficie con i dettagli forniti, sembra che dovresti considerare quanto segue: Conserva un database di grandi dimensioni, anche se esiste un numero enorme di tabelle. A meno che non vi siano limiti chiari, suddividere le tabelle in più archivi dati è più un problema che ne vale la pena, in quanto perdi integrità referenziale, join e tutta la potenza e la flessibilità di eseguire query SQL su un singolo set di dati.

Vorrei consigliare quanto segue: Utilizzare Django REST Framework per esporre i dati e le operazioni, disaccoppiati dalle viste HTML. DRF può sedersi facilmente a fianco dei tuoi modelli e viste Django vaniglia. Inoltre, la somiglianza concettuale con Django ti consente di sfruttare le conoscenze esistenti della tua squadra. Puoi creare un'app "api" o sottocartelle "api" in ciascuna delle tue app. Presta attenzione alla struttura e all'organizzazione del codice del tuo progetto Django e potresti essere sorpreso di quanto sia flessibile e produttivo un " maestoso monolite " può essere. Ora puoi offrire dati e operazioni aziendali (POST / annulla) in modo raffinato alle app per dispositivi mobili o sperimentare nuovi fantasiosi front-end JS. Se davvero si hanno requisiti di scalabilità che il semplice ridimensionamento orizzontale non può risolvere, è sempre possibile migrare i pezzi in un servizio Spring o Go. Forse a quel punto, il tuo livello di presentazione sarà React o Vue e puoi semplicemente aggiornare l'interfaccia utente per utilizzare i tuoi nuovi endpoint di servizio anziché quelli DRF.