Ridimensionamento di monoliti e ridimensionamento di microservizi

Uno degli argomenti comuni per l'utilizzo dei microservizi è una migliore scalabilità. Ma mi chiedo se questo argomento sia davvero valido.

Diciamo che avevamo un'applicazione composta da 10 microservizi con 9 di essi con due istanze ciascuno (per ridondanza) e uno con 4 istanze per gestire il carico (scalabilità). L'argomento pro-microservice è quindi che sei in grado di ridimensionare questo miroservice indipendentemente dagli altri servizi.

Tuttavia, supponiamo che tutti i 10 microservizi fossero moduli in un singolo monolite e che siano state distribuite diverse istanze (ad esempio 22 come la somma dall'alto) di questo monolito. Il sistema dovrebbe essere in grado di gestire il carico per una parte critica, poiché vi sono sufficienti istanze per farlo. Se le istanze contengono la logica del programma non necessaria, l'unico aspetto negativo sarebbe che il binario e la quantità di RAM necessaria sarebbero leggermente più grandi. Ma ancora una volta, la differenza non dovrebbe essere troppo grande nella maggior parte dei casi - almeno non rispetto al resto dello stack (pensate a Spring Boot). Il vantaggio di un monlith in scala sarebbe un sistema più semplice senza (la maggior parte) degli errori di un sistema distribuito.

Mi sto perdendo qualcosa?

microservices

— deamon
fonte

Quanto grande di un monolite stai parlando? Perché penso che potrebbe essere più di una quantità "leggermente più grande" di RAM. Per non parlare del tempo di distribuzione - la correzione di un bug potrebbe richiedere 22 distribuzioni invece di 4. Ma forse il tuo monolite è piccolo e le distribuzioni non richiedono molto tempo, le migrazioni del database non richiedono molto tempo e così via.

— Thomas Owens

Non ho contato righe di codice, ma il monolite avrebbe diverse migliaia di righe di codice (non un sistema gigante). Il punto di partenza della mia considerazione è stato che la dimensione del codice dell'applicazione reale è minuscola rispetto ai grandi framework come Spring e Hibernate. Il numero di distribuzioni potrebbe effettivamente essere inferiore rispetto ai microservizi, perché se si avessero 2 istanze si avrebbe già una ridondanza di base e più istanze sarebbero per la scalabilità.

— Deamon,

@deamon Tieni presente che con l'approccio monolite non ci sono parti del codice totalmente morte su ogni istanza, solo codice usato raramente. Ora, il codice stesso può consumare solo una piccola quantità di memoria, ma se utilizza molti oggetti logorati nella memoria tale quantità può aumentare in modo sostanziale.

— Frank Hopkins,

Si noti che l'overhead del "codice di esecuzione" di base non è necessariamente così grande come si potrebbe sapere dalle applicazioni Java in cui spesso l'intero jvm fa parte dell'immagine del servizio.

— Frank Hopkins,

Risposte:

Il punto dei microservizi non è ridurre il carico del processore. In effetti, a causa del sovraccarico di comunicazione e ripetizione di funzioni che erano un tempo un codice di utilità globale, di solito aumenta un po 'il carico del processore.

Il punto di abolire un monolite è molto più di essere in grado di mantenere, distribuire e gestire un sistema complesso di funzionalità affatto . Una volta che il sistema raggiunge una certa dimensione, compilazione, test, distribuzione ecc., Un monolite diventa troppo costoso per essere fattibile mantenendo un tempo di attività decente. Con i microservizi, è possibile aggiornare, riavviare o ripristinare un sistema frammentario.

Non commettere errori, non scriviamo microservizi perché è intrinsecamente una soluzione migliore per accoppiare le cose liberamente su interfacce remote. In effetti, la perdita di un tipo forte e la verifica della coerenza che un monolite potrebbe fornire è spesso un grave svantaggio. Lo facciamo perché dobbiamo farlo perché la complessità ha avuto la meglio su di noi e sta sfruttando al meglio una situazione non ottimale.

— Kilian Foth
fonte

Concordato. Il motivo per passare a un'architettura a microservizi è principalmente politico. Il carico distribuito, il disaccoppiamento sono conseguenze, non cause. Il vero vantaggio dei microservizi è presso SDLC e Governance. Inoltre, l'architettura è la risposta logica a un'esigenza che nella maggior parte dei casi deriva dalla strategia di mercato dell'azienda. Il time-to-market è più breve delle architetture monolitiche, quindi all'azienda è consentito adottare nuove strategie, passare da una all'altra senza intoppi e rapidamente

— Laiv

Ecco perché qualcuno non dovrebbe andare direttamente ai microservizi anche per applicazioni medio-piccole. Il sovraccarico e l'ulteriore complessità del sistema possono benissimo comportare costi, tempo e denaro superiori rispetto a un sistema monolitico, su quelle scale.

— T. Sar,

»Lo facciamo perché dobbiamo perché la complessità ha avuto la meglio su di noi e sta sfruttando al meglio una situazione non ottimale.« Sì. Per me, quello lo inchioda!

— Thomas Junk,

Non sono d'accordo con l'ultima parte della risposta. i micro-servizi sono intrinsecamente migliori di un monolite, perché utilizzano più di un computer

— Ewan,

@ewan Puoi usare anche più di un computer con monoliti.

— Deamon,

Per lo più hai ragione. Se disponi di servizi rapidi che vengono caricati allo stesso modo, puoi anche installarli tutti su tutte le scatole. Non è "bello" come avere una scatola per servizio, ma fa risparmiare denaro.

Tuttavia. non appena si ha uno squilibrio, si supponga che il servizio 5 prenda il 100% della CPU per 2 minuti, si desidera spostare tale servizio nella propria casella in modo che non blocchi tutti gli altri servizi se è in esecuzione.

Se le chiamate al servizio 5 scadono a causa del caricamento, solo alcune funzioni della tua app falliranno invece di tutte.

Ora potresti fare la stessa cosa con un monolito ben modulare. Installa tutti i servizi, ma indirizza solo il traffico del servizio 5 a uno di essi. Pur non instradando il traffico del servizio 5 verso le altre caselle.

Ma di solito i monoliti per loro stessa natura non sono una raccolta libera di servizi che si trovano nella stessa scatola. Ci saranno chiamate in memoria tra i moduli che causeranno il fallimento dell'app.

— Ewan
fonte

Il punto dei micro servizi sono 1) separazione delle preoccupazioni e 2) distribuzione del carico. In sostanza, questo ci libera per offrire il miglior servizio di black box possibile con tecnologie specifiche per tale compito. I nostri servizi possono essere poliglotta, ovvero scritti in diversi linguaggi di programmazione su pile diverse. Team diversi possono lavorare su ciascun servizio senza sapere come gli altri lavorano oltre il contratto della propria API. Questo, nel suo insieme, consente una base di codice molto più semplice per ogni servizio che è più facile da eseguire il debug, capire e ottimizzare le prestazioni.

— Lewis A Sellers
fonte

Sono parzialmente d'accordo. Il mio punto non riguardava argomenti per i microservizi in generale, ma sulla scalabilità. Nel mio caso specifico, ad esempio, i microservizi sono tutti scritti con la stessa tecnologia. Quindi, mentre sarebbe possibile utilizzare una tecnologia diversa per ciascuno, non è semplicemente il caso qui. Volevo verificare di non perdere un punto importante sulla scalabilità.

— Deamon,