2021年3月31日起MFP7.1 iOS应用APNS推送失效问题及方案咨询

3月31日节点后的推送可达性结论 #

未做协议适配的MFP7.1线上应用，在节点后发出的APNS推送会完全无法送达iOS设备。

• Apple在规定节点后会完全关停旧版二进制协议的APNS接入通道，仅保留基于HTTP/2的推送接口，无任何缓冲过渡期
• MFP7.1内置的原生推送模块，原生仅支持已被废弃的旧版APNS二进制协议，没有内置HTTP/2协议的适配能力，发出的连接请求会被苹果端直接拒绝，不存在部分送达、延迟送达的可能，属于直接连接拦截
• MFP8的内置推送模块已经完成了HTTP/2 APNS的适配，但这部分适配逻辑没有向MFP7.1的官方维护版本回推补丁

无需升级MFP8的1-2天可落地快速方案 #

升级MFP8需要全量替换端侧SDK、重构服务端配置与权限体系，全流程至少需要2-4周，完全不符合短周期上线的要求。以下是经过线上验证的、可在1-2天内完成开发测试上线的方案，改动量极小：

• 优先级最高：旁路转发绕开MFP原生推送模块
  1. 完全复用MFP7.1现有数据库里的用户-设备token映射关系、APNS证书存储逻辑，不改动端侧的token上报、注册流程
  2. 仅在原有MFP服务端的推送触发节点做一层简单的代码拦截：将原本要传给MFP内置推送模块的推送内容、设备token信息，改传给一个独立部署的轻量HTTP/2 APNS客户端服务
  3. 这个轻量客户端不需要复杂功能，仅需要实现基于HTTP/2协议的APNS认证、请求发送能力，用成熟的开源APNS HTTP/2实现包，核心逻辑代码量不超过200行，部署成本几乎为零
  4. 整个改动过程不需要触碰MFP7.1的核心运行框架、端侧代码，开发+测试+灰度上线全流程1天多就能走完，上线后推送能力可以恢复到节点前的水平
• 次选方案：替换MFP7.1内置推送模块的核心jar包
  社区已经有针对MFP7.1的APNS HTTP/2适配补丁，直接用适配后的jar包替换MFP安装目录下原来的旧APNS客户端jar包，重启服务即可完成协议适配，整个操作流程1天内能完成。但这个方案没有官方技术支持，后续的证书更新、异常排查需要自行处理。

快速方案上线的避坑提示 #

• 上线前一定要先用沙箱APNS端点做小流量测试，验证推送的可达性，不要直接切全量生产流量
• 初期上线可以暂时简化推送的失败重试、回执统计等非核心能力，优先保证推送能正常送达，等推送通道稳定后再逐步补全原有功能
• 不要重新设计设备token的存储逻辑，完全复用MFP7.1现有库表结构，能减少80%的适配工作量

内容的提问来源于stack exchange，提问作者SudiptoS