工作分享总结：如何分析接口调用产生的一些问题
今日公司周会上，旭哥给大家分享了一些接口调用产生的一些问题的分析套路和方法。下面做以记录，方便未来回顾和学习。
一、现状：
接口调用是目前部分使用最为频繁的环节，大部分问题产生因接口调用失败引起。接口调用日志记录不够规范、详细，导致出现问题时，难以迅速定位问题产生的具体原因，甚至要阅读源代码，耗费了较多的人力成本。接口调用失败时，对返回的错误状态（环境、网络、应用）、详细信息记录不全，导致现场信息没有记录，并且难以手工复现。
历史问题遗留，影响业务正常运行，以至影响到测试、产品、最终用户的满意度。花费了较多人力排查这些基础问题，影响开发效率，而且对同类问题的解决，没有形成有效的方法论和实践论。没有从根本上找清楚问题产生的根源，导致此类问题一直遗留。重复而单调的工作，不利程序员的成就感的形成。
二、基础知识储备1、一个域名可以解析到多个ip上，客户端连接时会使用到其中一个IP。使用nslookup命令查看域名对应的ip。
每个阶段，都可能超时，所以引起请求失败的原因是多样的，具有一定的复杂性：
1. 如果使用域名请求，目标机器是不确定的。
2. 请求的每个阶段，都有可能超时或出错。
3. 对同一个服务器，从不同的来源访问，数据传输的网络线路可能并不一样，导致比较难以复现。
如图示，由于网络线路的复杂性，从不同的源访问同一个目标，经过的线路就有差别，从而响应状态和结果，可能就有差异。
D能访问C, 但A不能访问C, A和D却能相互访问，这种现象现实中有可能存在。
所以，两个重要点：
3. 上述信息是否记录足够清楚详细？
如果从这三个因素入手， 就可以查明具体的原因，从根本上解决问题提供重要依据。
无论网络任何协议，都可以使用此方式来查明原因。
3、curl_getinfo的重要性
curl内置了请求状态信息，它是直接解决此问题的金钥匙。
一、现状：
接口调用是目前部分使用最为频繁的环节，大部分问题产生因接口调用失败引起。接口调用日志记录不够规范、详细，导致出现问题时，难以迅速定位问题产生的具体原因，甚至要阅读源代码，耗费了较多的人力成本。接口调用失败时，对返回的错误状态（环境、网络、应用）、详细信息记录不全，导致现场信息没有记录，并且难以手工复现。
历史问题遗留，影响业务正常运行，以至影响到测试、产品、最终用户的满意度。花费了较多人力排查这些基础问题，影响开发效率，而且对同类问题的解决，没有形成有效的方法论和实践论。没有从根本上找清楚问题产生的根源，导致此类问题一直遗留。重复而单调的工作，不利程序员的成就感的形成。
二、基础知识储备1、一个域名可以解析到多个ip上，客户端连接时会使用到其中一个IP。使用nslookup命令查看域名对应的ip。
nslookup www.zkait.com
Server: 10.143.22.118
Address: 10.143.22.118#53
Non-authoritative answer:
www.zkait.com canonical name = sk121.webcname.net.
Name: sk121.webcname.net
Address: 111.67.201.183
nslookup www.qq.com2、一次TCP请求的大致流程：
Server: 10.16.24.201
Address: 10.16.24.201#53
Non-authoritative answer:
Name: www.qq.com
Address: 61.135.157.156
Name: www.qq.com
Address: 125.39.240.113
- DNS解析
- TCP建连
- 发送数据
- 服务器响应
- 接收数据
每个阶段，都可能超时，所以引起请求失败的原因是多样的，具有一定的复杂性：
1. 如果使用域名请求，目标机器是不确定的。
2. 请求的每个阶段，都有可能超时或出错。
3. 对同一个服务器，从不同的来源访问，数据传输的网络线路可能并不一样，导致比较难以复现。
如图示，由于网络线路的复杂性，从不同的源访问同一个目标，经过的线路就有差别，从而响应状态和结果，可能就有差异。
D能访问C, 但A不能访问C, A和D却能相互访问，这种现象现实中有可能存在。
所以，两个重要点：
1. 具体的交互节点是什么？ 一般来说，往往就是源和目标的IP而不是目标的域名
2. 网络请求每个阶段行为是什么？ 即每个阶段的结果状态和耗时：
- DNS解析？ 解析结果是什么？ 成功还是失败？耗时多久？
- TCP建连？ 连接状态成功还是失败？耗时多久？
- 发送请求？ 共发送了多少字节？ 耗时多久？
- 服务器响应？ 服务器响应结果是成功还是失败？ 耗时多久？
- 接收数据 共接收了多少字节？ 结果有效还是无效？ 耗时多久？
3. 上述信息是否记录足够清楚详细？
如果从这三个因素入手， 就可以查明具体的原因，从根本上解决问题提供重要依据。
无论网络任何协议，都可以使用此方式来查明原因。
3、curl_getinfo的重要性
curl内置了请求状态信息，它是直接解决此问题的金钥匙。
[url] => http://www.baidu.com/ 本次请求的地址
[content_type] => text/html; charset=utf-8
[http_code] => 200
[header_size] => 1001
[request_size] => 248
[filetime] => -1
[ssl_verify_result] => 0
[redirect_count] => 0
[total_time] => 0.625064 总用时
[namelookup_time] => 0.001113 DNS查询耗时
[connect_time] => 0.002997 TCP建连耗时
[pretransfer_time] => 0.002999 传输之前的所有耗时（包括DNS查询）
[size_upload] => 0
[size_download] => 111640 返回的数据长度（包括header)
[speed_download] => 178605 传输速度(字节/秒）
[speed_upload] => 0
[download_content_length] => -1
[upload_content_length] => 0
[starttransfer_time] => 0.007983
[redirect_time] => 0
[redirect_url] =>
[primary_ip] => 220.181.112.244 目标IP
[local_ip] => 127.0.0.1 源IP
[certinfo] => Array()
[errno] => 0 错误号
[error] => 错误信息
