Совместно ли хранилище событий между разными микросервисами? Или существует несколько независимых баз данных хранилищ событий для каждого микросервиса и один общий брокер событий?
С их точки зрения, каждый микросервис должен писать в собственное хранилище событий. Это может означать отдельные экземпляры или отдельные разделы внутри одного и того же экземпляра. Это позволяет масштабировать микросервисы независимо.
Если первый вариант является решением, используя CQRS, я могу теперь предположить, что каждая база данных микросервиса предназначена для работы на стороне запроса, а общее хранилище событий находится на стороне команды. Это неправильное предположение?
Вроде. Как я уже писал выше, каждый микросервис должен иметь собственное хранилище событий (или раздел внутри общего экземпляра). Микрослужба не должна добавлять события в другое хранилище событий микросервиса.
Что касается мероприятий по чтению, я считаю, что мероприятия по чтению в целом должны быть разрешены. Опрос хранилища событий - это простейшее (и, на мой взгляд, лучшее) решение для распространения изменений на другие микросервисы. Его преимущество заключается в том, что удаленный микросервис опрашивает с той скоростью, с которой он может, и с тем, какие события он хочет. Это можно очень хорошо масштабировать, создавая реплики хранилища событий, сколько это необходимо.
В некоторых случаях вы не хотите публиковать каждое событие домена из хранилища событий. Некоторые говорят, что могут существовать внутренние события домена, от которых другие микросервисы не должны зависеть. В этом случае вы можете пометить события как бесплатные (или нет) для внешнего использования.
Самым чистым решением для распространения изменений в микросервисе является наличие оперативных запросов, на которые могут подписаться другие микросервисы. Его преимущество состоит в том, что логика проекции не проникает в другие микросервисы, но также имеет тот недостаток, что порождающий микросервис должен определять + реализовывать эти запросы; вы можете сделать это, когда заметите, что другие микросервисы дублируют логику проекции. Примером этого запроса является общая стоимость заказа в приложении электронной коммерции. У вас может быть такой запрос WhatIsTheTotalPriceOfTheOrder, который публикуется каждый раз, когда элемент добавляется / удаляется / обновляется в Заказе.
И раз уж мы в теме: сколько попыток мне нужно сделать в случае одновременной записи в Stream с использованием оптимистической блокировки?
Столько, сколько вам нужно, то есть до тех пор, пока запись не завершится успешно. У вас может быть ограничение в 99999, чтобы вы могли обнаруживать, когда что-то ужасно не так с механизмом повтора. В любом случае одновременную запись следует повторить только тогда, когда запись выполняется одновременно в том же потоке (для одного экземпляра Aggregate), а не для всего хранилища событий.
person
Constantin Galbenu
schedule
28.09.2018
