Come scalare orizzontalmente un microservizio che contiene un database

TL; DR

• I tuoi front-end Web non dovrebbero archiviare dati: dovrebbero essere banali da ridimensionare.
• Utilizza un archivio dati creato per ridimensionare orizzontalmente (altrimenti, scopri come condividere)
• Approfitta del fatto che i "microservizi" già distribuiscono il carico

In primo luogo: i tuoi front-end web non dovrebbero essere veramente di stato. Non dovrebbero memorizzare nulla che non ti puoi permettere di perdere in un dato momento . Tutti i dati dovrebbero vivere in un cluster di database dedicato. Dovresti essere in grado di eliminare un front-end Web o aggiungerne uno nuovo senza interrompere le sessioni oi dati di nessuno. Ridimensionamento che dovrebbe essere "banale".

Detto questo, scalare orizzontalmente il database di un servizio richiede una sorta di condivisione . Tuttavia, se opti per un negozio di tipo documento , il ridimensionamento orizzontale tramite sharding è usually a baked in feature che devi solo configurare. (Oppure, è un dettaglio che puoi ignorare completamente se utilizzi un servizio di hosting di database scalabile, come DynamoDB.)

Fondamentalmente, la sharding richiede l'identificazione di un campo utilizzato per determinare in che modo i dati vengono suddivisi tra i nodi. Potrebbe essere un user_id , che viene tradotto in un numero. Ad esempio, quale nodo di database è memorizzato un determinato record utente potrebbe dipendere da tale ID e da un algoritmo di hashing, ad esempio.

Un esempio veramente semplice potrebbe essere un modulo di un ID utente casuale, intero-iso. Prendi user_id % number_of_servers per determinare dove archiviare / recuperare il record.

Con un database nosql, molti dettagli su come questo si è preso cura di te: colpisci il cluster e capisce cosa fare.

Potrebbero esserci strategie più sofisticate, se hai bisogno di ACID -come conformità.

Detto questo, uno dei vantaggi di un servizio micro è il differimento di questo problema di scalabilità. Cioè, poiché il tuo database utente è distinto dai tuoi catalogo prodotti e ordini e così via, ognuno di questi database può già essere collocato su diversi host: il traffico è già in qualche modo distribuito.

A meno che tu non abbia un servizio veramente massiccio e non profittevole , puoi probabilmente rimandare il lavoro di scalabilità rimanente finché non hai il budget per affrontarli!

Per quanto riguarda la scalabilità, si presuppone che ogni servizio sia stateless e possa quindi essere ridimensionato arbitrariamente. Stateless qui significa che qualsiasi stato è memorizzato esternamente in alcuni database. In questa vista, un microservizio è in qualche modo separato da qualsiasi database che utilizza. In particolare, è possibile distribuire più istanze del servizio ma avere un database condiviso.

  API users
     |
Load balancing
  /  |    \
MS  MS ... MS
 \  |     / 
Shared Database

Il database non è immediatamente scalabile in quel progetto. Si noti inoltre che questo design non richiede microservizi: si ottengono gli stessi vantaggi di scalabilità da un progetto monolitico, purché i processi non abbiano uno stato interno.

I database sono difficili da ridimensionare se vogliamo mantenere la coerenza: il solo avvio di un'altra istanza non aiuterà. La soluzione tipica è rinunciare alla coerenza o utilizzare il ridimensionamento verticale: eseguire il DB su un server più potente. In molti casi, l'aggiunta di repliche di lettura a un database può già essere di grande aiuto. Inoltre, l'utilizzo di tecniche di data warehousing può ridurre il carico sul database di produzione. I microservizi aiutano leggermente perché diversi microservizi possono utilizzare database diversi, consentendo in tal modo il ridimensionamento indipendente del database di ciascun microservizio.