Проблема, с которой я сталкиваюсь, связана с пониманием взаимодействия с клиентом.
Возможно, некоторые проблемы связаны с пониманием, но я обещаю, что справедливая доля проблемы заключается в том, что литература отстой .
В частности, слово «Событие» повторно используется множеством разных способов.Если вы не будете обращать особого внимания на то, какое значение используется, вы получите узел.
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, но есть преимуществ для рассмотрения ).
В шаблоне, не связанном с источником событий, я предполагаю, что сначала он будет помещен в базу данных, а затем событие будет вызвано.
Даже если вы не являетесь источником событий, все же может иметь некоторые преимущества для фиксации событий в вашем магазине длительного пользования перед их отправкой. См. Пэт Хелланд: Данные снаружи и данные внутри .