当前位置:   article > 正文

.Net Core架构

net core架构

.NET 6.0 已经发布,高性能云原生开发框架。希望有更多的小伙伴加入大.NET阵营。这是本系列的第三篇文章:架构篇,喜欢的园友速度学起来吧。

本系列文章,主要分享一些.NET Core比较优秀的社区资料和微软官方资料。我进行了知识点归类,让大家可以更清晰的学习.NET Core。

首先感谢资料原作者的贡献。

第一篇:.NET Core资料精选:入门篇

介绍.NET历史、开源之路、基础、路由、依赖注入、HttpContext、cookie|session、HttpClient、gRPC、单元测试、发布部署等等。

第二篇:.NET Core资料精选:进阶篇

介绍.NET工程化、AOP、异常处理、缓存、日志、响应优化、上传下载、健康检查、后台任务、认证和授权、安全性(Https、CORS、CSRF)、EF Core 等等

第三篇:.NET Core资料精选:架构篇

介绍.NET跨平台的包袱与演变、.NET运行机制、性能分析方案;架构相关知识(设计原则、设计模式、DDD、微服务、中台等);.NET相关的微服务开发框架、微服务技术、云原生(docker、k8s)等

推荐资料:.NET开源github资源汇总(awesome-dotnet-core)

这是第三篇,知识点如图:

image

深入.NET

#、.NET Core跨平台解读

[.NET Core跨平台的奥秘上篇]:历史的枷锁

[.NET Core跨平台的奥秘中篇]:复用之殇

[.NET Core跨平台的奥秘下篇]:全新的布局(.NET Standard)

#、.NET Standard 与 .NET 5+

【译】介绍 .NET Standard

.NET Standard Versions(版本对应图)

[github]dotnet/standard

微软停止更新.NET Standard,.NET 5 取而代之

选择建议:

\1. 用于在.NET Framework 和所有其他平台之间共享代码,使用netstandard2.0

\2. 用于在Mono,Xamarin 和.NET Core 3.x 之间共享代码,使用netstandard2.1

\3. 向后共享代码,使用net5.0

.NET API 一览表

#、运行机制

.NET 的执行模型(CoreCLR 执行模型和Native AOT执行模型)

200行代码,7个对象——让你了解ASP.NET Core框架的本质(带源码)

(HttpContext,RequestDelegate,Middleware,ApplicationBuilder,Server,HttpListenerServer,WebHost)

ASP.NET Core 服务是如何启动、配置并运行的(IWebHost、Create­DefaultBuilder)

深入理解.NET Core的基元: deps.json, runtimeconfig.json, dll文件

补充:在vs中编译core项目时,在bin下面会生成deps.json记录nuget包依赖关系,并不会把依赖的nuget包拷贝到bin文件夹下。但执行dotnet publish命令发布core项目时,会将依赖的nuget包拷贝到发布目录

.NET Core 运行时配置设置(小节包含几篇文章,配置:依赖的包,加载路径,网络设置、线程设置等)

使用Directory.Build.props 文件管理多个csproj项目的配置

#、.NET Web 服务器

ASP.NET Core web服务器实现( kestrel&HTTP.sys )

为什么Linux 上的Asp.NET 5 需要 Kestrel ?

ASP.NET Core 的Kestrel Web 服务器

ASP.NET Core 的HTTP.sys Web 服务器

#、性能分析方案

性能分析

使用MiniProfiler 分析ASP.NET Core 、EF Core 性能

使用 BenchmarkDotnet 测试代码性能

分析快照堆栈、线程信息、异常信息、内存信息等

分析.net core在linux下内存占用过高问题(dotnet-counters,dotnet-dump)

如何排查.NET 内存泄漏(dotnet-counters,dotnet-dump)

Windbg程序调试系列(内存泄露、线程阻塞、高CPU等)

【一线码农】Windbg分析案例

架构相关理论

#、设计理论

一句话总结软件设计七大原则

一句话归纳23种设计模式

网站系统架构层次

The Clean Architecture(干净体系架构)

服务端高并发分布式架构15次演进之路

API设计

四连问:API 接口应该如何设计?如何保证安全?如何签名?如何防重?

API接口设计最佳实践

系统架构设计:进程缓存和缓存服务,如何抉择?

分布式之数据库和缓存双写一致性方案解析

MySQL数据库之互联网常用架构方案

一文搞懂蓝绿发布、灰度发布和滚动发布

