Samouczek: projektowanie mikrousług za pomocą klastrów elastycznych

W tym samouczku użyjesz usługi Azure Database for PostgreSQL jako zaplecza do przechowywania dla wielu mikrousług. W tym samouczku przedstawiono przykładową konfigurację i podstawową operację takiego klastra. Dowiedz się, jak:

• Wymagania wstępne
• Tworzenie ról dla mikrousług
• Tworzenie ról i schematów rozproszonych za pomocą narzędzia psql
• Tworzenie tabel dla przykładowych usług
• Konfigurowanie usług
• Uruchamianie usług
• Eksplorowanie bazy danych

Wymagania wstępne

Utwórz klaster elastyczny na jeden z następujących sposobów:

• Tworzenie klastra elastycznego przy użyciu portalu
• Tworzenie klastra elastycznego przy użyciu Bicep
• Tworzenie klastra elastycznego przy użyciu szablonu ARM

Tworzenie ról dla mikrousług

Schematy rozproszone można dynamicznie umieszczać w klastrze elastycznym. System może je ponownie zrównoważyć jako całą jednostkę w dostępnych węzłach, dzięki czemu można zwiększyć wydajność zasobów klastra bez ręcznej alokacji.

W przypadku stosowania fragmentowania schematu do wzorca projektowania mikrousług należy utworzyć schemat bazy danych dla każdej odpowiedniej mikrousługi. Ponadto należy użyć odrębnej roli dla każdej mikrousługi podczas nawiązywania połączenia z bazą danych. Gdy każdy użytkownik nawiąż połączenie, jego nazwa roli będzie wyświetlana na początku search_path. Jeśli nazwa roli jest zgodna z nazwą schematu, nie potrzebujesz żadnych dodatkowych zmian aplikacji, aby ustawić poprawną search_path.

W tym przykładzie użyj trzech mikrousług:

• użytkownik
• time
• ping

Utwórz role bazy danych dla każdej usługi:

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

Tworzenie schematów rozproszonych za pomocą narzędzia psql

Po nawiązaniu połączenia z klastrem elastycznym przy użyciu narzędzia psql możesz wykonać kilka podstawowych zadań.

Schemat można dystrybuować na dwa sposoby:

• Ręcznie wywołując funkcję 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');

Ta metoda umożliwia również konwertowanie istniejących schematów regularnych na schematy rozproszone.

Uwaga / Notatka

Można dystrybuować tylko te schematy, które nie zawierają tabel rozproszonych ani referencyjnych.

• Włączając zmienną citus.enable_schema_based_sharding konfiguracji. Możesz zmienić zmienną dla bieżącej sesji lub trwale, korzystając z parametrów węzła koordynatora. Po ustawieniu parametru na WŁĄCZONY wszystkie utworzone schematy są domyślnie dystrybuowane.

SET citus.enable_schema_based_sharding TO ON;

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

Uruchom następujące polecenie, aby wyświetlić listę aktualnie rozproszonych schematów:

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)

Tworzenie tabel dla przykładowych usług

Teraz możesz nawiązać połączenie z klastrem elastycznym dla każdej mikrousługi. W poniższym przykładzie baza danych klastra elastycznego nosi nazwę Citus. W sesji psql możesz użyć \c polecenia, aby zamienić się na innego użytkownika.

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

Konfigurowanie usług

W tym samouczku używamy prostego zestawu usług. Można je uzyskać, klonując to repozytorium publiczne:

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

Przed uruchomieniem usług należy jednak edytować user/app.pypliki , ping/app.pyi time/app.py udostępniając konfigurację połączenia dla klastra elastycznego:

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

Po wprowadzeniu zmian zapisz wszystkie zmodyfikowane pliki i przejdź do następnego kroku uruchamiania usług.

Uruchamianie usług

Przejdź do każdego katalogu aplikacji i uruchom je we własnym środowisku python.

cd user
pipenv install
pipenv shell
python app.py

Powtórz polecenia dla czasu i usługi ping, po czym możesz użyć interfejsu API.

Utwórz niektórych użytkowników:

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

Wyświetl listę utworzonych użytkowników:

curl http://localhost:5000/users

Pobierz bieżącą godzinę:

Get current time:

Uruchom polecenie ping względem example.com:

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

Eksplorowanie bazy danych

Po wywołaniu niektórych funkcji interfejsu API dane są przechowywane i możesz sprawdzić, czy citus_schemas odzwierciedla to, co jest oczekiwane:

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)

Podczas tworzenia schematów nie wskazywaliśmy, na których maszynach należy utworzyć schematy. Zostało to zrobione automatycznie. Zobaczysz, gdzie znajduje się każdy schemat, korzystając z następującego zapytania:

  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

Aby uzyskać zwięzłość przykładowych danych wyjściowych na tej stronie, zamiast używać nodename go jako adresu IP, zastąpimy go hostem lokalnym. Załóżmy, że localhost:7001 jest to węzeł jeden i localhost:7002 jest węzłem drugim.

Widać, że usługa czasu została umieszczona na węźle localhost:7001, podczas gdy usługi użytkownika i ping działają na tym samym drugim węźle localhost:7002. Przykładowe aplikacje są uproszczone, a rozmiary danych w tym miejscu są nieistotne, ale załóżmy, że ma to wpływ na nierówne wykorzystanie miejsca do magazynowania między węzłami. Bardziej sensowne byłoby umieszczenie dwóch mniejszych usług czasu i pinga na jednym węźle, podczas gdy duża usługa użytkownika znajdowałaby się na swoim własnym węźle.

Można łatwo ponownie zrównoważyć klaster według rozmiaru dysku:

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)

Po zakończeniu możesz sprawdzić, jak wygląda nasz nowy układ:

  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)

Zgodnie z oczekiwaniami schematy są przenoszone i mamy bardziej zrównoważony klaster. Ta operacja jest przezroczysta dla aplikacji. Nie trzeba ich nawet ponownie uruchamiać, kontynuują obsługę zapytań.

Następny krok

Dowiedz się więcej o klastrach elastycznych