为什么在微服务架构下,服务网关和数据库不能部署在虚拟机上

为什么在微服务架构下,服务网关和数据库不能部署在虚拟机上

最近开发了一基于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,是不能容忍的。

总结

相关推荐