Применение шаблона CQRS¶

Многие промышленные приложения используют СУРБД в качестве транзакционной системы записей, оставляя полнотекстовые запросы таким системам как Elasticsearch или Solr, либо одновременно записывая данные в обе БД, либо периодически копируя данные из СУРБД в поисковую систему. Такая архитектура использует и транзакционные свойства СУРБД, и возможности полнотекстового поиска.
Обобщенной версией этой архитектуры является CQRS. Идея в том, чтобы запросы выполнялись на особой БД (не обязательно полнотекстовой), куда данные реплицируются от источников.

Потенциальные причины использования CQRS¶

Реализация операции запроса ко многим сервисам¶

Рассмотрим пример: операцию findOrderHistory(), извлекающую историю заказов клиента. Параметры:

• consumerId — ID клиента
• pagination — страница результатов
• filter — фильтр по критериям (напр. давность заказов, статус заказа или ключевые слова)

Запрос возвращает объект OrderHistory, который содержит краткую информацию о заказах, отсортированных по давности в порядке возрастания.

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

Непростой односервисный запрос¶

К примеру, возьмем операцию findAvailableRestaurants(). Она находит рестораны, которые могут доставить еду по заданному адресу в заданное время. В ее основе лежит геопространственный поиск ресторанов, расположенных на определенном расстоянии от адреса доставки.
Ключевой аспект — выполнение эффективного геопространственного поиска. Если так сложилось, что основная БД сервиса Restaurant имеет такую функциональность — нам повезло. Если нет — придется хранить копию данных в БД, имеющую функциональность геопоиска.

Необходимость в разделении ответственности¶

Иногда за реализацию запроса должен отвечать не тот сервис, который владеет нужными данными. Например, ответственность сервиса Restaurant — позволить администрации управлять рестораном. Реализация запроса findAvailableRestaurants() не выглядит как обязанность такого сервиса.
Лучше сделать так, чтобы сервис Restaurant предоставлял данные, а реализацию запроса сделать частью другого сервиса — скорее всего, Order.

Шаблон CQRS¶

Для решения вышеуказанных проблем можно использовать шаблон CQRS. По большому счету CQRS - Это обобщенная разновидность методики использования СУРБД в качестве системы записей, а поисковая система (Elasticsearch) — за полнотекстовый поиск. Отличие в том, что в CQRS применяется более широкий диапазон БД.

Преимущества CQRS¶

Недостатки CQRS¶

Комментарии

Комментарии