.NET 生态系统的蜕变之 .NET 6

Posted 2021-11-02 自由、创新、研究、探索

.NET 6 是自.NET 4 框架以来生态系统看到的最大版本更新，虽然.NET Core 是2014年开始非常大的一项重大战略举措，但是.NET 6是真正的具有强大动力的非常重要的版本。

2021年11月9日即将正式发布的.NET 6, 也许你认为.NET 5才刚刚发布，我才刚开始使用.NET Core 3.1, .NET6 就又要发布了 ，没错的，.NET 5是2020年11月10日发布，.NET Core 3.1早在2019年12月就发布了，微软已经承诺了每年都会发布一个版本的.NET , .NET 6正是按照时间表发布的版本。和这个版本发布节奏对应有一个支持政策：https://dotnet.microsoft.com/platform/support/policy/dotnet-core#cadence

从.NET 5开始，奇数版本版本18个月修补丁周期，而偶数版本有 三年 的修补丁周期。如果您已经将应用迁移到.NET Core 3.1，请注意，它有一个为期三年的修补丁周期，将于 2022 年 12 月结束;如果您仍在任何之前版本的 .NET Core上，则您目前已不在支持周期内。虽然尚未宣布对.NET框架 4.6.2 及以后的支持正式结束，但微软表示，.NET 框架 4.8 是.NET 框架的最后一个主要版本，将会随Windows 的支持计划更新：新的功能开发应针对以前称为 .NET Core（例如.NET 6）的平台。

.NET 6 带来了许多性能改进和生产力提升，而且还是一个长期支持版本 。在.NET 的每个连续版本中，.NET 在执行速度和内存使用方面都取得了一些令人印象深刻的进步。如果你一直没有跟踪， 你很可能会被. NET 框架的累积收益吹走。这一点你可以看看Techempower的测试的报告，具体参见 https://www.techempower.com/benchmarks/#section=data-r20&hw=ph&test=composite

变化很大

我们从 .NET 5开始向前看，作为长期支持 （LTS） 版本，.NET 6 代表着进一步的改进，并具有大量的设计和性能改进。我们将主要看看ASP.NET 6 运行时间的性能改进列表和.NET 6 中的中断更改，可以看到变化非常大。

C# 语言更新

C#语言的最新版本是10.0，有几个有趣的变化，对于爱整洁的csharper 来说，全局引用（Global using）和 文件范围的命名空间 是很好的互补。现在，您可以声明适用于整个编译单元（很可能是项目）的全局使用，并避免到每个文件顶部的去添加相同指令集。文件范围的命名空间还允许您声明适用于给定文件中所有代码的命名空间，无需单行无需更多匹配卷曲大括号，源文件中的凹痕级别也较少。

以前

CSharp9_Widget.cs

using System;
using System.Collections.Generic;
using System.Linq;

namespace MyNamespace.Data
{
	class Widget
	{
		private List<WidgetPart> _widgetParts;
		public IEnumerable<WidgetPart> RequiredParts => 
			_widgetParts;

		public bool RequiresPart(int partId) => 
			_widgetParts.Any(x => x.Id == partId);
	}
}

CSharp9_WidgetPartsInventory.cs

using System;
using System.Collections.Generic;
using System.Linq;

namespace MyNamespace.Data
{
	class WidgetPartsInventory
	{
		private Dictionary<int, WidgetPart> _widgetPartsById;

		public bool HavePartsToBuildWidget(Widget widget) => 
			widget.RequiredParts.All(p => 
				_widgetPartsById.ContainsKey(p.Id));
	}
}

现在：

CSharp10_GlobalUsing.cs

global using System;
global using System.Collections.Generic;
global using System.Linq;

CSharp10_Widget.cs

namespace MyNamespace.Data;

class Widget
{
	private List<WidgetPart> _widgetParts;
	public IEnumerable<WidgetPart> RequiredParts => _widgetParts;

	public bool RequiresPart(int partId) => 
		_widgetParts.Any(x => x.Id == partId);
}

CSharp10_WidgetPartsInventory.cs

namespace MyNamespace.Data;

class WidgetPartsInventory
{
	private Dictionary<int, WidgetPart> _widgetPartsById;

	public bool HavePartsToBuildWidget(Widget widget) => 
		widget.RequiredParts.All(p => 
			_widgetPartsById.ContainsKey(p.Id));
}

还有其他一些与Record、模式和插值字符串相关的更新，但这些更新大多是语法糖。

ASP.NET Core 更新

如果你阅读每个版本的说明，很容易看到 ASP.NET Core 是一个核心，从网络主机和最小 API，热重载 到blazor都有很多感兴趣特性。

网络主机和最小 API

