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

缺乏、安全感 2023-06-30 13:56 22阅读 0赞

### 文章目录 ###

*  默认可执行文件
 *  单文件可执行文件
 *  程序集链接
 *  分层编译
 *  ReadyToRun 映像
 *  主要版本前滚
 *  Docker 和 cgroup 内存限制
 *  垃圾回收堆大小减小
 *  垃圾回收大型页面支持
 *  结语

你一定看过这篇文章 《 [进击的 Java ，云原生时代的蜕变][Java]》, 本篇文章的灵感来自于这篇文章。北京时间9.24 就将正式发布 .NET Core 3.0 , 所以写下这篇文章让大家全面认识 .NET Core。

.NET 生态系统是一个不断变化的生态圈，我相信它正在朝着一个伟大的方向发展。正好，最近 InfoQ 上发布了一篇文章《[.NET 生态系统概览][.NET]》，有了开源和跨平台这两个关键优先事项，我们就可以放心了。 下面我们来参考文章《进击的 Java ，云原生时代的蜕变》对云原生对应用运行时的不同需求，说明一个.NET Core 3.0 在云原生时代所完成的蜕变：

*  **体积更小：** 对于微服务分布式架构而言，更小的体积意味着更少的下载带宽，更快的分发下载速度，.NET Core 的镜像体积都很小，alpine 的镜像更小，带上应用程序通常 80M。
 *  **启动速度更快**：对于传统单体应用，启动速度与运行效率相比不是一个关键的指标。原因是，这些应用重启和发布频率相对较低。然而对于需要快速迭代、水平扩展的微服务应用而言，更快的的启动速度就意味着更高的交付效率，和更加快速的回滚。尤其当你需要发布一个有数百个副本的应用时，缓慢的启动速度就是时间杀手。对于 Serverless 应用而言，端到端的冷启动速度则更为关键，即使底层容器技术可以实现百毫秒资源就绪，如果应用无法在 500ms 内完成启动，用户就会感知到访问延迟。这里我拿 AWS Lambda 来举例，因为各大云厂商都是以 AWS 是模仿的目标，AWS Lambda 中可用的所有语言都是高级的，而不是像 Assembler，C / C ++ 或 Objective C 那样。从脚本语言到 JavaScript 和 Python，再到像Java 和C＃到 Go 这样被编译为二进制文件的托管运行时的语言，所有语言都是他们有自己的长处。在基准测试中，最重要的 .NET Core 是 冠军，具体参看[这里][Link 1]。
 *  **占用资源更少：** 运行时更低的资源占用，意味着更高的部署密度和更低的计算成本。.NET Core 的 CLR 启动速度非常快，降低启动时资源消耗，可以减少资源争抢，更好保障其他应用 SLA。
 *  **支持水平扩展：** .NET Core 3.0 默认更好的支持 Docker 资源限制，官方团队也在努力让 .NET Core 成为真正的容器运行时，使其在低内存环境中具有容器感知功能并高效运行。 具体可以参看文章《[从CLR GC 到 CoreCLR GC 看.NET Core对云原生的支持][CLR GC _ CoreCLR GC _.NET Core]》，随着内存成本的下降和虚拟化的流行，大内存配比已经成为趋势。所以我们一般是采用水平扩展的方式，同时部署多个应用副本，在一个计算节点中可能运行一个应用的多个副本来提升资源利用率。

.NET Core 3.0 新增功能 大部分的功能特性已经公开，可以通过网页[.NET Core 3.0 的新增功能][.NET Core 3.0]，其中有几个特性是非常期待应用到生产的，很多人都在等待着明天的正式发布。

# 默认可执行文件 #

.NET Core 现在默认生成[依赖于框架的可执行文件][Link 2]，这个行为是和 .NET Framework 保持一致了。 对于使用全局安装的 .NET Core 版本的应用程序而言，这是一种新行为。 以前，仅[独立部署][Link 3]会生成可执行文件。

