4.24号接项目组要求，对新开发的接口进行压测，因为调用方要求的tps比较高，综合各个业务方的要求，我们将目标tps定在了4.5w。
配合压测同学整理好压测脚本并调试通过，第二天凌晨2点开始压测，首先压测的是rsf接口(类似Dubbo的一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案)。rsf接口是直连到应用服务器的。rsf接口的压测结果如下：
rsf接口压测结果
从压测结果看，我们的应用服务器是能达到我们的目标tps的。
接着我们开始压测http接口服务，http接口的压测结果如下：
http接口压测结果
我们从http的压测结果也能看到我们的web服务器和应用服务器是能支持我们的目标tps。
最后我们再来看一下我们的https接口服务，https接口的压测结果如下：
https接口压测结果
https接口在压测的过程中，即使增加压力，tps也提升有限，同时后端服务器压力也没有提升，说明压力在前面卡住了没有走到后端服务器。
那么我们的问题出在哪儿呢？下面我们先来梳理一下公司内外网的网络拓扑
公网请求网络拓扑图
办公区内网请求网络拓扑图
服务器内网请求网络拓扑图
从压测机发起请求的网络请求链路是属于上面哪一种场景呢？那我们来看一下压测时的网络拓扑图
测时压测机和被压服务器的网络拓扑图
从网络拓扑图我们看到：当前压测机和被测应用均在属于相同服务器内网，访问过DNS 解析时，识别到请求源端为服务器内网时，会自动解析到内网VIP （现有的 DNS 解析策略），从而出现不经过 WAF 的情况。
那我们在压测https接口时，https的证书在哪儿卸载的呢？答案是负载。压测时，我们的http接口tps远大于我们的https接口tps。那么，这就说明在负载上卸载https的证书，对于我们https接口的tps有很大影响。那解决方案有哪些呢？
我们有如下三个方案(我们是硬件负载，所以不考虑调整负载)
方案一：调整所有压测机的 host 文件，指向过 WAF 的 VIP；
方案二：单独搭建压测机专用 DNS Server，指向过 WAF 的VIP；
方案三：将当前压测机所使用的服务器内网 DNS 改为办公内网 DNS；
由于大促临近，我们目前选择了方案二，调整后我们的网络拓扑如下:
方案二的网络拓扑图
按照上面调整后，我们的http接口和https接口在压测时，压测请求经过waf，那对于https的请求，会在waf上卸载证书。
其实最完美的方案是方案三：将压测机所使用的服务器内网DNS改为公网DNS，这样所有的压测流量都会走公网，那么压测流量必然经过WAF，这样就能达到在waf上卸载https证书的目的。
网友评论