Архитектура микросервисов CQRS
Я начинаю личный проект, чтобы узнать, как лучше всего реализовать микросервисы. Это может быть инженерное решение, но это больше похоже на процесс обучения. Вероятно, это не имеет значения, но я использую .Net Core
Я думаю о разработке решений следующим образом:
- Использование шаблона CQRS, чтобы можно было легко разделить запросы и команды. На данный момент у меня есть 2 конечных точки для этого
- У меня есть "ручной" API-шлюз, который будет действовать как прокси для различных микросервисов, которые мне понадобятся.
- Используйте NServiceBus для связи между микросервисами
Вопросы:
- Я подумываю использовать Redis для кеширования запросов. Например, кеширование данных пользователя. Однако, поскольку это кеш, я не думаю, что он должен быть источником правды, а это значит, что я буду одновременно обновлять другое хранилище данных. Насколько я понимаю, 1 микросервис должен иметь дело только с 1 хранилищем данных. Поэтому я создам конечную точку, работающую только с данными кеша, которые имеют для меня смысл. Как лучше всего обрабатывать и добавлять / обновлять команду? Обновить кеш и запустить событие для обновления основного хранилища данных? Или обновите хранилище данных и активируйте событие, чтобы обновить кеш. Я считаю, что я должен обновить основное хранилище данных перед кешем (потому что я не планировал предоставлять и конечную точку для обновления кеша, это должно быть только для чтения), но это может привести к некоторой потенциальной несогласованности. Хотя я понимаю, что в мире микросервисов данные «в конечном итоге согласованы», не означает ли это, что для простой операции, такой как обновление, пользователь может напрямую не обновлять свои личные данные, даже если он отправит свои изменения?
- Я вижу, что люди все больше и больше выступают за организацию мероприятий. Если (на данный момент) мне действительно не нужен аудит или даже способ воспроизвести события, мне это нужно? У меня такое чувство, что я могу все это сделать, используя шину сообщений / саги, которые, как мне кажется, намного производительнее, чем использование хранилища событий. Я прав?
Взгляните на это
Ответы 2
Архитектурные решения связаны с компромиссами, и, поскольку вы определяете требования, все идет (особенно в отношении вопроса 2). Что касается q1. Для каждой службы было бы разумно использовать кеш независимо, а не как общий ресурс (с точки зрения развертывания вы можете использовать один экземпляр для размещения различных кешей), упаковка API кеша с вашей собственной службой, похоже, не приносит много смысла.
Что касается обработки команд - возможная согласованность, опять же, является выбором - вы можете обновлять как источник правды, так и кэшировать транзакциями (реальный или приблизительный, в зависимости от ваших потребностей), вы можете отметить в обновлении после запроса, что вы хотите получить самое последнее (не кешированное) ) версия - кроме того, кто говорит, что вам даже нужен кеш, и, вероятно, есть несколько других вариантов
Не знаю, с чего начать, но постараюсь ответить на некоторые ваши вопросы. Но я на 100% с Арноном Ротем-Гал-Озом. Все дело в компромиссах.
При обмене сообщениями в очереди может быть сообщение для заказа товара, запасы которого уже исчерпаны. Другими словами, в то время как клиент (и система) думали, что он может заказать товар, когда приходит сообщение, его больше нет в наличии. С технической точки зрения можно сказать, что это означает, что ваши данные противоречивы.
С точки зрения бизнеса это означает другой сценарий, при котором вы можете либо вернуть деньги, либо позволить покупателю дождаться пополнения запасов, либо предоставить ему альтернативу. Бизнес всегда может найти способ справиться с непоследовательностью. Другими словами, реальный мир уже отлично справляется с возможной согласованностью.
Еще кое-что о возможной согласованности. У многих людей есть проблемы с конечной согласованностью, но они не моргают глазом при вводе кеша. Но кеш никогда не синхронизируется на 100% с хранилищем данных, поэтому данные, которые вы извлекаете из кеша, уже не на 100% согласованы с хранилищем данных и, следовательно, в конечном итоге согласованы. Надеюсь, это немного ответит на ваши вопросы о возможной согласованности? о :-)
I can see that people are more and more advocates event sourcing. If (at the moment), I don't really need an auditing or even a way to replay the events, do I need it?
Даже если вам нужен аудит или способ воспроизвести события, я не вижу причин вводить источники событий.
Примечание: я имею в виду тип источника событий, при котором вы создаете (или гидратируете) свои объекты (или агрегаты) на основе событий в некотором хранилище событий.
Просто сохраните куда-нибудь отправленные сообщения. Таким образом, у вас будет журнал аудита, и вы сможете воспроизвести свои события. Поскольку вы уже используете NServiceBus, вы можете использовать его функцию аудита.
Если вы хотите узнать обо всем этом побольше, напишите мне по адресу [email protected], и мы сможем обсудить это немного дальше.
Спасибо. Когда следует рассмотреть возможность использования хранилища событий? Похоже, что использование типа коммуникации с шиной сообщений намного эффективнее, чем использование хранилища событий.
Оба кажутся очень разными решениями. Один - это своего рода хранилище данных, другой используется для отправки сообщений. Я не понимаю, как можно выбрать одно из них для достижения одной и той же цели?
Хотя решения совершенно разные, мне действительно нужен лучший способ общения между микросервисами. Для этого, похоже, я могу использовать либо хранилище событий, либо обмен сообщениями? Разница для меня в том, что хранилище событий можно использовать для воспроизведения, в то время как обмен сообщениями является одноразовым.
любезно, если сложно ответить на этот вопрос ... вам нужен event sourcing? Что ж, раз это ваш личный POC, почему бы не попробовать его и посмотреть, дало ли оно вам что-то ...