使用场景
在实现业务的时候，我们常常有些需求需要系统主动发送消息给客户端，方案有轮询和长连接，但轮询需要不断的创建销毁http连接，对客户端、对服务器来说都挺消耗资源的，消息推送也不够实时。这里我们选择了WebSocket长连接的方案。
有大量的项目需要服务端主动向客户端推送消息，为了减少重复开发，我们做成了微服务。
使用于服务器需要主动向客户端推送消息、客户端需要实时获取消息的请求。例如聊天、广播消息、多人游戏消息推送、任务执行结果推送等方面。
使用流程
用Websocket客户端连接本服务，服务端会返回客户端一个唯一的client id，通过这个client id可以知道是哪个连接，客户端拿到这个id之后上报到服务端，服务端根据业务需求可以给这个长连接发送指定信息，或者绑定到分组。
分布式方案
维持大量的长连接对单台服务器的压力也挺大的，这里也就要求该服务需要可以扩容，也就是分布式地扩展。分布式对于可存储的公共资源有一套完整的解决方案，但对于WebSocket来说，操作对象就是每一个连接，它是维持在每一个程序中的。每一个连接不能存储起来共享、不能在不同的程序之间共享。所以我能想到的方案是不同程序之间进行通讯。
那么，怎样知道某个连接在哪个应用呢？答案是通过client id去判断。那么通过client id又是如何知道的呢？有以下几种方案：
HASH_SLOT = CRC16(key) mod 16384
以上两种方案都可以实现需求，但一致性hash算法的方案会使部分key找到的节点不准确；hash slot的方案需要维护一张虚拟表，在实现起来需要有一个功能去判断服务器是否挂了，然后修改这张虚拟表，新增节点也一样，在实现起来会遇到很多问题。
然后我采取的方案是，每个连接都保存在本应用，然后用redis的key value记录每个连接client id对应的服务器IP和端口。对指定client id进行操作时，去redis找出响应的ip和端口，判断是否为本机，不是本机的话进行RPC通讯告诉相应的程序。长连接的连接数据不可迁移，程序挂掉了相应的连接也就挂了，在该程序上的连接也就断开了，这时重连的话会找到另一个可用的程序。
Golang实现的分布式WebSocket微服务
简介
本系统基于Golang、Redis、RabbitMQ、RPC实现分布式WebSocket微服务，也可以单机部署，单机部署不需要Redis、RabbitMQ和RPC。分布式部署可以支持nginx负责均衡、水平扩容部署，程序之间使用RabbitMQ广播、RPC通信。
基本流程为：用ws协议连接本服务，得到一个clientId，由客户端上报这个clinetId给服务端，服务端拿到这个clientId之后，可以给这个客户端发送信息，绑定这个客户端都分组，给分组发送消息。
目前实现的功能有，给指定客户端发送消息、绑定客户端到分组、给分组里的客户端批量发送消息。适用于长连接的大部分场景，分组可以理解为聊天室，绑定客户端到分组相当于把客户端添加到聊天室，给分组发送信息相当于给聊天室的每个人发送消息。
架构图
单机服务
分布式
时序图
单发消息
- 客户端发送连接请求，连接请求通过nginx负载均衡找到一台ws服务器；
- ws服务器响应连接请求，返回client id，记录到redis，保持长连接；
- 客户端拿到client id之后，交给业务系统；
- 业务系统拿到client id之后，通过http发送相关消息，经过nginx负载分配到一台ws服务器；
- 这台ws服务器拿到clinet id和消息，去redis查询到IP地址和端口；
- 拿到IP地址和端口，通过PRC协议给指定ws程序发送信息；
- 该ws程序接收到client id和信息，给指定的连接发送信息；
- 客户端收到信息。
群发消息
- 前3个步骤跟单发的一样；
- 业务系统拿到client id之后，通过http给指定分组发送消息，经过nginx负载分配到一台ws服务器；
- 这台ws服务器拿到分组ID和消息，发布给RabbitMQ；
- 所有订阅到RabbitMQ的服务，会收到新信息推送，找到本机所有该分组的连接；
- 给所有这些连接发送消息；
- 客户端收到信息。
源码
交流
QQ群：1028314856