Architettura client-server

1.1 Architettura dell'applicazione

Questo corso è progettato per i principianti, perché non progetterai l'architettura di un'applicazione seria per molto tempo. Ma non preoccuparti, la buona architettura è l'eccezione piuttosto che la regola. È molto difficile scegliere la giusta architettura dell'applicazione prima di creare l'applicazione.

Esempi di architetture popolari per applicazioni server di grandi dimensioni:

• Architettura a strati (Architettura a strati).
• Architettura a livelli.
• Architettura orientata ai servizi (SOA).
• Architettura dei microservizi (Microservice Architecture).

Ognuno di loro ha i suoi pro e contro. Ma studiarli non ti darà nulla. L'architettura è la risposta alla domanda "come organizzare l'interazione di migliaia di oggetti all'interno del sistema" . E finché non sperimenterai tutta la complessità del problema, non sarai in grado di comprendere la piena versatilità della soluzione.

Tutte le applicazioni utilizzano un qualche tipo di architettura, o almeno fingono di farlo. Pertanto, la conoscenza degli approcci popolari alla progettazione dell'applicazione ti consentirà di comprendere rapidamente e meglio come funziona l'applicazione. E questo significa apportare modifiche esattamente dove ne hai bisogno.

Cosa significa "apportare modifiche dove necessario"? Ci sono luoghi in cui non è necessario apportare modifiche? Esattamente.

Per essere precisi, supponiamo che tu stia lavorando a un progetto di backend medio . È stato scritto per 5 anni da un team di 20 persone. Il progetto ha richiesto 100 anni uomo e contiene circa 100mila righe di codice. In totale, è composto da duemila classi, suddivise in 10 moduli di diverse dimensioni.

E aggiungi una dura realtà. La logica di alcuni compiti è distribuita su più moduli. Inoltre, la business logic può essere nel frontend (scritta in JavaScript) e/o scritta come stored procedure direttamente nel database. Sei ancora sicuro di poter determinare immediatamente il luogo esatto in cui apportare le modifiche ?

Questo non è un incubo che ho inventato per spaventarti. Questo è un progetto tipico. Succede anche peggio. Perché sta succedendo? Ci possono essere molte ragioni, ma quasi sempre ce ne sono:

• Molte persone lavorano al progetto, ognuna di loro lo vede in modo leggermente diverso.
• Per 5 anni, 10 persone sono cambiate nel progetto, i nuovi arrivati ​​\u200b\u200bnon l'hanno capito molto.
• La creazione di software è un costante apportare modifiche che cambiano costantemente tutto.
• Cinque anni fa, quando abbiamo deciso l'architettura, l'idea del progetto era un po' diversa.

Ma la cosa principale è che, indipendentemente dall'architettura del progetto, tutti i programmatori che ci lavorano hanno aderito alla stessa comprensione di come funziona questo progetto. Cominciamo con il concetto più semplice: l'architettura client-server.

1.2 Il concetto di interazione client-server

Ora capiremo il concetto che sta alla base dell'architettura client-server e ti permetterà di capire meglio come è organizzata l'interazione di milioni di programmi su Internet.

Come suggerisce il nome, questo concetto coinvolge due parti: client e server . Tutto è come nella vita qui: il cliente è il cliente di questo o quel servizio e il server è il fornitore di servizi. Il client e il server sono fisicamente programmi , per esempio un tipico client è un browser .

I seguenti esempi possono essere forniti come server:

• Server Web come Tomcat.
• Server di database come MySQL.
• Gateway di pagamento come Stripe.

Il client e il server di solito comunicano tramite Internet (sebbene possano funzionare nella stessa rete locale e in generale in qualsiasi altro tipo di rete). La comunicazione avviene tramite protocolli standard come HTTP, FTP o protocolli di livello inferiore come TCP o UDP.

Il protocollo viene solitamente scelto in base al tipo di servizio fornito dai server. Ad esempio, se si tratta di una videochiamata, di solito viene utilizzato UDP.

Ricordi come funzionano Tomcat e i suoi servlet? Il server riceve un messaggio HTTP, lo decomprime, estrae tutte le informazioni necessarie da lì e le passa al servlet per l'elaborazione. Quindi il risultato dell'elaborazione viene nuovamente impacchettato in una risposta HTTP e inviato al client.

Questa è la tipica interazione client-server. Il browser è il client web e Tomcat è il server web. Tomcat è anche chiamato un server web.

