使用Docker对时延影响几何?
【编者的话】本文通过介绍Azul Systems的技术副总裁兼首席技术官、联合创始人Gil Tene对Docker时延特性的分析，说明了针对Docker时延的关键影响因素（CPU、内存、IO）进行改善提高，认为时延对Docker的影响是一个“无关紧要”问题。
在 mechanical-sympathy 论坛列表里出现了一个很好的问题，这个问题可能很多人也遇到过：
我不断的听到有关Docker似乎是有史以来最伟大的技术的说法，但我也听闻有传闻证据表明对时延要求严格的应用会给此说法带来冲击。
有谁能比 Azul Systems 的技术副总裁兼首席技术官、联合创始人 Gil Tene 能更好的回答这个问题？就好比斯蒂芬-库里（Stephen Curry）跳投三分球般的精彩，Gil的观点总是值得期待的：
以下是 Gil的回答：
暂且把喜好和风格的问题放在一边，并将重点放在对延迟的影响上（最原始的原题），单纯从技术原理机制的角度分析是非常简单的：Docker使用 Linux容器技术作为执行手段，没有采用在操作系统层级虚拟化CPU和内存，并且在I/O上采用可选的虚拟化层技术（默认情况对I/O虚拟化）。
CPU和内存
从时延的角度来看，Docker（以及其他的Linux容器）的CPU和内存时延特性与Linux本身几乎没有什么区别。因此适用于Linux时延特性也同样适用于Docker。
如果你需要完全一致的低时延效果，你需要做与非Docker化和非容器化的Linux 相一致的同级别且同样的事情。比如，如果你需要从整体上对系统进行控制，那么你也需要在主机级别做和Docker同样的事情（排除相邻干扰）。
如果你需要隔离套接字或内核，并控制哪些进程在哪里结束，期望这些进程去做与docker容器或/和它里面线程相同的事情。
如果你通过numactl（译者注：numactl通过NUMA策略或内存分配策略来运行进程）或任何形式的针对numa驱动的内存分配，这也同样适用。
你需要额外做一些东西，这可能与其他人部署docker时与众不同，但是如果你确实对低时延连接感兴趣，你可能需要打开工具箱，并使用 cgroups、taskets等其他各种酷炫的东西去评估如何对布局进行控制。但是如果你这样做（当你这样做时） ，你在CPU和内存时延方面无法分辨docker化的进程和非docker化进程之间的区别。
IO
磁盘IO
I/O性能是各种配置下时延开销最主要的问题（和解决方法），通常也是最终的问题。对docker的磁盘I/O性能和配置选项，我没有足够的了解，从而不能进行深入的探讨。但我敢肯定存储中任何对吞吐量和时延敏感问题的解决方案都是“绕过虚拟化和卷相关的工具，并提供对磁盘设备和挂载点的直接访问”
网络
网络特性很清楚：如果你试图通过网络自动化生成工具任意接入一种NAT映射或桥接的部署方式，你可能需要在网络时延和吞吐量性能方面付出沉重的代价（相比于普通linux裸机专用网卡）。不过，在部署docker容器时也存在一些其它的选择方式（同样，可能与一些人期望的部署方式不一样）能够在 docker里实现低开销或基本上是零延迟开销网络连接。使用主机网络或者使用专用IP地址和网卡，你将会获得比默认桥接方式更好的效果。但同样你可以使用像Solarflare公司的网卡（在裸机低延迟环境中已普遍采用的解决方案），甚至使用内核旁路、或专用的旋转核心网络堆栈，如果进行同样的操作，Docker将会在延迟性能方面和裸机Linux没有区别。
Docker（以 “用户空间作为基本单元”）并不是将很多东西封装到一个盒子里，也不采用客户机操作系统虚拟化技术。当然，他们都可以被用于虚拟化技术（并且经常这样使用），但是最重要的好处是他们都能进行一致性迁移，并有充分保存配置的能力。以及具有对开发、测试、部署环境进行相同配置的能力。这后来演变成能够轻松的进行管理部署和版本控制（包括回退），并能实现弹性大小调整等酷炫的特性。也同样可以使用puppet/chef...等配置工具获得如在裸机里使用般类似的效果，当然（假设他们能控制你镜像里的一切），但是，打包你工作环境的所有东西成一堆数字串，并可被启动执行是非常吸引人的。
据我所知使用虚拟化的人甚至使用单客户主机（例如，现在使用的可能是AWS的r3.8xlarge虚拟机实例）。和人们使用docker的方式相同（每台主机一个容器）。两种案例都是关于如何进行配置控制和部署，而不是仅仅将所有的东西打包在一个小空间里。
低时延的问题就变成了一个“无关紧要”的问题。而且在对比低时延时Docker比虚拟化管理程序或基于KVM的虚拟化技术带来的损失更小，通过选择正确的I/O（专用的网卡、内核和设备），它的损失几乎可以忽略。
原文链接：How Does The Use Of Docker Effect Latency? （翻译：chenhl）