MASA Framework - Overall Design Ideas

Origin

At the beginning of the year, we were looking for a framework and hoped that it would have the following features:

1. low cost of learning

   You only need to learn the technology stack and middleware that must be supported by .Net's main technology stack every year, to reduce the burden on development students, and you only need to focus on the business.

   Personal opinion: A good framework should complement, not disrupt or over-innovate

2. open to extension

   Dependency implementations can be adjusted arbitrarily according to business requirements without being tied to an architectural idea

3. Powerful yet unrestricted architecture, adaptable from monolith to SOA to microservices

   Because there are always complex and simple systems in a system, it is best to fully cover our business scenarios

4. Industry is not limited

   It can not only support the business specificity of traditional industries, but also support the high concurrency characteristics of the Internet industry

5. stability

   There are strict testing standards, more secure to use

opportunity

When we do technology selection, the more we study Dapr, the clearer we become about what we want to do

Standing on the design of Dapr, we found a balance, Mecha

You can read this article (Mecha: Mesh through to the end): https://skyao.io/talk/202004-mecha-mesh-through-to-the-end/

Features of Mecha

1. Mecha is a general-purpose, highly configurable, reusable component that provides distributed primitives as out-of-the-box capabilities
2. Mecha can be deployed with a single Micrologic component (Sidecar mode) or as multiple shares (Note: I call it Node mode)
3. Mecha makes no assumptions about the Micrologic runtime. It works with polyglot microservices or even monoliths using open protocols and formats (e.g. HTTP/gRPC, JSON, Protobuf, CloudEvents)
4. Mecha is configured declaratively in a simple text format (e.g. YAML, JSON) indicating which features to enable and how to bind them to Micrologic endpoints
5. Rather than relying on multiple proxies for different purposes (e.g. web proxy, caching proxy, binding proxy), use one Mecha to provide all these capabilities

See Mecha from a different angle

1. Mecha provides capabilities, whether monolithic or distributed

2. There is an open API standard for the interaction between Mecha and the service

3. Mecha can be configured declaratively via text format (Yaml or Json)

   For .Net development, it is more accustomed to use Json

4. Applications require a variety of capabilities, Mecha provides a complete set of solutions but does not strongly bind all you need to use, as needed

5. Each capability has different implementation versions, and you can replace a certain part of the capability according to your own business situation

Why Mecha

The advantage of Mecha is the loose coupling between business logic and more and more distributed system problems. In addition to solving distributed problems, can we also extend the loose coupling between business logic and architecture?

Of course, after all, it's just a dll

In a distributed architecture, it guards the application in the form of a sidecar.

If it is in a .Net project, can it be similar to .Net Framework as a infrastructure/adapter/middleware/bus and other identities that reside in the .Net process to provide basic capabilities?

Design ideas

A complete design starts with the concept. In order to reduce the learning cost, we directly reuse the concept definition of Dapr

concept

building blocks

Provide interface standards, and in order to achieve a certain basic ability to connect different components (also through interfaces), loosely coupled but not decoupled

components

Based on the implementation of interface standards, such as the implementation of different components such as HttpClient and Dapr Service Invocation for inter-service communication

Tool Library

Provide more abstract underlying capabilities for business and components to complete their own functions, such as caching/configuration/data manipulation/security, etc.

Roadmap - v1.0

• Based on the .Net main push technology stack, no magic changes, reduce learning costs
• Provide project templates to freely combine function collections according to business needs
• Supports monolithic architecture and distributed architecture
• Support DDD methodology, also support CQRS
• Keep the set of dependencies as small as possible, but not for the sake of being small
• Convention over configuration
• Innovative and production-proven

current progress

We first completed the parts related to the guiding architecture, such as DDD, CQRS, Minimal APIs extension, etc., and kept the unit test coverage above 90%, currently 93%.

Take Contrib's directory structure as an example:

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

what's new

• Minimal APIs support Controller-like API classification aggregation
• Event Bus supports Hanlder orchestration, SAGA, Middleware, transaction control, Event and Hanlder decoupling modes. Compared with MediatR, there is only a 0.x% gap in performance, but it is more powerful, can face more complex business scenarios, and has planned a performance optimization route
• Integration Event Bus is an enhanced version of Event Bus that supports distributed transactions (eventual consistency) and integrates with Dapr
• Domain Event Bus is an integrated version of Event Bus and Integration Event Bus. It supports automatic control of in-process and out-of-process events in the domain, real-time sending and unified sending after stacking.

More functions are waiting for you to experience, and comments are welcome

What is MASA

MASA = Mesh Application Service Architecture, the grid application service architecture

In addition to MASA Framework, we will soon open source the Blazor component library (MASA Blazor), including the admin background template (MASA Blazor Pro)

There will be MASA Stack open source products, a one-stop PaaS platform based on MASA Framework, with platform-level capabilities such as DevOps, microservice observation governance, and data governance.

Example - MASA.EShop

MASA.EShop uses MASA.Framework to replicate the functions of eShopOnDapr, and provides examples of various architectures.

• Docker Compose support
• dapr component configuration
• Blazor version EShop website (in preparation to change to the UI of MASA Blazor Pro)
• Shared Contracts
• All services communicate with Dapr Pub/Sub using Minimal APIs
• MASA.EShop.Services.Basket demonstrates monolithic architecture, using Dapr State Management
• MASA.EShop.Services.Catalog demonstrates CQRS, using CQRS, anemia model
• MASA.EShop.Services.Ordering Demonstrates CQRS and Actor, using CQRS, Anemia Model, Dapr Actor
• MASA.EShop.Service.Payment demonstrates CQRS and DDD, using CQRS, DDD, hyperemia models

open source address

MASA.BuildingBlocks ：https://github.com/masastack/MASA.BuildingBlocks

MASA.Contrib ：https://github.com/masastack/MASA.Contrib

MASA.Utils ：https://github.com/masastack/MASA.Utils

MASA.EShop ：https://github.com/masalabs/MASA.EShop

If you are interested in our MASA Framework, whether it is code contribution, use, issue, please contact us

reference

• https://skyao.io/talk/202004-mecha-mesh-through-to-the-end/

{{o.name}}

{{m.name}}