Микросервисная архитектура CQRS

Question

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

. Я думаю о разработке решений следующим образом:

1. Использование шаблона CQRS, чтобы можно было легко разделять запросы и команды.,На данный момент у меня есть 2 конечные точки для этого
2. У меня есть «ручной» шлюз API, который будет выступать в качестве прокси для различных микросервисов, которые мне понадобятся
3. Используйте NServiceBus для связи междуmicroservices

Вопросы:

1. Я думаю об использовании Redis для кэширования запросов.Например, кеширование пользовательских данных.Однако, поскольку это кеш, я не думаю, что это должно быть источником правды, что означает, что я буду обновлять другое хранилище данных одновременно.Насколько я понимаю лучшие практики, 1 микросервис должен работать только с 1 хранилищем данных.Поэтому я создам конечную точку, имеющую дело только с данными кэша, которые имеют для меня смысл.
   Каков наилучший способ обработки и добавления / обновления команды?Обновить кэш и запустить событие для обновления основного хранилища данных?Или обновите хранилище данных и запустите событие, чтобы обновить кеш.У меня такое чувство, что я должен сначала обновить главное хранилище данных перед кэшем (поскольку я не планировал выставлять и конечную точку обновлять кэш, это должно быть сделано только для чтения), но это могло бы привести к некоторой потенциальной несогласованности.Хотя я понимаю, что в мире микросервисов данные «в конечном итоге непротиворечивы», разве это не означает, что для такой простой операции, как обновление, пользователь может напрямую не обновлять свои личные данные, даже если он отправляет свои изменения?
2. Я вижу, что люди все больше и больше выступают за привлечение событий.Если (на данный момент) мне действительно не нужен одитинг или даже способ воспроизвести события, нужен ли он мне?У меня есть чувство, что я могу сделать все это с помощью шины сообщений / саг, что, я думаю, гораздо более эффективно, чем использование хранилища событий.Я прав?

Answer 1

Я не уверен, с чего начать, но я постараюсь ответить на некоторые ваши вопросы.Но я на 100% с Арноном Ротем-Гал-Озом.Это все о компромиссах.

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

С точки зрения бизнеса это означает другой сценарий, в котором вы можете либо вернуть деньги, либо позволить клиенту дождаться пополнения запаса илипредоставить им альтернативу.Бизнес всегда может найти способ справиться с непоследовательностью.Другими словами, реальный мир уже прекрасно справляется с возможной последовательностью.

Еще одна вещь о возможной последовательности.У многих людей есть проблемы с возможной последовательностью, но они не моргнут, когда вводят кеш.Но кэш-память никогда не синхронизируется на 100% с хранилищем данных, поэтому данные, которые вы извлекаете из кэша, уже не на 100% согласованы с хранилищем данных и, следовательно, в конечном итоге согласуются.Я надеюсь, что это немного отвечает на ваши вопросы о возможной последовательности?o: -)

Я вижу, что люди все больше и больше выступают за привлечение событий.Если (на данный момент) мне действительно не нужен одитинг или даже способ воспроизведения событий, нужен ли он мне?

Даже если вам нужен одитинг или способ воспроизведения событий,Я не вижу смысла вводить источник событий.

Примечание. Я имею в виду тот тип источников событий, когда вы строите (или гидрируете) свои объекты (или агрегаты) на основе событий в каком-либо хранилище событий.

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

Если вы хотите узнать обо всем этом больше, напишите мне по адресу support@particular.net, и мы сможем обсудить это немного подробнее.

Answer 2

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

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