[[270987]]

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

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

性能壓測結果說明

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

性能壓測匯總

部分接口壓測結果

其中值得關注的是，用一臺zuul網關節(jié)點和一個業(yè)務節(jié)點壓測空接口，發(fā)現(xiàn)一個有意思現(xiàn)象：

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

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

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

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

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

虛擬機的特點

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

io開銷

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

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

共享物理機資源

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

docker容器部署

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

總結

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

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