MASA Framework - Ideas generales de diseño

Origen

A principios de año, estábamos buscando un marco y esperábamos que tuviera las siguientes características:

bajo costo de aprendizaje

Solo necesita aprender la pila de tecnología y el middleware que debe ser compatible con la pila de tecnología principal de .Net cada año, para reducir la carga de los estudiantes de desarrollo, y solo necesita concentrarse en el negocio.

Opinión personal: un buen marco debe complementar, no interrumpir o innovar en exceso
abierto a la extensión

Las implementaciones de dependencia se pueden ajustar arbitrariamente de acuerdo con los requisitos comerciales sin estar vinculados a una idea arquitectónica.
Arquitectura poderosa pero sin restricciones, adaptable de monolito a SOA a microservicios

Debido a que siempre hay sistemas complejos y simples en un sistema, es mejor cubrir completamente nuestros escenarios comerciales
La industria no se limita

No solo puede respaldar la especificidad comercial de las industrias tradicionales, sino también las características de alta concurrencia de la industria de Internet.
estabilidad

Existen estrictos estándares de prueba, más seguros de usar.

oportunidad

Cuando hacemos la selección de tecnología, cuanto más estudiamos Dapr, más claro nos volvemos sobre lo que queremos hacer.

De pie sobre el diseño de Dapr, encontramos un equilibrio, Mecha

Puede leer este artículo (Mecha: malla hasta el final): https://skyao.io/talk/202004-mecha-mesh-through-to-the-end/

Características de Mecha

Mecha es un componente reutilizable, altamente configurable y de propósito general que proporciona primitivos distribuidos como capacidades listas para usar
Mecha se puede implementar con un solo componente Micrologic (modo Sidecar) o como varios recursos compartidos (Nota: lo llamo modo Nodo)
Mecha no hace suposiciones sobre el tiempo de ejecución de Micrologic. Funciona con microservicios políglotas o incluso monolitos utilizando protocolos y formatos abiertos (por ejemplo, HTTP/gRPC, JSON, Protobuf, CloudEvents)
Mecha se configura de forma declarativa en un formato de texto simple (p. ej., YAML, JSON) que indica qué funciones habilitar y cómo vincularlas a los puntos finales de Micrologic
En lugar de depender de múltiples proxies para diferentes propósitos (por ejemplo, proxy web, proxy de almacenamiento en caché, proxy de vinculación), use un Mecha para proporcionar todas estas capacidades

Ver Mecha desde un ángulo diferente

Mecha proporciona capacidades, ya sean monolíticas o distribuidas
Existe un estándar API abierto para la interacción entre Mecha y el servicio.
Mecha se puede configurar de forma declarativa a través del formato de texto (Yaml o Json)

Para el desarrollo de .Net, está más acostumbrado a usar Json
Las aplicaciones requieren una variedad de capacidades, Mecha proporciona un conjunto completo de soluciones, pero no vincula fuertemente todo lo que necesita usar, según sea necesario.
Cada capacidad tiene diferentes versiones de implementación y puede reemplazar una determinada parte de la capacidad de acuerdo con su propia situación comercial.

¿Por qué Mecha?

La ventaja de Mecha es el acoplamiento flexible entre la lógica de negocios y cada vez más problemas de sistemas distribuidos. Además de resolver problemas distribuidos, ¿podemos extender el acoplamiento flexible entre la lógica de negocios y la arquitectura?

Por supuesto, después de todo, es solo un dll

acoplamiento-en-diferentes-arquitecturas_hu05f2d69ba0319c258f11ab39e179ac17_281537_1200x1200_fit_q75_lanczos.jpg

En una arquitectura distribuida, protege la aplicación en forma de sidecar.

Si está en un proyecto .Net, ¿puede ser similar a .Net Framework como infraestructura/adaptador/middleware/bus y otras identidades que residen en el proceso .Net para proporcionar capacidades básicas?

Ideas de diseño

Un diseño completo comienza con el concepto.Para reducir el costo de aprendizaje, reutilizamos directamente la definición del concepto de Dapr

concepto

bloques de construcción

Proporcionar estándares de interfaz, y para lograr una cierta capacidad básica para conectar diferentes componentes (también a través de interfaces), débilmente acoplados pero no desacoplados

componentes

Basado en la implementación de estándares de interfaz, como la implementación de diferentes componentes como HttpClient y Dapr Service Invocation para la comunicación entre servicios.

Biblioteca de herramientas

Proporcione capacidades subyacentes más abstractas para que las empresas y los componentes completen sus propias funciones, como almacenamiento en caché/configuración/manipulación de datos/seguridad, etc.

Hoja de ruta - v1.0

Basado en la pila de tecnología de inserción principal de .Net, sin cambios mágicos, reduce los costos de aprendizaje
Proporcione plantillas de proyectos para combinar libremente colecciones de funciones de acuerdo con las necesidades comerciales
Soporta arquitectura monolítica y arquitectura distribuida
Admite la metodología DDD, también admite CQRS
Mantenga el conjunto de dependencias lo más pequeño posible, pero no por ser pequeño
Convención sobre configuración
Innovador y probado en producción

