Взаимодействие клиента с источником событий

Question

Недавно я изучал источники событий и у меня возникли вопросы по поводу взаимодействия с клиентами.

Так что событийный источник звучит великолепно. Отсоединение всех ваших микросервисов, хранение вашей информации в неизменяемых событиях и составление сохраненных состояний, соответствующих вашим потребностям, действительно удобно. Распространение событий через вашу систему / службы и реагирование на события по-своему - это нормально.

У меня возникла проблема с пониманием взаимодействия с клиентом.

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

Таким образом, вопрос заключается в том, как клиенты запускают определенное событие и взаимодействуют (не только с системой, основанной на событиях), но и с системой, основанной на источнике событий.

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

Так как же работают эти конечные точки?

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

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

Извините, если большая часть всего этого - чепуха, я все еще изучаю эту архитектуру и очень хорошо разбираюсь в монолите с ответами REST.

Любая помощь будет оценена.

Answer 1

Проблема, с которой я сталкиваюсь, связана с пониманием взаимодействия с клиентом.

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

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

Event Sourcing действительно о постоянстве - как микросервер хранит егочастная копия состояния для последующего повторного использования?Вместо того чтобы разрушительно перезаписывать наше предыдущее состояние, мы пишем новую информацию, которая ссылается на предыдущее состояние.Если вы представляете, что каждый микросервис, хранящий каждое изменение состояния в виде коммита в своем собственном git-репозитории, вы находитесь на правильном этапе.

Это отличное от использования Сообщения о событии сообщение для обмена информацией междуодин микросервис и другой.

Конечно, есть некоторые очевидные совпадения, потому что одно сообщение, которым вы, вероятно, поделитесь с другими микросервисами, это «Я только что изменил состояние».

Итаккак работают эти конечные точки?

Так же, как веб-формы.Я отправляю вам представление формы, клиент отображает форму для вас.Вы заполняете свои данные и отправляете форму, клиент обрабатывает содержимое формы и отправляет обратно мне HTTP-запрос с событием «FormSubmitted» в теле сообщения.

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

Когда внешний мир является авторитетом для некоторой части данных (например, адрес доставки покупателя, например,), вы, скорее всего, увидите более традиционный подход «просто отредактируйте существующее представление».

Итак, поскольку это асинхронный процесс, и пользователь запустил и забыл, как вы тогда показываетепользователь это или потерпел неудачу или преуспел?

Fire and forget действительно не работает для распределенного протокола в ненадежной сети.В большинстве случаев важна доставка хотя бы один раз, поэтому Fire until verified является более распространенным вариантом.Первоначальным подтверждением сообщения может быть что-то вроде 202 Accepted - «Мы получили ваше сообщение, записали его, вот наш текущий прогресс, вот несколько ссылок, которые вы можете получить для отчетов о ходе работы».

Мне не кажется, что источник событий соответствует традиционной модели REST, в которой вы используете CRUD-ресурс.

Доклад Джима Уэббера 2011 может помочьудалить шум.REST API - это маскировка того, что носит модель вашего домена;вы обмениваетесь сообщениями о манипулировании ресурсами, и в качестве побочного эффекта ваша модель домена выполняет полезную работу.

Один из способов сделать это, который выглядел бы более «традиционным», - это работать с представлениями потока событий.Я делаю GET /08ff2ec9-a9ad-4be2-9793-18e232dbe615, и он возвращает мне представление списка событий.Я добавляю новое событие в конец этого списка, и PUT /08ff2ec9-a9ad-4be2-9793-18e232dbe615, и происходят интересные побочные эффекты.Или, возможно, вместо этого я создаю документ исправления, описывающий мои изменения, и PATCH /08ff2ec9-a9ad-4be2-9793-18e232dbe615.

Но, скорее всего, я бы сделал что-то другое - вместо GET /08ff2ec9-a9ad-4be2-9793-18e232dbe615, чтобы получить представление списка событий,Вероятно, я бы GET /08ff2ec9-a9ad-4be2-9793-18e232dbe615 получил представление доступных протоколов, то есть документ, заполненный гиперссылками.Оттуда я мог бы GET /08ff2ec9-a9ad-4be2-9793-18e232dbe615/603766ac-92af-47f3-8265-16f003ce5a09 получить представление о форме сбора данных.Я заполняю детали своего мероприятия, отправляю форму и POST /08ff2ec9-a9ad-4be2-9793-18e232dbe615 данные формы на сервер.

Вы, конечно, можете использовать любое написание для URI.

В первом случае нам нужно что-то вроде редактора документов с поддержкой HTTP; во втором случае используется нечто большее, чем веб-браузер.

Если было много разных видов событий, то во втором случае вполне может быть много разных ресурсов формы, все из которых отправляют POST /08ff2ec9-a9ad-4be2-9793-18e232dbe615 запросов.

(У вас нет , чтобы все формы отправлялись на один и тот же URI, но есть преимуществ для рассмотрения ).

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

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