我想问下这个调用方式该怎么优化

[macscsbf]

因为项目经理对原来的项目的调用方式不满意，现在的调用方式是客户端通过 websocket 连接到我这个模块，其他模块每次通过消息队列请求我这个模块，我会把这个请求扔到队列里,当得到了客户端的回复我再通过 http 请求那个模块通知结果。

我与客户端通信的数据的协议规定我必须要处理完一个请求(也就是得到客户端的回复)才能发送他们发过来的下一个请求(所以我用了队列)。

他希望的是其他模块直接用 http 请求我这个模块，直到客户端回复我的时候直接把结果返回给那个模块，我跟他们说如果一个客户端请求多的话可能会阻塞很久,因为其他的请求要等待着上一个请求等到回复后才能继续发送，于是他也不满意这种方式。他说原来的方式对用户的体验不好，但是他又想不出什么方案来，就说是本来就是要你解决这个问题的，你应该要想办法解决。

所以我想来请教下大伙。

[jones2000]

合并消息处理， 请求一直往队列里面塞， 取的时候批量取， 然后批量执行，执行完了， 把批量结果返回过去。

[ymy3232]

明显是项目经理觉得慢 看你描述是慢在客户端 那就把问题推给客户端 不是你的问题不要帮别人想办法

[sujin190]

用了 websocket 又设计个同步的 request response 协议，简直坑死人

用户体验不好应该看效率阻塞在哪了和哪的错误率最高，别头痛医头脚痛医脚啊，项目经理希望改成 http 阻塞请求说不定是你这么等客户端返回再请求对应模块的时候，那个模块没办法及时返回给它那边的前端，然后延时高用户体验差呢

[macscsbf]

@ymy3232
@sujin190
忘了说明了，是他不知道怎么推送给前端，平常都是前端请求后端然后直接得到结果，这种方式他不会去做就说了用户体验差,让我改成阻塞的形式

[macscsbf]

@sujin190
@ymy3232
然后他就先是让前端加刷新按钮，之后又觉得这种方式不合理，就要让我阻塞等到结果。

[macscsbf]

@sujin190 确实，我感觉这种 request ，response 弄的就很难受

[MoYi123]

给每个消息加个 id, 由客户端控制 id 是什么, 服务器原样返回, 这样客户端就有办法拿到每次请求的上下文了.
这样客户端可以用一个 map<id, closure function> 来处理消息.

当然根据我的经验, 要改早改了, 客户端十有八九搞不懂怎么写异步通信, 建议跑路.

[sujin190]

@macscsbf 其实如果请求量有限这个问题不大，你这边看样子是有状态服务，那么提供阻塞调用是没有问题的，仔细评估业务场景和量，实际上没必要猜测如果量太多怎么办这种问题，毕竟如果量真的很大那么就应该另一边的也应该用 websocket 接入到你这边才对

[opengg]

他这是在扯淡。
服务被客户端阻塞可还行？服务就是要快。
被上游业务阻塞也就算了，还搞什么被客户端阻塞，两头堵那是找死。

至于为什么用户体验差，根源恐怕不在这个改动上。
建议跟客户端商量一下，多条消息在客户端上并行处理。