Пример шаблона CQRS C# для микросервисов

Застряли на проектировании микросервисов? Попробуй этот режим, может получится

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

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

Что именно решает эта модель?

Проще говоря, CQRS делит операции чтения данных и обновления данных на два набора. Как и в случае с управлением складом, если соблюдать один и тот же процесс для складирования (запись) и исходящей проверки (чтение), в часы пик он определенно будет хаотичным. Теперь давайте создадим отдельный канал для каждого из них.

В CQRS «командная» часть специализируется на создании и обновлении этих операций изменения состояния. Он ориентирован на обеспечение правильности и безопасности изменений данных. Конец «запроса» отвечает только за максимально быстрое отображение данных. Он даже может разработать структуру данных специально для скорости запросов.

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

Зачем использовать его в микросервисах C#?

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

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

Тогда происходит четкое разделение обязанностей. Команда разработчиков может быть более сосредоточена: одни люди работают над основной бизнес-логикой (командная часть), а другие — над пользовательским интерфейсом и отображением данных (сторона запросов). Структура кода стала чище, а обслуживание стало менее головной болью.

Другое дело — гибкость. Сторона запроса может свободно выбирать наиболее подходящую базу данных или технологию кэширования и не должна быть привязана к стороне записи. Сегодня я использую SQL Server для хранения команд, а завтра использую Redis для кэширования результатов запросов. Комбинация очень гибкая.

Как использовать его шаг за шагом?

Чтобы попрактиковаться в CQRS в проекте микросервиса C# с нуля, вы можете пойти по следующему пути:

1. Определение команд и запросов: Сначала уточните, какие операции являются «командами» для изменения состояния (например,Команда SetMotorPosition), которые представляют собой «запросы» для получения данных (например.GetAssemblyLineStatusQuery). Это основа дизайна.
2. Создание отдельных моделей: Создайте модели предметной области и DTO для команд и запросов соответственно. Они имеют разное предназначение и могут иметь совершенно разную структуру.
3. Выберите способ связи: После обработки стороны команды, как уведомить сторону запроса о том, что данные обновлены? Обычно через события. В экосистеме .NET такие библиотеки, как MediatR, можно использовать для элегантной обработки внутрипроцессных команд и запросов, а также можно рассмотреть возможность межсервисной интеграции шин сообщений.
4. Обеспечьте согласованность данных: После разделения чтения и записи синхронизация данных происходит не совсем в реальном времени (eventual согласованность). Это необходимо оценить на основе сценария, насколько это приемлемо. Например, для обратной связи по положению роботизированной руки в реальном времени задержка должна быть чрезвычайно малой; в то время как для ежедневных производственных отчетов обычно достаточно задержки в несколько секунд.
5. Начните с простого: CQRS не обязательно применять во всех службах с самого начала. Вы можете начать пилотировать сервис с очевидными различиями в нагрузках на чтение и запись и умеренной сложностью, чтобы накопить опыт.

Это панацея?

Конечно, нет. CQRS вносит дополнительную сложность и больше подходит для использования в сценариях, где нагрузки чтения и записи действительно несбалансированы и предъявляют более высокие требования к производительности или масштабируемости. Если это простое приложение CRUD, его использование может оказаться излишним.

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

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

Основанная в 2005 году,мощностьбыла посвящена профессиональному производителю компактных приводов со штаб-квартирой в Дунгуане, провинция Гуандун, Китай. Используя инновации в модульной технологии привода, Kpower объединяет высокопроизводительные двигатели, прецизионные редукторы и многопротокольные системы управления, чтобы предоставить эффективные и индивидуальные решения для интеллектуальных систем привода. Kpower предоставила профессиональные решения в области приводных систем более чем 500 корпоративным клиентам по всему миру, предлагая продукты, охватывающие различные области, такие как системы «умный дом», автоматическая электроника, робототехника, точное земледелие, дроны и промышленная автоматизация.