为什么进行PK

boot4go-gateway开源项目，是一个golang实现的高性能的gateway功能的项目， 在springcloud的项目里都是使用springcloud-gateway作为gateway的服务组件，springcloud虽然后面使用webflux实现了所有的gateway功能，提供springcloud环境里的API反向代理的功能，在性能能有了不错的提升，但是和nginx比较起来，毕竟是java系列的，即使使用netty作为底层通信的服务，但是在性能上和nginx还是差距了很大， 这个在以前的springcloud项目里，我已经做过测试和比较，但是在springcloud在中国目前中小公司的流行程度，还是很多公司在使用，springcloud我个人的感觉，由于其先天的java血统，对springcloud系列的组件支持很方便，但是对其他的云环境就不能支持，所以在未来的云原生的环境下，由于其不是特别优秀的性能，必须要做出一定的转变，否则，范围会跃龙越窄。

boot4go-gateway是用springcloud-gateway的功能方式以golang实现的一个组件，功能上对等springcloud-gateway，集成的服务治理上目前仅支持etcd，nacos，zookeeper，zulu版本后期看情况是否继续支持，既然这个产品是为云原生诞生的，那么nacos，zookeeper这样云原生的非热门产品是否支持还在考虑中，主要是以etcd系列为主了。

在项目放到github上之初，就有朋友关注了，提出意见，既然作为初衷，那么这个产品的性能必须要可nginx进行一下比较， 简单的通过页面访问进行过简单的感觉，不比nginx差，但是作为服务端产品，在多并发的情况下，进行压力和性能负载测试，才能更客观的进行两者性能的比较。

PK的环境

所以先通过jmeter进行了简单的并发和压力测试，jmeter单机，本版本测试没有部署多台jmeter进行测试，毕竟是第一轮，先简单的比较下，有意义再模拟更多的场景，所以只规划准备一单节点的jmeter进行压力测试

第一版本测试试，还没有非常全面的进行测试，

场景如下：

分别使用Nginx和Boot4go-gateway作为前端的反向代理，代理的目标机器是nginx的两台http服务器，

测试场景中的返回数据使用了4中场景的数据包。

场景1： 默认文件，index.html 45KB文件大小， html文件

场景2： 中型文件 index-m.html 20KB文件大小， html文件

场景3： 小型文件 index-s.html 5KB文件大小，html文件

场景4： 超小型文件 index-xs.html 1KB文件大小，html文件

环境均搭建在同一个开发机器的虚拟机上的不同的docker容器里。 由于gateway使用了etcd作为数据存储，还有一个3个节点etcd集群作为gateway的服务治理端，

Nginx均使用官方的latest作为镜像， boot4go-gateway是golang实现，直接dockerfile制作成本地镜像进行容器的部署， etcd使用3.5.1的官方镜像， 三节点都是3.5.1的版本， 数据大小为100M左右

压测策略

环境都是安装在自己的笔记本上的， 没有压太多量，最大600的并发数， 持续加压的策略。

测试环境

作为gateway的nginx配置，

upstream gateway {  server 192.168.56.101:10081;  server 192.168.56.101:10082;}    location / {        # root   /usr/share/nginx/html;        # index  index.html index.htm;		proxy_pass ;    }

可以看到是最简单的场景，作为gateway的nginx的开发端口是10080，访问的地址

, 反向代理到后面的 192.168.56.101:10081 和192.168.56.101:10082

PK方boot4go-gateway的配置。

boot4go-gateway有管理的界面，在界面里进行配置，

boot4go-gateway支持多域名多网址代理模式，这里可以看到，使用192.168.56.101:9000进行代理，没有开放ssl，和nginx同等环境，

路径同样代理到后面的两台服务器 192.168.56.101：10081和192.168.56.101:10082, 路径的映射是代理/nginx/下的请求，即 访问即可访问到192.168.56.101:10081/index-s.html。

测试结果

大数据，45KB数据包，summary

Boot4go-Gateway

Nginx

​​

PK结果

请求错误数相同，但是请求总量，Boot4o-Gateway多于Nignx，使得错误率明显比Nginx降低，TPS相差不大，10的差距，不过是45KB的数据包，在receive bytes/sec上差距明显，

二）中等数据，20KB数据包， Summary

Boot4go-Gateway

Nginx

PK结果

此数据包情况的测试下， 在TPS上相差依然不大，只是在错误率上，Nginx的错误返回达到了2000多，boot4go-gateway的错误数不到1000，错误率相差较大，一个在2%左右，一个已经下降到了1%以内。总请求书依然相差不多。

三）小数据 ， 5KB数据包， Summary

Boot4go-gateway

Nginx

PK结果

此数据包测试情况下， 错误率都大幅下降，boot4go-gateway没有错误，nginx错误降到了800左右，

四）精简数据， 1KB数据包，Summary

Boot4go-gateway

Nginx

PK结果

精简数据包情况下，Boot4go-gateway没有错误，Nginx的错误下降到500以内，

篇尾

此次为简单的测试，只是测试的get协议，没有测试上传数据，单单从数据下载的情况上来看，boot4o-gatteay不逊色于nginx作为反向代理，而且在某些方面，还稍稍优于nginx，在超时错误这块还要再进一步仔细的去查找原因，boot4go-gateway是使用的fasthttp作为通讯底层的支持，反向代理作为后台服务器的client，也是使用fasthttpclient作为http的通道，从而获得较好的性能支持。

本篇文章，仅仅支持简要的概要一下性能测试的结果和PK的结果，后面会有文章详细的去解析性能测试的具体环节和分析过程。并且汇总一下，性能测试中对boot4go-gateway发现的一些bug及性能优化的过程。 敬请关注。

​