Dove si inserisce Elixir / erlang nell'approccio dei microservizi? [chiuso]


109

Ultimamente ho fatto alcuni esperimenti con docker compose per distribuire più microservizi collaborativi. Vedo i numerosi vantaggi offerti dai microservizi e ora che esiste un buon set di strumenti per gestirli, penso che non sia estremamente difficile entrare nel carro dei microservizi.

Ma ho anche sperimentato Elixir e sono piuttosto appassionato dei benefici che fornisce da solo. Dato che incoraggia il confezionamento del codice in più applicazioni disaccoppiate e supporta gli aggiornamenti del codice a caldo, come mescoleresti docker con elixir (o erlang, se è per questo)?

Ad esempio, se voglio usare docker perché fornisce la parità dev-prod, come si adatta l'elisir? Dato che i contenitori Docker sono immutabili, perdo la possibilità di eseguire aggiornamenti hot-code, giusto? Che dire delle distribuzioni blu / verdi o delle versioni canary?

Voglio dire, potrei semplicemente scrivere microservizi con Elixir e usarli come se fossero scritti in qualsiasi altra lingua, il poliglotismo è comunque uno dei vantaggi dei microservizi, ma poi non sto ottenendo tutti i vantaggi dell'utilizzo della piattaforma OTP, io Immagino che le applicazioni erlang collaborative pure siano molto più ottimali rispetto all'utilizzo di code intermedie per comunicare tra microservizi scritti in linguaggi diversi (o meno).


7
Vedo che il voto negativo è dovuto al fatto che la domanda "non mostra alcuno sforzo di ricerca". È triste perché non è proprio vero, ovviamente il problema potrebbe essere sulla domanda stessa, ma non posso essere accusato di non fare ricerche perché ultimamente è l'unica cosa che ho fatto. Un sacco.
Papipo

1
Questa domanda è troppo ampia: le domande su stackoverflow dovrebbero includere problemi specifici.
Paweł Obrok

4
dovrei spostarlo su un altro sito stackexchange? Perché la domanda è legittima IMO.
Papipo

2
Penso che sia una domanda interessante, ma potrebbe appartenere allo stackexchange dei programmatori? Detto questo, non si vota per chiudere
George Mauer

1
È fantastico e totalmente fatto per il lavoro.
bryan hunt

Risposte:


138

Questa è una domanda molto aperta, ma cercherò di illustrare perché Elixir / Erlang potrebbe essere la migliore piattaforma disponibile per lo sviluppo di sistemi distribuiti (indipendentemente dal fatto che si lavori con microservizi).

Per prima cosa, iniziamo con alcune informazioni di base. Erlang VM e la sua libreria standard sono state progettate in anticipo per la creazione di sistemi distribuiti e questo si vede davvero. Per quanto ne so, è l'unico runtime e VM ampiamente utilizzati nella produzione progettati in anticipo per questo caso d'uso.

applicazioni

Ad esempio, hai già accennato alle "applicazioni". In Erlang / Elixir, il codice è contenuto in applicazioni che:

  1. vengono avviati e arrestati come unità. Avviare e arrestare il sistema è questione di avviare tutte le applicazioni in esso contenute
  2. fornire una struttura di directory unificata e un'API di configurazione (che non è XML!). Se hai già lavorato e configurato un'applicazione OTP, sai come lavorare con qualsiasi altra
  3. contiene il tuo albero di supervisione dell'applicazione, con tutti i processi (per processo intendo "processi VM" che sono thread di calcolo leggeri) e il loro stato

L'impatto di questo design è enorme. Significa che gli sviluppatori Elixir, quando scrivono le applicazioni, hanno un approccio più esplicito a:

  1. come il loro codice viene avviato e interrotto
  2. quali sono i processi che fanno parte di un'applicazione e quindi qual è lo stato dell'applicazione
  3. come questi processi reagiranno e saranno influenzati in caso di crash o quando qualcosa va storto

Non solo, gli strumenti attorno a questa astrazione sono fantastici. Se avete installato Elixir, aprire "iex" e digitare: :observer.start(). Oltre a mostrare informazioni e grafici sul tuo sistema live, puoi uccidere processi casuali, vedere il loro utilizzo della memoria, lo stato e altro. Ecco un esempio di come eseguirlo in un'applicazione Phoenix:

