Микросервисы. Используется ли технология хранилища событий (в решениях поиска источников) для всех микросервисов?
Насколько мой небольшой текущий опыт позволяет мне понять, одно из основных понятий о "микросервисе" заключается в том, что он опирается на свою собственную базу данных, независимую от других микросервисов.
Углубляясь в то, как обрабатывать распределенные транзакции в системе микросервисов, кажется, что лучшей стратегией является паттерн Event Sourcing, ядром которого является Event Store.
Распределяется ли хранилище событий между различными микросервисами? Или существует несколько независимых баз данных хранилищ событий для каждого микросервиса и одного общего посредника событий?
Если первым вариантом является решение, используя CQRS, я могу теперь предположить, что база данных каждого микросервиса предназначена для стороны запросов, в то время как общее хранилище событий находится на стороне команд. Это неправильное предположение?
И поскольку мы находимся в теме: сколько повторных попыток мне нужно сделать в случае одновременной записи в поток с использованием оптимистической блокировки?
Большое спасибо заранее за каждый совет, который вы можете дать мне!
3 ответа
Распределяется ли хранилище событий между различными микросервисами? Или существует несколько независимых баз данных хранилищ событий для каждого микросервиса и одного общего посредника событий?
Каждый микросервис должен писать в свой собственный магазин событий, с их точки зрения. Это может означать отдельные экземпляры или отдельные разделы внутри одного экземпляра. Это позволяет микросервисам масштабироваться независимо.
Если первым вариантом является решение, используя CQRS, я могу теперь предположить, что база данных каждого микросервиса предназначена для стороны запросов, в то время как общее хранилище событий находится на стороне команд. Это неправильное предположение?
Своего рода. Как я писал выше, каждый микросервис должен иметь свое собственное хранилище событий (или раздел внутри общего экземпляра). Микросервис не должен добавлять события в другое хранилище событий микросервиса.
Что касается чтения событий, я думаю, что чтение событий в целом должно быть разрешено. Опрос хранилища событий - самое простое (и, на мой взгляд, лучшее) решение для распространения изменений на другие микросервисы. Он имеет преимущество в том, что удаленный микросервис опрашивает с той скоростью, с которой он может, и какие события он хочет. Это можно очень хорошо масштабировать, создавая копии хранилища событий настолько, насколько это необходимо.
В некоторых случаях вы не хотите публиковать каждое событие домена из хранилища событий. Некоторые говорят, что могут существовать события внутреннего домена, от которых другие микросервисы не должны зависеть. В этом случае вы можете пометить события как свободные (или нет) для внешнего потребления.
Самое чистое решение для распространения изменений в микросервисе состоит в том, чтобы иметь прямые запросы, на которые могут подписаться другие микросервисы. Преимущество заключается в том, что логика проецирования не проникает в другие микросервисы, но также имеет тот недостаток, что микросервис-эмитент должен определять + реализовывать эти запросы; Вы можете сделать это, когда заметите, что другие микросервисы дублируют логику проецирования. Примером этого запроса является общая цена заказа в приложении электронной коммерции. Вы могли бы иметь такой запрос WhatIsTheTotalPriceOfTheOrder это публикуется каждый раз, когда элемент добавляется / удаляется / обновляется в Заказе.
И поскольку мы находимся в теме: сколько повторных попыток мне нужно сделать в случае одновременной записи в поток с использованием оптимистической блокировки?
Столько, сколько вам нужно, т.е. пока запись не удастся. Вы можете иметь ограничение в 99999, просто чтобы обнаружить, когда что-то ужасно неправильно с механизмом повтора. В любом случае одновременная запись должна быть повторена только тогда, когда запись выполняется одновременно в одном и том же потоке (для одного экземпляра Aggregate), а не для всего хранилища событий.
Как правило: в сервисных архитектурах, включающих микросервисы, каждый сервис отслеживает свое состояние в частной базе данных.
"Приватный" здесь в первую очередь означает, что никакая другая служба не имеет права писать или читать из нее. Это может означать, что каждая служба имеет свой собственный выделенный сервер базы данных, или службы могут использовать одно устройство, но иметь разрешения на доступ только для своей части.
Выражается иначе: сервисы общаются друг с другом, обмениваясь информацией через общедоступные API, а не записывая сообщения в базы данных друг друга.
Для сервисов, использующих источники событий, каждый сервис имел бы доступ для чтения и записи только к своим потокам. Если эти потоки хранятся в одном доме - хорошо; но корректность системы не должна зависеть от разных служб, хранящих свои события на одном устройстве.
TL; DR: все эти шаблоны применяются к единственному ограниченному контексту (сервису, если хотите), не распространяйте события домена за пределы вашего ограниченного контекста, не публикуйте события интеграции на ESB (корпоративную служебную шину) или что-то подобное, как общедоступный интерфейс.
Итак, у нас есть три шаблона, которые мы кратко рассмотрим по отдельности, а затем вместе.
- Микросервисы
- CQRS
- Поиск событий
Микросервисы
https://docs.microsoft.com/en-us/azure/architecture/microservices/ Основная цель: изолировать и отделить изменения в системе от отдельных служб, обеспечивая независимое развертывание и тестирование без побочного воздействия. Это достигается за счет инкапсуляции изменений за общедоступным API и ограничения зависимостей времени выполнения между сервисами.
CQRS
https://docs.microsoft.com/en-us/azure/architecture/patterns/cqrs Основная цель: изолировать и отделить проблемы записи от проблем чтения в одной службе. Этого можно достичь несколькими способами, но основная идея заключается в том, что модель чтения - это проекция модели записи, оптимизированной для запросов.
Поиск событий
https://docs.microsoft.com/en-us/azure/architecture/patterns/event-sourcing Основная цель: использовать правила бизнес-домена в качестве модели данных. Это достигается путем моделирования состояния в виде потока неизменяемых событий домена только для добавления и восстановления текущего агрегированного состояния путем воспроизведения потока с самого начала.
Все вместе
Здесь много отличного контента https://docs.microsoft.com/en-us/previous-versions/msp-np/jj554200(v=pandp.10) Каждый из них имеет свою сложность, компромиссы и проблемы, и, хотя это увлекательное упражнение, вам следует подумать, превосходит ли затраты выгоды. Все они применяются в рамках одной услуги или ограниченного контекста. Как только вы начинаете разделять хранилище данных между сервисами, вы открываете для себя проблемы, поскольку общее хранилище данных не может быть изменено изолированно, поскольку теперь это общедоступный интерфейс.
Скорее попробуйте опубликовать события интеграции на общей шине в качестве общедоступного интерфейса для других служб и ограниченных контекстов, которые можно использовать и использовать для построения проекций данных контекстов других доменов.