本文讲的是使用Docker对时延影响几何，
【编者的话】本文通过介绍Azul Systems的技术副总裁兼首席技术官、联合创始人Gil Tene对Docker时延特性的分析，说明了针对Docker时延的关键影响因素（CPU、内存、IO）进行改善提高，认为时延对Docker的影响是一个“无关紧要”问题。
在
mechanical-sympathy
论坛列表里出现了一个很好的问题，这个问题可能很多人也遇到过：
我不断的听到有关Docker是有史以来最伟大的技术的说法，但我也听说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...等配置工具获得如在裸机里使用般类似的效果，当然（假设他们能控制你镜像里的一切），但是，打包你工作环境的所有东西成一堆数字串，并可被启动执行是非常吸引人的。
低时延的问题就变成了一个“无关紧要”的问题。而且在对比低时延时Docker比虚拟化管理程序或基于KVM的虚拟化技术带来的损失更小，通过选择正确的I/O（专用的网卡、内核和设备），它的损失几乎可以忽略。
原文链接：How Does The Use Of Docker Effect Latency?（翻译：chenhl）
原文发布时间为：2015-12-21
本文作者：chenhl
本文来自云栖社区合作伙伴DockerOne，了解相关信息可以关注DockerOne。
原文标题：使用Docker对时延影响几何?
