前言
在以前的一篇文章《基于Fasthttp实现的Gateway，性能媲美Nginx》中，介绍给大家一款使用Go语言开发的实现反向代理功能的开源项目boot4go-gateway，boot4go-gateway项目以fasthttp作为http的底层服务通信，实现和springcloud gateway相同功能的API网关服务， 同时提供图形化的Gateway管理配置的功能， 在SpringCloud实现的微服务云架构的项目中，完全替代SpringCloud Gateway， SpringCloud Gateway底层只用Netty，结合 Reactor，使用flux的方式替代原有的Zuul的阻塞式响应(Zuul2也实现了非阻塞式响应)，在SpringCloud的微服务云项目中成为Gateway功能的主要产品，boot4go-gateway具有比SpringCloud gateway更高的性能，同时还提供了SpringCloud Gateway所没有的图形化管理功能，本文主要给大家介绍的就是Boot4go-gateway的性能测试的过程，并且对比Nginx提供的反向代理的功能进行性能测试。
测试策略
对比Nginx的测试，在没有进行压力和并发测试之前，笔者就使用Chrome的开发者工具，通过开发者工具里的请求时间，简单的通过页面的调用，页面分别使用Nginx作为反向代理以及Gateway作为反向代理，在相同的环境下，代理目标到相同的API接口， 简单的目测结果Gateway的性能明显的优于Nginx的反向代理功能， 不过目测都是简单的点击，此时的性能测试的PK并不能真正的反映出两者在并发和压力情况的性能，这也就了本文的测试的来历；
本文中我们使用Jmeter作为并发和压力测试的工具，没有使用jmeter进行分布式的多个客户端的模拟测试，只是在单机的Jmeter机器上，通过Jmeter模拟出高并发的压力测试场景， 有必要的情况下，再通过Jmeter构建成更多的Jmeter客户端，进行更高量级的并发和压力测试场景。
环境都是安装在自己的笔记本上的， 没有压太多量，最大600的并发数， 持续加压的策略。
测试场景
测试用例分别各使用Nginx的反向代理功能和Boot4go-gateway来对WEB API目标节点(单个节点)进行反向代理，代理的WEB API目标节点都是使用Nginx部署的Http服务。通过对Nginx的反向代理提供的URL和Boot4go-gateway提供的反向代理的URL进行高并发的压力测试， 这样对于这场PK，目标的WEB API是一致的，网络环境是一致的，差异仅仅就在于提供反向代理的产品上面， 这样经过各种不同压力场景下得到的PK的结果，也可以反映出这两种不同的反向代理产品的性能差异了。
根据目标WEB API返回的数据字节大小，我们选择了4种不同的数据大小的返回结果作为各数据字节测试场景，以此来对各种不同的数据返回字节的情况下的性能测试PK的比较。由于Fasthttp的实现机制，在返回数据量比较大的情况下，可能出现Bug的诟病，我们在Gateway产品的实现上特别的进行针对性的代码优化和调整；
- 场景1： 默认文件，index.html 45KB文件大小， html文件
- 场景2： 中型文件 index-m.html 20KB文件大小， html文件
- 场景3： 小型文件 index-s.html 5KB文件大小，html文件
- 场景4： 超小型文件 index-xs.html 1KB文件大小，html文件
Gateway项目的产品定位是作为SpringCloud的微服务体系中的API网关，最大的数据包我们也只做到了45KB测试场景，毕竟不是作为Http服务器，没必要做大文件下载这样的考虑，同时上传数据包这块也没有做特别的场景测试，调用都是使用Get方式的调用，没有做Post，Put，Delete的场景测试，如果以后有必要可以做这些的场景测试，第一次进行PK，出于方便的考虑，就是通过简单的URL发送请求。
测试环境部署
测试环境都是通过Docker进行部署，2个作为反向代理目标机器的Nginx分别部署在Docker的两个容器内，作为反向代理的前端的Nginx部署在同个宿主机的容器内， 作为反向代理的前端的Gateway也部署在同个宿主机的容器内。
Nginx均使用官方的latest作为镜像， boot4go-gateway是golang实现，直接dockerfile制作成本地镜像进行容器的部署， 由于gateway使用了etcd作为数据存储，还有一个3个节点etcd集群作为gateway的服务治理端，etcd使用3.5.1的官方镜像， 三节点都是3.5.1的版本， 数据大小为100M左右
作为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 http://gateway;
}反向代理Nginx的前端端口是10080， 后端目标机器的IP和端口分别为192.168.56.101:10081，192.168.56.101:10082； Docker宿主机的IP是192.168.56.101
通过Get访问反向代理前端Nginx的URL是http://192.168.56.101:10080, 负载均衡策略为轮询策略不加权；通过反向代理的依次访问目标机器192.168.56.101:10081，192.168.56.101:10082；
boot4go-gateway的反向代理配置
Boot4go-gateway提供管理界面，直接在管理界面里可以动态的进行反向代理规则的配置；修改后立即生效，不需要重启服务， boot4go-gateway的配置数据保存在etcd里。
如上配置， boot4go-gateway的前端访问地址http://192.168.56.101:9000，boot4go-gateway支持域名配置，支持ssl配置。boot4go-gateway支持多域名多网址代理模式。
反向代理策略配置
通过上图配置，反向代理通过前端gateway的处理后代理到后面的两台服务器 192.168.56.101:10081和192.168.56.101:10082, 负载均衡的策略是轮询策略(不加权)；boot4go-gateway支持同IP或者域名的多级路径代理策略配置，支持请求类型(ANY/GET/POST/PUT/DELETE)；不同路径可以配置不同的代理策略，如图中的配置
路径的映射是代理访问路径/nginx/下的所有请求，只要访问路径在/nginx/下的请求，都会按照当前的代理策略配置进行代理转发（根据后面的转换规则进行路径的转换）；
图中的配置，实现就是转发所有/ngixn/下的所有请求，转换规则是直接转换，即
http://192.168.56.101:9000/nginx/index-s.html 转发到192.168.56.101:10081(192.168.56.101:10082)/index-s.html。
http://192.168.56.101:9000/nginx/index.html 转发到192.168.56.101:10081(192.168.56.101:10082)/index.html。
结束语
本文主要介绍文章《基于Fasthttp实现的Gateway，性能媲美Nginx》中的Boot4go-gatway和Nginx进行性能测试的相关性能测试的场景介绍， 场景准备后，将按照场景中规划的场景分别对Boot4go-gateway以及Nginx作为反向搭理的性能进行PK比拼，在下一文章中，我们将重点介绍两者作为反向代理的性能测试过程以及测试结果； 还请各位朋友及时关注。
请持续关注程序员紫龙，不要错过精彩内容。
