socket.d
socket.d copied to clipboard
noear
Application protocols based on "event" and "semantic message "" stream" (alternative to http, websocket, etc., in microservices, mobile applications, iot, etc.)
服务端调用 session.close() 后，服务端和客户端的处理流程是什么； 若客户端调用 session.close() 后，服务端和客户端的处理流程是什么；
大神好，就socket.d的应用场景有问题需指教一二（结合类似在线或IM聊天场景）： 1. 现状：当前公司在线系统（即会员与客服聊天）前后端交互主要通过HTTP协议（前端发起请求后、使用轮询方式来更新最新聊天数据——而后端服务则是私有协议、基于thrift，中间通过网关层将私有协议暴露成HTTP方式供外部调用，前后端交互通过对外域名、经网关层后转发给到后端服务）；系统迭代过程中也要支持会员与大模型聊天，当前选型是通过grpc方式对接——即在线后端服务与某grpc服务交互，而前端仍选择是轮询方式；鉴于轮询方式存在弊端且特别对人机交互不友好，故需选型类似sse或ws的协议支持 2. 困难：当前网关层承接了前后端服务的路由、但现有网关对外并不纯支持长连接方式（均以HTTP协议为准、即将私有协议发布成HTTP URI方式）而后端服务是基于私有协议并不支持类WS这种双工或SSE这种服务端推的方式，即对聊天这种交互不友好。现有解决方案则跟爱奇艺的方式近似：https://baijiahao.baidu.com/s?id=1692748005375644637&wfr=spider&for=pc 但这种方式架构则比较复杂（如后端服务要把消息发送给前端、需先发送到一个restful的服务、然后该服务将消息投递给到MQ， 然后网关节点消费该消息并与本地session匹配.......） 3. 问题： 3.1 socket.d涉及http协议： 1）Q1. 鉴于Http协议相比tcp以及ws还是有其优势的，特别是2.0/3.0，即便前端与后端使用ws等交互、http也需保留来支持兜底——因此socket.d是否需支持，考虑到socket.d的transport有netty模块，是否考虑支持http方式的接入 2）Q2. 就上述，若socket.d支持了http、但基于http协议的sse是否可支持（或者是server push）、我理解当前sse前端是一套标准的js的是否跟现有socket.d的js存在出入 3.2 socket.d涉及multi broker： 1）背景：即考虑将现网关改造成multi broker，前端与后端均类似于client方式接入到broker、而broker肯定是多台（multi broker） 2) Q1：一般前端都是通过nginx代理给到broker的，若要兼顾broker是高可用的——如何使得Nginx代理到这多台组成的集群中（而且一般当下都是域名、即只有一个serverUrl） 3）Q2：同上、如果mult broker对外就是域名本身，若是后端服务接入当调用createClusterClient的时候是否创建也是clusterSession 4) Q3：如果需要broker兼顾支持sse以及ws或者http 是否可以——...
