为什么在微服务架构下，服务网关和数据库不能部署在虚拟机上
最近开发了一基于springcloud的微服务架构的门户项目，因为客户对系统性能有要求，所以作者对系统的一些api接口进行了大量压力测试。在压测过程中，发现接口的性能瓶颈之一是服务网关和数据库部署在虚机上，所以本文将分享内容分为两部分：
- 性能压测结果说明
- 为什么服务网关和数据库不能部署到虚机
性能压测结果说明
性能压测思路是从软硬件负载 f5，nginx，到容器化平台k8s、docker、zuul网关，再到数据存储es、mysql、mongodb、redis，进行全面测试。
性能压测汇总
部分接口压测结果
其中值得关注的是，用一台zuul网关节点和一个业务节点压测空接口，发现一个有意思现象：
空接口压测不走zuul，一个业务节点tps能达到32000，走zuul网关，一个业务节点空接口tps只有11000，性能损耗64%。
当时就感觉zuul网关在我心中高大的形象碎了一地，但是没办法，性能不达标必须要优化。所以楼主查了很多资料，也问过一些docker和k8s的容器化平台大牛，总结出两点经验：
- docker和k8s部署到虚机上，zuul网关性能衰减40%左右
- 数据存储es、mysql、mongodb、redis不能用虚机部署
所以我向公司申请物理机，继续性能压测，当然这不是重点，重点是接下来要讲的：为什么服务网关和数据库不能部署到虚拟机上。
为什么服务网关和数据库不能部署到虚拟机
虚拟机的特点
- 运行在物理机上
- 有自己的虚拟网络
- 多台虚拟机共享物理机资源
io开销
我们知道，不管虚机上部署了多少个应用，一旦涉及到数据的存储，如果采用虚机部署数据库，会带来不必要的网络io开销。因为虚拟机在调度大量物理的cpu和内存、特别是磁盘IO时，必须经过虚拟机和物理机两层网络io读写开销操作，是非常耗系统性能的。
一般情况下，使用虚拟机部署应用，其性能衰减约20%左右，这不是优化代码能解决的。
共享物理机资源
因为虚拟机在cpu资源、网络等方面共享物理机资源，虚拟机之间会存在竞争物理机资源，造成程序不稳定情况。
docker容器部署
更要命的是，如果数据库和zuul网关部署到容器（实质也是虚拟机）里，那么网络io读写变成docker（虚拟机）到虚机，再到物理机三层访问，无形之中又增加了io读写性能开销。尤其是对于请求吞吐量要求很高的服务网关zuul，是不能容忍的。