Микросервисная архитектура в последние годы приобрела большую популярность. Но, несмотря на все ее преимущества, у нее есть и некоторые проблемы. Одна из них — сбор необходимых данных для передачи во фронтэнд. Здесь напрашивается простое и интуитивное решение — паттерн API composition (композиция API). Это решение данной проблемы, но не идеальное. Например, в случае высоконагруженных и высокодоступных систем, вызов нескольких сервисов для создания только одного представления может быть неприемлемым. Нужно придумать что-то другое. Давайте попробуем CQRS.
CQRS
Паттерн CQRS, описанный Крисом Ричардсоном, — альтернатива API Composition. Вместо сбора информации из нескольких источников создается специализированная read-модель (модель чтения, модель представления), хранящая всю необходимую информацию. Read-модель представляет собой отдельную базу данных, используемую только Edge-сервисом (пограничный сервис) и, по сути, дублирующую данные. На рисунке ниже приведен пример, как может выглядеть высокоуровневая архитектура такого подхода.
Однако CQRS — не избавит от всех проблем, связанных с запросами в микросервисной архитектуре. Наполнение read-модели — довольно простая задача. Изменение схемы базы данных (например, добавление нового поля, которое должно отображаться в пользовательском интерфейсе) — куда сложнее.
Построение read-модели
Давайте посмотрим на рисунок ниже. У обоих событий (SomethingHappened, SomethingElseHappened) простая структура из двух полей. Но, допустим, нам нужна только часть информации каждого события. За извлечение необходимой информации из события и добавление его к соответствующей записи в базе данных отвечает Edge-сервис. Запись в БД мы идентифицируем по id доменного события.
В конце концов, когда мы обработаем все доменные события, будет построена первая версия read-модели, которую можно использовать для передачи данных в UI. Обратите внимание, здесь мы предполагали доступность всех доменных событий, но это не всегда так. Причины этого рассмотрим далее.
Возможные проблемы с read-моделью
Недоступность данных
Продукт развивается, и со временем выясняется, что в UI необходимо передать дополнительные данные. Допустим, в событие SomethingHappened добавляется еще одно поле.
На первый взгляд, решение этой проблемы относительно просто:
Повторно обрабатываем все события соответствующего типа.
Находим в базе данных read-модели запись по
idсобытия.Обновляем запись в read-модели.
К сожалению, велик риск, что такое наивное решение не сработает. Например, некоторые события к этому моменту могут быть удалены брокером сообщений. При использовании Apache Kafka срок хранения по умолчанию равен семи дням. В случае AWS Kinesis Data Streams — всего 24 часа. Если мы заранее не предусмотрели такой сценарий, то теперь у нас связаны руки. Здесь нет идеального и красивого решения. Но все-таки как мы можем решить эту новую проблему?
Можно вернуться к паттерну API Composition, но он неразрывно связан с предположением, что сервис, публикующий события
SomethingHappened, предоставляет API для чтения интересующей нас сущности. Это не всегда так.Если доменные события сохраняются в постоянное хранилище и доступны нам, то у нас еще есть надежда. Иначе мы пропали и будем вынуждены применять "грязные" решения.
Изменения формата события
Предположим, мы построили и заполнили нашу read-модель, обработав все необходимые доменные события. Но тем временем продюсер событий внес изменения в схему события.
С точки зрения потребителя, появились две проблемы:
Если мы хотим сохранить информацию, переданную в поле x, то нам нужно как-то найти это поле в старых событиях. Это та же проблема, описанная выше.
Необходимо реализовать свой десериализатор (а может и не один), чтобы быть уверенным, что мы сможем десериализовать все сообщения в потоке. Это не только дополнительная работа, которую нужно сделать, но она может оказаться и не такой простой, поскольку у событий разные несовместимые схемы. Также стоит отметить, что реализация кастомного десериализатора — это не разовое действие. Скорее всего, потребуется постоянно вносить в него изменения, потому что схемы сообщений будут меняться.
Очередность событий
Рассмотрим случай, когда для построения read-модели потребуется несколько доменных событий.
CompanyCreated
{
"id": "68d2a8d8-eea1-44ea-bbd3-1533f223b0f4",
"taxOfficeId": "de6a9b5a-e74c-4145-bfd0-71e3e6ee7689",
"name": "Easy Invoicing",
"size": 100
}TaxOfficeClerkChanged
{
"id": "de6a9b5a-e74c-4145-bfd0-71e3e6ee7689",
"name": "John Doe"
}В нашей системе выставления счетов требуется отображать на дашборде название компании, ее размер и имя сотрудника налоговой инспекции, которому мы подчиняемся.
{
"companyId": "68d2a8d8-eea1-44ea-bbd3-1533f223b0f4",
"taxOfficeId": "de6a9b5a-e74c-4145-bfd0-71e3e6ee7689",
"companyName": "Easy Invoicing",
"companySize": 100,
"taxOfficeClerkName": "John Doe"
}В этом случае нам нужно убедиться, что событие CompanyCreated мы получили перед событием TaxOfficeClerkChanged. Можно решить эту проблему, сохраняя события TaxOfficeClerkChanged в отдельной временной базе данных, и искать в ней имя клерка при получении события CompanyCreated. Однако стоит отметить, что в этом случае мы значительно увеличиваем дублирование данных, возможно, создавая новые проблемы, которые всплывут в будущем. Например, если событие TaxOfficeClerkChanged содержит персональные данные, и мы сохранили их, то нам нужно это учитывать при обсуждении вопросов соответствия GDPR.
Утечка знаний о предметной области
Помимо чисто технических моментов, описанных ранее, есть еще один, который не виден сразу. Рассмотрим следующий сценарий:
Продюсер генерирует событие
InvoicePaid(счет оплачен), в котором присутствует информация об оплаченной сумме.Мы обрабатываем это событие и, исходя из оплаченной суммы, списываем часть денег со счета клиента.
На стороне продюсера происходят изменения: появляется новый способ оплаты с покупкой в рассрочку. Клиент оплачивает счет и генерируется событие
InvoicePaid. Счет оплачен и нам неважно, кто оплатил счет (банк или клиент). Отличие только в том, что теперь мы не должны списывать всю сумму со счета единовременно, а делать это частями ежемесячно.Допустим, мы не знали об этом изменении и не внесли правок на нашей стороне. В итоге пользователи увидят как новый договор с банком, так и списание полной суммы с их счета. Это серьезная проблема, мы бы не хотели, чтобы наши клиенты хоть на мгновение сомневались в том, что мы можем управлять их деньгами.
Приведенный выше пример показывает, что, даже если мы преодолеем все ранее описанные проблемы, все равно что-то может пойти не так. Однако между этими двумя проблемами есть существенная разница. Первую мы сможем обнаружить при функциональном тестировании, а в случае утечки знаний предметной области, как бы мы ни старались, не поймаем ошибку, так как на момент тестирования все работает нормально…
Альтернативное решение
Как было показано, построение read-модели на основе доменных событий может оказаться долгим и чреватым ошибками. Хотя это не значит, что нет безопасного способа для ее построения. Вместо использования доменных событий можно использовать события сущности (entity event). Они, наряду с другими интересными концепциями, описаны в статье, посвященной Data Mesh. Если вкратце, то на основе событий сущности можно создать полный снимок измененной сущности. Каждое изменение может инициировать как доменные события, так и события сущности. Первые из них используются для организации бизнес-процессов. Вторые — для аналитических целей, а также для построения read-моделей.
Заключение
В заключение я бы хотел сказать, что, конечно, вы можете и не встретиться с указанными проблемами при построении read-модели на основе доменных событий. Однако поднятые мною вопросы не выдуманы. Они встретились в моей практике, и я хотел бы рассказать вам о них. Спасибо, что дочитали до конца и удачных экспериментов!
Приглашаем всех желающих на открытое занятие «Микросервисная архитектура – когда нужна, а когда нет?». На занятии рассмотрим плюсы и минусы монолитов и микросервисов. Рассмотрим боли при двух подходах, а также основные паттерны в микросервисной архитектуре. Записаться можно по ссылке.
