Esercitazione: Progettare microservizi con cluster elastici

In questa esercitazione si usa Database di Azure per PostgreSQL come back-end di archiviazione per più microservizi. L'esercitazione illustra un'installazione di esempio e il funzionamento di base di questo cluster. Scopri come:

Prerequisiti
Creare ruoli per i microservizi
Usare l'utilità psql per creare ruoli e schemi distribuiti
Creare tabelle per i servizi di esempio
Configurare i servizi
Eseguire servizi
Esplorare il database

Prerequisiti

Creare un cluster elastico in uno dei modi seguenti:

Creare ruoli per i microservizi

È possibile inserire in modo dinamico gli schemi distribuiti all'interno di un cluster elastico. Il sistema può ribilanciarli come un'intera unità tra i nodi disponibili, in modo da ottenere una migliore efficienza tra le risorse del cluster senza allocazione manuale.

Quando si applica il partizionamento orizzontale dello schema a un modello di progettazione di microservizi, si crea uno schema di database per ogni microservizio corrispondente. Usare inoltre un ruolo distinto per ogni microservizio per la connessione al database. Quando ogni utente si connette, il nome del ruolo inizia all'inizio del search_path. Se il nome del ruolo corrisponde al nome dello schema, non sono necessarie altre modifiche dell'applicazione per impostare il search_path corretto.

In questo esempio usare tre microservizi:

utente
time
ping

Creare i ruoli del database per ogni servizio:

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

Usare l'utilità psql per creare schemi distribuiti

Dopo la connessione al cluster elastico tramite psql, è possibile completare alcune attività di base.

È possibile distribuire uno schema in due modi:

Manualmente chiamando la citus_schema_distribute(schema_name) funzione :

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');

Questo metodo consente inoltre di convertire gli schemi regolari esistenti in schemi distribuiti.

Annotazioni

È possibile distribuire solo gli schemi che non contengono tabelle distribuite e di riferimento.

Abilitando la citus.enable_schema_based_sharding variabile di configurazione. È possibile modificare la variabile per la sessione corrente o in modo permanente dai parametri del nodo coordinatore. Quando si imposta il parametro su ON, tutti gli schemi creati vengono distribuiti per impostazione predefinita.

SET citus.enable_schema_based_sharding TO ON;

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

Eseguire il comando seguente per elencare gli schemi attualmente distribuiti:

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)

Creare tabelle per i servizi di esempio

È ora possibile connettersi al cluster elastico per ogni microservizio. Nell'esempio seguente il database del cluster elastico è denominato Citus. Dalla sessione psql è possibile usare il comando \c per eseguire lo scambio con un altro utente.

\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
);

Configurare i servizi

In questa esercitazione viene usato un semplice set di servizi. È possibile ottenerlo clonando questo repository pubblico:

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

Prima di eseguire i servizi, tuttavia, modificare i file user/app.py, ping/app.py e time/app.py fornendo la configurazione di connessione per il tuo cluster elastico:

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

Dopo aver apportato le modifiche, salvare tutti i file modificati e passare al passaggio successivo dell'esecuzione dei servizi.

Eseguire servizi

Passare a ogni directory dell'app ed eseguirle in un ambiente python personalizzato.

cd user
pipenv install
pipenv shell
python app.py

Ripetere i comandi per il servizio tempo e il servizio ping, dopo di che è possibile usare l'API.

Creare alcuni utenti:

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

Elencare gli utenti creati:

curl http://localhost:5000/users

Ottenere l'ora corrente:

Get current time:

Eseguire il ping su example.com:

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

Esplorare il database

Ora che sono state chiamate alcune funzioni API, i dati vengono archiviati ed è possibile verificare se citus_schemas riflette quanto previsto:

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)

Quando sono stati creati gli schemi, non è stato indicato in quali computer creare gli schemi. L'operazione è stata eseguita automaticamente. È possibile vedere dove risiede ogni schema con la query seguente:

  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

Per brevità dell'output di esempio in questa pagina, anziché usare nodename come indirizzo IP lo sostituiamo con localhost. Si supponga che localhost:7001 sia il nodo 1 e localhost:7002 sia il nodo 2.

È possibile vedere che il servizio tempo è arrivato al nodo localhost:7001 mentre l'utente e il servizio ping condividono lo spazio sul secondo nodo localhost:7002. Le app di esempio sono semplicistiche e le dimensioni dei dati in questo caso sono insignificanti, ma si supponga di essere influenzate dall'utilizzo non uniforme dello spazio di archiviazione tra i nodi. Sarebbe più opportuno che i due servizi tempo e ping più piccoli risiedano in un nodo, mentre quello utente più grande risieda in un proprio nodo.

È possibile ribilanciare facilmente il cluster in base alle dimensioni del disco:

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)

Al termine, è possibile verificare l'aspetto del nuovo layout:

  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)

In base alle aspettative, gli schemi vengono spostati e si dispone di un cluster più bilanciato. Questa operazione è trasparente per le applicazioni. Non è nemmeno necessario riavviarli, continuano a gestire le query.

Passo successivo

Altre informazioni sui cluster elastici

Commenti e suggerimenti

Questa pagina è stata utile?

Ultimo aggiornamento: 2026-07-08