Надежный обмен данными микросервисов с потоковой базой данных

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

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

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

Потребность в надежном обмене данными микросервисов

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

Традиционная синхронная связь между микросервисами может привести к жесткой связи и потенциальным проблемам с производительностью и надежностью. Отправляющая служба должна знать местоположение, интерфейс и контракт других микрослужб, что может привести к сложной сети зависимостей. Это может затруднить разработку, тестирование и независимое развертывание микросервисов, поскольку любое изменение в одном микросервисе может потребовать изменений в нескольких зависимых микросервисах. Иногда эти целевые службы могут быть временно недоступны и могут привести к снижению производительности из-за необходимости ожидания и блокировки до получения ответа.

Асинхронный и развязанный обмен данными

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

Исходящие сообщения микрослужбы затем обрабатываются обработчиком исходящих сообщений (отдельным компонентом или службой, например потоковой базой данных RisingWave, которая описана в разделе ниже), который считывает события или изменения из исходящих сообщений и отправляет их в другие микрослужбы или хранилища данных. асинхронно. Это позволяет микросервисам продолжать обработку запросов, не дожидаясь завершения обмена данными, что приводит к повышению производительности и масштабируемости .

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

Теперь давайте посмотрим, как можно реализовать паттерн Outbox с помощью потоковой базы данных на примере RisingWave. На рынке есть и другие варианты потоковой базы данных; Этот пост поможет вам понять, что такое база данных потоковой передачи, когда и зачем ее использовать , а также обсудит некоторые ключевые факторы, которые следует учитывать при выборе правильной базы данных потоковой передачи для вашего бизнеса.

RisingWave 

RisingWave — это потоковая база данных, которая помогает создавать сервисы, управляемые событиями, в реальном времени. Он может напрямую считывать события изменения базы данных из традиционных бинарных журналов баз данных или тем Kafka и создавать материализованное представление, объединяя несколько событий вместе. RisingWave будет обновлять представление по мере поступления новых событий и позволит вам запрашивать с помощью SQL, чтобы иметь доступ к последним изменениям, внесенным в данные.

Шаблон исходящих сообщений с потоковой базой данных

База данных потоковой передачи может действовать как платформа потоковой передачи в реальном времени (процессор исходящих сообщений). Он прослушивает любые операции записи/обновления в указанной таблице базы данных, используя встроенный коннектор Change Data Capture (CDC) , фиксирует изменения и распространяет эти изменения на другие микросервисы в режиме реального времени или почти в реальном времени с помощью Kafka.

Одним из ключевых преимуществ использования потоковой базы данных является то, что вам не нужно использовать и Debezium, и Kafka Connect, чтобы добиться того же. Кроме того, у него есть собственное хранилище, вы никогда не потеряете потоковые данные и можете создавать материализованные представления, оптимизированные для запросов к микросервисам, что объясняется в другом посте в DST Club.

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

Вот как может работать обмен данными с шаблоном «Исходящие» и потоковой базой данных для нашего примера службы заказа такси:

Служба Ride (микрослужба A). Когда пользователь запрашивает поездку, служба Ride создает сведения о поездке и записывает событие, например RideRequested, в свою таблицу исходящих сообщений в собственной базе данных, скажем, в MySQL.

По умолчанию база данных потоковой передачи захватывает событие «RideRequested» из исходящей таблицы Ride Service, используя свой коннектор для MySQL CDC . Он обрабатывает событие и отправляет его другим микрослужбам, которые необходимо обновить, таким как служба драйверов (микрослужба B), служба платежей (микрослужба C) и служба уведомлений (микрослужба D), используя брокер сообщений, такой как Apache Kafka.

Служба водителя (микрослужба B). Служба водителя получает событие RideRequested от процессора исходящих сообщений и находит доступного водителя для поездки на основе сведений о поездке. Затем он записывает событие, такое как «DriverAssigned», в свой собственный почтовый ящик.

Платежная служба (микрослужба C). Платежная служба также получает событие «RideRequested» из другой темы Kafka и рассчитывает стоимость поездки на основе сведений о поездке. Затем он записывает событие, например «FareCalculated», в свой собственный почтовый ящик.

Мы можем создать несколько тем Kafka, чтобы предоставить потребительским службам возможность подписываться только на определенные типы событий.

Заключение

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