关于后端:MASA-Framework-整体设计思路

120次阅读

共计 4035 个字符,预计需要花费 11 分钟才能阅读完成。

源起

年初咱们在找一款框架,心愿它有如下几个特点:

  1. 学习成本低

    只须要学.Net 每年主推的技术栈和业务个性必须反对的中间件,给开发同学减负,只须要专一业务就好

    个人见解:一款好用的框架应该是补充,而不是颠覆或适度翻新

  2. 对扩大凋谢

    能够依照业务需要任意调整依赖实现,而不被捆绑在一个架构思路上

  3. 功能强大却不限度架构,从单体到 SOA 再到微服务都能够适应

    因为一个零碎中总有简单的也有简略的,最好能全面笼罩咱们的业务场景

  4. 行业不限

    既能反对传统行业的业务特殊性,又能够反对互联网行业的高并发个性

  5. 稳定性

    有严格的测试规范,用起来更安心

契机

在咱们做技术选型的时候,对 Dapr 的钻研越深刻,对咱们想要做的事件就越清晰

站在 Dapr 的设计上咱们找到了一个平衡点,Mecha

能够看下这篇文章(Mecha:将 Mesh 进行到底):https://skyao.io/talk/202004-…

Mecha 的个性

  1. Mecha 是通用的,高度可配置的,可重用的组件,提供分布式原语作为现成的能力
  2. Mecha 能够与单个 Micrologic 组件一起部署 (Sidecar 模式),也能够部署为多个共享 (注:我称之为 Node 模式)
  3. Mecha 不对 Micrologic 运行时做任何假如。它与应用凋谢协定和格局(例如 HTTP/gRPC,JSON,Protobuf,CloudEvents)的多语言微服务甚至单体一起应用
  4. Mecha 以简略的文本格式(例如 YAML,JSON)申明式地配置,批示要启用的性能以及如何将其绑定到 Micrologic 端点
  5. 与其依附多个代理来实现不同的目标(例如网络代理,缓存代理,绑定代理),不如应用一个 Mecha 提供所有这些能力

换个角度看 Mecha

  1. Mecha 提供的是能力,不论是单体还是分布式
  2. Mecha 与服务之间交互是有凋谢 API 规范的
  3. Mecha 能够通过文本格式(Yaml 或 Json)申明式地配置

    对于.Net 开发来说,更习惯用 Json

  4. 利用须要多种多样的能力,Mecha 提供了一整套解决方案却不强绑定你所有都要用到,按需即可
  5. 每个能力有不同的实现版本,能够依据本身业务状况替换其中某一部分的能力

为什么是 Mecha

Mecha 的益处是业务逻辑和越来越多的分布式系统问题之间的松耦合,除了能够解决分布式以外,咱们是否也能够延展成业务逻辑和架构之间的松耦合?

当然,说到底就是 dll 而已

在分布式架构中,它以 Sidecar 的模式守护在利用身旁。

如果在.Net 我的项目中,它是否能够相似.Net Framework 作为基建 / 适配器 / 中间件 / 总线等身份驻留在.Net 过程中提供根底能力?

设计思路

一个残缺的设计要先从概念开始,为了升高学习老本咱们间接复用 Dapr 的概念定义

概念

构建块

提供接口标准,并为了达到某个根底能力的串接不同组件(也通过接口),松耦合但不脱钩

组件

基于接口标准的实现,比方服务间通信提供 HttpClient 和 Dapr Service Invocation 等不同组件的实现

工具库

提供更形象的底层能力,供业务和组件实现本身性能,如缓存 / 配置 / 数据操作 / 平安等

Roadmap – v1.0

  • 基于.Net 主推技术栈,不魔改,升高学习老本
  • 提供我的项目模板,依据业务需要自由组合性能汇合
  • 反对单体架构,也反对分布式架构
  • 反对 DDD 方法论,也反对 CQRS
  • 尽量小的依赖汇合,但不为了小而小
  • 约定优于配置
  • 有翻新,且要通过生产验证

目前停顿

咱们首先实现了用于领导架构相干的局部,如 DDD、CQRS、Minimal APIs 扩大等,并放弃单元测试覆盖率在 90% 以上,目前 93%。

以 Contrib 的目录构造为例:

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

有什么新性能

  • Minimal APIs 反对相似 Controller 的 API 分类聚合
  • Event Bus 反对 Hanlder 编排、SAGA、Middleware、事务管制、Event 和 Hanlder 解耦模式。相较于 MediatR 性能仅有 0.x% 的差距但性能更加弱小,能够面对更简单的业务场景,并且已布局性能优化路线
  • Integration Event Bus 是 Event Bus 的增强版,反对分布式事务(最终一致性),与 Dapr 集成
  • Domain Event Bus 是 Event Bus 和 Integration Event Bus 的集成版,反对在畛域内自动控制过程内与过程外的事件,反对实时发送也反对入栈后对立发送

更多功能等你来体验,也欢送提意见

什么是 MASA

MASA = Mesh Application Service Architecture,即网格应用服务架构

除了 MASA Framework,咱们马上将开源 Blazor 组件库(MASA Blazor),包含治理后盾模板(MASA Blazor Pro)

后续还有 MASA Stack 开源产品,基于 MASA Framework 打造的一站式 PaaS 平台,具备 DevOps、微服务观测治理、数据治理等平台级能力

示例 – MASA.EShop

MASA.EShop 是应用 MASA.Framework 复刻了 eShopOnDapr 的性能,并提供了多种架构形式的示例。

  • 反对 Docker Compose
  • dapr component 配置
  • Blazor 版 EShop 网站(正在筹备更换为 MASA Blazor Pro 的 UI)
  • 共享 Contracts
  • 所有服务都应用 Minimal APIs 和 Dapr Pub/Sub 进行通信
  • MASA.EShop.Services.Basket 演示单体架构,应用 Dapr State Management
  • MASA.EShop.Services.Catalog 演示 CQRS,应用 CQRS、贫血模型
  • MASA.EShop.Services.Ordering 演示 CQRS 与 Actor,应用 CQRS、贫血模型、Dapr Actor
  • MASA.EShop.Service.Payment 演示 CQRS 与 DDD,应用 CQRS、DDD、充血模型

开源地址

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

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

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

MASA.EShop:https://github.com/masalabs/M…

如果你对咱们的 MASA Framework 感兴趣,无论是代码奉献、应用、提 Issue,欢送分割咱们

参考

  • https://skyao.io/talk/202004-…

正文完
 0