Lernprogramm: Design für Microservices mit elastischen Clustern

In diesem Lernprogramm verwenden Sie Azure-Datenbank für PostgreSQL als Speicher-Back-End für mehrere Microservices. Das Lernprogramm veranschaulicht eine Beispieleinrichtung und einen einfachen Betrieb eines solchen Clusters. Erfahren Sie, wie Sie Folgendes tun können:

• Voraussetzungen
• Erstellen von Rollen für Ihre Microservices
• Verwenden des psql-Hilfsprogramms für das Erstellen von Rollen und verteilten Schemas
• Erstellen der Tabellen für die Beispieldienste
• Konfigurieren von -Diensten
• Ausführen der Dienste
• Untersuchen der Datenbank

Voraussetzungen

Erstellen Sie einen elastischen Cluster auf eine der folgenden Arten:

• Erstellen eines elastischen Clusters mithilfe des Portals
• Erstellen eines elastischen Clusters mit Bicep
• Erstellen eines elastischen Clusters mit ARM-Vorlage

Erstellen von Rollen für Ihre Microservices

Sie können verteilte Schemas dynamisch in einem elastischen Cluster platzieren. Das System kann sie als eine gesamte Einheit über die verfügbaren Knoten hinweg neu verteilen und dadurch die Effizienz Ihrer Clusterressourcen ohne manuelle Zuordnung verbessern.

Wenn Sie schemasharding auf ein Microservice-Entwurfsmuster anwenden, erstellen Sie ein Datenbankschema für jeden entsprechenden Microservice. Verwenden Sie außerdem beim Herstellen einer Verbindung mit der Datenbank eine eigene ROLLE für jeden Microservice. Wenn jeder Benutzer eine Verbindung herstellt, wird deren Rollenname am Anfang des Suchpfads eingefügt. Wenn der Rollenname dem Schemanamen entspricht, benötigen Sie keine weiteren Anwendungsänderungen, um die richtige search_path festzulegen.

Verwenden Sie in diesem Beispiel drei Microservices:

• user
• time
• Ping

Erstellen Sie die Datenbankrollen für jeden Dienst:

CREATE USER user_service;
CREATE USER time_service;
CREATE USER ping_service;

Verwenden des psql-Hilfsprogramms für das Erstellen von verteilten Schemas

Nachdem Sie mithilfe von psql eine Verbindung mit dem elastischen Cluster hergestellt haben, können Sie einige grundlegende Aufgaben ausführen.

Sie können ein Schema auf zwei Arten verteilen:

• Manuell durch Aufrufen der citus_schema_distribute(schema_name) Funktion:

CREATE SCHEMA AUTHORIZATION user_service;
CREATE SCHEMA AUTHORIZATION time_service;
CREATE SCHEMA AUTHORIZATION ping_service;

SELECT citus_schema_distribute('user_service');
SELECT citus_schema_distribute('time_service');
SELECT citus_schema_distribute('ping_service');

Mit dieser Methode können Sie auch vorhandene reguläre Schemas in verteilte Schemas konvertieren.

Hinweis

Sie können nur Schemas verteilen, die keine verteilten Tabellen und Referenztabellen enthalten.

• Durch Aktivieren der citus.enable_schema_based_sharding Konfigurationsvariable. Sie können die Variable für die aktuelle Sitzung oder dauerhaft über die Parameter des Koordinationsknotens ändern. Wenn Sie den Parameter auf EIN festlegen, werden alle erstellten Schemas standardmäßig verteilt.

SET citus.enable_schema_based_sharding TO ON;

CREATE SCHEMA AUTHORIZATION user_service;
CREATE SCHEMA AUTHORIZATION time_service;
CREATE SCHEMA AUTHORIZATION ping_service;

Führen Sie den folgenden Befehl aus, um die derzeit verteilten Schemas auflisten:

SELECT * FROM citus_schemas;

 schema_name | colocation_id | schema_size | schema_owner
-------------+---------------+-------------+--------------
 user_service |             5 | 0 bytes     | user_service
 time_service |             6 | 0 bytes     | time_service
 ping_service |             7 | 0 bytes     | ping_service
(3 rows)

Erstellen der Tabellen für die Beispieldienste

Sie können jetzt für jeden Microservice eine Verbindung mit dem elastischen Cluster herstellen. Im folgenden Beispiel heißt die elastische Clusterdatenbank Citus. Aus der psql-Sitzung können Sie den Befehl \c verwenden, um zu einem anderen Benutzer zu wechseln.

\c citus user_service

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    name VARCHAR(255) NOT NULL,
    email VARCHAR(255) NOT NULL
);

\c citus time_service

CREATE TABLE query_details (
    id SERIAL PRIMARY KEY,
    ip_address INET NOT NULL,
    query_time TIMESTAMP NOT NULL
);

\c citus ping_service

CREATE TABLE ping_results (
    id SERIAL PRIMARY KEY,
    host VARCHAR(255) NOT NULL,
    result TEXT NOT NULL
);

Konfigurieren von -Diensten

In diesem Tutorial verwenden wir eine einfache Reihe von Diensten. Sie können diese abrufen, indem Sie dieses öffentliche Repository klonen:

git clone https://github.com/citusdata/citus-example-microservices.git

$ tree
.
├── LICENSE
├── README.md
├── ping
│   ├── app.py
│   ├── ping.sql
│   └── requirements.txt
├── time
│   ├── app.py
│   ├── requirements.txt
│   └── time.sql
└── user
    ├── app.py
    ├── requirements.txt
    └── user.sql

