技术背景：
业务系统：管理机器人，机器人任务执行等等
机器人使用是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，主要是做网关与业务系统的解藕。
至于用什么消息中间件看自己需求，基本上常用的都可以满足，看自己具体的业务需要了
下面我们来一起几个业务流程场景
业务系统推送架流程图
在线机器人消息推送
