I sistemi Erlang (o qualsiasi cosa che gira su BEAM VM) devono essere monolitici, cioè tutti in esecuzione nella stessa applicazione distribuita, o dovrebbero essere suddivisi in più microservizi come farebbe qualsiasi negozio python / go / c ++?
Poiché ogni processo in Erlang ha il suo spazio di memoria, sembra che si comportino come microservizi internamente, e quindi, una singola applicazione di Erlang dovrebbe essere sufficiente, ma forse c'è qualcosa che ho trascurato?
Si noti che non esiste alcun concetto di spazio dei nomi o isolamento dei processi all'interno di Erlang VM. Puoi avere solo un modulo con un nome specifico, quindi se provi a eseguire troppe applicazioni diverse alla fine potresti finire con nomi in conflitto.
Detto questo, non c'è nulla che impedisca ad una Erlang VM di prendere tutte le risorse disponibili e di crescere tanto grande quanto necessario. Ho lavorato con sistemi che eseguono una singola VM su 32 sistemi CPU con 100 GB di memoria. BEAM avvia semplicemente uno scheduler per CPU e distribuisce i processi di Erlang su tutte le risorse disponibili.
È più una questione di carico anticipato, scalabilità dello sviluppo e progettazione dell'architettura generale. Alcuni punti da considerare:
Ogni nodo è aggiornato come unità - se qualcosa va storto la singola VM si blocca e ha bisogno essere riavviato. Immagina che il nodo in esecuzione su 32 CPU, che occupa 100 GB di memoria e che gestisca centinaia di migliaia di utenti alla volta si blocca durante l'aggiornamento del software e l'avvio richiede un'ora perché è il tempo necessario per caricare i dati dal DB a la memoria. Se questo è il tuo scenario, potresti voler disaccoppiare il nodo in più micro servizi che possono essere aggiornati separatamente. Tuttavia, se hai 10 nodi del genere e il traffico è distribuito tra di loro, potresti semplicemente prendere la strada della minor resistenza.
A causa della mancanza di spazi dei nomi e dell'isolamento dei processi dal punto di vista dello sviluppo, potrebbe essere più semplice mantenere un repository comune con tutte le applicazioni (per evitare il conflitto di nomi) ma creare più Erlang releases , ognuno dei quali esegue un servizio specifico utilizzando solo una selezione di applicazioni disponibili in quel repository (micro servizio).
Il test è molto più semplice se si dispone di più micro servizi che possono essere testati in isolamento dove gli altri nodi sono presi in giro rispetto a se si ha un grande nodo multifunzione che fa tutto e il lavello della cucina.
Erlang è progettato per essere massicciamente scalabile. I processi di Erlang sono leggeri; puoi avere milioni di loro se vuoi. Quindi ogni "microservizio" a cui si fa riferimento molto probabilmente mapperà a diverse istanze di Erlang.
Probabilmente è più utile pensare a ciascun microservizio come Modulo , non a un Processo. Il mio suggerimento sarebbe quello di creare un modulo per ogni microservizio e avviare un processo di Erlang per ogni richiesta di microservizio in entrata.
Ulteriori letture
Moduli di Erlang
Erlang Processes
Leggi altre domande sui tag architecture microservices erlang