文章出自：聽雲博客
隨着公司業務的不斷增長，我們的應用數量也有了爆發式增長。伴隨着應用爆發式的增長，管理的難度也隨之加大。如何在業務爆發增長的同時快速完成擴容成了很大的挑戰。Docker的橫空出世恰巧解決了我們的問題。利用Docker我們可以快速完成擴容縮容，且配置統一，不易出錯。
在Docker的集群管理選型上，我們比較糾結，目前比較流行的是Mesos和Kubernetes。從功能來說，我們更傾向於使用Kubernetes，他在容器編排方面的能力強於Meoso，且提供了持久化存儲方案，更適合我們的場景。但是Kubernetes的網絡模型要比Mesos復雜，在高並發的情況下性能能否滿足需求成了關鍵問題。
Mesos本身不處理網絡問題，利用Marathon我們可以選擇Docker本身提供的Host模式和Bridge模式。Host模式與宿主機共享網絡棧網絡性能是最高的，Bridge模式有待評測。
Kubernetes采用扁平化的網絡模型，要求每個Pod擁有一個全局唯一IP，Pod直接可以跨主機通信。目前比較成熟的方案是利用Flannel。Flannel有幾種工作模式，分別是UDP、VXLAN、Host-gw和Aws-vpc。Aws-vpc有平台局限性我們不考慮，UDP性能較差不考慮。重點測試VXLAN和Host-gw。有相關評測測試過Host-gw性能好於VXLAN，但是Host-gw模式要求宿主機的網絡滿足二層直接交換。這在許多共有雲平台是無法滿足的。即使共有雲平台某個機房內可以滿足該網絡要求，多機房互聯時也無法滿足該要求。如果VXLAN模式無法滿足需求，多機房互聯時就需要多個Kubernetes集群，增加了管理難度。
為了使結果更具真實性，我們選了線上一個並發較高的系統進行評測。機器配置均為16C 32G，應用本身不存在性能問題。由於Kubernetes要求網絡互聯，我們測試Kubernetes時選用兩台機器。
綜上，我們待測得環境如下：
| 待測機器 | 機器配置 | 機器數量 |
| K8s flannel vxlan | 16C 32G | 2 |
| K8s flannel host-gw | 16C 32G | 2 |
| Mesos host模式 | 16C 32G | 1 |
| Mesos bridge模式 | 16C 32G | 1 |
| 公有雲虛機（對比） | 16C 32G | 1 |
聽雲Server可以監控代碼級的響應時間，在負載均衡上加上一個頭信息可以監測到負載均衡到后端RealServer的阻塞時間。利用這個特性，我們可以用來評測上述幾種網絡模型的阻塞時間，從而得出高並發情況下VXLAN模型能否滿足我們的需求。
聽雲Network可以模擬請求到服務端，綜合取得全國各地的網絡訪問時間，我們可以利用它來監測同時用這幾種模型的時候是否對生產系統產生影響。
測試方法：我們由公有雲提供的負載均衡分別往這7台機器上打相同的流量。通過聽雲Server來監控這幾種模型的阻塞時間來對比他們的性能差異。同時觀察聽雲Network的可用性和訪問性能，從客戶端的角度看是否因為某個模型網絡性能差導致用戶體驗變差。如下圖所示：
我們在負載均衡后加入這些機器
其中第一個8080為公有雲虛機，30099端口的為VXLAN的service，30098的兩台機器為Host-gw的service，8081端口為Docker bridge模式，8080端口為Host模式。
我們先用聽雲Network看下整體服務是否受到影響。
下圖是性能曲線圖，有波動，屬於正常范圍。我們是HTTPS服務，前端負載均衡負責解碼SSL，會消耗部分時間。
排除掉一些點本身的網絡問題，可用性基本在100%。
接下來對比下看下聽雲Server。
下圖為吞吐率，平均值為425081rpm。 共7台，平均每台吞吐率約為60725rpm。
下圖為服務器響應時間圖。
時間約為0.67秒，與前邊聽雲Network測試的時間基本吻合。
從圖上看大部分時間花在阻塞時間。這里我們要詳細分解下阻塞時間，從而獲取我們要評測的網絡性能。
阻塞時間的定義是從負載均衡到后端RealServer的時間。這個時間在我們的場景下為
K8s： 阻塞時間=SSL解碼時間+負載均衡響應時間+轉發包給后端虛機時間+flanneld轉發包時間。
Mesos bridge： 阻塞時間=SSL解碼時間+負載均衡響應時間+轉發包給后端虛機時間+本機NAT轉發時間
Mesos host： 阻塞時間=SSL解碼時間+負載均衡響應時間+轉發包給后端Docker時間。
雲虛機對比: 阻塞時間=SSL解碼時間+負載均衡響應時間+轉發包給后端虛機時間。
我們只要對比下各個測試情況下阻塞時間，將雲虛機的Docker消耗時間記為0.
其他機器與與雲虛機作的阻塞時間做減法，就可以得出相對應網絡消耗。
兩台機器的我們取平均值。
| 待測機器 | 平均阻塞時間 | Docker本身消耗 |
| K8s flannel vxlan | 644.778ms | 6.778ms |
| K8s flannel host-gw | 641.585ms | 3.585ms |
| Mesos host模式 | 650.021ms | 12.021ms |
| Mesos bridge模式 | 643.67ms | 5.67ms |
| 公有雲虛機（對比） | 638ms | 0 |
上表的結果中，Host模式耗時最長出乎我們的意料，可能是個例因素導致。其他結果和我們的預期基本符合。其中VXLAN模式平均比公有雲虛機多6ms的同時網絡適應能力強，應該可以滿足我們的需求。
在更大的並發下會怎樣呢？通過橫向擴展是否能達到我們的性能需求呢？
我們在此基礎上測試了20台K8s vxlan模式與32台雲主機機同時跑在上千萬rpm的場景。從流量各半到逐步加大K8s的量來觀察性能影響，同時觀察其穩定性，測試結果下期揭曉。
各位小伙伴在應用架構遷移到K8s、Mesos或者原生Docker時，也可以利用聽雲的工具，測試下架構變更后對真實系統的影響。