#、领域驱动设计(DDD)

领域驱动涉及的主要概念:领域、界限上下文、领域模型、统一建模语言(UML)、模块、实体、值对象、应用服务&领域服务、领域事件、聚合、聚合根、仓储、工作单元(Uow)等等

一文理解DDD 领域驱动设计!

[圣杰]DDD理论学习系列——案例及目录

DDD 领域驱动设计:贫血模型、充血模型的深入解读

《微服务架构设计模式》读书笔记:微服务架构中的业务逻辑设计

DDD中重要且难理解部分的摘抄:

\1. 领域:一个领域本质上可以理解为就是一个问题域,只要是同一个领域,那问题域就相同。所以,只要我们确定了系统所属的领域,那这个系统的核心业务,即要解决的关键问题、问题的范围边界就基本确定了。

\2. 领域模型:就是将业务中涉及到的概念以面向对象的思想进行抽象,抽象出实体对象,确定实体所对应的方法和属性,以及实体之间的关系。然后将这些实体和实体之间的关系以某种形式(比如UML、图形、代码、文字描述等)展现出来。

\3. 模块:

l 模块通过分解领域模型为不同的模块,以降低领域模型的复杂性,提高领域模型的可读性。

l 模块的设计要符合高内聚低耦合的设计思想。

​ [clip_image0024]

\4. 领域事件= 事件发布+ 事件存储+ 事件分发+ 事件处理

\5. 领域服务

l 领域服务是无状态的,它存在的意义就是协调多个领域对象完成某个操作,所有的状态还是都保存在相应的领域对象中。

l 领域服务还有一个很重要的功能就是可以避免领域逻辑泄露到应用层。因为如果没有领域服务,那么应用层会直接调用领域对象完成本该是属于领域服务该做的操作,这样一来,领域层可能会把一部分领域知识泄露到应用层。因为应用层需要了解每个领域对象的业务功能,具有哪些信息,以及它可能会与哪些其他领域对象交互,怎么交互等一系列领域知识。因此,引入领域服务可以有效的防治领域层的逻辑泄露到应用层。

\6. 聚合和聚合根

l 聚合的一些特点:

\1) 每个聚合有一个根和一个边界,边界定义了一个聚合内部有哪些实体或值对象,根是聚合内的某个实体;

\2) 聚合内实现事务一致性,聚合外实现最终一致性(使用领域事件进行事务拆分,实现最终一致性)。在一个事务中,只能创建或更新一个聚合。

\3) 聚合内部的对象之间可以相互引用,但是聚合外部如果要访问聚合内部的对象时,必须通过聚合根开始导航,绝对不能绕过聚合根直接访问聚合内的对象,也就是说聚合根是外部访问聚合的网关;

\4) 聚合内除根以外的其他实体的唯一标识都是本地标识,也就是只要在聚合内部保持唯一即可,因为它们总是从属于这个聚合的;

\5) 基于聚合的以上概念,我们可以推论出从数据库查询时的单元也是以聚合为一个单元,也就是说我们不能直接查询聚合内部的某个非根的对象;

\6) 使用小聚合(大聚合会影响性能;大聚合容易导致并发冲突;大聚合扩展性差)

\7) 聚合内部的对象可以保持对其他聚合根的引用;

\8) 删除一个聚合根时必须同时删除该聚合内的所有相关对象,因为他们都同属于一个聚合,是一个完整的概念;

\9) 停下来重构模型。寻找模型中觉得有些疑问或者是蹩脚的地方,比如思考一些对象应该通过关联导航获得到还是应该从仓储获取?聚合设计的是否正确?考虑模型的性能怎样,等等;

l 如何识别聚合:

先从业务的角度深入思考,然后慢慢分析出有哪些对象是:

\1) 有独立存在的意义,即它是不依赖于其他对象的存在它才有意义的;

\2) 可以被独立访问的,还是必须通过某个其他对象导航得到的;

有分析报告显示,通常在大部分领域模型中,有70%的聚合通常只有一个实体,即聚合根,该实体内部没有包含其他实体,只包含一些值对象;另外30%的聚合中,基本上也只包含两到三个实体。

l 如何识别聚合根:

如果一个聚合只有一个实体,那么这个实体就是聚合根;如果有多个实体,那么我们可以思考聚合内哪个对象有独立存在的意义并且可以和外部直接进行交互。

