{"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":"Pattern architettonici pratici","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ciao, Habr!<\/p>\n

<\/p>\n

Alla luce degli eventi attuali legati al coronavirus, diversi servizi online hanno registrato un aumento del carico. Ad esempio, una delle catene di distribuzione nel Regno Unito ha semplicemente chiuso il sito per gli ordini online<\/a><\/noindex>, poich\u00e9 non disponeva di risorse sufficienti. E non sempre \u00e8 possibile aumentare la capacit\u00e0 di un server semplicemente investendo in hardware pi\u00f9 potente, ma \u00e8 necessario gestire le richieste dei clienti (altrimenti andranno dai concorrenti).<\/p>\n

<\/p>\n

In questo articolo parler\u00f2 brevemente delle pratiche popolari che possono consentire di creare un servizio rapido e resiliente. Tuttavia, tra gli approcci di sviluppo, ho selezionato solo quelli che ora sono facilmente accessibili<\/strong>. Per ciascun punto, avete gi\u00e0 a disposizione librerie pronte oppure avete la possibilit\u00e0 di risolvere il problema utilizzando una piattaforma cloud.<\/p>\n

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

Scalabilit\u00e0 orizzontale<\/h1>\n

<\/p>\n

Il punto pi\u00f9 semplice e noto. In linea di massima, esistono due schemi di distribuzione del carico: la scalabilit\u00e0 orizzontale e quella verticale. Nel primo caso<\/a><\/noindex> si consente ai servizi di lavorare in parallelo, distribuendo cos\u00ec il carico tra di essi. Nel secondo<\/a><\/noindex> si ordinano server pi\u00f9 potenti o si ottimizza il codice.<\/p>\n

<\/p>\n

Per esempio, prender\u00f2 un'astrazione di un cloud storage per file, simile a OwnCloud, OneDrive e cos\u00ec via.<\/p>\n

<\/p>\n

L'immagine standard di uno schema simile \u00e8 qui sotto, ma essa dimostra solo la complessit\u00e0 del sistema. Dobbiamo trovare un modo per sincronizzare i servizi. Cosa succede se un utente salva un file dal tablet e poi vuole visualizzarlo sul telefono?<\/p>\n

<\/p>\n

\"Pattern
\nLa differenza tra gli approcci: nel ridimensionamento verticale siamo pronti ad aumentare la potenza dei nodi, mentre in quello 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 permette a diversi clienti di connettersi a vari servizi e di ricevere flussi di eventi identici. I suoi vantaggi non sono cos\u00ec evidenti per un'applicazione semplice, ma sono fondamentali (e semplici) per un servizio ad alto carico. La sua essenza \u00e8 che i flussi di dati in entrata e in uscita non devono sovrapporsi. In altre parole, non puoi inviare una richiesta e aspettarti una risposta; invece, invii una richiesta al servizio A e ricevi una risposta nel servizio B.<\/p>\n

<\/p>\n

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

<\/p>\n

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

    <\/p>\n

    Immaginiamo che al punto 2 si sia verificata un'interruzione della connessione (o la rete ha riavviato la connessione, o l'utente \u00e8 passato a 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 un po' diversa:<\/p>\n

    <\/p>\n

      \n
    1. Il cliente si \u00e8 iscritto agli aggiornamenti.<\/li>\n
    2. Il cliente 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 \"1\".<\/li>\n<\/ol>\n

      <\/p>\n

      \"Pattern<\/p>\n

      <\/p>\n

      Come si pu\u00f2 vedere, lo schema \u00e8 leggermente pi\u00f9 complesso. Inoltre, l'approccio intuitivo request-response qui \u00e8 assente. 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 realmente connesso al servizio da pi\u00f9 dispositivi (ad esempio, da un telefono cellulare e da un tablet), \u00e8 possibile fare in modo che la risposta arrivi a entrambi i dispositivi.<\/p>\n

      <\/p>\n

      \u00c8 interessante notare che il codice per gestire i messaggi in arrivo diventa simile (non al 100%) sia per gli eventi influenzati dal cliente stesso, sia per gli altri eventi, inclusi quelli provenienti da altri clienti.<\/p>\n

      <\/p>\n

      Tuttavia, nella realt\u00e0, otteniamo ulteriori vantaggi poich\u00e9 il flusso unidirezionale pu\u00f2 essere gestito in uno stile funzionale (utilizzando RX e analoghi). Questo \u00e8 un vantaggio significativo, poich\u00e9 in sostanza l'applicazione pu\u00f2 essere realizzata in modo completamente reattivo, utilizzando anche un approccio funzionale. Per le applicazioni pi\u00f9 complesse, questo pu\u00f2 ridurre notevolmente le risorse necessarie per lo sviluppo e la manutenzione.<\/p>\n

      <\/p>\n

      Se si combina questo approccio con la scalabilit\u00e0 orizzontale, otteniamo anche la possibilit\u00e0 di inviare richieste a un server e ricevere risposte da un altro. In questo modo, il cliente pu\u00f2 scegliere il servizio pi\u00f9 conveniente per lui, mentre il sistema interno riesce comunque a 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 un tempo comune e di una sezione critica condivisa. Per un singolo processo, potete eseguire la sincronizzazione (sugli stessi mutex), all'interno della quale siete certi che nessun altro stia eseguendo quel codice. Tuttavia, per un sistema distribuito, ci\u00f2 \u00e8 pericoloso, poich\u00e9 comporta delle spese generali e compromette l'intero vantaggio della scalabilit\u00e0: tutti i componenti dovranno comunque aspettare uno.<\/p>\n

      <\/p>\n

      Da ci\u00f2 deriva un fatto importante: un sistema distribuito veloce non pu\u00f2 essere sincronizzato, altrimenti ridurremo le prestazioni. D'altra parte, spesso \u00e8 necessaria una certa coerenza dei componenti. Per questo motivo, si pu\u00f2 adottare l'approccio della eventual consistency<\/a><\/noindex>, dove si garantisce che, in assenza di modifiche ai dati, dopo un certo intervallo di tempo dall'ultimo aggiornamento (\u00abin fin dei conti\u00bb), tutte le richieste restituiranno l'ultimo valore aggiornato.<\/p>\n

      <\/p>\n

      \u00c8 importante comprendere che per i database classici si applica spesso coerenza rigorosa<\/a><\/noindex>, dove ogni nodo possiede le stesse informazioni (questo si ottiene spesso quando una transazione \u00e8 considerata stabilita solo dopo la risposta del secondo server). Ci sono alcune eccezioni dovute ai livelli di isolamento, ma il concetto generale rimane lo stesso: puoi vivere in un mondo completamente coerente.<\/p>\n

      <\/p>\n

      Tornando quindi al compito iniziale. Se una parte del sistema pu\u00f2 essere costruita con eventual consistency<\/a><\/noindex>, si pu\u00f2 costruire il seguente schema.<\/p>\n

      <\/p>\n

      \"Pattern<\/p>\n

      <\/p>\n

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

      <\/p>\n