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

Posted 2023-05-05

参考技术A

最近开发了一基于springcloud的微服务架构的门户项目，因为客户对系统性能有要求，所以楼主对系统的一些api接口进行了大量压力测试。在压测过程中，发现接口的性能瓶颈之一是服务网关和数据库部署在虚机上，所以本文将分享内容分为两部分

性能压测思路是从软硬件负载 f5，nginx，到容器化平台k8s、docker、zuul网关，再到数据存储es、mysql、mongodb、redis，进行全面测试。

性能压测汇总

部分接口压测结果

其中值得关注的是，用一台zuul网关节点和一个业务节点压测空接口，发现一个有意思现象：

空接口压测不走zuul，一个业务节点tps能达到 32000， 走zuul网关，一个业务节点空接口tps只有11000，性能损耗64%。

当时就感觉zuul网关在我心中高大的形象碎了一地，但是没办法，性能不达标必须要优化。所以楼主查了很多资料，也问过一些docker和k8s的容器化平台大牛，总结出两点经验：

所以楼主向公司申请物理机，继续性能压测，当然这不是重点，重点是接下来要讲的：为什么服务网关和数据库不能部署到虚拟机上 。

虚拟机的特点

io开销

我们知道，不管虚机上部署了多少个应用，一旦涉及到数据的存储，如果采用虚机部署数据库，会带来不必要的网络io开销。因为虚拟机在调度大量物理的cpu和内存、特别是磁盘IO时，必须经过虚拟机和物理机两层网络io读写开销操作，是非常耗系统性能的。

一般情况下，使用虚拟机部署应用，其性能衰减约20%左右，这不是优化代码能解决的。

共享物理机资源

因为虚拟机在cpu资源、网络等方面共享物理机资源，虚拟机之间会存在竞争物理机资源，造成程序不稳定情况。

docker容器部署

更要命的是，如果数据库和zuul网关部署到容器（实质也是虚拟机）里，那么网络io读写变成docker（虚拟机）到虚机，再到物理机三层访问，无形之中又增加了io读写性能开销。尤其是对于请求吞吐量要求很高的服务网关zuul，是不能容忍的。

所以虚机对于IO密集型以及对延迟要求很高的业务场景不合适。

另外，早期的时候，作为一名架构师需要尽早的规划好服务网关和数据库的物理部署方式以及软硬件性能要求。

阿里大神分享API网关在微服务架构中的应用！

案例背景介绍：
在实践微服务架构时，我们经常会面对以下需求：如何隔离外部和内部，如何保障后台服务安全性，如何降低运维成本，如何减少变更的流程和错误成本，如何减少客户端与服务的耦合等，API网关是一个非常重要的集中管控点。

解决思路/成功要点：
通过引入API网关这一角色，可以高效的实现微服务集群的输出，节约后端服务开发成本，减少上线风险，并为服务熔断，灰度发布，线上测试等提供简单方案。

成果：
API网关是一个关键的互联网入口，选择一个适合的API网关，并用好网关产品，可以有效的简化开发并提高运维与管理效率。

长按订阅更多精彩▼

如有收获，点个在看，诚挚感谢