Observer in esecuzione con un'applicazione Phoenix

La differenza qui è che Applicazioni e processi ti danno un'astrazione per ragionare sul tuo codice in produzione . Molti linguaggi forniscono pacchetti, oggetti e moduli principalmente per l'organizzazione del codice senza alcuna riflessione sul sistema di runtime. Se hai un attributo di classe o un oggetto singleton: come puoi ragionare sulle entità che possono manipolarlo? Se hai una perdita di memoria o un collo di bottiglia, come puoi trovare l'entità responsabile?

Se chiedi a qualcuno che gestisce un sistema distribuito, questo è il tipo di intuizione che vogliono, e con Erlang / Elixir hai questo come elemento costitutivo.

Comunicazione

Tutto questo è davvero solo l'inizio. Quando si costruisce un sistema distribuito, è necessario scegliere un protocollo di comunicazione e il serializzatore di dati. Molte persone scelgono HTTP e JSON che, a pensarci bene, è una combinazione molto prolissa e costosa per eseguire quelle che sono veramente chiamate RPC.

Con Erlang / Elixir, hai già un protocollo di comunicazione e un meccanismo di serializzazione fuori dagli schemi. Se vuoi che due macchine comunichino tra loro, devi solo dare loro un nome, assicurarti che abbiano lo stesso segreto e il gioco è fatto.

Jamie ne ha parlato alla Erlang Factory 2015 e di come sono stati in grado di sfruttarlo per costruire una piattaforma di gioco: https://www.youtube.com/watch?v=_i6n-eWiVn4

Se vuoi usare HTTP e JSON, va bene anche questo e librerie come Plug e framework come Phoenix ti garantiranno che sei produttivo anche qui.

Microservices

Finora non ho parlato di microservizi. Questo perché, fino a questo punto, non contano davvero. Stai già progettando il tuo sistema e i tuoi nodi attorno a processi molto piccoli che sono isolati. Chiamali nanoservizi se vuoi!

Non solo, sono anche impacchettati in applicazioni, che li raggruppano come entità che possono essere avviate e arrestate come unità. Se hai applicazioni A, B e C, e poi vuoi distribuirle come [A, B] + [C] o [A] + [B] + [C], avrai pochissimi problemi nel farlo a causa al loro design intrinseco. O, ancora meglio, se vuoi evitare di aggiungere in anticipo la complessità delle distribuzioni di microservizi al tuo sistema, puoi semplicemente distribuirli tutti insieme nello stesso nodo.

E, alla fine della giornata, se stai eseguendo tutto questo utilizzando il protocollo distribuito di Erlang, puoi eseguirli in nodi diversi e saranno in grado di raggiungerne altri fintanto che ti riferisci a loro {:node@network, :name}invece di :name.

Potrei andare oltre ma spero di averti convinto a questo punto. :)


In realtà mi piacciono molto Elixir e OTP, la domanda era più su come ottenere alcuni vantaggi dei microservizi (come la parità dev-prod, le versioni canary, ecc.) Mentre si utilizza Elixir.
Papipo

Avevo un paragrafo su Docker ma è andato perso. :) Il succo è che lo usi per la distribuzione dei nodi, quindi scegli quali applicazioni hanno senso per nodo. Le distribuzioni blu / verdi sono sicuramente realizzabili, ma dipendono dal protocollo, dal tipo di stato e da altri fattori.
José Valim

5
Il discorso che ho citato copre uno strato di instradamento che potrebbe essere utilizzato per blu / verde o canarino. Di nuovo, dipende dal protocollo scelto, ma puoi andare da una voce globale in Erlang distribuito, qualcosa che usa console o haproxy per qualcosa basato su HTTP.
José Valim

L'approccio alla scoperta dei servizi ha senso. Immagino di aver sempre pensato in termini di bilanciamento del carico.
Papipo

1
Che dire di uno degli altri vantaggi dei micro servizi come la scelta della lingua migliore per un'attività specifica. Amo l'elisir, tuttavia non è il linguaggio migliore per ogni singola attività. Quello che voglio dire è che potrebbe essere necessario che uno specifico micro servizio utilizzi una lingua diversa invece dell'elisir. Allora dovrebbe ancora seguire un'architettura tradizionale dei micro servizi?
Jeancarlo
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.