.NET 云原生技术使用调查

.NET Core 3.0 即将发布RC，.NET Core 3.0默认更好的支持Docker资源限制，官方团队也在努力让.NET Core成为真正的容器运行时，使其在低内存环境中具有容器感知功能并高效运行。

GC堆限制

.NET Core减少了CoreCLR默认使用的内存，如G0代内存分配预算，以更好地与现代处理器缓存大小和缓存层次结构保持一致。

在新的创建的GC堆数量的策略里，GC保留了一个内存片段，每个堆最小是16M，在低内存限制的机器上也可以很好的运行。在多核CPU的机器上运行时，系统并没有设置CPU的核数限制。例如，如果在48核计算机上设置160 MB内存限制，则不需要创建48个GC堆。也就是说如果设置160 MB限制，则只会创建10个GC堆。如果未设置CPU限制，应用程序可以利用计算机上的所有核心。

有了这样的新策略，可以不需要启用Docker环境下的.NET Core应用的工作站GC的工作负载。

支持Docker内存限制

Docker资源限制建立在cgroup之上，而cgroup是Linux的内核功能。从运行时的角度来看，我们需要定位cgroup原语。

设置cgroup限制时的.NET Core 3.0内存使用规则：

默认GC堆大小：容器上cgroup内存限制的最大值20MB或最大值的75%
每个GC堆的最小保留段大小16MB，这将减少在具有大量内核和小内存限制的计算机上创建的堆数

为了支持容器方案，添加了2个HardLimit配置：

GCHeapHardLimit - 指定GC堆的硬限制
GCHeapHardLimitPercent - 指定允许此进程使用的物理内存的百分比

如果同时指定了两者，则首先检查GCHeapHardLimit，并且只有在未指定GCHeapHardLimit时才检查GCHeapHardLimitPercent。

如果两者都未指定，但进程正在有内存限制的容器中运行，则默认是使用如下设置：

max（20mb，容器内存限制的75％）

如果指定了hardlimit配置，并且程序在有内存限制的容器中使用，GC堆的使用不会超过hardlimit限制，但总内存仍然受容器的内存限制。所以当我们统计内存消耗时，基于容器内存限制得出的数据。

举例：
进程在设置了200MB限制的容器中运行，用户还将GCHeapHardLimit配置为100MB。
如果把GC限制中100MB限制中的50MB用于GC，而容器限制中剩余的100MB用于其他用途，那么内存消耗即为(50+100)/200=75%。

GC将更积极地执行资源回收与释放，因为GC堆越接近GCHeapHardLimit限制，就越能实现提供更多可用内存的目标，也越能使得应用程序可以继续而又安全地运行。如果算法计算出的结果认为此时的GC效率低下，那么将避免持续执行完全阻塞的GC。

即使GC堆完全压缩，GC依然会抛出一个OutOfMemoryException异常出来，这是因为所分配的堆大小超过了GCHeapHardLimit的限制。

由此可见，.NET Core 3.0的设计是要稳定运行于有资源限制的容器中。

支持DockerCPU限制

在CPU限制的情况下，Docker上设置的值将向上舍入为下一个整数值。此值是CoreCLR使用的最大有效CPU核数。

默认情况下，ASP.NET Core应用程序启用了服务器GC（它不适用于控制台应用程序），因为它可以实现高吞吐量并减少跨核心的争用。当进程仅限于单个处理器时，运行时会自动切换到工作站GC。即使您明确指定使用服务器GC，工作站GC也将始终用于单核环境。

通过计算CPU繁忙时间，设置CPU限制，我们避免了线程池的各种推导性竞争：

尝试分配更多的线程以增加CPU繁忙时间
尝试分配更少的线程，因为添加更多的线程不会提高吞吐量

你应该会看到很多关于Kubernetes和Docker的消息，以至于你可能想知道哪个更好。事实上，没有“更好”一说，因为它们所解决的问题是不一样的。Docker就像飞机，而Kubernetes就像飞机场。就像你不可能说“我应该基于哪个去旅行——飞机或者飞机场？”，Docker和Kubernetes也是一样的，你需要它们两个。今天做一个调查。