背景:
最近在做公司一个收单项目的自动化,涉及到业务中应用调用其他项目应用的情况(鉴权应用),比如开商户需要对商户的三要素进行鉴权,在单独执行一个case的时候调鉴权正常,但是同时执行多条该接口的case时,经常出现failed to respond,捣鼓了好久,终于解决了O(∩_∩)。
原因:
客户端与鉴权通信的代码使用了连接池,而连接池是一种长连接的TCP通讯,而鉴权是支持短连接的,所以当客户端建立长连接以后,就会一直发http请求,但是服务端(鉴权)已经把连接断开了,因此服务端不会再给客户端响应,所以是failed to respond。
解决办法:
清楚了原因,大概就知道解决办法了,我们在两个应用调用之间加个ngnix,通过ngnix转发访问鉴权,即可
客户端请求ngnix默认是长连接,ngnix转发到客户端默认是短连接,如果想支持长连接也可以通过 keepalive_timeout 120;参数设置
知识补充:
1、HTTP协议是应用层协议,无长短之说--HTTP协议是基于请求/响应模式的,因此只要服务端给了响应,本次HTTP连接就结束了,或者更准确的说,是本次HTTP请求就结束了,根本没有长连接这一说。那么自然也就没有短连接这一说了。
1.1、HTTP1.0短连接,客户端与网络服务器建立连接以后,只能获得一个资源
1.2、HTTP1.1长连接,客户端与网络服务器建立连接以后,在一个连接上获得一个资源(节约网络带宽,可以只先发头部信息,没问题再发送body)
1.3、HTTP2.0:
多路复用(单链接资源,减少服务器的压力)
首部压缩(减少发送内容大小、速度快)
二进制帧(应用层和传输层之间多了一个二进制分桢层)
服务器主动推送机制(一个请求过来,可以把服务端的一些资源缓冲到客户端,下次请求就可以直接用)
2、TCP是传输层协议,一般我们说的HTTP分为长连接和短连接,其实本质上是说的TCP连接。TCP连接是一个双向的通道,它是可以保持一段时间不关闭的,因此TCP连接才有真正的长连接和短连接这一说
简单举个例子:ip就相当于一条公路,而路上的汽车、货车等就相当于TCP/UDP,车上的货物就相当于HTTP、FTP这样的协议
现在我们日常的web网站基本都是用的HTTP1.0(默认长连接keep-alive),如果使用长连接,客户端和服务端都得设置成长连接才有效。
长连接是指的TCP连接,也就是说复用的是TCP连接。连接情况下,多个HTTP请求可以复用同一个TCP连接,这就节省了很多TCP连接建立和断开的消耗。
3、ngnix
Nginx是一款轻量级的Web 服务器/反向代理服务器及电子邮件(IMAP/POP3)代理服务器。 Nginx 主要提供反向代理、负载均衡、动静分离(静态资源服务)等服务。
代理:
正向代理,像vpn需要我们自己手动做一些设置才能使用
反向代理,代理我们要访问的服务器,通过ngnix转发到我们要访问的内部服务器上,并将服务器上的结果通过它返回给客户端
简单的理解,就是正向代理是为客户端做代理,代替客户端去访问服务器,而反向代理是为服务器做代理,代替服务器接受客户端请求。
负载均衡:
在高并发情况下需要使用,其原理就是将并发请求分摊到多个服务器执行,减轻每台服务器的压力,多台服务器(集群)共同完成工作任务,从而提高了数据的吞吐量
轮询方式:
(1)、轮询(默认)
每个请求按时间顺序逐一分配到不同的后端服务器,如果后端服务器 down 掉,能自动剔除。
weight 代表权,重默认为 1,权重越高被分配的客户端越多,如下配置;
upstream server_pool{
server 127.0.0.1:8081 weight=2;
server 127.0.0.1:8082 weight=1;
}
(2)、ip_hash
每个请求按访问 ip 的 hash 结果分配,这样每个访客固定访问一个后端服务器,可以解决 session 的问题。 例如:
upstream server_pool{
ip_hash;
server 127.0.0.1:8081;
server 127.0.0.1:8082;
}
(3)、fair(第三方)按后端服务器的响应时间来分配请求,响应时间短的优先分配
upstream server_pool{
server 127.0.0.1:8081;;
server 127.0.0.1:8082;
fair; }
动静分离
动静分离是让动态网站里的动态网页根据一定规则把不变的资源和经常变的资源区分开来,动静资源做好了拆分以后,我们就可以根据静态资源的特点将其做缓存操作,这就是网站静态化处理的核心思路