{"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":"Costruzione di blocchi per 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 sul design dei sistemi di servizi di massa: \u201cEsperimento VTrade\u201d \u2014 un tentativo di scrivere un framework per sistemi di trading. Nel ciclo verr\u00e0 esaminata sia la teoria che la pratica della creazione di una borsa, un'asta e un negozio. Alla fine dell'articolo invito a votare per gli argomenti che vi interessano di pi\u00f9.
\n<\/em><\/p>\n

<\/p>\n

\"Costruzione<\/p>\n

<\/p>\n

Questo \u00e8 l'ultimo articolo del ciclo sulle applicazioni reattive distribuite in Erlang\/Elixir. Nel primo articolo<\/a><\/noindex> si possono trovare le basi teoriche dell'architettura reattiva. Secondo articolo<\/a><\/noindex> illustra i principali modelli e meccanismi per la costruzione di sistemi simili.<\/p>\n

<\/p>\n

Oggi affronteremo questioni relative allo sviluppo del codice e ai progetti nel loro complesso. <\/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 in un unico controller. Ad esempio, il servizio users, che gestisce i profili degli utenti del progetto, deve rispondere alle richieste req-resp e informare sugli aggiornamenti dei profili tramite pub-sub. Questo caso \u00e8 piuttosto semplice: a gestire il messaging c'\u00e8 un singolo controller che implementa la logica del servizio e pubblica gli aggiornamenti.<\/p>\n

<\/p>\n

La situazione si complica quando dobbiamo realizzare un servizio distribuito e a prova di guasto. Immaginiamo che i requisiti per users siano cambiati: <\/p>\n

<\/p>\n

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

    <\/p>\n

    Nota:<\/em> Non consideriamo la questione della conservazione e replicazione consistente dei dati. Presumiamo che queste questioni siano state risolte in precedenza e che nella sistema esista gi\u00e0 uno strato di memorizzazione affidabile e scalabile, mentre i gestori hanno meccanismi per interagire con esso.<\/p>\n

    <\/p>\n

    La descrizione formale del servizio utenti \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 presso il punto di scambio req-resp. <\/p>\n

    <\/p>\n

    La necessit\u00e0 di gestire i compiti in background si presenta frequentemente. Nel contesto degli utenti, questo pu\u00f2 includere controlli sui documenti degli utenti, elaborazione di multimedia caricato o sincronizzazione dei dati con i social media. Queste attivit\u00e0 devono essere distribuite all'interno del cluster e monitorate. Pertanto, abbiamo due opzioni: utilizzare il modello di distribuzione dei compiti dell'articolo precedente, oppure, se non si adatta, scrivere un pianificatore di compiti personalizzato che gestisca il pool di elaboratori nel modo necessario. <\/p>\n

    <\/p>\n

    Il punto 3 richiede l'espansione del modello pub-sub. Per implementarlo, dopo aver creato il punto di scambio pub-sub, dobbiamo anche avviare un controller di quel punto all'interno del nostro servizio. In questo modo, sembrerebbe che trasferiamo la logica di gestione dell'iscrizione e delle disiscrizioni dallo strato messaging all'implementazione degli utenti.<\/p>\n

    <\/p>\n

    Di conseguenza, la scomposizione del compito ha mostrato che per soddisfare i requisiti dobbiamo avviare 5 istanze del servizio su diversi nodi e creare un'entit\u00e0 aggiuntiva: un controller pub-sub, responsabile dell'iscrizione.
    \nPer avviare 5 gestori non \u00e8 necessario modificare il codice del servizio. L'unica azione aggiuntiva \u00e8 configurare le regole di bilanciamento al punto di scambio, di cui parleremo pi\u00f9 avanti.
    \nSi \u00e8 presentata anche un'ulteriore complessit\u00e0: il controller pub-sub e il pianificatore di attivit\u00e0 personalizzato devono funzionare in un'unica istanza. Ancora una volta, il servizio messaging, in quanto fondamentale, deve fornire un meccanismo di leadership.<\/p>\n

    <\/p>\n

    Scelta del leader<\/h3>\n

    <\/p>\n

    Nei sistemi distribuiti, la selezione di un leader \u00e8 la procedura di designazione di un unico processo responsabile della pianificazione dell'elaborazione distribuita di un certo carico. <\/p>\n

    <\/p>\n

    Nei sistemi che non tendono alla centralizzazione, si applicano algoritmi generali e algoritmi basati sul consenso, come Paxos o Raft.
    \nPoich\u00e9 il messaging funge da broker e elemento centrale, \u00e8 a conoscenza di tutti i controller del servizio che sono candidati a diventare leader. Il messaging pu\u00f2 nominare 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> corrisponda al pid<\/code> processo attuale, viene nominato leader e l'elenco Servers<\/code> include tutti i nodi e i loro parametri.
    \nNel momento in cui appare un nuovo nodo e uno funzionante viene disattivato nel 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 \u00e8 garantito un solo leader in ogni momento.<\/p>\n

    <\/p>\n

    Intermediari<\/h2>\n

    <\/p>\n

    Per implementare processi distribuiti complessi e ottimizzare l'architettura esistente, \u00e8 utile utilizzare intermediari.
    \nPer non dover modificare il codice dei servizi e affrontare, ad esempio, la registrazione o la logistica dei messaggi, \u00e8 possibile inserire un gestore proxy davanti al servizio, che eseguir\u00e0 tutto il lavoro aggiuntivo.<\/p>\n

    <\/p>\n

    Un classico esempio di ottimizzazione pub-sub \u00e8 un'applicazione distribuita con un core di business che genera eventi di aggiornamento, come ad esempio una variazione del prezzo sul mercato, e uno strato di accesso costituito da N server che forniscono un'API websocket per i clienti web.
    \nSe affrontiamo il problema in modo diretto, la gestione del cliente appare nel seguente modo:<\/p>\n

    <\/p>\n