Sistemi distribuiti 101

I sistemi distribuiti ci circondano: Fb, Uber, Revolut – anche il motore di ricerca di Google è uno di questi. Una ricerca in Google può attivare decine (o centinaia) di chiamate a diversi microservizi di proprietà di Google.

Inoltre, sono il nucleo di ciò con cui lavoriamo: più servizi che lavorano insieme, o forse un database, o solo un servizio o due con alcuni livelli di cache o persino un servizio che si collega tramite una coda di messaggi asincroni.

Tutti condividono tratti e problemi simili. In questo testo, cercherò di descrivere almeno il più comune di questi problemi: cosa sono, come possono avere un impatto sul tuo sistema e come puoi potenzialmente mitigarli.

Cominciamo con una definizione di sistemi distribuiti.

Quali sono i sistemi distribuiti?

E l’argomento diventa complicato dall’inizio, perché ci sono più risposte a questa domanda. Per quanto ne so, ce ne sono almeno tre diversi e quasi tutti quelli che scrivono un libro sull’argomento hanno il proprio approccio.

Di sicuro, non sono disposto advert aggiungerne un altro all’elenco. Invece, vorrei sottolineare che tutte queste definizioni descrivono sistemi che condividono alcuni tratti comuni:

• Distribuzione (hehehe) – Il sistema è diviso su più di un nodo, di solito molto più di questo
• Comunicazione – Nodi diversi nel sistema comunicano tra loro in modo asincrono o sincrono
• Cooperazione – I nodi nel sistema lavorano insieme verso un obiettivo comune, come permetterti di ordinare il tuo viaggio nel caso di Uber

Per quanto riguarda la definizione esatta, secondo me, il più vecchio e il più divertente è il migliore. Citando Leslie Lamport, un uomo con un impatto enorme su come appare il panorama dei sistemi distribuiti:

Un sistema distribuito è quello in cui il fallimento di un laptop che non sapevi nemmeno esistesse può rendere inutilizzabile il tuo laptop.

Questa definizione, sebbene in qualche modo divertente, descrive perfettamente un aspetto chiave dei sistemi distribuiti – o in realtà qualsiasi sistema creato utilizzando un’architettura di microservizi. Cooperazione verso l’obiettivo comune e dividere su più nodi.

Sfide chiave nei sistemi distribuiti

Come potresti vedere, mentre le definizioni possono essere ambigue, ci sono alcuni tratti che descrivono ogni sistema distribuito. Lo stesso vale per le sfide relative ai sistemi distribuiti. Ci sono alcuni problemi chiave che incontrerai prima o poi mentre lavori con questa classe di sistemi.

Disponibilità

Nei tempi attuali, mentre ogni millisecondo di ritardo può portare alla perdita di più dollari o migliaia di dollari, la disponibilità è probabilmente il tratto più importante che espongono i sistemi.

Disponibilità descrive come i nostri sistemi gestiscono i guasti; Determina anche il tempo di attività del sistema. Di solito, descriviamo la disponibilità di un sistema in notazione “nove”. La disponibilità del 99% garantisce un massimo di 14,40 minuti di fermo al giorno, mentre il 99,999%-i cosiddetti 5 nove-si riduce a 846 millisecondi.

La maggior parte dei servizi cloud ha un SLA con 3-5 garanzie di disponibilità di nines per gli utenti finali.

Inoltre, il termine alta disponibilità O Ah viene utilizzato per descrivere i servizi che hanno almeno 3 nines di garanzie di disponibilità.

C’è una famosa lotta legata a disponibilità e coerenza. La nozione comune è che in caso di fallimento, possiamo avere l’uno o l’altro. Mentre nella maggior parte dei casi questo è vero, l’argomento nel suo insieme è molto più sfumato e complesso. Per esempio, CRDTS mettere in discussione tutta questa affermazione; Lo stesso vale per la chiave interna di Google.