\7. 仓储

l 仓储里面存放的对象一定是聚合,原因是领域模型中是以聚合的概念去划分边界的;聚合是我们更新对象的一个边界,事实上我们把整个聚合看成是一个整体概念,要么一起被取出来,要么一起被删除。我们永远不会单独对某个聚合内的子对象进行单独查询或做更新操作。因此,我们只对聚合设计仓储

l 仓储还有一个重要的特征就是分为仓储定义部分和仓储实现部分,在领域模型中我们定义仓储的接口,而在基础设施层实现具体的仓储。这样做的原因是:由于仓储背后的实现都是在和数据库打交道,但是我们又不希望客户(如应用层)把重点放在如何从数据库获取数据的问题上,因为这样做会导致客户(应用层)代码很混乱,很可能会因此而忽略了领域模型的存在。

l 仓储定义的接口要有具体领域意义,不能是一个模糊的通用的接口。通用接口会导致取数据逻辑泄露到应用层或领域层。

#、微服务

微服务介绍

微服务划分的姿势

分布式系统架构的冰与火

从亚马逊的实践,谈分布式系统的难点

.NET 微服务:适用于容器化.NET 应用程序的体系结构- 电子书

#、中台

阿里大中台小前台解读

企业级中台建设

头部电商的中台实践血泪总结

.NET 微服务架构

#、ABP基础开发框架

官网:https://cn.abp.io/

github:https://github.com/abpframework/abp

官方教程:https://docs.abp.io/zh-Hans/abp/latest

商业版demo:https://commercial.abp.io/demo

使用

get-started:https://www.abp.io/get-started

(使用Volo.Abp.Cli下载项目有时会失败,可以在get-started网站上直接创建项目模板)

基于abp vnext制作项目脚手架

AbpHelper.CLI

使用ABPHelper自动生成代码 (CRUD演示)

CRUD演示

示例

Abp官方所有示例

Abp官方微服务解决方案示例

最佳实践

跟着“土牛”学架构知识

[Abp官方]模块开发最佳实践& 约定

基于ABP落地领域驱动设计-01.全景图

基于ABP落地领域驱动设计-02.聚合和聚合根的最佳实践和原则

基于ABP落地领域驱动设计-03.仓储和规约最佳实践和原则

基于ABP落地领域驱动设计-04.领域服务和应用服务的最佳实践和原则

基于ABP落地领域驱动设计-05.实体创建和更新最佳实践

基于ABP落地领域驱动设计-06.正确区分领域逻辑和应用逻辑

其他:

