{"id":80035,"date":"2020-05-02T13:42:54","date_gmt":"2020-05-02T11:42:54","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/udobnye-arhitekturnye-patterny"},"modified":"2020-05-02T13:42:54","modified_gmt":"2020-05-02T11:42:54","slug":"udobnye-arhitekturnye-patterny","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/udobnye-arhitekturnye-patterny","title":{"rendered":"Modelli architetturali pratici","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ciao, Habr!<\/p>\n

<\/p>\n

Alla luce degli attuali eventi legati al coronavirus, molti servizi online hanno registrato un aumento del carico di lavoro. Ad esempio, una delle catene di distribuzione nel Regno Unito ha semplicemente arrestato il sito per gli ordini online<\/a><\/noindex>, poich\u00e9 non c'erano sufficienti risorse. E non \u00e8 sempre possibile aumentare la potenza del server semplicemente aggiungendo hardware pi\u00f9 potente, tuttavia \u00e8 necessario gestire le richieste dei clienti (o passeranno ai concorrenti).<\/p>\n

<\/p>\n

In questo articolo parler\u00f2 brevemente delle pratiche popolari che consentono di creare un servizio veloce e resistente ai guasti. Tuttavia, tra le possibili schemi di sviluppo, ho selezionato solo quelli che attualmente sono facili da usare<\/strong>. Per ciascun punto, avete gi\u00e0 a disposizione librerie pronte o avete la possibilit\u00e0 di risolvere il problema tramite una piattaforma cloud.<\/p>\n

<\/a><\/noindex><\/p>\n

Scalabilit\u00e0 orizzontale<\/h1>\n

<\/p>\n

Il punto pi\u00f9 semplice e noto a tutti. In generale, le due modalit\u00e0 di distribuzione del carico che si incontrano pi\u00f9 frequentemente sono la scalabilit\u00e0 orizzontale e verticale. Nel primo caso<\/a><\/noindex> consentite ai servizi di lavorare in parallelo, distribuendo cos\u00ec il carico tra di essi. Nel secondo<\/a><\/noindex> ordinate server pi\u00f9 potenti o ottimizzate il codice.<\/p>\n

<\/p>\n

Per esempio, prendo come riferimento un'astratta soluzione di archiviazione cloud, cio\u00e8 un qualche equivalente di OwnCloud, OneDrive e cos\u00ec via.<\/p>\n

<\/p>\n

L'immagine standard di tale schema \u00e8 qui sotto, tuttavia essa dimostra solo la complessit\u00e0 del sistema. Dobbiamo infatti sincronizzare i servizi in qualche modo. Cosa succede se un utente ha salvato un file sul tablet e poi vuole visualizzarlo sul telefono?<\/p>\n

<\/p>\n

\"Modelli
\nLa differenza tra gli approcci: nella scalabilit\u00e0 verticale siamo disposti ad aumentare la potenza dei nodi, mentre in quella orizzontale aggiungiamo nuovi nodi per distribuire il carico.<\/p>\n

<\/p>\n

CQRS<\/h1>\n

<\/p>\n

Command Query Responsibility Segregation<\/a><\/noindex> \u00e8 un pattern piuttosto importante, poich\u00e9 consente a diversi clienti non solo di connettersi a diversi servizi, ma anche di ricevere flussi di eventi identici. I suoi vantaggi non sono cos\u00ec evidenti per una semplice applicazione, tuttavia \u00e8 estremamente importante (e semplice) per un servizio carico. La sua essenza: i flussi di dati in entrata e in uscita non devono incrociarsi. Questo significa che non puoi inviare una richiesta e aspettarti una risposta; invece, invii una richiesta al servizio A, ma ricevi la risposta nel servizio B.<\/p>\n

<\/p>\n

Il primo vantaggio di questo approccio \u00e8 la possibilit\u00e0 di interrompere la connessione (in senso ampio) durante l'esecuzione di una lunga richiesta. Prendiamo come esempio una sequenza pi\u00f9 o meno standard:<\/p>\n

<\/p>\n

    \n
  1. Il client ha inviato una richiesta al server.<\/li>\n
  2. Il server ha avviato un'elaborazione lunga.<\/li>\n
  3. Il server ha risposto al client con il risultato.<\/li>\n<\/ol>\n

    <\/p>\n

    Immaginiamo che nel punto 2 ci sia stata un'interruzione della connessione (o la rete si \u00e8 riconnessa, o l'utente ha navigato su un'altra pagina, interrompendo la connessione). In questo caso, sar\u00e0 difficile per il server inviare una risposta all'utente con le informazioni su cosa sia stato elaborato. Applicando CQRS, la sequenza sar\u00e0 leggermente diversa:<\/p>\n

    <\/p>\n

      \n
    1. Il client si \u00e8 iscritto per ricevere aggiornamenti.<\/li>\n
    2. Il client ha inviato una richiesta al server.<\/li>\n
    3. Il server ha risposto 'richiesta ricevuta'.<\/li>\n
    4. Il server ha risposto con il risultato attraverso il canale del punto '1'.<\/li>\n<\/ol>\n

      <\/p>\n

      \"Modelli<\/p>\n

      <\/p>\n

      Come si pu\u00f2 notare, lo schema \u00e8 leggermente pi\u00f9 complesso. Inoltre, l'approccio intuitivo di richiesta-risposta \u00e8 assente qui. Tuttavia, come si pu\u00f2 notare, l'interruzione della connessione durante l'elaborazione della richiesta non porter\u00e0 a un errore. Inoltre, se l'utente \u00e8 effettivamente connesso al servizio da pi\u00f9 dispositivi (ad esempio, da un telefono cellulare e da un tablet), \u00e8 possibile far s\u00ec che la risposta arrivi a entrambi i dispositivi.<\/p>\n

      <\/p>\n

      Ci\u00f2 che \u00e8 interessante \u00e8 che il codice per elaborare i messaggi in arrivo diventa simile (non al 100%) sia per gli eventi influenzati dal client stesso, sia per gli altri eventi, compresi quelli di altri clienti.<\/p>\n

      <\/p>\n

      Tuttavia, nella realt\u00e0 otteniamo vantaggi aggiuntivi poich\u00e9 il flusso unidirezionale pu\u00f2 essere elaborato in modo funzionale (utilizzando RX e analoghi). E questo \u00e8 gi\u00e0 un grande vantaggio, poich\u00e9 in sostanza l'applicazione pu\u00f2 diventare completamente reattiva, e ancor di pi\u00f9 grazie all'approccio funzionale. Per le applicazioni<\/p>\n

      <\/p>\n

      Se si combina questo approccio con la scalabilit\u00e0 orizzontale, il vantaggio \u00e8 di poter inviare richieste a un server e ricevere risposte da un altro. In questo modo, il client pu\u00f2 scegliere il servizio pi\u00f9 conveniente per lui, mentre il sistema interno sar\u00e0 comunque in grado di gestire correttamente gli eventi.<\/p>\n

      <\/p>\n

      Event Sourcing<\/h1>\n

      <\/p>\n

      Come sapete, una delle caratteristiche principali di un sistema distribuito \u00e8 l'assenza di tempo comune e di una sezione critica comune. Per un processo, \u00e8 possibile effettuare la sincronizzazione (sugli stessi mutex), all'interno della quale si \u00e8 certi che nessun altro stia eseguendo quel codice. Tuttavia, per un sistema distribuito, ci\u00f2 \u00e8 pericoloso, poich\u00e9 richieder\u00e0 delle sovraccarichi e si perder\u00e0 tutto il fascino della scalabilit\u00e0: comunque tutti i componenti dovranno aspettare uno.<\/p>\n

      <\/p>\n

      Da qui otteniamo un fatto importante: un sistema distribuito veloce non pu\u00f2 essere sincronizzato, poich\u00e9 ci\u00f2 ridurrebbe le prestazioni. D'altra parte, spesso abbiamo bisogno di una certa coerenza dei componenti. E per questo possiamo utilizzare l'approccio con coerenza finale<\/a><\/noindex>, dove \u00e8 garantito che, in assenza di modifiche ai dati, dopo un certo intervallo di tempo dall'ultimo aggiornamento (\u00abin definitiva\u00bb) tutte le richieste restituiranno l'ultimo valore aggiornato.<\/p>\n

      <\/p>\n

      \u00c8 importante comprendere che per i database classici si applica abbastanza spesso coerenza rigorosa<\/a><\/noindex>, dove ogni nodo possiede la stessa informazione (ci\u00f2 si ottiene spesso quando una transazione \u00e8 considerata stabilita solo dopo la risposta di un secondo server). Qui ci sono alcune concessioni a causa dei livelli di isolamento, tuttavia il concetto generale rimane lo stesso: si pu\u00f2 vivere in un mondo completamente coerente.<\/p>\n

      <\/p>\n

      Tornando per\u00f2 all'obiettivo iniziale. Se una parte del sistema pu\u00f2 essere costruita con coerenza finale<\/a><\/noindex>, allora si pu\u00f2 costruire il seguente schema.<\/p>\n

      <\/p>\n

      \"Modelli<\/p>\n

      <\/p>\n

      Caratteristiche importanti di questo approccio:<\/p>\n

      <\/p>\n