Руководство по проектированию микрослужб с помощью эластичных кластеров

В этом руководстве вы используете Azure Database для PostgreSQL в качестве бэкенд-хранилища для множества микросервисов. В этом руководстве демонстрируется пример установки и базовая операция такого кластера. Узнайте, как:

Предпосылки
Создание ролей для микрослужб
Использование служебной программы psql для создания ролей и распределенных схем
Создание таблиц для примеров служб
Настройка служб
Запуск служб
Изучение базы данных

Предпосылки

Создайте эластичные кластеры одним из следующих способов:

Создание ролей для микрослужб

Вы можете динамически размещать распределенные схемы в эластичном кластере. Система может перебалансировать их как единое целое на доступных узлах, поэтому вы получаете улучшенную эффективность ресурсов кластера без ручного выделения.

При применении сегментирования схемы к шаблону конструктора микрослужб создается схема базы данных для каждой соответствующей микрослужбы. Кроме того, при подключении к базе данных используйте отдельную РОЛЬ для каждой микрослужбы. При подключении каждого пользователя имя роли добавляется в начало списка search_path. Если имя роли соответствует имени схемы, вам не нужны дополнительные изменения приложения, чтобы задать правильный search_path.

В этом примере используйте три микрослужбы:

Пользователь
time
ping

Создайте роли базы данных для каждой службы:

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

Использование служебной программы psql для создания распределенных схем

После подключения к эластичному кластеру с помощью psql можно выполнить некоторые основные задачи.

Схему можно распространять двумя способами:

Вручную вызовите функцию citus_schema_distribute(schema_name).

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

Этот метод также позволяет преобразовать существующие обычные схемы в распределенные схемы.

Замечание

Вы можете распространять только схемы, не содержащие распределенные и ссылочные таблицы.

Включив citus.enable_schema_based_sharding переменную конфигурации. Можно изменить переменную для текущего сеанса или окончательно из параметров узла координатора. Если задать для параметра значение ON, все созданные схемы распределяются по умолчанию.

SET citus.enable_schema_based_sharding TO ON;

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

Выполните следующую команду, чтобы вывести список распределенных схем.

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)

Создание таблиц для примеров служб

Теперь вы можете подключиться к эластичному кластеру для каждой микрослужбы. В следующем примере база данных эластичного кластера называется Citus. Из сеанса psql можно использовать команду \c для переключения на другого пользователя.

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

Настройка служб

В этом руководстве мы используем простой набор служб. Их можно получить, клонируя этот общедоступный репозиторий:

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

Прежде чем запускать службы, измените user/app.pyping/app.pyи time/app.py файлы, предоставляющие конфигурацию подключения для эластичного кластера:

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

После внесения изменений сохраните все измененные файлы и перейдите к следующему шагу запуска служб.

Запуск служб

Перейдите в каждый каталог приложения и запустите их в их собственных виртуальных окружениях Python.

cd user
pipenv install
pipenv shell
python app.py

Повторите команды для служб времени и ping, после чего можно использовать API.

Создайте некоторых пользователей:

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

Перечислить созданных пользователей:

curl http://localhost:5000/users

Получение текущего времени:

Get current time:

Запустите команду ping на example.com.

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

Изучение базы данных

Теперь, когда вы вызвали некоторые функции API, данные хранятся, и вы можете проверить citus_schemas , отражает ли это ожидаемое:

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)

При создании схем вы не указали, на каких компьютерах необходимо создать схемы. Это было сделано автоматически. Вы можете увидеть, где находится каждая схема с помощью следующего запроса:

  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

Для краткости выходных данных примера на этой странице вместо использования nodename в качестве IP-адреса мы заменим его на localhost. Предположим, что localhost:7001 это узел один и localhost:7002 два узла.

Вы можете видеть, что служба времени размещена на узле localhost:7001, а пользовательская служба и служба ping совместно размещены на втором узле localhost:7002. Примеры приложений являются упрощенными, а размеры данных здесь незначительны, но предположим, что на вас влияет неравномерное использование дискового пространства между узлами. Было бы более логично, если бы две меньшие службы — времени и ping — размещались на одном узле, в то время как большая служба пользователей находилась бы на своем собственном узле.

Вы можете легко перебалансировать кластер по размеру диска:

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)

По завершении можно проверить, как выглядит новый макет:

  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)

В соответствии с ожиданиями схемы перемещаются, и у нас есть более сбалансированный кластер. Эта операция является прозрачной для приложений. Вы даже не должны перезапустить их, они продолжают обслуживать запросы.

Следующий шаг

Дополнительные сведения об эластичных кластерах

Обратная связь

Были ли сведения на этой странице полезными?

Последнее обновление: 2026-07-08