ФОРМИРОВАНИЕ ЕДИНОГО АНАЛИТИЧЕСКОГО КОНТУРА ДАННЫХ В МИКРОСЕРВИСНОЙ АРХИТЕКТУРЕ НА ОСНОВЕ ЛОГИЧЕСКОЙ РЕПЛИКАЦИИ POSTGRESQL

Автономное хранение данных считается одной из опор микросервисной архитектуры: сервис изменяет свою базу данных независимо и не предоставляет другим компонентам прямой доступ к операциям над хранилищем. Эта граница удобна для разработки, но становится заметной помехой при подготовке сводных отчётов. Один запрос может одновременно требовать сведения об объектах, принадлежащих разным сервисам. Объединение данных путём последовательного обращения к API нескольких микросервисов делает построение отчёта зависимым от доступности каждого из них. Кроме того, реализованную в прикладном коде логику трудно повторно использовать во внешних аналитических системах [2, 3].

В рассматриваемой системе каждый микросервис работает с отдельной базой PostgreSQL. Для общего чтения нужны не все данные, а ограниченный набор таблиц, содержащих необходимые для анализа сущности. Целевой контур должен получить существующие записи, затем принимать изменения строк с минимальной задержкой и корректно обрабатывать INSERT, UPDATE и DELETE. Запись из бизнес-сервисов в агрегирующую базу запрещается. Тем самым она остаётся производной моделью чтения, а не новым владельцем предметных данных.

Объединение через API подходит для единичных экранов, однако плохо масштабируется как источник регулярной отчётности: отказ одного сервиса делает неполным весь ответ, а логика сопоставления данных начинает дублироваться. Пакетный ETL надёжнее изолирует аналитическую нагрузку, но свежесть результата определяется расписанием запуска. Двойная запись из приложения ещё опаснее, поскольку сбой между двумя фиксациями создаёт расхождение. Поэтому для задачи выбран подход, при котором подтверждённые изменения считываются из журнала транзакций после выполнения бизнес-операции.

Логическая репликация PostgreSQL и Debezium используют один общий источник изменений – WAL, но формируют разные модели доставки. Встроенный механизм PostgreSQL сначала копирует содержимое выбранных таблиц, а затем применяет изменения на стороне подписчика. Debezium превращает каждое изменение строки в событие Kafka Connect, благодаря чему поток можно разветвлять, преобразовывать и передавать неоднородным потребителям [1, 4]. Различие важно не столько по скорости переноса, сколько по назначению результата: готовые таблицы для SQL-запросов либо поток событий для интеграционной платформы.

Таблица 1.

Сравнение механизмов синхронизации

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

Практическая топология строится симметрично: в каждой базе-источнике создаётся собственная публикация, а в агрегирующей базе создается подписка на эту публикацию. Такой вариант упрощает диагностику, так как состояние и задержка каждого источника наблюдаются независимо. В публикации перечисляются только таблиц и необходимые типы операций. Для корректной передачи UPDATE и DELETE у таблицы должнен быть указан валидный replica identity, чаще всего первичный ключ. После завершения первичного копирования принимающие таблицы используются исключительно на чтение.

Отдельного проектного решения требует размещение объектов на подписчике. Штатная логическая репликация сопоставляет таблицы по полному имени, включая схему, и не выполняет переименование при доставке [4]. Поэтому одинаковые имена из нескольких баз нельзя без подготовки свести в один public. В предлагаемом варианте предметные области получают уникальные схемы, причём те же имена заранее создаются на стороне источника и получателя. Когда менять исходные схемы нельзя, рациональнее использовать несколько приёмных баз либо CDC-инструмент с маршрутизацией событий.

Рисунок 1. Архитектура консолидации данных микросервисов

Над реплицированным слоем создаются обычные представления для часто повторяющихся соединений и материализованные представления для тяжёлых расчётов. Индексы аналитической базы подбираются под отчёты и не влияют на схемы рабочих сервисов [3].

Внедрение целесообразно начинать не с настройки PostgreSQL, а с карты данных. Для каждого отчёта фиксируются таблицы-владельцы, необходимые столбцы, ключи соединения, допустимая задержка и чувствительность информации. Это защищает контур от привычки реплицировать всё. Затем на получателе создаются совместимые таблицы, поскольку изменения DDL автоматически не передаются. На издателях настраиваются логический уровень WAL, слоты и процессы walsender, а на подписчике резервируются worker-процессы применения [5, 6].

Наиболее рискованный этап – первичная синхронизация. Если принимающая таблица уже содержит строку с тем же уникальным ключом, репликация останавливается на конфликте insert_exists [6]. Такое состояние возникает после ручного наполнения таблицы, повторного запуска подписки поверх старых данных или случайной записи со стороны приложения. Безопасное восстановление начинается с остановки подписки и определения происхождения конфликтующей строки. После этого целевая таблица очищается либо восстанавливается из доверенного снимка, синхронизация запускается повторно, а права на локальную запись отзываются.

Изменение структуры таблиц выполняется как согласованная миграция двух сторон. Новый совместимый столбец сначала появляется у подписчика, затем у издателя. Переименование и удаление лучше разносить по нескольким релизам: прекратить использование старого поля, обновить аналитические представления, изменить обе таблицы и только после проверки убрать прежнюю структуру. Последовательности в поток логической репликации не входят [6]. Поэтому агрегирующая база не должна рассматриваться как готовый резервный узел для внезапного переключения операций записи.

Эксплуатационная пригодность решения определяется наблюдаемостью. На подписчике pg_stat_subscription позволяет увидеть процессы применения и позиции WAL, pg_stat_subscription_stats – накопленные ошибки и конфликты, а pg_subscription_rel – состояние синхронизации отдельных таблиц. На издателях необходимо следить за pg_replication_slots и объёмом WAL, удерживаемого неактивным слотом [5]. Практическими сигналами инцидента служат исчезновение worker-процесса, рост расстояния между полученной и применённой позицией, длительное состояние начального копирования и увеличение дискового пространства под WAL.

Таким образом, отдельная база логической репликации формирует единый аналитический контур, не превращая микросервисы в систему с общей операционной базой. Решение особенно эффективно, когда обе стороны используют PostgreSQL, таблицы переносятся без сложной трансформации, а число потребителей невелико. Его ограничения заранее известны: DDL нужно согласовывать вручную, полные имена объектов должны совпадать, а между источниками сохраняется eventual consistency. Когда требуются преобразование событий, несколько независимых получателей или разные технологии хранения, более оправдан Debezium [1, 4].