MASA.Framework.png

progreso actual

Primero completamos las partes relacionadas con la arquitectura de guía, como DDD, CQRS, extensión mínima de API, etc., y mantuvimos la cobertura de prueba unitaria por encima del 90 %, actualmente el 93 %.

Tome la estructura de directorios de Contrib como ejemplo:

MASA.Contrib
├── solution items
│   ├── nuget.config
├── src
│   ├── BasicAbility
│   │   ├── MASA.Contrib.BasicAbility.Dcc                          Configuration API
│   ├── Configuration
│   │   ├── MASA.Contrib.Configuration
│   ├── Data
│   │   ├── MASA.Contrib.Data.UoW.EF                               Unit of work
│   │   └── MASA.Contrib.Data.Contracts.EF                         Protocol EF version
│   ├── DDD
│   │   ├── MASA.Contrib.DDD.Domain                                In-process and cross-process support
│   │   └── MASA.Contrib.DDD.Domain.Repository.EF
│   ├── Dispatcher
│   │   ├── MASA.Contrib.Dispatcher.Events                         In-process event
│   │   ├── MASA.Contrib.Dispatcher.IntegrationEvents.Dapr
│   │   └── MASA.Contrib.Dispatcher.IntegrationEvents.EventLogs.EF Cross-process event
│   ├── ReadWriteSpliting
│   │   └── CQRS
│   │   │   └── MASA.Contrib.ReadWriteSpliting.CQRS                CQRS
│   ├── Service
│   │   └── MASA.Contrib.Service.MinimalAPIs                       Best practices for [MinimalAPI]
├── test
│   ├── MASA.Contrib.Dispatcher.Events
│   │   ├── MASA.Contrib.Dispatcher.Events.BenchmarkDotnetTest
│   │   ├── MASA.Contrib.Dispatcher.Events.CheckMethodsParameter.Tests
│   │   ├── MASA.Contrib.Dispatcher.Events.CheckMethodsParameterNotNull.Tests
│   │   ├── MASA.Contrib.Dispatcher.Events.CheckMethodsParameterType.Tests
│   │   ├── MASA.Contrib.Dispatcher.Events.CheckMethodsType.Tests
│   │   ├── MASA.Contrib.Dispatcher.Events.OnlyCancelHandler.Tests
│   │   ├── MASA.Contrib.Dispatcher.Events.CheckMethodsType.Tests
│   │   ├── MASA.Contrib.Dispatcher.Events.Tests
│   ├── MASA.Contrib.Data.UoW.EF.Tests
│   ├── MASA.Contrib.Dispatcher.IntegrationEvents.EventLogs.EF.Tests
│   ├── MASA.Contrib.DDD.Domain.Tests
│   ├── MASA.Contrib.DDD.Domain.Repository.EF.Tests

qué hay de nuevo

Las API mínimas admiten la agregación de clasificación de API similar a un controlador
Event Bus es compatible con la orquestación de Hanlder, SAGA, Middleware, control de transacciones, modos de desacoplamiento de eventos y Handlder. En comparación con MediatR, solo hay una brecha de rendimiento del 0,x%, pero es más potente, puede enfrentar escenarios comerciales más complejos y ha planificado una ruta de optimización del rendimiento.
Integration Event Bus es una versión mejorada de Event Bus que admite transacciones distribuidas (coherencia eventual) y se integra con Dapr
Domain Event Bus es una versión integrada de Event Bus e Integration Event Bus. Admite el control automático de eventos en proceso y fuera de proceso en el dominio, envío en tiempo real y envío unificado después del apilamiento.

Más funciones están esperando que las experimente, y los comentarios son bienvenidos.

Que es MASA

MASA = Arquitectura de servicio de aplicación de malla, la arquitectura de servicio de aplicación de red

Además de MASA Framework, pronto abriremos la biblioteca de componentes de Blazor (MASA Blazor), incluida la plantilla de fondo de administración (MASA Blazor Pro)

Habrá productos de código abierto MASA Stack, una plataforma PaaS integral basada en MASA Framework, con capacidades a nivel de plataforma como DevOps, gobierno de observación de microservicios y gobierno de datos.

Ejemplo - MASA.EShop

MASA.EShop utiliza MASA.Framework para replicar las funciones de eShopOnDapr y proporciona ejemplos de varias arquitecturas.

Compatibilidad con Docker Compose
configuración del componente dapr
Sitio web de Blazor versión EShop (en preparación para cambiar a la interfaz de usuario de MASA Blazor Pro)
Contratos compartidos
Todos los servicios se comunican con Dapr Pub/Sub usando API mínimas
MASA.EShop.Services.Basket demuestra arquitectura monolítica, utilizando Dapr State Management
MASA.EShop.Services.Catalog demuestra CQRS, usando CQRS, modelo de anemia
MASA.EShop.Services.Ordering Demuestra CQRS y Actor, usando CQRS, Anemia Model, Dapr Actor
MASA.EShop.Service.Payment demuestra CQRS y DDD, usando CQRS, DDD, modelos de hiperemia