{"id":31124,"date":"2019-10-31T21:39:36","date_gmt":"2019-10-31T18:39:36","guid":{"rendered":"https:\/\/prohoster.info\/blog\/stroitelnye-bloki-raspredelennyh-prilozhenij-vtoroe-priblizhenie\/"},"modified":"2019-10-31T21:39:36","modified_gmt":"2019-10-31T18:39:36","slug":"stroitelnye-bloki-raspredelennyh-prilozhenij-vtoroe-priblizhenie","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/stroitelnye-bloki-raspredelennyh-prilozhenij-vtoroe-priblizhenie","title":{"rendered":"Blocchi fondamentali delle applicazioni distribuite. Secondo approccio","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Annuncio<\/strong><\/p>\n

<\/p>\n

Colleghi, a met\u00e0 estate prevedo di pubblicare un altro ciclo di articoli sulla progettazione di sistemi di assistenza di massa: \u201cEsperimento VTrade\u201d \u2014 un tentativo di scrivere un framework per i sistemi di trading. Il ciclo analizzer\u00e0 la teoria e la pratica della costruzione di borse, aste e negozi. Alla fine dell'articolo vi invito a votare per gli argomenti che trovate pi\u00f9 interessanti.
\n<\/em><\/p>\n

<\/p>\n

\"Blocchi<\/p>\n

<\/p>\n

Questo \u00e8 l'articolo conclusivo del ciclo sulle applicazioni reattive distribuite in Erlang\/Elixir. In articolo precedente<\/a><\/noindex> possiamo trovare le basi teoriche dell'architettura reattiva. Il secondo articolo<\/a><\/noindex> illustra i principali modelli e meccanismi di costruzione di tali sistemi.<\/p>\n

<\/p>\n

Oggi affronteremo le questioni relative all'evoluzione del codice e dei progetti in generale. <\/p>\n

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

Organizzazione dei servizi<\/h2>\n

<\/p>\n

Nella vita reale, durante lo sviluppo di un servizio, spesso \u00e8 necessario combinare diversi modelli di interazione all'interno di un unico controller. Ad esempio, il servizio users, che si occupa della gestione dei profili degli utenti del progetto, deve rispondere a richieste req-resp e comunicare aggiornamenti sui profili tramite pub-sub. Questo caso \u00e8 piuttosto semplice: per il messaging c'\u00e8 un unico controller che implementa la logica del servizio e pubblica aggiornamenti.<\/p>\n

<\/p>\n

La situazione si complica quando dobbiamo implementare un servizio distribuito resistente ai guasti. Immaginiamo che i requisiti per users siano cambiati: <\/p>\n

<\/p>\n

    \n
  1. ora il servizio deve elaborare richieste su 5 nodi del cluster, <\/li>\n
  2. essere in grado di eseguire compiti in background, <\/li>\n
  3. nonch\u00e9 gestire dinamicamente gli elenchi di iscrizione agli aggiornamenti dei profili.<\/li>\n<\/ol>\n

    <\/p>\n

    Nota:<\/em> Non consideriamo la questione della memorizzazione coerente e della replica dei dati. Supponiamo che queste problematiche siano state risolte in precedenza e che nel sistema esista gi\u00e0 uno strato di archiviazione affidabile e scalabile, e che i gestori abbiano meccanismi di interazione con esso.<\/p>\n

    <\/p>\n

    La descrizione formale del servizio users \u00e8 diventata pi\u00f9 complessa. Dal punto di vista del programmatore, grazie all'uso del messaging, le modifiche sono minime. Per soddisfare il primo requisito, dobbiamo configurare il bilanciamento nel punto di scambio req-resp. <\/p>\n

    <\/p>\n

    La necessit\u00e0 di elaborare compiti in background si presenta spesso. In users possono esserci controlli sui documenti degli utenti, elaborazione di media caricati o sincronizzazione dei dati con i social network. Questi compiti devono essere distribuiti in qualche modo all'interno del cluster e monitorati nel loro espletamento. Pertanto, abbiamo due opzioni per la risoluzione: o utilizzare il modello di distribuzione dei compiti dell'articolo precedente, o, se non va bene, scrivere un pianificatore di compiti personalizzato che gestisca il pool di elaboratori nel modo necessario. <\/p>\n

    <\/p>\n

    Il punto 3 richiede un'estensione del modello pub-sub. E per l'implementazione, dopo aver creato il punto di scambio pub-sub, \u00e8 necessario avviare ulteriormente il controller di questo punto all'interno del nostro servizio. In questo modo, estraiamo logica di elaborazione delle iscrizioni e disiscrizioni dallo strato di messaging nella realizzazione di users.<\/p>\n

    <\/p>\n

    Di conseguenza, la scomposizione del compito ha mostrato che per soddisfare i requisiti \u00e8 necessario avviare 5 istanze del servizio su nodi diversi e creare un ulteriore entit\u00e0: un controller pub-sub responsabile dell'iscrizione.
    \nPer avviare 5 elaboratori non \u00e8 necessario modificare il codice del servizio. L'unica azione aggiuntiva \u00e8 la configurazione delle regole di bilanciamento sul punto di scambio, di cui parleremo pi\u00f9 avanti.
    \n\u00c8 emersa anche una difficolt\u00e0 aggiuntiva: il controller pub-sub e il pianificatore di compiti personalizzato devono operare in una singola istanza. Ancora una volta, il servizio messaging, come fondamentale, deve fornire un meccanismo di scelta del leader.<\/p>\n

    <\/p>\n

    Scelta del leader<\/h3>\n

    <\/p>\n

    Nelle sistemazioni distribuite, la scelta del leader \u00e8 una procedura di designazione di un unico processo responsabile della pianificazione dell'elaborazione distribuita di qualche carico. <\/p>\n

    <\/p>\n

    Nei sistemi non soggetti a centralizzazione, vengono applicati algoritmi universali e algoritmi basati su consenso, ad esempio paxos o raft.
    \nPoich\u00e9 messaging \u00e8 un broker e un elemento centrale, conosce tutti i controller del servizio - candidati al ruolo di leader. Messaging pu\u00f2 designare un leader senza alcuna votazione.<\/p>\n

    <\/p>\n

    Tutti i servizi, dopo l'avvio e la connessione al punto di scambio, ricevono un messaggio di sistema #'$leader'{exchange = ?EXCHANGE, pid = LeaderPid, servers = Servers}<\/code>. Nel caso in cui LeaderPid<\/code> corrisponde a pid<\/code> del processo corrente, viene designato come leader, e l'elenco Servers<\/code> include tutti i nodi e i loro parametri.
    \nNel momento in cui compare un nuovo nodo e si disconnette un nodo funzionante del cluster, tutti i controller del servizio ricevono #'$slave_up'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts}<\/code> e #'$slave_down'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts}<\/code> rispettivamente.<\/p>\n

    <\/p>\n

    In questo modo, tutti i componenti sono a conoscenza di tutte le modifiche, e nel cluster, in ogni momento, \u00e8 garantito che ci sia un solo leader.<\/p>\n

    <\/p>\n

    Intermediari<\/h2>\n

    <\/p>\n

    Per implementare processi di elaborazione distribuiti complessi e per ottimizzare l'architettura esistente \u00e8 conveniente utilizzare degli intermediari.
    \nPer evitare di modificare il codice dei servizi e risolvere, ad esempio, compiti di elaborazione aggiuntiva, instradamento o registrazione dei messaggi, \u00e8 possibile inserire un gestore proxy davanti al servizio, che eseguir\u00e0 tutto il lavoro aggiuntivo.<\/p>\n

    <\/p>\n

    Un esempio classico di ottimizzazione pub-sub \u00e8 un'applicazione distribuita con un core aziendale che genera eventi di aggiornamento, come ad esempio il cambiamento dei prezzi sul mercato, e uno strato di accesso \u2014 N server che forniscono API websocket per i client web.
    \nSe risolviamo la questione 'direttamente', il servizio al cliente appare nel modo seguente:<\/p>\n

    <\/p>\n