Bevor Sie jedoch die Dienste ausführen, bearbeiten Sie die Dateien user/app.py, ping/app.py und time/app.py, die die Verbindungskonfiguration für Ihren elastischen Cluster bereitstellen:

# Database configuration
db_config = {
    'host': 'EXAMPLE.postgres.database.azure.com',
    'database': 'postgres',
    'password': 'SECRET',
    'user': 'ping_service',
    'port': 5432
}

Nachdem Sie die Änderungen vorgenommen haben, speichern Sie alle geänderten Dateien und fahren Sie mit dem Ausführen der Dienste fort.

Ausführen der Dienste

Wechseln Sie in jedes App-Verzeichnis und führen Sie sie in ihrer eigenen Python-Umg. aus.

cd user
pipenv install
pipenv shell
python app.py

Wiederholen Sie die Befehle für den Zeit- und Ping-Dienst. Anschließend können Sie die API verwenden.

Erstellen von einigen Benutzern:

curl -X POST -H "Content-Type: application/json" -d '[
  {"name": "John Doe", "email": "john@example.com"},
  {"name": "Jane Smith", "email": "jane@example.com"},
  {"name": "Mike Johnson", "email": "mike@example.com"},
  {"name": "Emily Davis", "email": "emily@example.com"},
  {"name": "David Wilson", "email": "david@example.com"},
  {"name": "Sarah Thompson", "email": "sarah@example.com"},
  {"name": "Alex Miller", "email": "alex@example.com"},
  {"name": "Olivia Anderson", "email": "olivia@example.com"},
  {"name": "Daniel Martin", "email": "daniel@example.com"},
  {"name": "Sophia White", "email": "sophia@example.com"}
]' http://localhost:5000/users

Auflisten der erstellten Benutzer:

curl http://localhost:5000/users

Abrufen der aktuellen Zeit:

Get current time:

Ausführen des Pings für example.com:

curl -X POST -H "Content-Type: application/json" -d '{"host": "example.com"}' http://localhost:5002/ping

Untersuchen der Datenbank

Jetzt, da Sie einige API-Funktionen aufgerufen haben, sind die Daten gespeichert und Sie können überprüfen, ob citus_schemas das widerspiegelt, was erwartet wird:

SELECT * FROM citus_schemas;

 schema_name | colocation_id | schema_size | schema_owner
-------------+---------------+-------------+--------------
 user_service |             1 | 112 kB      | user_service
 time_service |             2 | 32 kB       | time_service
 ping_service |             3 | 32 kB       | ping_service
(3 rows)

Beim Erstellen der Schemas haben Sie nicht angegeben, auf welchen Computern die Schemas erstellt werden sollen. Dies ist automatisch erfolgt. Mit der folgenden Abfrage können Sie sehen, wo sich jedes Schema befindet:

  SELECT nodename,nodeport, table_name, pg_size_pretty(sum(shard_size))
  FROM citus_shards
  GROUP BY nodename,nodeport, table_name;

nodename  | nodeport |         table_name         | pg_size_pretty
-----------+----------+---------------------------+----------------
 localhost |     7001 | time_service.query_details | 32 kB
 localhost |     7002 | user_service.users         | 112 kB
 localhost |     7002 | ping_service.ping_results  | 32 kB

Um die Beispielausgabe auf dieser Seite zu vereinfachen, ersetzen wir nodename als IP-Adresse durch localhost. Nehmen wir an, dass localhost:7001 der Knoten eins und localhost:7002 der Knoten zwei ist.

Sie können sehen, dass der Zeitdienst auf Knoten localhost:7001 gelandet ist, während sich der Benutzer und der Ping-Dienst den Platz auf dem zweiten Knoten localhost:7002 teilen. Die Beispiel-Apps sind einfach, und die Datengrößen hier sind unbedeutend, nehmen wir jedoch an, dass Sie von der ungleichmäßigen Speicherplatznutzung zwischen den Knoten betroffen sind. Es wäre sinnvoller, die beiden kleineren Zeit- und Pingdienste auf einem Knoten zu haben, während sich der große Benutzerdienst auf einem eigenen Knoten befindet.

Sie können den Cluster ganz einfach anhand der Datenträgergröße neu ausgleichen:

SELECT citus_rebalance_start();

NOTICE:  Scheduled 1 moves as job 1
DETAIL:  Rebalance scheduled as background job
HINT:  To monitor progress, run: SELECT * FROM citus_rebalance_status();
 citus_rebalance_start
-----------------------
                     1
(1 row)

Wenn Sie fertig sind, können Sie überprüfen, wie unser neues Layout aussieht:

  SELECT nodename,nodeport, table_name, pg_size_pretty(sum(shard_size))
  FROM citus_shards
  GROUP BY nodename,nodeport, table_name;

 nodename  | nodeport |         table_name        | pg_size_pretty
-----------+----------+---------------------------+----------------
 localhost |     7001 | time_service.query_details | 32 kB
 localhost |     7001 | ping_service.ping_results  | 32 kB
 localhost |     7002 | user_service.users         | 112 kB
(3 rows)

Erwartungsgemäß werden die Schemata verschoben und wir haben einen ausgewogeneren Cluster. Dieser Vorgang ist für die Anwendungen transparent. Sie müssen sie nicht einmal neu starten, sie stellen weiterhin Abfragen bereit.

Nächster Schritt

Weitere Informationen zu elastischen Clustern