DockerCon 2019 <https://www.docker.com/dockercon/>本周将在旧金山举行 ,DockerCon
是从业者、贡献者、维护者、开发者和容器生态系统学习、网络和创新的一站式活动。 .NET 团队博客发布了《一起使用.NET和Docker - DockerCon
2019更新
<https://devblogs.microsoft.com/dotnet/using-net-and-docker-together-dockercon-2019-update/>
》,分享.NET团队如何在过去一年中改进使用.NET和Docker的经验。.NET团队去年改进.NET Core Docker体验的大部分工作都集中在.NET
Core 3.0上。.NET Core 3.0 是第一个发布实质性运行时更改以使CoreCLR更有效的支持Docker资源限制,并提供更多配置供您调整的版本。

.NET 团队致力于使.NET Core成为真正的容器运行时。在过去的版本中,我们认为.NET Core是容器友好的。.NET
团队现在正在加强运行时,使其在低内存环境中具有容器感知功能并高效运行。 我们做出的最基本的改变是减少CoreCLR默认使用的内存,在过去的几个版本中,.NET
团队付出了很多努力来改进.NET Core在TechEmpower基准测试中的表现
<https://www.techempower.com/benchmarks/>。使用.NET Core 3.0,.NET
团队找到了显着提高性能并减少大量使用内存的方法。.NET 团队现在在容量限制为大约150
MB的容器中运行TechEmpower纯文本基准测试,同时每秒处理数百万个请求,这使我们能够每天验证内存受限的情况。

说到Docker,我对.NET Core搭配 Docker的使用非常满意,.NET Core
3.0的到来会更加美好,再借助于kubernetes的协调,我们的生活会越来越美好。

但是长久以来,Docker 和 Java
就像一对“欢喜冤家”。一方面,容器技术的“不可变基础设施”特性为开发者带来了无比宝贵的依赖与环境一致性保证;但另一方面, Linux 容器通过 Cgroups
对应用进行资源限制的方式跟所有依赖于 JVM
进行资源分配的编程语言都产生了本质的冲突。我在客户咨询的过程中经常见到客户的基于java8的应用程序(国内大量的Java应用都是java8)在docker中运行时出现“随机”故障?或者也许是一些奇怪的死机?两者都可能是Java
8(仍广泛使用的)中糟糕的docker支持引起的。Docker使用控制组(cgroups)来限制资源。在容器中运行应用程序时限制内存和CPU绝对是个好主意――它可以阻止应用程序占用整个可用内存及/或CPU,这会导致在同一个系统上运行的其他容器毫无反应。限制资源可提高应用程序的可靠性和稳定性。它还允许为硬件容量作好规划。在Kubernetes或DC/OS之类的编排系统上运行容器时尤为重要。

JVM可以“看到”系统上的整个内存和可用的所有CPU核心,并确保与资源一致。它默认情况下将最大堆大小(heap
size)设置为系统内存的1/4,并将某些线程池大小(比如针对GC)设置为物理核心数量,我们在拥有64GB内存的系统上运行,默认的最大堆大小是物理内存的1/4即16GB。如果我们使用docker
cgroups限制内存,会发生什么,JVM进程被杀死了。由于它是一个子进程――容器本身幸存下来,但通常当java是容器(PID 1)内的唯一进程时,容器会崩溃。

CPU怎么样? 系统上的确有12个CPU。因此,即使可用处理器的数量限制为1,JVM也会尝试使用12 ,
Java8和Docker的相杀,但是如果你升级到新的Java版本(10及以上版本)已经内置了docker支持功能。但有时升级不是办法,比如说如果应用程序与新JVM不兼容就不行,而且Oracle在2019年4月更改了Java
8更新的许可证,自Java SE 8 Update 211以来商业使用不再免费。 不过也有好消息,而就在上周,最近发布的OpenJDK 镜像
openjdk:8u212-jdk 终于能够让 Java 8 运行时在容器里面为应用分配出合理的 CPU 数目和堆栈大小了,具体可以参考
https://blog.softwaremill.com/docker-support-in-new-java-8-finally-fd595df0ca54?spm=a2c4e.11153940.blogcont700628.17.10fb43bf5u3n1d

<https://blog.softwaremill.com/docker-support-in-new-java-8-finally-fd595df0ca54?spm=a2c4e.11153940.blogcont700628.17.10fb43bf5u3n1d>


从Oracle JDK 8 切换到OpenJDK 8 是想继续使用Java的好选择,不过我还是劝告大家可以考虑下.NET Core
了,新的项目可以采用.NET Core 2.2进行开发,半年后就可以转到.NET Core 3.0 .NET Core是以MIT协议开源,
Java是GPL协议开源。 Java 8
SDK升级Oracle要收费这件事对于很多小公司是有着重大的影响的。众多没有能力开发维护OpenJDK的公司完全可以转向更具有竞争力的.NET
Core,.NET Core从属于.NET基金会,由微软进行官方支持。使用最宽松的MIT和Apache
2开源协议,文档协议遵循CC-BY。这将允许任何人任何组织和企业任意处置,包括使用,复制,修改,合并,发表,分发,再授权,或者销售。唯一的限制是,软件中必须包含上述版
权和许可提示,后者协议将会除了为用户提供版权许可之外,还有专利许可,并且授权是免费,无排他性的(任何个人和企业都能获得授权)并且永久不可撤销,用户使用.NET
Core完全不用担心收费问题,你可以很自由的部署在任何地方,。

现在是云计算时代,.NET
Core已经磨练5年时间,准备好了迎接云计算时代的云原生应用开发,云系统中,用更少的硬件为更高密度的用户提供服务是非常重要的。应用程序的占位面积越小,密度越高。容器只包含应用程序及其依赖项。文件大小要小很多倍,启动时间以秒为单位,只有应用程序加载到内存中,容器保证在任何主机上工作。鉴于容器的明显优势,.NET
Core的设计决定之一就是使其成为模块化。这意味着你的.NET Core应用程序可以被"发布",使得它和它的所有依赖关系在一个地方,这很容易放入容器

友情链接
ioDraw流程图
API参考文档
OK工具箱
云服务器优惠
阿里云优惠券
腾讯云优惠券
华为云优惠券
站点信息
问题反馈
邮箱:ixiaoyang8@qq.com
QQ群:637538335
关注微信