Microservices - dovrebbero esserci più istanze dello stesso servizio?

La risposta dipende in gran parte dai requisiti di scalabilità / tempo di attività / failover. Se è necessario disporre di un'architettura altamente resiliente, allora sì, è necessario disporre di più istanze (a volte anche distribuite su più data center).

Questo è in realtà uno dei vantaggi dei microservizi: puoi scalare diversi servizi in modo indipendente, alcuni dei quali sono più critici per le prestazioni rispetto ad altri, quindi crea più istanze di questi. Confrontalo con applicazioni monolitiche in cui puoi scalare solo l'intero monolite (ignorando il fatto che ci sono diversi requisiti per le diverse parti del monolite).

Se sei fortunato, allora il tuo microservizio è senza stato - tutte le istanze sono completamente isolate. Questo è fantastico perché puoi ridimensionarli quasi all'infinito. Ma spesso hai uno stato che deve essere distribuito tra i singoli nodi. Se si dispone di un database relazionale, è possibile connettere tutti i nodi alla stessa istanza DB, ma in genere non viene eseguita correttamente. È quindi possibile impostare repliche di lettura (slave) o anche repliche multi-master (leggere e scrivere possibili da diverse istanze DB che quindi sincronizzano), ma è ancora possibile raggiungere alcuni limiti (in base ai requisiti dell'applicazione e di scalabilità). Recentemente, l'hype per gli store a valore-chiave distribuiti - ad es. Hazelcast che può avere molti nodi (anche uno per istanza dell'applicazione) che poi si sincronizza. Questo di solito è migliore rispetto ai DB di relazione, ma di solito i dati non sono persistenti e persi dopo l'arresto anomalo del sistema.

Quando si hanno più istanze di applicazioni, è una buona idea nascondere questo fatto dal client - si dovrebbe avere un solo endpoint che è servito da un servizio di bilanciamento del carico (ad esempio HAProxy) che quindi indirizza il traffico alle istanze dell'applicazione effettive. Queste istanze possono essere aggiunte / rimosse in base al carico in modo dinamico, l'endpoint non cambia mai.

Perché no. Se i microservizi sono privi di stato o hanno uno stato di backup del database condiviso, è necessario poter disporre di più istanze dei servizi dietro un bilanciamento del carico di rete (F5 big-ip o Microsoft NLB come esempio). Suppongo che i microservizi abbiano un http api (REST). La risposta è leggermente più complicata se i microservizi sono integrati su un bus di servizio, ma anche in questo caso è possibile avere più istanze.

I servizi in generale dovrebbero essere apolidi, se possibile. Ciò ti consente di sfruttare uno dei loro più potenti vantaggi: la scalabilità orizzontale. Se sei su AWS, ad esempio, puoi impostare gruppi con scalabilità automatica che creano semplicemente più server quando necessario e li distruggono in seguito, senza perdita di informazioni o richieste.