这是一个创建于 624 天前的主题，其中的信息可能已经有所发展或是发生改变。
因为项目经理对原来的项目的调用方式不满意，现在的调用方式是客户端通过 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
他这是在扯淡。
服务被客户端阻塞可还行？服务就是要快。 被上游业务阻塞也就算了，还搞什么被客户端阻塞，两头堵那是找死。 至于为什么用户体验差，根源恐怕不在这个改动上。 建议跟客户端商量一下，多条消息在客户端上并行处理。 |
Select Language