优化之道: 如何将交易响应时间从40秒缩短至2秒

一次升级，系统大量报错，交易返回全部超时。

我接手的某汽车融资项目，由于某银行网络方面的要求，互联网架构改为了专线模式。这次改动较小，在测试环境验证了常规的接口功能之后就和对方车厂约定了上线时间，结果上线之后大量异常，各种socat超时错误。生产系统崩溃，业务面临瘫痪。

原因初现：对方接口发送频率从30s一次修改为了1s200次。

看前置转发机日志发现，对方在某一时刻发了大量请求进来，项目只有在前几个有寥寥返回，后面的请求都报超时错误。联系对方确认了对方一次性将200多条有业务需求的接口发送了过来，但是项目服务器资源以及并发处理能力有限，哪怕是调大线程数也收效甚微。看原有的互联网架构前置机日志发现对方发送的频率为30-40s一次，由于对方无法短时改动发送频率以及特定的接口，无奈将专线暂时恢复到了互联网版本。

继续排查，一次交易竟然需要40s一次返回？

继续等待了两天，对方发送频率可以进行手动控制了，先按照原有生产环境的频率发送，我们这边的项目可以正常处理。但是有时业务量比较大，虽然业务时效性不要求那么高，可以按照40s一次的频率发，考虑到未来业务的增长或者月末业务增加，准备将响应速度提升。联系对方按照30s一次、20s一次的频率发，忽然发现接收几个交易之后后面的交易返回越来越慢。进一步排查发现，从接收到对方发送的请求开始，直到给对方响应回去，单笔并发的时间都需要40s左右。调整了发送频率之后，上一个请求还没有响应回去新的请求就又进来，直到同时处理了很多个。

问题定位，为何上传下载文件需要7s之久。

进一步排查发现，某额度查询交易一次上传下载文件时需要的时间竟然需要7s，但是文件本身非常小，只有几十几百k。

某001交易上传文件后文件服务器会返回校验码，这一步需要6s左右，该001交易返回报文之后，还会有一个下载响应文件的操作，这里也需要6-7s左右。该交易有两次和文件服务器关于文件相关的交易，再加上另外一个007交易，上传下载总共三次，就耗时了20s左右。 起初怀疑是网路原因，使用ping -t 命令持续和文件服务器测试了延迟，发现延迟非常低，那问题还是出现了自己项目这块。进一步看代码发现文件上传和下载的