因为项目经理对原来的项目的调用方式不满意,现在的调用方式是客户端通过 websocket 连接到我这个模块,其他模块每次通过消息队列请求我这个模块,我会把这个请求扔到队列里,当得到了客户端的回复我再通过 http 请求那个模块通知结果。
我与客户端通信的数据的协议规定我必须要处理完一个请求(也就是得到客户端的回复)才能发送他们发过来的下一个请求(所以我用了队列)。
他希望的是其他模块直接用 http 请求我这个模块,直到客户端回复我的时候直接把结果返回给那个模块,我跟他们说如果一个客户端请求多的话可能会阻塞很久,因为其他的请求要等待着上一个请求等到回复后才能继续发送,于是他也不满意这种方式。他说原来的方式对用户的体验不好,但是他又想不出什么方案来,就说是本来就是要你解决这个问题的,你应该要想办法解决。
所以我想来请教下大伙。
1
jones2000 2023-03-08 15:44:12 +08:00
合并消息处理, 请求一直往队列里面塞, 取的时候批量取, 然后批量执行,执行完了, 把批量结果返回过去。
|
2
ymy3232 2023-03-08 16:38:36 +08:00
明显是项目经理觉得慢 看你描述是慢在客户端 那就把问题推给客户端 不是你的问题不要帮别人想办法
|
3
sujin190 2023-03-08 17:01:27 +08:00
用了 websocket 又设计个同步的 request response 协议,简直坑死人
用户体验不好应该看效率阻塞在哪了和哪的错误率最高,别头痛医头脚痛医脚啊,项目经理希望改成 http 阻塞请求说不定是你这么等客户端返回再请求对应模块的时候,那个模块没办法及时返回给它那边的前端,然后延时高用户体验差呢 |
4
macscsbf OP |
7
MoYi123 2023-03-08 17:09:16 +08:00
给每个消息加个 id, 由客户端控制 id 是什么, 服务器原样返回, 这样客户端就有办法拿到每次请求的上下文了.
这样客户端可以用一个 map<id, closure function> 来处理消息. 当然根据我的经验, 要改早改了, 客户端十有八九搞不懂怎么写异步通信, 建议跑路. |
8
sujin190 2023-03-08 19:28:59 +08:00
@macscsbf 其实如果请求量有限这个问题不大,你这边看样子是有状态服务,那么提供阻塞调用是没有问题的,仔细评估业务场景和量,实际上没必要猜测如果量太多怎么办这种问题,毕竟如果量真的很大那么就应该另一边的也应该用 websocket 接入到你这边才对
|
9
opengg 2023-03-08 20:26:31 +08:00
他这是在扯淡。
服务被客户端阻塞可还行?服务就是要快。 被上游业务阻塞也就算了,还搞什么被客户端阻塞,两头堵那是找死。 至于为什么用户体验差,根源恐怕不在这个改动上。 建议跟客户端商量一下,多条消息在客户端上并行处理。 |