Внедрение AWS Event-Sourcing

Question

Я довольно новичок в микросервисах и Event-Sourcing, и я пытался найти способ развертывания всей системы на AWS.

Насколько я знаю, есть два способа реализацииУправляемая событиями архитектура:

• Использование AWS Kinesis Data Stream
• Использование AWS SNS + SQS

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

Первое имеет следующие преимущества:

• Заказ сообщений
• По крайней мере, одна доставка

Но недостатки весьма проблематичны:

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

Второй имеет следующие преимущества:

• Полностью управляется
• Очень высокий TPS
• Подписка на темы
• Функциональность видимости сообщений

Недостатки:

• Сообщения SQS - это упорядочение по принципу наилучшего возможного, но они еще не знают, что они означают.В нем говорится: «Стандартная очередь делает все возможное, чтобы сохранить порядок сообщений, но более одной копии сообщения может быть доставлено не по порядку».Означает ли это, что предоставление n копий сообщения первой копии доставляется по порядку, тогда как остальные доставляются неупорядоченными по сравнению с копиями других сообщений?Или «больше, чем один» может быть «всем»?

Большое спасибо за любые советы!

Answer 1

I'm quite a newbe in microservices and Event-Sourcing

Просмотрите доклад Грега Янга Данные Polygot , чтобы получить более полное представление о том, что следует далее.

Для обмена событиями через границы служб предусмотрено два основных подхода - модель push и модель pull.Для подписчиков, которые заботятся о порядке событий, модель pull проще поддерживать.

Основная идея заключается в том, что каждый подписчик отслеживает свою собственную верхнюю отметку для количества обработанных событий в потоке,и запрашивает упорядоченное представление списка событий для получения обновлений.

В AWS вы обычно получаете это представление, запрашивая полномочный сервис для обновленного списка событий (реализация которого может включать в себя разбиение на страницы).Служба может предоставить список событий, выполнив запрос к DynamodB напрямую или получив последний ключ от DynamoDB, а затем просмотрев кэшированные представления событий в S3.

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

Я бы обычно достигал SNS (fan-out) для трансляции уведомлений.Потребители, которым нужна поддержка бухгалтерии, для которых обработанные уведомления будут использовать SQS.Но основным каналом для передачи упорядоченных событий является тяга.

Я сам не слишком внимательно смотрел на Кинезис - в предыдущих вопросах есть общее обсуждение *1019* - но я думаю, что Кевин Сукочефф начто-то, когда он пишет

... если вы покопаетесь немного глубже, вы обнаружите, что Kinesis хорошо подходит для очень конкретного варианта использования, а если ваше приложение не подходит для этого варианта использования, Kinesisможет быть намного больше проблем, чем стоит.

Основным вариантом использования Kinesis является сбор, хранение и обработка непрерывных потоков данных в реальном времени.Потоки данных - это данные, которые непрерывно генерируются тысячами источников данных, которые обычно отправляют записи данных одновременно и в небольших размерах (порядка килобайт).

Another thing: the fact that I'm accessing data from another 
microservice stream is an anti-pattern, isn't it?

Ну, частьСмысл деления системы на микросервисы состоит в том, чтобы уменьшить связь между возможностями системы.Доступ к данным через границы микросервиса увеличивает связь.Так что здесь есть некоторая напряженность.

But basically if I'm using a pull model I need to read 
data from other microservices' stream. Is it avoidable?

Если вы запрашиваете информацию в службе, которая вам нужна, вместо того, чтобы самостоятельно выкапывать ее из потока, вы уменьшаете связь - так же, как запрашивая данные у службы, а нечем войти в СУБД и самостоятельно запросить таблицы.

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

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