低延迟应用使用Docker时的问题解决方案

一个伟大的问题诞生在 mechanical-sympathyGoogle邮件列表，或许已经有许多其他的伟大的问题诞生在此了。问题如下：
　　我不断地听说Docker，就好像他是切片面包以来最伟大的发明一样，但是我还听说低延迟应用在使用它的时候遭受打击。没有谁比Azul Systems的技术副总裁、首席技术官和联合创始人Gil Tene更适合回答这个问题了。就像我们相信乔丹的三步上栏一样，我们总能依靠Gil的洞察力，参见下面的文章：
　　系统地去除Linux操作系统抖动的黑魔法你的载荷生成器可能骗了你——吃下红药丸然后找出原因
　　下面是Gil的答案：
　　抛开问题的品味和风格不说，单说延迟效果（原始的问题），从机制角度来分析，答案很简单：Docker使用Linux容器作为执行方式没有对CPU和内存的操作系统虚拟层，有可选的（即使缺省是打开的）对I/O的虚拟层。
　　CPU和内存从延迟的角度来说，Docker（和其他Linux容器）的CPU和内存延迟特性不能够和Linux自身区分出来，但是对Linux有效的控制迟延行为对Docker也有效。
　　如果你想要清楚和一致的低延迟，你必须做不用Docker和不用容器时相同的工作来获得相同级别的一致性。例如，如果你想让整个系统尽在掌握（没有饥饿的邻居），你也不得不在主机这个层次为Docker做工作。
　　如果你需要分隔套接字或者内核和选择哪些进程在哪里，对Docker容器或者其中的线程，你也要做相同的事。
　　如果你使用非统一内存存取（NUMA， Non-Uniform Memory Access），或者使用任何类型的直接的NUMA驱动的内存分配，你也要做相同的事。
　　并且，你需要做的一些事情可能看起来违反一些人想要的部署Docker的模式。但是，如果你真正对一致性的低延迟感兴趣，你或许需要摆脱现有工具集，使用不同的控制组（cgroups）、任务设置（tasksets）和其他酷的工具来确保事情的安排。然而，即使你做了这些事情，你也不能够区分容器内外的进程的CPU和内存的延迟。
　　I/O磁盘I/O
　　在不同配置下的I/O行为是许多延迟问题产生和解答的原因。对于磁盘I/O行为和选项我也所知甚少，不能谈论太多。但我确定解决任何存储吞吐量和延迟敏感问题的答案是“越过虚拟层和逻辑分区，直接访问磁盘和挂接点”。
　　网络
　　网络的情形相当清楚：如果你想要网络地理位置无关、网络地址翻译（NAT， Network Address Translation）或桥接、自动生成的网络等功能，你或许会为网络延迟或吞吐量（相比Linux上直接真实物理网卡）付出代价。然而，也有为Docker配置低成本或基本上零延迟成本的网络链路的选项（再一次，可能与一些人想要的部署方式不同）。使用宿主机的网络或者专用IP地址和网卡，你将获得比缺省的桥接网络更好的性能。但你将会遇到配置Solarflare的网卡（在裸金属低延迟环境中很普遍）、绕过内核、专用自旋核心网络协议栈等相关的事宜。这些延迟相关的行为与是在宿主机上还是用Docker没有分别。
　　Docker（作为一个整体属于用户空间）不是把大杂烩装进一个盒子，客机（guest OS）作为一个整体的虚拟化方案也不是。确实，他们都能够这样用（经常是这样），但是使用他们的最大益处是发布一致的精心选择的配置，还有开发、测试和部署都使用相同配置的能力。后者可以容易地管理发布和版本（包括回滚），还有实现如“弹性大小”这样的酷的事情。其他配置工具（puppet或者shef等）当然也能得到相同的结果（假定他们控制你的镜像中的一切），但是把可以工作的东西打包在一起开箱即用确实是很诱人的事。
　　我知道有使用一个宿主机上只有一个客机这样虚拟化方案的人们（例如，AWS r3.8加大实例类型目前大概就是这样的）。也知道有采用相同方式使用Docker的人们（一个宿主机一个容器）。这两种用例是为了配置控制和部署，不是为了节约成本而把东西打包。
　　低延迟这件事现在变成了“它更糟吗？”这个问题。相比较基于宿主机和客机或KVM的虚拟化方案，在低延迟这个问题上，只要做正确的选择（专用网卡、内核和设备），Docker带来的损害更少，真正的不可察觉。