Inoltre, possiamo usare varie tecniche per bilanciare entrambi questi tratti. Inoltre, il nostro sistema può favorire l’uno rispetto all’altro in determinati luoghi, non appena in altri. Ricorda solo che questa lotta esiste ed è uno dei casi più importanti di studio nella ricerca sui sistemi distribuiti.

Quali limita la disponibilità?

• Singoli punti di fallimento -L’uso di un servizio a istanza singola o strumenti come un database è un killer di disponibilità. In caso di grave fallimento, il nostro servizio va immediatamente offline e iniziamo a bruciare denaro.
• Statale – Mentre in alcuni casi sono richiesti servizi o processi statali, dovremmo almeno limitarli il più possibile e/o ridurre il numero di servizi coinvolti nei flussi statali.
• Comunicazione sincrona – La comunicazione sincrona crea una dipendenza diretta tra i servizi. Se un lato di questa comunicazione diventa lento, la disponibilità dell’altro viene influenzata automaticamente. Allo stesso modo, come nel caso dell’elaborazione statale, se ti concentri troppo sulla comunicazione sincrona, puoi facilmente avere un impatto sulla disponibilità dell’intero sistema.

Cosa aumenta la disponibilità:

• Ridondanza – Avere più istanze di un servizio in grado di gestire le richieste in arrivo in caso di guasto. Se uno fallisce, l’altro può facilmente prendere il sopravvento e continuare a fare il lavoro.
• Failover automatico – Il passaggio a un’istanza sana di un database o altro servizio in caso di guasto non fornirà tempi di inattività.

Scalabilità

Questa proprietà descrive la prontezza di un sistema per gestire un aumento del carico. Migliore è la riduzione del sistema, più richieste in arrivo simultanee possono elaborare prima che gli utenti inizino a notare qualsiasi degrado delle prestazioni.

È fondamentale progettare il tuo sistema pensando alla scalabilità sin dal primo giorno, come se non vi fosse alcuna correlazione di progettazione, soddisfare la gestione dell’aumento del carico richiederà cambiamenti architettonici. Potrebbe non essere l’esperienza più piacevole in un sistema di produzione vivente e che respira.

In termini di importanza, esiste un legame tra scalabilità e disponibilità. Decidere quale è più importante è molto difficile e nella maggior parte dei casi dipende dal caso di utilizzo esatto del sistema. Tuttavia, nella maggior parte dei casi, vanno testa a testa e le stesse azioni possono mitigare i problemi con entrambi i tratti.

I fattori limitanti sono quasi gli stessi del caso della disponibilità, in quanto è difficile ridimensionare un sistema che non è disponibile. Inoltre, possiamo aggiungere un accoppiamento stretto tra componenti e architettura monolitica, in una certa misura, poiché entrambi rendono difficile ridimensionare i singoli componenti separatamente. Costringendoci così a ridimensionare il sistema nel suo insieme.

Come aumentare la scalabilità:

• Comunicazione asincrona
• Bilanciamento del carico
• Cache
• Architettura a microservizio

Sembra interessante? Mi immergo un po ‘più a fondo nel tema di Scalabilità nel testo.

Manutenibilità

Oltre a rendere disponibile e scalabile un sistema, c’è anche una cosa importante che dobbiamo tenere a mente. Dovremo mantenere questo sistema dopo averlo rilasciato. Alcuni potrebbero dire che questo tratto è ancora più importante di entrambi i precedenti. Anche il sistema perfetto può causare molti mal di testa se abbiamo problemi a mantenerlo.

Cosa fare quando c’è un problema di produzione e non hai tronchi di cui ragionare? Come notare il degrado delle prestazioni quando non ci sono metriche? Certo, possiamo contare sui nostri utenti per segnalarlo, ma potrebbe non essere la decisione aziendale più intelligente.

Come rendere un sistema mantenibile:

• Osservabilità -Un termine di cattura per tronchi, metriche, avvisi e traccia. Senza di loro, mantenere il sistema è un ordine di grandezza più difficile. Abbiamo bisogno di risposte tempestive e adeguate in caso di problema, e probabilmente nessuno vorrebbe essere svegliato da una telefonata che sta accadendo qualcosa di brutto con il nostro software program.
• Take a look at – È così semplice: i check sono obbligatori. Dire “So che dovrebbe funzionare” non è un buon approccio.

Complessità

La progettazione del sistema è una lotta costante per gestire più/più veloce/migliore. Con tutta questa gara, non dobbiamo dimenticare la complessità della nostra soluzione. È importante non fare in modo eccessivo il sistema.

La tendenza nel software program è che tutto cresca prima o poi in un motore ingestibile che fa tutto. Non comprendiamo nemmeno remoto la metà di ciò che fa. Come ingegneri, Dobbiamo ritardare questo processo il più a lungo possibile.

I triviali come “più complessi è il nostro sistema, più è difficile aggiungere o cambiare qualcosa al suo interno” o “più è complesso, più i costi aziendali possono aumentare” sono così comuni, ma tuttavia, eccolo qui. Sembra che non stiano raggiungendo comunque le persone corrette.

Ricorda solo di mantenere tutto il più semplice possibile in un determinato punto e lasciare tutto lo spazio di progettazione per dopo: la complessità arriverà comunque con il tempo.

Per quanto riguarda alcuni altri esempi concreti:

• Forse non ne hai bisogno o quella tecnologia o strumento;
• Forse non abbiamo bisogno di un’altra lingua da qualche parte nella nostra architettura generale.
• Questa o quella tendenza di fantasia, sebbene fantasiosa, potrebbe non essere una buona opzione a lungo termine.

Parti e compromessi comuni

Questi sono solo alcuni problemi comuni che sorgono nei sistemi distribuiti. Ci sono più di loroe alcuni punti sono ancora più sfumati.

Alcuni approcci possono affrontare più di una trappola.

• Advert esempio, la reproduction può essere uno strumento per influire sulla disponibilità e sulla scalabilità. Possiamo usare repliche per la lettura dei dati e continuare a scrivere sul primario.
• Lo stesso è il caso del bilanciamento del carico: possiamo far girare uno o più bilanciatori di carico che dividerebbero il carico tra i nostri servizi, il che influisce sulla disponibilità (failover automatico) sia sulla scalabilità inserindo le richieste a più servizi per l’elaborazione.
• D’altra parte, la migrazione dei microservizi o qualche altra architettura scalabile orizzontalmente influisce ampiamente sulla complessità del sistema.

Inoltre, tutta questa ridondanza, bilanciatori del carico, monitoraggio, ecc. Influisce anche sulla complessità. Con ogni nuovo componente, cresce.

Probabilmente il più grande punto di svolta per tutti e quattro i problemi è l’elaborazione/servizi apolidi. Affronta tutte le preoccupazioni in un modo o nell’altro:

• Disponibilità – Puoi girare più servizi e possono facilmente raccogliere il lavoro di quelli non riusciti
• Scalabilità – girare nuove istanze finché il price range lo consente
• Complessità – Nessuno stato significa meno parti mobili ed è più facile ragionare su ciò che sta accadendo esattamente

Qui puoi trovare il discorso di Neal Ford sul compromessi e conseguenze. Consiglio vivamente di guardare.

Riepilogo

Con questa nota ottimistica sui compromessi, raggiungiamo la superb del viaggio di oggi. La progettazione di sistemi è difficile ed è ancora più difficile farlo bene.

Sotto i takeaway chiave vorrei che tu tiri fuori da questo weblog:

• Ricorda che le tue scelte hanno conseguenze e possono influire su più aree del sistema.
• Cerca sempre di mantenere tutto semplice.
• Apolveless è meglio che stato.
• L’osservabilità e i check sono entrambi essenziali.

Buona fortuna con la progettazione di architetture e divertiti a farlo. Grazie per il tuo tempo.