[[270987]]

最近開發了一基于springcloud的微服務架構的門戶項目，因為客戶對系統性能有要求，所以作者對系統的一些api接口進行了大量壓力測試。在壓測過程中，發現接口的性能瓶頸之一是服務網關和數據庫部署在虛機上，所以本文將分享內容分為兩部分：

1. 性能壓測結果說明
2. 為什么服務網關和數據庫不能部署到虛機

性能壓測結果說明

性能壓測思路是從軟硬件負載 f5，nginx，到容器化平臺k8s、docker、zuul網關，再到數據存儲es、mysql、mongodb、redis，進行全面測試。

性能壓測匯總

部分接口壓測結果

其中值得關注的是，用一臺zuul網關節點和一個業務節點壓測空接口，發現一個有意思現象：

空接口壓測不走zuul，一個業務節點tps能達到32000，走zuul網關，一個業務節點空接口tps只有11000，性能損耗64%。

當時就感覺zuul網關在我心中高大的形象碎了一地，但是沒辦法，性能不達標必須要優化。所以樓主查了很多資料，也問過一些docker和k8s的容器化平臺大牛，總結出兩點經驗：

1. docker和k8s部署到虛機上，zuul網關性能衰減40%左右
2. 數據存儲es、mysql、mongodb、redis不能用虛機部署

所以我向公司申請物理機，繼續性能壓測，當然這不是重點，重點是接下來要講的：為什么服務網關和數據庫不能部署到虛擬機上。

為什么服務網關和數據庫不能部署到虛擬機

虛擬機的特點

1. 運行在物理機上
2. 有自己的虛擬網絡
3. 多臺虛擬機共享物理機資源

io開銷

我們知道，不管虛機上部署了多少個應用，一旦涉及到數據的存儲，如果采用虛機部署數據庫，會帶來不必要的網絡io開銷。因為虛擬機在調度大量物理的cpu和內存、特別是磁盤IO時，必須經過虛擬機和物理機兩層網絡io讀寫開銷操作，是非常耗系統性能的。

一般情況下，使用虛擬機部署應用，其性能衰減約20%左右，這不是優化代碼能解決的。

共享物理機資源

因為虛擬機在cpu資源、網絡等方面共享物理機資源，虛擬機之間會存在競爭物理機資源，造成程序不穩定情況。

docker容器部署

更要命的是，如果數據庫和zuul網關部署到容器（實質也是虛擬機）里，那么網絡io讀寫變成docker（虛擬機）到虛機，再到物理機三層訪問，無形之中又增加了io讀寫性能開銷。尤其是對于請求吞吐量要求很高的服務網關zuul，是不能容忍的。

總結

所以虛機對于IO密集型以及對延遲要求很高的業務場景不合適。

另外，早期的時候，作為一名架構師需要盡早的規劃好服務網關和數據庫的物理部署方式以及軟硬件性能要求。