在 `dotnet build` 或 `dotnet publish` 期间，将创建一个与你使用的 SDK 的环境和平台相匹配的可执行文件。 和其他本机可执行文件一样，可以使用这些可执行文件执行相同操作，例如：

*  可以双击可执行文件。
 *  可以直接从命令提示符启用应用程序，如 Windows 上的 myapp.exe，以及 Linux 和 macOS 上的 ./myapp。

# 单文件可执行文件 #

`dotnet publish` 命令支持将应用打包为特定于平台的单文件可执行文件。 该可执行文件是自解压缩文件，包含运行应用所需的所有依赖项（包括本机依赖项）。 首次运行应用时，应用程序将根据应用名称和生成标识符自解压缩到一个目录中。 再次运行应用程序时，启动速度将变快。 除非使用了新版本，否则应用程序无需再次进行自解压缩。

若要发布单文件可执行文件，请使用 `dotnet publish` 命令在项目或命令行中设置 `PublishSingleFile`：

或者  
`dotnet publish -r win10-x64 /p:PublishSingleFile=true`

这个单文件是大家一直期待的 go 特性，.NET Core 3.0 正式有了，更详细的信息参看 [Single-file Publish][]。

# 程序集链接 #

.NET core 3.0 SDK 随附了一种工具，可以通过分析 IL 并剪裁未使用的程序集来减小应用的大小。

自包含应用包括运行代码所需的所有内容，而无需在主计算机上安装 .NET。 但是，很多时候应用只需要一小部分框架即可运行，并且可以删除其他未使用的库。

.NET Core 现在包含一个设置，将使用 [IL 链接器][IL]工具扫描应用的 IL。 此工具将检测哪些代码是必需的，然后剪裁未使用的库。 此工具可以显著减少某些应用的部署大小。

要启用此工具，请使用项目中的 `<PublishTrimmed>`设置并发布自包含应用：

或者

`dotnet publish -r <rid> -c Release`

例如，包含的基本 “hello world” 新控制台项目模板在发布时命中大小约为 70 MB。 通过使用 `<PublishTrimmed>`，其大小将减少到约 30 MB，这个特性可以用于进一步的减小应用程序的大小。请务必考虑到使用反射或相关动态功能的应用程序或框架（包括 ASP.NET Core 和 WPF）通常会在剪裁时损坏。

# 分层编译 #

.NET Core 3.0 中默认启用了 [分层编译 (TC)][_TC]。 此功能使运行时能够更适应地使用实时 (JIT) 编译器来获得更好的性能，这也是一个可以加速应用启动的选项。

TC 的主要优势是使（重新）实时编译方法能够要么牺牲代码质量以更快地生成代码，要么以较慢的速度生成更高质量的代码。 这有助于提高应用程序在从启动到稳定状态的各个执行阶段的性能。 这与非 TC 方法完全不同，其中每种方法均以单一方式进行编译（与高质量层相同），这种方法偏向于稳定状态而不是启动性能。

若要启用快速 JIT（第 0 层实时编译的代码），请在项目文件中使用此设置：

# ReadyToRun 映像 #

可以通过将应用程序集编译为 `ReadyToRun (R2R)`格式来改进.NET Core 应用程序的启动时间。R2R 是一种预先 (AOT) 编译形式，这也是一项加速应用启动时间的选项。

R2R 二进制文件通过减少应用程序加载时实时 (JIT) 编译器需要执行的工作量来改进启动性能。 二进制文件包含与 JIT 将生成的内容类似的本机代码。 但是，R2R 二进制文件更大，因为它们包含中间语言 (IL) 代码（某些情况下仍需要此代码）和相同代码的本机版本。仅当发布面向特定运行时环境 (RID)（如 Linux x64 或 Windows x64）的自包含应用时 R2R 才可用。

# 主要版本前滚 #

.NET Core 3.0 引入了一项选择加入功能，该功能允许应用前滚到 .NET Core 最新的主要版本。 此外，还添加了一项新设置来控制如何将前滚应用于应用。 这可以通过以下方式配置：

*  项目文件属性：RollForward
 *  运行时配置文件属性：rollForward
 *  环境变量：DOTNET\_ROLL\_FORWARD
 *  命令行参数：–roll-forward