Ma se ci pensi, non è importante il nome, ma l'essenza: la distribuzione dei ruoli tra i programmi. Il tuo script JS in esecuzione in una pagina HTML potrebbe essere chiamato un client e il tuo servlet un server . Dopotutto, lavorano in coppia nell'ambito del concetto client-server .

1.3 Una sfumatura importante

Vale anche la pena notare che l'interazione client-server si basa sul principio che tale interazione è avviata dal client : il server risponde solo al client e comunica se può fornire il servizio al client e, in tal caso, a quali condizioni .

Non importa dove si trova fisicamente il client e dove si trova il server. Il software client e il software server sono generalmente installati su macchine diverse, ma possono anche essere eseguiti sullo stesso computer.

Questo concetto è stato sviluppato come primo passo verso la semplificazione di un sistema complesso. Ha questi punti di forza:

• Semplificazione logica : il server non sa nulla del client e di come utilizzerà i suoi dati in futuro.
• Potrebbero esserci client deboli : tutte le attività ad alta intensità di risorse possono essere trasferite al server.
• Sviluppo indipendente di codice client e codice server.
• Molti client diversi, ad esempio Tomcat e diversi browser.

La versione più semplice dell'interazione tra il client e il server è mostrata nell'immagine:

È importante notare due dettagli qui. Innanzitutto, l'immagine mostra che molti client possono accedere a un server. In secondo luogo, possono accedervi contemporaneamente. Anche questa è una parte importante del server.

Un client di solito interagisce con un utente, quindi spesso non è necessaria nemmeno l'autorizzazione. Tuttavia, il server elabora le richieste di migliaia di client e, durante lo sviluppo del codice, è necessario essere in grado di distinguere tra autorizzazione e autenticazione.

È anche importante che il server elabori migliaia di richieste in parallelo. Ciò significa che durante lo sviluppo del codice di back-end, dovrai costantemente pensare all'attività di accesso simultaneo alle risorse. Inoltre, il codice del server ha un'altissima probabilità di race condition (thread race), deadlock (blocco reciproco dei thread).

Il ciclo di vita degli oggetti importanti deve essere monitorato:

Non puoi semplicemente avviare un nuovo thread sul server tramite new Thread().start(). Invece, devi avere un ThreadPool che condividerà tra tutti i thread del servizio.

Inoltre, non puoi semplicemente avviare un'attività asincrona, perché vengono eseguite anche in thread separati. Quando crei un'attività di questo tipo, dovresti sempre sapere quale pool di thread lo sta eseguendo e cosa accadrà se tale pool va in overflow.

Tutto il lavoro con file e directory deve essere eseguito tramite try-with-resources. Se in una normale applicazione hai dimenticato di chiudere uno stream o un file, è un problema? Si chiuderà automaticamente quando esci dal programma. Ma se hai dimenticato di chiudere un file sul server da qualche parte nel codice e il tuo server è in esecuzione da mesi ... Presto si accumuleranno migliaia di tali file non chiusi e il sistema operativo smetterà di aprire nuovi file per la lettura (lavora con i file è controllato dal sistema operativo). Il caposquadra non ti darà una pacca sulla testa...

1.4 Architettura client-server

altro punto importante. L'architettura client-server definisce solo i principi generali dell'interazione tra computer , i dettagli dell'interazione sono determinati da vari protocolli.

Questo concetto (client-server) ci dice che dobbiamo dividere le macchine sulla rete in macchine client, che hanno sempre bisogno di qualcosa, e macchine server, che danno ciò di cui hanno bisogno. In questo caso, il client avvia sempre l'interazione e le regole con cui avviene l'interazione sono descritte dal protocollo.

Esistono due tipi di architettura di interazione client-server: la prima è chiamata architettura client-server a due livelli, la seconda è l'architettura client-server multilivello (a volte chiamata architettura a tre livelli o architettura a tre livelli, ma questo è un caso particolare).

Il principio di funzionamento dell'architettura a due livelli dell'interazione client-server è che l'elaborazione di una richiesta avviene su un server senza fare riferimento ad altri server nel processo di questa elaborazione.

Il modello di interazione client-server a due livelli può essere disegnato come un semplice diagramma.

Qui puoi vedere che il primo livello è tutto ciò che riguarda il client e il secondo livello è tutto ciò che riguarda il server.