IM系统该如何选择消息推送平台

IM系统该如何选择消息推送平台

消息推送根据业务类型与产品形态分为IM（Instant Messaging即时通讯）与非IM两大类。
常见属于IM类，比如：微信、qq、陌陌、探探等社交app的聊天消息；
常见非IM类有：

1. 新闻资讯类，如今日头条、网易新闻、天天快报的新闻资讯推送等；
2. 运营营销类，如淘宝、天猫、京东平台的活动大促销等；
3. 个性推荐类，如淘宝、抖音的个性化推荐、猜你喜欢、你的好友正在看之类；
4. 系统通知类，如电商平台的到货合物流通知、支付宝生日祝福、设置提醒等与个人活动相关的行为相关的系统内部的推送通知。

非IM类型推送目的大多是以通知为主的单向操作，从业务角度看其复杂度要远低于IM类消息推送，IM类消息推送涉及人与人，人与群组，人与系统的沟通与反馈。

行业现状

大多数的公有云推送平台，都是以非IM类应用场景为主，为了兼容不同厂商的推送(例如苹果，华为，小米等)，在推送接口添加了大量的兼容性参数，导致开发者需要做大量的适配工作。
有的平台在推送基础上封装了IM的SDK，但业务单一固定，不满足实际项目需求，开发者无法使用。
这些平台虽然提供了免费版本，但要想优雅的使用，必须购买指定付费版本。
有的项目客户对信息安全敏感度较高，需要私有化部署，如果使用公有云方案，无法满足客户需求，购买其私有云版本价格有可能比项目预算还高，这种私有化版本本身是公有云架构，在后续的部署，运维上还需付出大量时间和精力。

项目实践

我们在早期的项目中掺杂了大量的消息通讯类代码，集成所有厂商推送SDK，这些代码入侵到各个业务模块，尤其是IM类消息业务，例如：我们系统是即有电脑端，也有手机端，当用户A给用户B发送一条消息，这个最基本的场景，需要经历如下操作，

1. 系统推送用户A的消息给用户B的PC端
2. 系统判断用户B的手机厂商，构建此厂商推送消息对象，调用厂商推送接口，推送消息给用户B的手机端。如果用户B的PC端在线，厂商推送采用静默方式(避免手机和PC同时弹出消息)。
3. 系统需要把这条消息同步推送给用户A的其他平台设备，例如用户A用手机发送的消息，需要把消息同步给A的PC端，采用静默推送的方式，自己发送的消息不需要弹通知
4. 如果用户B点击手机通知栏查看消息，需要处理通知栏点击操作跳转到指定页面，不同的厂商通知栏点击操作各有不同
5. 用户B查看这条消息，系统推送已读状态给用户A的手机端和PC端

就这样的一个简单的人与人发送消息就如此复杂，试想人与群的消息呢，如果是万人大群呢？如果除了手机端PC端还有网页端还有其他平台呢？

UPush

UPush推送系统是我们在实际项目中总结出来的”方法论“，达到了消息推送和业务的完美平衡。

• 首先它适配了所有主流操作系统Android、IOS、Windows、MacOS、Linux，主流跨平台开发框架Uniapp、Electron、Qt
• 集成所有厂商推送(苹果、华为、小米、OPPO、VIVO、魅族、谷歌FCM)，注意不是其他友商简单的集成。发送端，不需要开发者构建厂商消息对象，接收端，统一消息接收处理，统一通知点击回调处理，回调消息对象统一，接收消息结构和发送消息结构统一，参照如下：

1. 发送端(服务端)

// 系统会推送给userId所有平台设备，如果有手机端会自动构建厂商消息推送
UPushMsgTask userPush(UMessage message, String userId)

2. 接收端(Android)

 /**
  * 接收消息，无需要区分是穿透消息还是厂商消息，统一消息结构
  * @param msg            消息
  * @param pushTime       推送时间
  * @param isOfflineMsg   是否为离线消息
  */
public abstract void onPush(UMessage msg, long pushTime, boolean isOfflineMsg);

/**
  * 通知被点击，不需要区分是本地通知栏消息还是厂商通知栏消息，统一入口，统一消息结构
  * @param msg 通知栏被点击的消息
  */
public abstract void onNotificationClicked(UMessage msg);

• 私有化协议，每个数据包动态加密，支持TCP、UDP、Websocket协议，大部分友商使用开源通讯协议，如果协议被曝漏洞，会造成安全隐患，还需要升级协议版本，增加维护成本。

• UniPush深度整合，UniPush是Uniapp中默认的推送模块，可在UniPush后台直接配置厂商推送，即可应用到UPush中，无需额外的集成配置。

• 群组订阅/发布，支持万人大群，群组可以是IM中的群组，也可以是抽象概念的群组/虚拟群组，比如对审批流程ID进行订阅，可对流程里所有用户推送审批状态，审批完结删除群组。

// groupId可以是审批流程ID，无需对流程里的用户分别推送
UPushMsgTask groupPush(UMessage message, String groupId)

• 管理后台项目开源，开发者可在此基础二次开发，作为IM后台管理系统，添加业务维护画面，例如组织架构等
  
  

官网文档

具体可以参照官方文档
文档 点击进入