@rrfeng 把 haproxy 当成一个 mq 怎么样，主要的问题还是在怎么可靠地排队、监控队列情况。。。因为我是想不要引入新的模块，后续接替我维护这个系统的人光理解现在的这些代码就已经很费劲。。我们情况也还比较特殊， MQ 不太好接进来，后边那些耗时的服务程序有很多个，完成不同的功能，要改接口的话是个极为繁重的任务而且很可能引入 bug.系统现在已经在生产环境上线，我们也并没有那么强大的运维能力和人力去搞一个完善的测试环境，所以还是想怎么在现有基础上继续进化， API 的队列机制和 Haproxy 的配置还是比较好改的。。。

@surfire91 其实 API 前端的异步、同步倒是问题不大，现在的设计是请求在 2 分钟内返回就可以，改成异步的话我不知道是不是怕同时的连接太多导致资源耗尽？然后这个系统其实是给第三方做的，大面积的改接口并不太可行。这种方式确实在有些情况下很好我们在别的地方的 API 就用到了这种模式，但是这个系统现在已经基本定型了所以。。。。。

可能我没太表达清楚问题，请求方调用 API 的方式没有问题，问题是在于我觉得现在 API 到服务程序之间排队的模式（ API 一个限制并发的队列+Haproxy 连接时间限制）不太好通过监控即时发现请求数量超过处理能力的情况，而请求是脉冲型的特点似乎又让这个需求变得更加扑朔迷离……