Блог

Я новичок в поиске событий, и у меня на уме несколько вопросов. Вот пример диаграммы.

1. Допустим, у нас есть 2 экземпляра service BookShop и 2 экземпляра service Wallet. Пользователь просит BookService_1 купить ему книгу. Эта служба book создает событие BuyBookRequestCreated и отправляет его на шину событий. Шина событий отправляет это событие в два экземпляра service Wallet. Теперь два экземпляра пытаются зарезервировать достаточно денег из кошелька пользователя, и оба они генерируют событие BookMoneyReserved? Теперь, с другой стороны, два экземпляра сервисов книжного магазина получают 2 события, и оба они пытаются выдать событие BookBought? Или, может быть, eventbus отправит BuyBookRequestCreated только одному подписчику? Но что тогда происходит, когда эта выбранная служба выходит из строя?

2. Как этот шаблон обрабатывается с точки зрения потребителя API? Если я обращаюсь к какому-либо API, чтобы купить мне книгу, я ожидаю, что он «вернет 200», когда книга будет куплена. В шаблоне поиска событий нет ожидания ответа от других служб, поэтому в случае, если какая-либо другая служба должна выдать событие для завершения покупки книги, невозможно сообщить клиенту, действительно ли его покупка завершилась неудачей или нет.

3. Я немного потерялся во всем мире микросервисов. С одной стороны, у нас есть Grpc, protobufs и service mesh, но с другой стороны, у нас есть источники событий и архитектура, управляемая событиями. Когда использовать что? И из того, что я вижу и могу понять, я мог бы использовать источники событий и grpc вместе? Я мог бы просто использовать grpc для связи с сервисами beetwen и сохранять события как форму сохранения состояния, или, может быть, я просто не понял этого и должен снова прочитать статьи?

Спасибо за помощь.

Я не понимаю источник событий

Это не ваша вина. Литература отстой.

Вот пример диаграммы.

Итак, самый важный урок, который я могу дать вам об этой схеме: она не имеет ничего общего с источником событий. Это имеет довольно много общего с обменом сообщениями, распределенными системами и управляемыми событиями. Но источники событий — это другое животное.

На высоком уровне фундаментальная проблема заключается в том, что распределенные системы несовершенны. Поэтому нам нужно принять это как ограничение в наших проектах и работать с ним. Воспоминания, догадки и извинения Пэта Хелланда — хорошая отправная точка.

При нормальной работе у нас никогда не было бы двух сервисов кошельков, выполняющих одну и ту же работу. Возможно, они разделяют работу (во многом так же, как книжные службы разделяют работу с балансировщиком нагрузки).

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

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

Для других проблем ответ заключается в том, что какой-то человек звонит по телефону и сообщает кому-то другому, что произошла ошибка, и можем ли мы что-то исправить?