从 ASP.NET Core开始，每个应用程序都将应用初始化代码拆分为Program.cs（用于创建 Web 主机）和"Startup.cs（用于配置路由和 IoC 容器配置等应用程序问题）中，通常包含的两个单独的Class。特别是Startup类有一种神奇的感觉，它的方法从来没有被开发人员直接调用。而是WebHost在幕后自动调用配置方法。

ASP.NET团队分析了这个设计，并与其他 Web 框架相比，认为设置涉及的东西太多。因此，最小的API概念诞生了。 现在，应用程序初始化可以全部包含在一个文件中。而且你可能感到奇怪，Main方法都不需要了。可以在应用设置中定义路由，从而大大减少代码数量以启动和运行一个应用程序。

var builder = WebApplication.CreateBuilder(args);

var app = builder.Build();

app.MapGet("/", () => "Hello World!");

app.Run();

当然如果你仍然喜欢将服务设置与应用配置分离的组织样式，你仍然可以为 IServiceCollection 和 IApplicationBuilder 创建扩展方法，并从构建器和应用程序对象调用它们。

Hot Reload

几年来，许多 javascript 框架都支持热重载，现在它也成为 C#中 ASP.NET Core应用的标配：通过热重加载，您可以在应用运行期间（在调试器下）编辑您的 C#代码，并且您的代码更改将自动反映在您的应用中，而不会丢失应用状态。换句话说，应用程序不需要重新启动。对于调试和交互式开发工作流程来说，这应该是一个很好的改进。 这个功能对于开发来说非常重要，就是这个小功能微软近日激怒了开源.NET社区，好消息是微软听取了社区的声音，恢复了通过CLI支持HotReload功能。具体参见 https://www.cnblogs.com/shanyou/p/15450214.html

Blazor

在 ASP.NET Core 6 里面有大量的更新是关于Blazor。例如，Blazor 应用程序现在可以直接编译到 WebAssembly，以便在 IL 解释（即.NET 本地编译）版本的相同代码上来提高应用程序速度。本地编译/调试体验仍然很快，因为漫长的编译时间仅适用于包装/发布。说到性能，Blazor WebAssembly可实现客户端代码的多线程。Javascript 受制于浏览器中的单线程。真正的多线程为可以从并行处理中受益的应用程序开辟了一些新的可能性（当然，这取决于浏览器的支持）。

还有一个非常有趣的功能，使 Blazor 可用于通过 MAUI 编写桌面应用程序。 Blazor 的最大好处就是开发人员可以完全用 C# 编写 Web 应用程序，而不需要为了写前端必须切换到 Javascript。 如果没有 C# 和 Javascript 之间的额外接缝，前端和后端代码之间就不需要映射层。 可以在两侧使用相同的 C# 模型，这意味着需要的代码更少，因此开发应用程序所需的时间也更少。 Blazor 桌面进一步扩展了这一概念，以允许此共享代码现在也可以与桌面应用程序无缝集成。

MAUI

MAUI 是 Multi-platform App UI 的缩写，是微软对跨平台 UI 框架的下一个尝试。 MAUI 是 Xamarin 的演进，还包括桌面平台。 它允许从单个代码库针对 ios、android、macOS 和 Windows。 MAUI 处理对本机平台 API 的抽象，因此您可以以与平台无关的方式访问设备传感器等内容。 对 Xamarin 的一种印象是，它们最终得到的界面很少，而且在任何平台上都不太好看。 MAUI 将如何解决这一问题还有待观察。 如果你关心的是跨多个平台的开发速度和维护成本，那么 MAUI 值得仔细研究。 MAUI 要在2022年的第二个季度正式发布，建议当前采取观望的方法，进行小的尝试以了解平台在全面采用之前的长期发展方向。

欢迎大家扫描下面二维码成为我的客户，为你服务和上云

.NET 生态系统的蜕变之 .NET 6云原生

云原生的英文名是cloud native，native 就是土著的意思，也就是土著对当地的环境是非常适应的，在云的环境和传统的数据中心是非常不同的，云原生就是要用的云的技术来构建应用， 利用云的技术来降低种端服务的风险和提高可用性，.NET Core和kubernetes 同年诞生发展， 2018年kubernetes 已经奠定了在容器编排领域的王者地位，2019年之后越来越多的企业选择基于云原生的技术或管理方法，把业务生于云或迁移到云平台，从而享受云的高效和持续的服务能力。

