业务场景中向外部的API发送请求过慢，有哪些优化方案？

Question

场景：
系统A在完成一项操作后，需要将结果向外部网站的HTTP形式的API接口发送通知，但因为外部网站不可控，如HTTP连接时间/连接后外部网站的响应时间均不可控(因为要等到它回应：OK，我收到你的通知了才算行，否则会一直重试)，所以造成系统A发出的每一个请求缓慢，线程经常被hold住，堆积、堵塞，最终使系统A本身的逻辑很慢的走下去。

1.系统A执行某项任务(快)->2.执行完通知外部API(快)->3.获得外部响应OK(慢)->4.系统A执行某段逻辑(慢)

请问有哪些优化方案？注，经过分析，90％的时间是在等待外部网站返回结果。所以咱先不说类似替换一个更快的HTTP类库这种，因为这种优化可能的确能提高性能和吞吐量，但这种优化最多也可能提升10％。

我能想到的：
1.push改为pull，或push+pull(就说方案，暂时也不提改动成本，假设都能满足业务)
2.异步化(异步后虽然系统A本身的请求返回快了，即上面流程图中第2步后就直接4了，但是毕竟仍然有一个线程在后台向外通知，这个通知仍然会很慢，占用资源，如果量大就，，，所以只能说解决一半)

求教还有没别的方案？欢迎参与讨论

Answer 1

不知道你这个场景具体是在哪个平台上。我想在不同的平台上，具体方案会有所不同，这里就说一个通用的思路。
我认为你说的【2.异步化】是一个好方案，但要加入一个连接池（线程池）。原则就是，让主线程流畅起来。
主线程分4步，瓶颈在3，那就把3拿出去，让主线程顺畅起来。分出来的这个步骤3在单独一个线程里，这个线程的是block还是怎样，不影响主线程。
又犹豫步骤3异步以后，会出现并发现象，如果说每一个步骤3都有一个线程，那么线程数量会大幅增加，拖慢整个进程，主线程也就慢了。所以，做一个线程池（每一个连接占有一个线程，也就相当于连接池），用来管理这些步骤3，保证并发不会太多，主线程可以顺畅运行。