Микросервисы. Используется ли технология хранилища событий (в решениях поиска источников) для всех микросервисов? - PullRequest
0 голосов
/ 27 сентября 2018

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

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

Совместно ли хранилище событий используется разными микросервисами?Или есть несколько независимых баз данных хранилищ событий для каждого микросервиса и одного распространенного посредника событий?

Если первым вариантом является решение, используя CQRS, я могу теперь предположить, что база данных каждого микросервиса предназначена как сторона запроса, в то время какхранилище общих событий находится на командной стороне.Это неверное предположение?

И поскольку мы находимся в теме: сколько повторных попыток мне нужно сделать в случае одновременной записи в поток с использованием оптимистической блокировки?

Очень большой большойЗаранее благодарим за каждый совет, который вы можете мне дать!

Ответы [ 2 ]

0 голосов
/ 28 сентября 2018

Распространено ли хранилище событий между различными микросервисами?Или существует несколько независимых баз данных хранилищ событий для каждого микросервиса и одного общего посредника событий?

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

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

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

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

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

Самым чистым решением для распространения изменений в микросервисе является наличие активных запросов, на которые могут подписаться другие микросервисы.Преимущество состоит в том, что логика проецирования не проникает в другие микросервисы, но также имеет тот недостаток, что микросервис-эмитент должен определять + реализовывать эти запросы;Вы можете сделать это, когда заметите, что другие микросервисы дублируют логику проецирования.Примером этого запроса является общая цена заказа в приложении электронной коммерции.У вас может быть такой запрос WhatIsTheTotalPriceOfTheOrder, который публикуется каждый раз, когда элемент добавляется / удаляется из / обновляется в Заказе.

И поскольку мы находимся в теме: сколько повторов ячто делать в случае одновременной записи в поток с использованием оптимистической блокировки?

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

0 голосов
/ 28 сентября 2018

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

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

Выражается иначе: службы общаются друг с другом, обмениваясь информацией.через общедоступные API , а не путем записи сообщений в базы данных друг друга.

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

...