#microservices #grpc #event-sourcing
#микросервисы #grpc #источник событий
Вопрос:
Я новичок в поиске событий, и у меня на уме несколько вопросов. Вот пример диаграммы.
-
Допустим, у нас есть 2 экземпляра service BookShop и 2 экземпляра service Wallet. Пользователь просит BookService_1 купить ему книгу. Эта служба book создает событие BuyBookRequestCreated и отправляет его на шину событий. Шина событий отправляет это событие в два экземпляра service Wallet. Теперь два экземпляра пытаются зарезервировать достаточно денег из кошелька пользователя, и оба они генерируют событие BookMoneyReserved? Теперь, с другой стороны, два экземпляра сервисов книжного магазина получают 2 события, и оба они пытаются выдать событие BookBought? Или, может быть, eventbus отправит BuyBookRequestCreated только одному подписчику? Но что тогда происходит, когда эта выбранная служба выходит из строя?
-
Как этот шаблон обрабатывается с точки зрения потребителя API? Если я обращаюсь к какому-либо API, чтобы купить мне книгу, я ожидаю, что он «вернет 200», когда книга будет куплена. В шаблоне поиска событий нет ожидания ответа от других служб, поэтому в случае, если какая-либо другая служба должна выдать событие для завершения покупки книги, невозможно сообщить клиенту, действительно ли его покупка завершилась неудачей или нет.
-
Я немного потерялся во всем мире микросервисов. С одной стороны, у нас есть Grpc, protobufs и service mesh, но с другой стороны, у нас есть источники событий и архитектура, управляемая событиями. Когда использовать что? И из того, что я вижу и могу понять, я мог бы использовать источники событий и grpc вместе? Я мог бы просто использовать grpc для связи с сервисами beetwen и сохранять события как форму сохранения состояния, или, может быть, я просто не понял этого и должен снова прочитать статьи?
Спасибо за помощь.
Комментарии:
1. Интеграция, управляемая событиями, не является источником событий. Проверьте это youtube.com/watch?v=STKCRSUsyP0 и , может быть , eventstore.com/blog/what-is-event-sourcing и некоторые из наших прошлых вебинаров eventstore.com/webinars
Ответ №1:
Я не понимаю источник событий
Это не ваша вина. Литература отстой.
Вот пример диаграммы.
Итак, самый важный урок, который я могу дать вам об этой схеме: она не имеет ничего общего с источником событий. Это имеет довольно много общего с обменом сообщениями, распределенными системами и управляемыми событиями. Но источники событий — это другое животное.
На высоком уровне фундаментальная проблема заключается в том, что распределенные системы несовершенны. Поэтому нам нужно принять это как ограничение в наших проектах и работать с ним. Воспоминания, догадки и извинения Пэта Хелланда — хорошая отправная точка.
При нормальной работе у нас никогда не было бы двух сервисов кошельков, выполняющих одну и ту же работу. Возможно, они разделяют работу (во многом так же, как книжные службы разделяют работу с балансировщиком нагрузки).
Один из способов совместного использования работы — присвоить каждому сообщению уникальный номер; верхний кошелек обрабатывает сообщения с нечетными номерами и игнорирует четные сообщения, нижний кошелек обрабатывает четные сообщения и игнорирует сообщения с нечетными номерами.
Конечно, нормальная работа — это то, чего вы хотите, но не обязательно то, что вы получаете — в конце концов, распределенные системы несовершенны. Для решения некоторых проблем существуют удобные шаблоны — блокировка или идемпотентная обработка сообщений — и ваша система может продолжать приносить пользу бизнесу.
Для других проблем ответ заключается в том, что какой-то человек звонит по телефону и сообщает кому-то другому, что произошла ошибка, и можем ли мы что-то исправить?
Комментарии:
1. Кажется, я начинаю понимать. Я перепутал источники событий и события домена. Связь с событиями — это службы! = источник событий, но поскольку на большинстве лекций в Интернете эти два показаны вместе, это смешалось в моей голове как единая концепция.
2. @Arczewski Абсолютно. Источник событий — это просто механизм сохранения данных. Речь идет о сохранении потока «фактов» о вашем домене (например, «CustomerSignedUp», «CustomerCreditLimitIncreased», «CustomerMovedAddress»), Которые могут быть «воспроизведены» для построения текущего состояния совокупности доменов (например, Клиент, заказ на продажу, продукт и т. Д.). Ничто в источниках событий не требует, чтобы сообщения отправлялись по сети, однако на самом деле большинство систем с источниками событий также являются распределенными системами и поэтому также асинхронно обмениваются сообщениями.
3. @VoiceOfUnreason не уверен, почему литература отстой. Я оптимистично предполагаю, что в моей книге достаточно информации о источниках событий. В блоге магазина событий мы опубликовали несколько статей, объясняющих, что такое источник событий. Я согласен, что многие сообщения в блогах не приносят пользы людям, рассказывая странные вещи о источниках событий, но это справедливо и в отношении других вещей.