使用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）