必须指定以下值之一。 如果省略该设置，则默认值为“Minor” 。

*  LatestPatch  
    前滚到最高补丁版本。 这会禁用次要版本前滚。
 *  Minor  
    如果缺少所请求的次要版本，则前滚到最低的较高次要版本。 如果存在所请求的次要版本，则使用 LatestPatch 策略。
 *  Major  
    如果缺少所请求的主要版本，则前滚到最低的较高主要版本和最低的次要版本。 如果存在所请求的主要版本，则使用 Minor 策略。
 *  LatestMinor  
    即使存在所请求的次要版本，仍前滚到最高次要版本。 适用于组件托管方案。
 *  LatestMajor  
    即使存在所请求的主要版本，仍前滚到最高主要版本和最高次要版本。 适用于组件托管方案。
 *  Disable  
    不前滚。 仅绑定到指定的版本。 建议不要将此策略用于一般用途，因为它会禁用前滚到最新补丁的功能。 该值仅建议用于测试。

# Docker 和 cgroup 内存限制 #

从预览版 3 开始，在 Linux 上使用 Docker 运行 .NET Core 3.0 时，可以更好地处理 cgroup 内存限制。 运行具有内存限制的 Docker 容器（例如使用 docker run -m）会更改 .NET Core 的行为方式。

*  默认垃圾回收器 (GC) 堆大小：最大为 20 MB 或容器内存限制的 75%。
 *  可以将显式大小设置为绝对数或 cgroup 限制的百分比。
 *  每个 GC 堆的最小保留段大小为 16 MB。 此大小可减少在计算机上创建的堆数量。

# 垃圾回收堆大小减小 #

垃圾回收器的默认堆大小已减小，以使 .NET Core 使用更少的内存。 此更改更符合具有现代处理器缓存大小的第 0 代分配预算。

# 垃圾回收大型页面支持 #

大型页面（也称为 Linux 上的巨型页面）是一项功能，其中操作系统能够建立大于本机页面大小（通常为 4K）的内存区域，以提高请求这些大型页面的应用程序的性能。

现在可以使用 GCLargePages 设置将垃圾回收器配置为一项选择加入功能，以选择在 Windows 上分配大型页面。

# 结语 #

.NET 技术在云原生时代也在不停地进化。.NET Core 作为.NET 生态的非常重要的一员，在对现有 .NET 应用保持高度兼容的同时，对启动速度和内存占用做了细致的优化，比较适于微服务架构配合使用, 在以kubernetes 为代表的云原生应用开发平台上发生蜕变。

在云原生时代，我们要能够在横向的应用开发生命周期中，将开发、交付、运维过程进行有效的分割和重组，提升研发协同效率；并且要能在整个纵向软件技术栈中，在编程模型、应用运行时和基础设施等多层面进行系统优化，实现 radical simplification，提升系统效率。

[Java]: https://mp.weixin.qq.com/s/x509eBHiDuasGmJupJKVow
[.NET]: https://www.infoq.cn/article/A6XZ1b5XSZgGHgOjExr6
[Link 1]: https://react-etc.net/entry/aws-lambda-benchmarks-node-js-python-java-c-go-dotnet-core
[CLR GC _ CoreCLR GC _.NET Core]: https://blog.csdn.net/wnvalentin/article/details/104024360
[.NET Core 3.0]: https://docs.microsoft.com/zh-cn/dotnet/core/whats-new/dotnet-core-3-0
[Link 2]: https://docs.microsoft.com/zh-cn/dotnet/core/deploying/index#framework-dependent-executables-fde
[Link 3]: https://docs.microsoft.com/zh-cn/dotnet/core/deploying/index#self-contained-deployments-scd
[Single-file Publish]: https://github.com/dotnet/designs/blob/master/accepted/single-file/design.md
[IL]: https://github.com/mono/linker
[_TC]: https://devblogs.microsoft.com/dotnet/tiered-compilation-preview-in-net-core-2-1/