系统架构 #
- Master负责请求处理， 可以通过Nginx，LVS，DNS进行负载均衡，也可以使用F5方式。Master通过智能路由寻址可以直接定位推送目标所在服务器，无需查库，无需请求，无需冗余发包。
- PushServer处理推送核心逻辑。
- Connector负责维护客户端的连接。
- Vendor Server负责厂商推送
客户端注册时序1 #
方式1，客户端SDK请求Master服务，根据分配规则(默认是connector负载最小)，分配一个connector服务给客户端，客户端建立连接后，接收到pushToken。
客户端注册时序2 #
方式2，客户端请求业务服务器，业务服务器请求master，master分配一个connector并返回其地址信息，客户端使用connector地址注册。这种方式优势是无需把master服务地址暴漏给客户端，master只接收来自业务服务器的api调用。
推送时序 - PushToken方式 #
客户端注册到UPush，把返回的pushToken提交到业务服务器，业务服务器存储pushToken，推送时取出pushToken进行消息推送。优点是可以把消息推送到指定到设备，缺点需要业务服务器维护pushToken和业务用户的关系。除非需要精细到对指定设备进行推送(例如扫码登录等)否则不推荐这种方式。
推送时序 - UserId方式(推荐) #
客户端注册到UPush，返回的pushToken可以不提交业务服务器，用户登录到业务系统，请求UPush绑定用户ID，返回新的pushToken也是可以不提交到业务服务器的。业务服务器需要推送的时候，直接对用户ID推送消息即可，如果用户ID绑定了多个设备，也会对多个设备同时进行推送。99.9%的系统在使用时都需要用户登录，所以更推荐这种方式，业务服务器不需要关注设备的pushToken，根据业务用户ID直接推送。
