socket.d针对http协议及multi broker协作支持等问题

[bwzhang2011]

大神好，就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
3. Q3：如果需要broker兼顾支持sse以及ws或者http 是否可以—— socket.d兼顾支持tcp和ws应该是没问题的、但如果加http以及sse是否可行（我这边现有解决方案是新做一套支持ws协议的网关）

[noear]

• socket.d 是强调双向通讯的框架，所以 http 不适合。。。socket.io 可能更适合你，它偏向推送，且支持 http
• createClusterClient 不管一个地址，或多个地址，都可以用。。。创建的也是 clusterSession

其它的问题，因为不支持 http。所以也不好答复