随着2021年kubernetes 的进一步普及， 微服务构建也转向了以Sidecar 模式，这种Sidecar 模式正在以更加迅猛的势头将中间件领域的能力下沉至 Kubernetes 这个新一代的应用基础设施当中，除了已经如火如荼的 Istio 对流量治理领域的颠覆，微软在CNCF 社区开源了 Open Service Mesh ，在Service Mesh这个领域处于战国时期，各种框架百花齐放。而与此同时， OAM 在微软的姊妹项目 Dapr 则直接拉齐了 Kubernetes 与中间件在“服务发现与绑定”侧的距离。所有这一切背后的用户动机是非常清晰的：云原生时代的中间件，既要语言无关，也要平台无关。

在所有问题上，对于任何给定的项目而言，正确的方法都可能介于两个极端之间（要么微服务架构，要么单体架构），微服务的构建在企业软件设计中正在取得平衡，不会再走向极端，而是接受了微服务的真正内涵，既与语言无关，又与平台无关，选择适合自己团队背景的技术构建云原生应用，对于dotnet 技术背景的团队在构建云原生应用，.NET 6为你提供了很好的技术底座。

• 体积更小：对于微服务分布式架构而言，更小的体积意味着更少的下载带宽，更快的分发下载速度，.NET 6的镜像体积都很小，alpine的镜像更小，带上应用程序通常80M。

• 启动速度更快：对于传统单体应用，启动速度与运行效率相比不是一个关键的指标。原因是，这些应用重启和发布频率相对较低。然而对于需要快速迭代、水平扩展的微服务应用而言，更快的的启动速度就意味着更高的交付效率，和更加快速的回滚。尤其当你需要发布一个有数百个副本的应用时，缓慢的启动速度就是时间杀手。对于Serverless 应用而言，端到端的冷启动速度则更为关键，即使底层容器技术可以实现百毫秒资源就绪，如果应用无法在 500ms 内完成启动，用户就会感知到访问延迟。

• 占用资源更少：运行时更低的资源占用，意味着更高的部署密度和更低的计算成本。.NET 6的 CLR启动速度非常快，降低启动时资源消耗，可以减少资源争抢，更好保障其他应用 SLA。

• 支持水平扩展：.NET 6默认更好的支持Docker资源限制，官方团队也在努力让.NET 6成为真正的容器运行时，使其在低内存环境中具有容器感知功能并高效运行。随着内存成本的下降和虚拟化的流行，大内存配比已经成为趋势。所以我们一般是采用水平扩展的方式，同时部署多个应用副本，在一个计算节点中可能运行一个应用的多个副本来提升资源利用率。

上面说了.NET 6 在云原生方面所完成的蜕变，很多人可能会以Java生态丰富来说明Java的种种优势，.NET 6相对于Java 17在云原生时代有太多的优势，.NET团队早在2014年完成转型，在云原生时代完成了蜕变，和Java相比已经是不同的世界，.NET更多的向Go、Rust等轻量级平台靠齐。随着 Dapr 在2021年2月份发布了1.0版本，它为我们提供了一组构建块和支持工具，可帮助我们以易于部署和可重复的方式实现关键的微服务设计模式，有了Dapr的支持，再来谈Java 生态丰富就有点可笑。

Dapr 当前有7大模块，每个模块都是为云原生应用开发的特定问题准备的，其中核心模块是Actor。

Actor 是一种并发编程的模型，Actor 表示的是一个最基本的计算单元，封装了可以执行的行为和私有状态。actor 之间相互隔离，它们并不互相共享内存，也就是说，一个 actor 能维持一个私有的状态，并且这个状态不可能被另一个actor所改变。在 actor 模型里每个 actor 都有地址(信箱)，所以它们才能够相互发送消息。每个 actor 只能顺序地处理消息。单个actor不考虑并发。

Dapr 中 actor 是虚拟的，它们并不一定要常驻内存。它们不需要显式创建或销毁。dapr actor runtime 在第一次接收到该 actor ID 的请求时自动激活 actor。如果该 actor 在一段时间内未被使用，那么 runtime 将回收内存对象。如果以后需要重新启动，它还将还原 actor 的一切原有数据。

Actor placement service 为系统提供了 actor 分发和管理，placement 会跟踪 actor 类型和所有实例的分区，并将这些分区信息同步到每个 dapr 实例中，并跟踪他们的创建和销毁。

Dapr的Virtual Actor 源自dotnet的老牌开源项目Orleans：https://github.com/dotnet/orleans。Orleans 更像是Spring Cloud构建微服务的体系，局限在.NET社区里，如果你喜欢使用Orleans 构建微服务，最近正好出版了一本Orleans的中文书《Orleans：构建高性能分布式Actor服务》 ,Dapr Actor 把 Orleans 带到所有的社区，如果你是用java，可以使用spring boot + dapr actor 写业务，这里可以给你一个案例，就是深圳的 行云创新他们就是用的这个组合，具体可以参考b站视频《直播回顾：Dapr——云原生开发新思路》。