技术背景：
业务系统：管理机器人，机器人任务执行等等
机器人使用是ros1 ，业务系统与机器人交互使用rosbridge, rosbridge 就是websocket 链接，所以就有了如下的一些架构思想

架构图

客户端

客户端主要分为app端、pc端、h5端等。每个端都会与网关维护一条稳定的长连接。当然pc端的多窗口其实是多websocket连接了

ingress

ingress负责七层域名，这里可以是nginx组件也可以是k8s的ingress controller组件。

并且在这一层可以挂载证书，做TLS的加解密，继而将长连接代理到网关去。

这里要注意的是客户端和ingress这一层是wws协议，ingress和ws-gateway是ws协议。

ws-gateway

ws-gateway维护了所有机器人登录后的ws长连接。有如下职责：

• 尽可能的去承担机器人 的ws长连接。

• 做机器人 鉴权，解析机器人ID和一些业务ID。

• 负责将机器人消息分到到下游，将服务端消息通知到在线机器人。

生成socketId，并维护socketId与ws连接的关系。这里的sid在后续的设计中尤为重要。

网关的设计应该是稳定的，无业务的。

ws-api

ws-api是业务系统与网关的媒介。换句话说，它是业务系统与在线机器人沟通的桥梁。

ws-api与网关的信息交互，我们一开始的设计是ws通道，后续切换到了gRPC-Stream。关于这里的思考，大家可以看一些关于gRPC-Stream websocket的文章。

ws-api的职责如下：

负责向在线机器人 通知实时消息的API。

负责维护多个维度的映射关系。

负责消息广播，将一条消息广播到各个gateway的节点上。

负责维护连接的心跳（通过redis key ttl实现）。

负责消息/机器人 连接等指标统计。

负责将在线机器 消息下发到MQ Topic中，由下游的业务系统消费。

ws-api与ws-gateway是打包在一起的，一切业务皆在下游。

MQ

消息中间件，可以是RocketMQ，可以是Kafka，主要是做网关与业务系统的解藕。

至于用什么消息中间件看自己需求，基本上常用的都可以满足，看自己具体的业务需要了

下面我们来一起几个业务流程场景

业务系统推送架流程图

在线机器人消息推送