Introduzione all'architettura a tre livelli
L'architettura a tre livelli è l'architettura di interazione più comune su Internet. È apparso quando la parte del server a due livelli è stata divisa in due parti: un livello logico e un livello dati .
Sembrava qualcosa del genere:
Il livello client è la parte dell'"applicazione distribuita" responsabile dell'interazione dell'utente. Questo livello non deve contenere la logica aziendale e non deve archiviare dati critici. Inoltre, non dovrebbe interagire direttamente con il livello del database, ma solo attraverso il livello della logica aziendale.
Tuttavia, c'è ancora una certa logica qui. In primo luogo, si tratta di interazione con l'utente tramite l'interfaccia, convalida dei dati da lui inseriti, lavoro con file locali. Ciò include anche tutto ciò che riguarda l'autorizzazione dell'utente e la crittografia dei dati quando si lavora con il server.
In secondo luogo, è una semplice logica aziendale. Ad esempio, se un negozio online ha inviato un elenco di prodotti, possiamo ordinarli e filtrarli lato cliente. E anche l'archiviazione primitiva dei dati è qui: memorizzazione nella cache, cookie degli utenti registrati e simili.
Il livello della logica aziendale si trova al secondo livello, la maggior parte della logica aziendale è concentrata su di esso. Al di fuori di esso rimangono solo i frammenti che vengono esportati al client, così come gli elementi logici che sono immersi nel database (procedure memorizzate e trigger).
Gran parte del server di logica aziendale contiene non solo questa stessa logica, ma risolve anche problemi di scalabilità: il codice è diviso in parti e distribuito a diversi server. Alcuni servizi molto richiesti possono essere eseguiti su dozzine di server. Il carico tra di loro è gestito dal bilanciamento del carico.
Le applicazioni server sono generalmente progettate in modo tale che un'altra copia del server possa essere facilmente avviata e iniziare a lavorare in collaborazione con altre copie di esso. Cioè, anche nel processo di scrittura del codice del server, non avrai mai la garanzia che la tua classe statica venga lanciata in una singola istanza.
Il livello dati fornisce l'archiviazione dei dati ed è posto su un livello separato, implementato, di norma, mediante sistemi di gestione di database (DBMS), la connessione a questo componente è fornita solo dal livello del server delle applicazioni.
Motivi per separare il livello dati
La separazione del livello dati in un terzo livello a tutti gli effetti è avvenuta per molte ragioni, ma la principale è l'aumento del carico sul server.
Innanzitutto, i database hanno iniziato a richiedere molta memoria e tempo del processore per l'elaborazione dei dati. Pertanto, hanno iniziato a essere posizionati ovunque su server separati.
Con un carico maggiore, il back-end poteva essere facilmente duplicato e si potevano creare dieci copie di un server, ma era impossibile duplicare il database: il database rimaneva comunque un componente unico e indivisibile del sistema.
In secondo luogo, i database sono diventati intelligenti : hanno una propria logica aziendale. Hanno iniziato a supportare stored procedure, trigger, i propri linguaggi come PLSQL. E sono apparsi anche programmatori che hanno iniziato a scrivere codice che gira all'interno del DBMS.
Tutta la logica che non era legata ai dati è stata trasferita al back-end e lanciata in parallelo su dozzine di server. Tutto ciò che è criticamente legato ai dati è rimasto all'interno del DBMS, e già lì i problemi dell'aumento del carico dovevano essere risolti con i nostri metodi:
- Un cluster di database è un gruppo di server di database che archiviano gli stessi dati e li sincronizzano utilizzando un protocollo specifico.
- Sharding: i dati vengono suddivisi in blocchi logici e distribuiti su diversi server di database. È molto difficile mantenere le modifiche al database con questo approccio.
- L'approccio NoSQL consiste nell'archiviare i dati in database creati per archiviare enormi quantità di dati. Questi spesso non sono nemmeno database, ma archivi di file specifici. Funzionalità molto scarsa rispetto ai database relazionali.
- Cache dei dati. Invece di una semplice cache a livello di database, è apparso l'intero DBMS di memorizzazione nella cache, che memorizzava il risultato solo in memoria.
È chiaro che erano necessarie persone separate e / o interi team per gestire questo zoo di tecnologie server, che ha portato alla rimozione del livello dati in un livello separato.
Importante! Tutte le tecnologie avanzate nascono nel profondo delle grandi aziende IT, quando i vecchi approcci non affrontano più le nuove sfide. La creazione di database in un livello separato non è stata inventata da nessun programmatore, ma da un gruppo di ingegneri da qualche parte nelle profondità di Oracle o IBM.
Interessante! Quando Zuckerberg ha iniziato a scrivere Facebook, ha lavorato semplicemente su PHP + MySQL. Quando c'erano milioni di utenti, scrivevano un traduttore speciale che traduceva tutto il codice PHP in C ++ e lo compilava in codice macchina nativo.
Inoltre, MySQL non è in grado di archiviare i dati di miliardi di utenti, quindi Facebook ha sviluppato il concetto di database NoSQL e ha scritto un potente DBMS NoSQL lato server - Cassandra. A proposito, è completamente scritto in Java.
Ambiguità della posizione della logica dell'applicazione
E sebbene un'architettura a tre livelli distribuisca in modo quasi inequivocabile i ruoli tra le sue parti, non è sempre possibile determinare correttamente esattamente dove nel sistema deve essere aggiunta una nuova parte della logica aziendale (nuovo codice).
Un esempio di tale ambiguità è mostrato nella figura seguente:
La parte del server è riempita con uno sfondo grigio, la parte del client è riempita di bianco. Un buon esempio di quest'ultimo approccio (estrema destra) sono le moderne app mobili. Il lato client (sul telefono) contiene la vista (display), la logica e i dati. E solo a volte questi dati sono sincronizzati con il server.
Un esempio dell'opzione più a sinistra è un tipico server PHP, che ha tutta la logica sul server e fornisce al client HTML già statico. Da qualche parte tra questi due estremi, si troverà il tuo progetto.
All'inizio del lavoro, dopo aver familiarizzato con il progetto, dovrai consultare i programmatori che ci lavorano sui luoghi in cui è meglio implementare la logica dell'attività successiva.
Sentiti libero di farlo. In primo luogo, non entrano nel monastero di qualcun altro con il loro statuto. In secondo luogo, sarà più facile per tutti (e anche per te) trovare il codice di cui hai bisogno nel luogo in cui ti aspetti di trovarlo.