2016-03-18 24 views
8

Stiamo provando a convertire la nostra applicazione monolitica in un'architettura basata su micro servizi. Usiamo Postgresql come uno dei nostri database nell'applicazione monolitica con BoneCP per il pooling delle connessioni.Strategia del pool di connessione al database per i microservizi

Quando questo monolite è diviso a una serie di micro-servizi indipendenti con ognuno di loro in esecuzione in una JVM diversa, posso pensare a due opzioni per il pool di connessioni

  1. BoneCP o qualsiasi pool di connessione decente per ogni microservice - La mia ricerca iniziale mostra che questa è la scelta principale. È possibile avere un controllo a grana fine dei requisiti di connessione per ciascun servizio.Ma, il lato negativo è che con l'aumento del numero di servizi, aumenta anche il numero di pool di connessioni e alla fine ci saranno troppe connessioni inattive assumendo che le connessioni minime in ogni pool è maggiore di 0.
  2. Affidatevi a estensioni specifiche del database come PGBouncer - Questo approccio ha il vantaggio che il pool di connessioni è gestito da una fonte centrale anziché da un pool per ogni micro servizio e quindi il numero di connessioni inattive può essere ridotto. È anche agnostico di lingua e tecnologia. Verso il basso è che queste estensioni sono specifiche del database e alcune delle funzionalità in JDBC potrebbero non funzionare. Ad esempio: le statistiche preparate potrebbero non funzionare con PGBouncer in modalità Transaction_Pooling.

Nel nostro caso la maggior parte dei micro-servizi (almeno 50) si collegherà allo stesso server Postgres anche se il database può essere diverso. Quindi, se andiamo con l'opzione 1, c'è una maggiore possibilità di creare troppe connessioni inattive. Il traffico verso la maggior parte dei nostri servizi è molto moderato e la logica alla base del passaggio al micro-servizio è più semplice per l'implementazione, il ridimensionamento, ecc.

Qualcuno ha affrontato un problema simile durante l'adozione dell'architettura dei micro-servizi? C'è un modo migliore per risolvere questo problema nel mondo dei micro-servizi?

+0

Perché non è possibile utilizzare un singolo pool di connessioni JDBC? Oppure ogni micro-servizio è in esecuzione nel proprio server delle applicazioni? –

+0

@a_horse_with_no_name Ogni micro-servizio sarà eseguito nel proprio server delle applicazioni. –

risposta

2

Non vedo come pgbouncer risolverà tutti i problemi che avreste con il primo approccio. Ci sono molti motivi per usare pgbouncer ma non penso che siano realmente applicabili qui.

Inoltre, nella mia esperienza, mentre le connessioni inattive possono essere un problema, probabilmente non saranno sulla scala di cui si sta parlando. Voglio dire, non stiamo parlando di centinaia di connessioni inattive, giusto?

Più criticamente, una cosa fondamentale che un approccio microservizi potrebbe darvi è la possibilità di spostare dbs su altri server. Se lo fai, avere il tuo pool di connessione gestito centralmente rende questo compito più difficile.

Il pool per-service è generalmente più flessibile e rende l'infrastruttura un po 'più flessibile.

+0

Che dire di quando 50 applicazioni si connettono a un server di database con un sondaggio HikariCP di massimo 10 connessioni? che sta per raggiungere 500 connessioni al database. Se si ridimensiona a più istanze, quel numero aumenterà. Come puoi risolvere quello? –

+0

Ho detto "generalmente" per una ragione. Vuoi prestare molta attenzione a dove potresti aver bisogno anche di altre soluzioni. Ci sono dei compromessi in entrambi i modi, ma in genere non inizierei da lì. –