基于go的websocket消息推送的集群实现

目前websocket技术已经很成熟，选型Go语言，当然是为了节省成本以及它强大的高并发性能。我使用的是第三方开源的websocket库即gorilla/websocket。

由于我们线上推送的量不小，推送后端需要部署多节点保持高可用，所以需要自己做集群，具体架构方案如图：

Auth Service：鉴权服务，根据Token验证用户权限。

Collect Service：消息采集服务，负责收集业务系统消息，存入MongoDB后，发送给消息分发服务。

Dispatch Service：消息分发服务，根据路由规则分发至对应消息推送服务节点上。

Push Service：消息推送服务，通过websocket将消息推送给用户。

集群推送的关键点在于，web端与服务端建立长连接之后，具体跟哪个推送节点保持长连接的，如果我们能够找到对应的连接节点，那么我们就可以将消息推送出去。下面讲解一下集群的大致流程：

1>. web端用户登录之后，带上token与后端推送服务（Push Service）保持长连接。

2>. 推送服务收到连接请求之后，携带token去鉴权服务（Auth Service）验证此token权限，并返回用户ID。

3>. 把返回的用户ID与长连接存入本地缓存，保持用户ID与长连接绑定关系。

4>. 再将用户ID与本推送节点IP存入redis，建立用户（即长连接）与节点绑定关系，并设置失效时间。

5>. 采集服务（Collect Service）收集业务消息，首先存入mongodb，然后将消息透传给分发服务（Dispatch Service）。

6>. 分发服务收到消息之后，根据消息体中的用户ID，从redis中获取对应的推送服务节点IP，然后转发给对应的推送节点。

7>. 推送服务节点收到消息之后，根据用户ID，从本地缓存中取出对应的长连接，将消息推送给客户端。

其他注意事项：

苹果的消息推送是通过请求域名：https://api.push.apple.com 实现的，该域名解析结果为美国，这引发了两个问题：

1、接口请求时间长,性能低，而且容易请求超时报错

2、高峰期推送请求错误率升高

总体思路：增加一个美国代理服务器，通过代理服务器请求苹果消息推送服务

1、原来流程

2、现在流程

3、具体方案实施选择

选择一：proxy服务器，部署一个正向代理服务，提供push消息的正向代理，消息通过代理服务器送达苹果服务端

选择二：proxy服务器，独立实现、部署一个 标准的apns服务，负责 ios消息推送。将需要走美国节点的请求转发到该proxy节点

具体情况、具体分析，应思考的点：

问题一、苹果官方提供的SDK中，不支持设置代理服务器。官方SDK不适合更改，对以后系统更新不利

问题二、只有苹果的push服务需要代理，其他例如华为、小米、vivo不应走海外代理

问题三、代理安全性

问题四、代理方案下，有重试逻辑。 如何准确定义和判断失败， 可能会引起消息重复推送

问题五、实现简单、有效，正向代理方式：只需实现一个实例化对象方法，其他利用原始sdk即可。独立apns服务方式：需要实现一个apns服务，国内、国外均需服务部署，需要增加独立的开发和运营成本，另外还得改造调用服务，实现请求调度，优点服务独立、单一，具备一个单独微服务条件

github.com/sideshow/apns2

方法一: 修改SDK文件

第一步：设置环境变量

第二步：修改apns2.NewClient方法

方法二: 从新定义一个NewClient方法

---