Datenbank-Verbindungspool-Strategie für Micro Services

8

Wir versuchen, unsere monolithische Anwendung in eine Micro-Services-basierte Architektur umzuwandeln. Wir verwenden Postgresql als eine unserer Datenbanken in der monolithischen Anwendung mit BoneCP für das Verbindungs-Pooling.

Wenn dieser Monolith auf mehrere unabhängige Micro-Services aufgeteilt wird, wobei jeder in einer anderen JVM ausgeführt wird, kann ich über zwei Optionen für das Verbindungs-Pooling nachdenken

  1. BoneCP oder ein anständiger Verbindungspool für jeden Microservice - Meine erste Untersuchung zeigt, dass dies die erste Wahl ist. Es ist möglich, die Verbindungsanforderungen für jeden Dienst feingranular zu steuern. Aber nach unten bedeutet dies, dass mit steigender Anzahl der Dienste auch die Anzahl der Verbindungspools zunimmt und schließlich zu viele Verbindungen im Leerlauf vorhanden sind, vorausgesetzt, dass jeweils minimale Verbindungen vorhanden sind Pool ist größer als 0.
  2. Verlassen Sie sich auf datenbankspezifische Erweiterungen wie PGBouncer - Dieser Ansatz hat den Vorteil, dass der Verbindungspool von einer zentralen Quelle und nicht von einem Pool für jeden Mikroservice verwaltet wird und somit die Anzahl der inaktiven Verbindungen verringert werden kann. Es ist auch Sprache / Technologie Agnostiker. Nachteil ist, dass diese Erweiterungen datenbankspezifisch sind und einige Funktionen in JDBC möglicherweise nicht funktionieren. Zum Beispiel: Vorbereitete Statements funktionieren möglicherweise nicht mit PGBouncer im Transaction_Pooling-Modus.

In unserem Fall werden sich die meisten Mikro-Dienste (mindestens 50) mit demselben Postgres-Server verbinden, obwohl die Datenbank unterschiedlich sein kann. Also, wenn wir mit Option 1 gehen, gibt es eine höhere Chance, zu viele inaktive Verbindungen zu schaffen. Der Verkehr zu den meisten unserer Dienste ist sehr moderat und der Grund für den Wechsel zu Micro-Service ist für einfachere Bereitstellung, Skalierung usw.

Hat jemand mit einem ähnlichen Problem konfrontiert, als er die Micro-Services-Architektur übernommen hat? Gibt es einen besseren Weg, dieses Problem in der Mikro-Service-Welt zu lösen?

    
Justin Jose 18.03.2016, 11:44
quelle

1 Antwort

2

Ich sehe nicht, wie pgbouncer irgendwelche der Probleme lösen wird, die Sie mit dem ersten Ansatz haben würden. Es gibt viele Gründe, pgbouncer zu verwenden, aber ich denke nicht, dass sie hier wirklich anwendbar sind.

Nach meiner Erfahrung sind Leerlaufverbindungen möglicherweise ein Problem, aber sie werden wahrscheinlich nicht in dem Umfang sein, über den Sie sprechen. Ich meine, wir sprechen nicht Hunderte von Leerlauf-Verbindungen richtig?

Noch kritischer ist, dass eine Schlüsselfrage, die ein Microservices-Ansatz Ihnen geben könnte, die Fähigkeit ist, dbs auf andere Server zu verschieben. Wenn Sie dies tun, ist es schwieriger, Ihren Verbindungspool zentral zu verwalten.

Pro-Service-Pool ist in der Regel flexibler und macht Ihre Infrastruktur auch ein wenig flexibler.

    
Chris Travers 05.12.2016 05:57
quelle

Tags und Links

Django: Verwenden von Annotate, Count und Distinct in einem Queryset Unterschied zwischen objektorientierter Programmierung und reaktiver Programmierung