Abp官方(https://www.abp.io/get-started)有提供社区版前端客户端:Razor Pages、Blazor、Angular、ReactNative。暂时没有提供Vue前端客户端。这边给出几个vue-admin的社区资源:

abp+vue-element-admin

abp+vue-vben-admin(vue3+typescript+ant design)

abp-vnext-pro + vben

模板项目图:

clip_image003

项目依赖图:

clip_image005

因本人使用过ABP,所以文中以ABP基础开发框架为例

在DotNet Core中还有很多其他的优秀基础开发框架,如: WTMOsharpFurioinSilky 等等

#、.NET 微服务相关的技术

API网关:Kong、Ocelot、Nginx

服务注册与发现:Consul(Consul Tamplate+nginx)、etcd、ZooKeeper

身份认证中心:IdentityServer4

服务调用:WebAPI、gRPC

消息事件总线:本地消息总线(进程内存缓存)、分布式消息总线(RabbitMQ、Kafka)

瞬态故障处理:Polly

分布式追踪:SkyWalking、Cat、Zipkin、Elastc.APM

分布式系统监控:Prometheus、(App.Metrics+InfluxDB+Grafana)

分布式事务:CAP、MassTransit

分布式日志:ExceptionLess、ELK

分布式缓存:StackExchange.Redis

分布式锁:RedLock.NET

消息队列:RabbitMQ、Kafka

配置中心:Apollo

DevOps:Jenkins、Docker、K8S、GitLab-ci、Azure Pipelines

相关资料推荐

API网关

高性能微服务网关.NETCore客户端Kong.Net开源发布

Ocelot简易教程(简介、配置、负载、认证、限流、聚合等)

IdentityServer4 认证授权

[阮一峰]理解OAuth 2.0

OAuth2.0授权登录四种模式时序图

IdentityServer4实现了OAuth和OpenId Connect

OAuth只负责Authorization(授权). 那么谁来负责Authentication(认证)呢?那就是OpenId Connect, OpenId Connect是对OAuth的一种补充, 因为它能进行Authentication.

OAuth通常有以下几种endpoint:authorize,token,revocation等

OpenId Connect 通常有以下几种endpoints:userinfo,checksession,endsession,.well-known/openid-configuration,.well-known/jwks等

[晓晨Master]IdentityServer4 中文文档与实战

Asp.Net Core 中IdentityServer4 授权原理及刷新Token的应用

[免费视频]IdentityServer4 教程视频

分布式事务

聊聊分布式事务(ACID、CAP、BASE、2PC、TCC、本地消息表(异步确保)、MQ 事务消息)

Asp.Net Core&CAP实现分布式事务

Apollo

Apollo guthub:https://github.com/ctripcorp/apollo

Apollo官方Demo:http://106.54.227.205/(账户密码是:apollo/admin)

监控

使用Elastic APM监控你的.NET Core应用

ASP.NET Core之跨平台的实时性能监控(App.Metrics+InfluxDB+Grafana)

其他

RabbitMQ 七种队列模式应用场景案例分析(通俗易懂)

基于Redis的分布式锁设计(RedLock.net)

应用示例:

eShopOnContainers项目

[github]eShopOnContainers

[圣杰]eShopOnContainers 分析文章系列

[github]abp-samples/MicroserviceDemo项目

云原生

TVP腾讯云最具价值专家张善友,他给到的解释是——“云原生的本质是一系列最佳实践的结合;云原生是云这种环境下的一种开发的理念、一种模式,无服务器、微服务、容器、DevOps都是云原生理念里面的子集。

什么是云原生

云是和本地相对的,传统的应用必须跑在本地服务器上,现在流行的应用都跑在云端,云包含了IaaS,、PaaS和SaaS。

原生就是土生土长的意思,我们在开始设计应用的时候就考虑到应用将来是运行云环境里面的,要充分利用云资源的优点,比如️云服务的弹性和分布式优势。

可以简单地把云原生理解为:云原生= 微服务+ DevOps + 容器化+ 持续交付

云原生全景图谱

云原生全景图详解

进击的.NET 在云原生时代的蜕变

云原生应用的12要素

给各种云服务一个灵活度排序:IaaS(各种云主机)> CaaS(Docker 等容器服务)> PaaS(BAE、SAE、GAE 等APP Engine)> FaaS > BaaS > SaaS(各种Web APP,如Google Doc)。(查看更多=>

clip_image002

#、Docker 与Kubernetes(K8S)

极简Docker和Kubernetes发展史

Docker与k8s的恩怨情仇

Docker员工自述:我们为什么“输”给了Kubernetes?

Docker

一文掌握 Docker 常用命令

K8S

kubernetes中文社区、中文文档

8 分钟了解 Kubernetes

[Edison Zhou]ASP.NET Core on K8s 入门学习系列文章目录

实例

如何使用vs将asp.net core项目添加容器支持并发布docker镜像到私有dockerhub和添加k8s/helm管理

从零开始在Windows 上部署.NET Core 到 Kubernetes

#、自动化集成与部署

流程:编码-> 构建-> 集成-> 测试-> 交付-> 部署

一文看懂持续部署按需发布!DevOps部署和发布方法大全

[CI&CD]jenkins自动化工具使用教程

持续集成(Continuous Integration)简称CI

持续交付(Continuous Delivery)简称CD

GitHub Actions

GitHub Actions 快速入门

两种github action 打包.Net Core 项目docker镜像推送到阿里云镜像仓库

Azure Pipeline

使用Azure DevOps Pipeline实现.Net Core程序的CI

示例:WTM-pipelines

==============================================================================

over,谢谢查阅,觉得文章对你有收获,请多帮推荐。欢迎向我提供更好的资料信息。

作者:滴答的雨
出处:http://www.cnblogs.com/heyuquan/
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。

欢迎园友讨论下自己的见解,及向我推荐更好的资料。
本文如对您有帮助,还请多帮 【推荐】 下此文。
谢谢!!! (_)
技术群:185718116(广深莞·NET技术),欢迎你的加入
技术群:广西IT技术交流(广西IT技术交流),欢迎你的加入

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/小丑西瓜9/article/detail/586669
推荐阅读
相关标签
  

闽ICP备14008679号