Ejemplo de microservicios de C# con patrón cqrs

¿Atascado en el diseño de microservicios? Prueba este modo, tal vez funcione.

¿Alguna vez se ha encontrado con esta situación: un sistema de línea de ensamblaje controlado por servomotor, las instrucciones frontales se envían con frecuencia y los informes de datos deben generarse en tiempo real? Cuando las dos partes están abarrotadas, el sistema comienza a ralentizarse y ocasionalmente pierde datos. En este momento es posible que tengas que lidiar con diferentes ritmos de lectura y escritura, pero la arquitectura tradicional siempre parece incómoda.

Algunas personas han comenzado a preguntarse si la "lectura" y la "escritura" se pueden separar completamente. Ésta es la idea central del modelo CQRS. ¿Suena un poco abstracto? No te preocupes, hablemos despacio.

¿Qué resuelve exactamente este modelo?

En pocas palabras, CQRS divide las operaciones de lectura de datos y actualización de datos en dos conjuntos. Al igual que administrar un almacén, si se sigue el mismo proceso para el almacenamiento (escritura) y la verificación de salida (lectura), definitivamente será caótico durante las horas pico. Ahora, creemos un canal dedicado para cada uno de ellos.

En CQRS, el lado de "comando" se especializa en crear y actualizar estas operaciones de cambio de estado. Se centra en garantizar que los cambios de datos sean correctos y seguros. El final "consulta" sólo se encarga de mostrar los datos lo más rápido posible. Incluso puede diseñar una estructura de datos específicamente para la velocidad de consulta.

¿Cuál es el flujo de procesamiento típico bajo la arquitectura CQRS? Cuando llega una nueva instrucción (como ajustar el ángulo del servo), el comando la verificará y procesará, y persistirá el evento de cambio de estado. Casi la consulta escuchará estos eventos y actualizará su propia vista de datos para una lectura eficiente, que el front-end o el informe pueden llamar en cualquier momento. Ambas partes desempeñan sus respectivas funciones sin bloquearse entre sí.

¿Por qué usarlo en microservicios de C#?

Imagine que tiene un sistema distribuido construido en C# y los servicios cooperan como engranajes en una maquinaria de precisión. La introducción de CQRS es como agregar lubricación y protección contra sobrecarga al conjunto de engranajes.

Los mayores beneficios son el rendimiento y la escalabilidad. Después de separar la lectura y la escritura, ambos lados pueden expandirse independientemente según la presión. ¿Es estresante el servicio de lectura? Simplemente agregue algunas instancias de lectura más y no afectará en absoluto al servicio de escritura responsable de la lógica empresarial central. existirkpotenciaEn algunas soluciones que implican un control mecánico complejo, esta separación mejora la velocidad de respuesta del panel de monitoreo en tiempo real y la estabilidad del procesamiento de comandos de back-end.

Entonces hay una clara división de responsabilidades. El equipo de desarrollo puede estar más centrado, con algunas personas trabajando en la lógica empresarial central (lado del comando) y otras en la interfaz de usuario y la visualización de datos (lado de la consulta). La estructura del código es más limpia y el mantenimiento es menos complicado.

La otra cosa es la flexibilidad. El lado de la consulta es libre de elegir la base de datos o la tecnología de almacenamiento en caché más adecuada y no tiene que estar vinculado al lado de la escritura. Hoy uso SQL Server para almacenar comandos y mañana uso Redis para almacenar en caché los resultados de las consultas. La combinación es muy flexible.

¿Cómo usarlo paso a paso?

Para practicar CQRS en un proyecto de microservicio C# desde cero, puede seguir este camino:

1. Definir comandos y consultas.: Primero aclare qué operaciones son "comandos" para cambiar el estado (comoComando Establecer posición del motor), que son "consultas" para obtener datos (p. ej.ObtenerAssemblyLineStatusQuery). Esta es la base del diseño.
2. Construir modelos separados: cree modelos de dominio y DTO para comandos y consultas respectivamente. Tienen diferentes propósitos y pueden tener estructuras completamente diferentes.
3. Elija el método de comunicación: Después de procesar el lado del comando, ¿cómo notificar al lado de la consulta que los datos se han actualizado? Generalmente a través de eventos. En el ecosistema .NET, se pueden utilizar bibliotecas como MediatR para manejar con elegancia comandos y consultas en proceso, y se puede considerar la integración entre servicios de buses de mensajes.
4. Manejar la coherencia de los datos: Después de la separación de lectura y escritura, la sincronización de datos no es absolutamente en tiempo real (consistencia final). Esto debe evaluarse en función del escenario para determinar si es aceptable. Por ejemplo, para obtener información de posición en tiempo real de un brazo robótico, el retraso debe ser extremadamente bajo; mientras que para los informes de producción diarios, un retraso de unos segundos suele estar bien.
5. Comience simple: No es necesario aplicar CQRS en todos los servicios desde el principio. Puede comenzar a probar un servicio con diferencias obvias en las cargas de lectura y escritura y una complejidad moderada para acumular experiencia.

¿Es una panacea?

Por supuesto que no. CQRS introduce complejidad adicional y es más adecuado para su uso en escenarios donde las cargas de lectura y escritura están realmente desequilibradas y tienen mayores requisitos de rendimiento o escalabilidad. Si se trata simplemente de una aplicación CRUD simple, usarla puede resultar excesivo.

La coherencia final requiere la cooperación de la lógica empresarial y el equipo de desarrollo también necesita tiempo para adaptarse a este nuevo modelo de pensamiento.

Algunos amigos pueden preguntar: ¿esto hará que el sistema sea demasiado complicado? De hecho, la introducción de cualquier patrón arquitectónico es una compensación. existirkpotenciaEn algunos proyectos de integración de servosistemas de alto rendimiento, cuando el flujo central de comando y control está entrelazado con una gran cantidad de requisitos de análisis de datos y monitoreo de estado, el uso de CQRS para separar las preocupaciones hace que la arquitectura general sea más clara y sólida. Puede que no sea la primera herramienta que se retira, pero puede ser una opción de diseño que vale la pena considerar cuando se necesita lidiar con un cuello de botella de crecimiento específico.

Establecido en 2005,kpotenciase ha dedicado a un fabricante profesional de unidades de movimiento compacto, con sede en Dongguan, provincia de Guangdong, China. Aprovechando las innovaciones en tecnología de accionamiento modular, Kpower integra motores de alto rendimiento, reductores de precisión y sistemas de control multiprotocolo para proporcionar soluciones de sistemas de accionamiento inteligentes eficientes y personalizadas. Kpower ha brindado soluciones de sistemas de accionamiento profesionales a más de 500 clientes empresariales en todo el mundo con productos que cubren diversos campos, como sistemas domésticos inteligentes, electrónica automática, robótica, agricultura de precisión, drones y automatización industrial.