基于rockermq的异步服务

背景

开发：你确定这个玩意有实现的必要？
产品：当然，需求就是这样的
开发：但是对方接口的响应时间太长了吧，而且是两个
产品：嗯，我跟对方确认过的，第一个接口的响应时间是12s左右，第二个接口的响应时间是40s左右，并且调用第二个接口还需要在第一个接口的返回基础之上
开发：那还有做的必要吗？这个用户体验得差到什么程度，要是长连接服务器得爆掉，要是定时请求，服务器也承受不住啊
产品：这个是公司的一个试探性产品，主要是为了探索市场，产品体验差没关系，不过这两个接口和衔接的流程你得好好设计一下，因为这两个接口这条产品线会一直使用
开发：目瞪口呆😰

流程梳理

为了探索市场，产品需要快速开发一个产品，该产品需要调用第三方两个接口，但是这两个接口的响应时间真不好意思说（作者高度怀疑第三方的服务器架设在火星上），更坑的是用户输入内容需要顺序调用这两个接口，调用第二个接口需要根据第一个接口返回的内容，最坑的是，这个流程可能会成为这条产品线的主要流程，所以需要好好设计一下，保证服务的可用性，一图以毕之：

对，整个接口的响应时间大约需要52s，就问你坑不坑，而且产品居然能够根据这两个接口设计产品，小弟在这里已经跪下了。

技术设计第一版

虽然产品很坑，虽然第三方很坑，虽然接口非常坑，但是我们是谁，我们是程序猿，就算这个世界都在坑，我们也会是最稳的，基于上面接口响应的现状，以及前端原因，无法进行push，那么定时pull成为了更好的选择，

流程如下：
1：前端调用接口，开始主业务，主页返回执行中信息，并且开启异步方法，异步方法调用统一的出口服务，出口服务调用第三方
2：异步方法根据第一个接口返回结果调用第二个接口，进行价格计算，经过漫长的40s等待之后，返回结果
3：前端一直定时请求该接口，根据用户ID获取执行结果，一旦执行完成，那么同样通过该接口获取返回结果
缺点&#