「 关注“石杉的架构笔记”，大厂架构经验倾囊相授 」
问题背景
两个月前的一个版本需要对接腾讯会议相关接口，需要接收腾讯会议事件变更回调，腾讯会议通过webhook的形式发送http请求到我们的测试环境服务中，暂且称之为A服务，假设域名为a.test.abc.com。
在保存接口配置的时候，腾讯会议对接口url进行可用性的校验，3秒内进行响应，并正确返回即可进行配置。
问题现象
在配置的过程中出现了异常提示，无法正常保存配置，反复操作十几次后，才正常保存成功一次（具体原因可参考文末第五节）。如图所示：
问题排查
排查接口是否存在复杂逻辑
接口是简单的GET请求返回base64解码后的字符串，没有做任何特殊处理。
排查controller层发现无特殊的aop耗时逻辑。
在本地电脑上使用Postman模拟请求，无论是公司内网或者外网调用接口响应时间都很快，均在200ms内响应。
与相关方收集接口请求数据
与腾讯会议后端负责人沟通，腾讯后端负责人排查日志发现，腾讯会议后端发起http调用A服务测试环境url超时。
临时解决方案
为了避免影响送测，我们临时在线上阿里云服务上的某个服务做了一层请求中转，让腾讯云把请求打到了线上服务，线上服务通过okhttp发起第二次http请求转发到测试服务中。
经过这层中转临时解决了问题，实现了业务正常回调。
可是对于测试环境来说，阿里云线上的服务器一样是外网环境，为什么我们的服务调用测试环境没有问题，而腾讯的服务调用就超时呢？文末第五节有谈到问题解析
排查网络链路问题
排查链路问题之前，尝试用自己的服务器和线上服务器部署了简单的web服务，提供回调接口，均可正常配置。基本可以确定腾讯会议服务访问A服务测试环境存在耗时问题。
模拟外网请求测试环境接口，查看耗时
使用curl模拟外网请求测试环境接口，打印各个环节耗时：
选择阿里云多台容器测试：
使用腾讯云服务器测试：
可以发现，在域名查找(time_namelookup)这个环节耗费了绝大部分时间。
而tcp连接、http请求响应、数据传输的环节耗时非常低，均在200ms左右。
curl代码示例
curl -w "time_namelookup：%{time_namelookup}ntime_connect：%{time_connect}ntime_pretransfer：%{time_pretransfer}ntime_starttransfer：%{time_starttransfer}ntime_total：%{time_total}n" -o /dev/null -s -L "https://a.test.abc.com/server-main/api/v1/meeting/disable/callback?check_str=xxx(此处填上url)"curl部分参数对应关系
| 参数 | 描述 |
|---|---|
| time_total | 总时间，按秒计。精确到小数点后三位 |
| time_namelookup | DNS解析时间,从请求开始到DNS解析完毕所用时间 |
| time_connect | 连接时间,从开始到建立TCP连接完成所用时间,包括DNS解析时间(得到连接时间=time_connect-time_namelookup) |
| time_appconnect | 连接建立完成时间，如SSL/SSH等建立连接或者完成三次握手时间 |
| time_pretransfer | 从开始到准备传输的时间 |
| time_redirect | 重定向时间，包括到最后一次传输前的几次重定向的DNS解析，连接，预传输，传输时间 |
| time_starttransfer | 开始传输时间。在client发出请求之后，Web 服务器返回数据的第一个字节所用的时间 |
观察服务入口流量
使用tcpdump对A服务流量入口进行抓包操作，将日志dump到本地，使用wireshark进行分析可以发现。从建立TCP连接开始到发起http请求，耗时确实很低，与上面打印的时间相符
tcpdump命令
tcpdump -i eth0 -s 0 -w tcp.pcap
观察外网调用方发起http请求的流量详情
依然通过tcpdump进行抓包和分析，可以发现，仅使用0.3ms，dns服务器就已经返回了域名对应的ip地址。但是完成这步操作之后，客户端没有开始建立tcp连接，而是继续查找AAAA a.test.abc.com的操作，而这一步耗时长达5秒多，完全符合4.1中的耗时情况。
此处query AAAA的操作为查找ipv6地址，每一次curl请求都发出了两次DNS query，一个是A记录，另外一个是AAAA记录，也就是同时请求了IPV4和IPV6地址。IPV4很快就返回了结果，而IPV6则常常耗时长达5秒(IPV6请求会被forward到upstream的DNS)，且最终返回NXDomain无IP结果。
验证问题
对curl请求加上-4参数，直接使用Ipv4地址进行请求，验证是否是ipv6地址查询耗时导致。确实非常快得到了响应。至此，问题已经被验证。
解决方案
带着问题和数据包，向运维求助。最终由运维的同事针对*.test.abc.com的泛cname做ipv6的假响应配置，即不做任何处理，直接返回NXDomain。问题得到解决。
过程遇到的其他问题
1.阿里云线上环境请求测试环境也存在耗时的情况，那为什么在临时解决方案中使用了中转服务可以正常使用呢？
定位okhttp的源码可以发现，okhttp会解析http请求url的域名，在域名第一次请求获取ip的时候，将域名和ip进行一一对应的缓存，并且这个缓存操作与操作系统级别的dns缓存不同，是没有过期时间的。
所以可能会存在第一次请求的时候耗时较长的情况。但是经过第一次请求后，后面发起的http请求都是直接用ip地址进行请求，无需再次解析。
代码位置：java.net.InetAddress#getAllByName0(java.lang.String, java.net.InetAddress, boolean)
2.腾讯会议服务多次保存只有少数次可以成功
猜测依然是与上面一样存在ip缓存的机制，由于现在绝大部分web服务都是分布式地部署多台容器，多次http请求中，只要有两次走到了同一台机器上，即可使用组件缓存的ip地址直接请求。
------------- END -------------
点个在看你最好看
网友评论已有0条评论, 我也要评论