#design-patterns #microservices #event-sourcing
Вопрос:
Предположим, у нас есть 2 службы, служба A и служба B. Они взаимодействуют друг с другом с помощью источников событий. Обслуживание события публикации ( объект 1, созданный с полями f1, f2, f3). Услуга B создайте собственную копию сущности 1 с полями f1 и f2. Теперь о том, как мы можем рассмотреть эти два сценария.
- Новое требование в сервисе 2 и потребности в f3. Как service2 должен обновлять свои локальные данные?
- Изменение схемы в службе 1. как служба 2 должна обновлять свои локальные данные и схему?
В сценарии 2 службы тесно связаны схемой и могут вызывать ошибки, что противоречит цели поиска событий. Как мы можем решить эту проблему?
Комментарии:
1. Если вы используете формат схемы, который имеет четко определенные правила эволюции, такие как Avro, то здесь вы не должны сталкиваться с какими-либо конкретными проблемами, поскольку схемы не должны напрямую совпадать
Ответ №1:
Для сценария 1, где представление сущности изменяется, чтобы включить поля, которые были опубликованы в потоке событий, проще всего, вероятно, воспроизвести события (например, если поток событий находится в Кафке, используя новую группу потребителей с auto.offset.reset=earliest ) с обработчиком событий, который использует новое поле. Это часто может быть на удивление быстрым, позволяя запускать это перестроение во временном окне, в котором запущена предыдущая версия службы; в противном случае вы должны иметь возможность запускать старый экземпляр службы B вместе с новым экземпляром (если они записывают в разные базы данных): когда новый экземпляр догоняет, вы переключаете весь трафик, попадающий в службу B, на использование нового экземпляра и разрушаете старый (в основном сине-зеленое развертывание).
Для второго сценария необходимо сделать несколько вариантов:
- Вы можете определить
Entity1CreatedV2событие, которое соответствует новой схеме (это, вероятно, потребует, чтобы пользователи сначала узнали о новом событии). - Если поля в старой схеме не изменились (т. Е. Изменение схемы является строго аддитивным), вы можете сохранить старое
Entity1Createdсообщение, а затем создать событие для новых полей. Обратите внимание, что внесение изменений в схему для существующих объектов в службе A может привести вас к этому решению в любом случае, особенно если для службы A не выполняется поиск команд (поиск команд может позволить вам притвориться, что новая схема существовала вечно).