Più siti con lo stesso codebase in Python

Perché stai ottimizzando?
Sembri preoccupato per l'utilizzo della memoria. Perché? I risparmi previsti sono abbastanza grandi da permetterti di noleggiare una macchina virtuale più economica? L'attuale uso dei siti minaccia di distruggere la RAM attuale della tua macchina? (E anche se lo sono, sei sicuro che spenderai meno tempo di sviluppo per questa funzione di quanto faresti per ottenere una macchina migliore?)

Supponiamo che ti sia già chiesto che ... E la sfortunata conclusione è stata che esiste un motivo convincente per ottimizzare l'utilizzo della memoria.

Si sta parlando di messa in opera e dell'infrastruttura del codice per collegare questi siti in un'unica unità ottimizzata. Se questi siti separati sono inestricabilmente collegati tra di loro in un modo diverso dalla condivisione della stessa base di codice, ha senso costruire un'infrastruttura fisica su quel raggruppamento logico. Se si tratta di siti funzionalmente separati che utilizzano quasi sempre la stessa base di codice, consiglierei di non pensare nemmeno a usare un framework come questo a meno che tu non abbia altra scelta.

Che cosa succede se uno dei siti desidera in seguito rilevare una dipendenza da Windows (presumendo che gli altri siano in esecuzione su * nix in questo momento)? Cosa succede se uno dei siti diventa così popolare da dover essere installato su una macchina separata per motivi di prestazioni? Cosa succede se il cliente desidera spostare uno dei siti per tempi di risposta migliori in Europa?

Senza altri dettagli su ciò su cui stai lavorando, creare un'architettura che leghi questi siti suona come uno sforzo piuttosto discutibile.

Suggerisco di inserire il codice in git, quindi di utilizzare i sottomoduli per caricare la "libreria" di codice condiviso.

Se ci leggi sopra, sembra esattamente quello di cui hai bisogno:

link

It often happens that while working on one project, you need to use another project from within it. Perhaps it’s a library that a third party developed or that you’re developing separately and using in multiple parent projects.

Lo utilizziamo estensivamente e ha funzionato bene per la nostra organizzazione che fa centinaia di implementazioni settimanali dello stesso codice con modifiche minime a ciascuna versione che viene implementata.

I miei 2 cent.

Django ti aiuterà in questo modo. Reindirizzerai più siti alla tua istanza Django e l'istanza Django utilizzerà l'API che può aiutarti a risparmiare attraverso economie di scala, con costi di abbonati / costi di sottoscrizione dell'API, ecc.

In questo contesto, presumo che non si stiano utilizzando livelli gratuiti limitati o che non si abbiano SLA complicati con i fornitori di servizi (come l'uso corretto delle risorse). Prima di reindirizzare tutti i tuoi siti in un'unica istanza di Django (che funzionerà su un server e utilizzerà una sola API), controlla i tuoi accordi in modo da non avere penalità o soglie superiori.

Un altro aspetto che devi considerare sono i profili utente e i carichi di lavoro separati dei tuoi siti. Se il carico di lavoro complessivo sarà eccessivo, finirai per utilizzare un sistema di bilanciamento del carico che aumenterà il numero di istanze. D'altra parte, dal momento che sarà la stessa implementazione a funzionare, lo sviluppo del software sarà più semplice.

Per una risposta precisa, è necessario esaminare le metriche, verificare le risorse disponibili e concentrarsi sul business case (l'unità dietro le esigenze di ottimizzazione). Sfortunatamente, questa è più arte che scienza.

Umut.

Il mio suggerimento sarebbe di usare nginx, uWSGI e pallone. nginx è robusto e funziona bene con uWSGI in modalità Imperatore. Oltre a questo Flask è super flessibile per i coder Python, quindi dovresti essere in grado di apportare rapidamente le modifiche necessarie per sfruttare il tuo codice base condiviso.

Questo post di blog dovrebbe iniziare .