从 到 搭建技术中台之推送平台实践：高吞吐、低延迟、多业务隔离的设计与实现.docxVIP

从 0 到 1 搭建技术大陆与台湾之推送平台实践：高吞吐、低延迟、多业务隔离的设计与实现 APP推送是触达用户的一个格外重要的手段，对于提高产品活跃度、提高功能使用体验、提升用户粘性、提升用户留存率都会起到重要作用。伴鱼旗下多款 APP，支持丰富的用户交互体验，对推送的依靠上表现的尤为突出。随着公司业务的快速进展，伴鱼旗下的 APP 也在日积月累，对推送场景的需求也开头多样化，推送量的需求更是飞速增长，这些都对伴鱼推送平台提出了更高的要求。本文就伴鱼推送平台在实践中遇到问题以及相应的技术方案进行具体说明，以期给读者带来一些思考以及处理类似问题的思路。 推送平台通常会遇到的问题，在伴鱼这里也都同样遇到，最具有代表的问题： 高吞吐。推送巨大的流量如何支撑，尤其在运营集中做活动时候表现的尤为突出，动辄是千万量级 亦或是亿级别的量级，怎样能够很好的支撑？ 低延迟。推送任务要能以最快的速度让用户收到。运营集中做活动的时间很短，要在这有限的时间内，尽可能快的触达用户。 同时伴鱼推送平台也遇到了我们业务特有的推送问题： 多客户端推送。伴鱼旗下的诸多 APP，在业务上有着强的关联关系，业务上的同一功能可能要给多个APP 下发推送，比如：家长都很关怀同学的学习情况，同学若在同学端获得一个嘉奖，需要推送同学端，也需要准时通知家长端 多种推送场景。伴鱼诸多业务中比较突出的有三种场景的推送，一种是业务实时推送，在线课堂的交互实时推送就是比较典型的示例，这类推送用户多为在线用户，推送时效性要求很高，否则会影响用户的上课体验；一种是类似站内信的系统通知，这类推送用户多为离线用户，推送消息牢靠性很高；一种是营销推送，这类推送用户多为离线用户，牢靠性要求没有前两种高。第一种场景的流量曲线跟业务高峰期的曲线相同，每天量相对稳定，后两种场景流量是典型的脉冲式流量，有推送时流量会霎时陡增。 推送相互隔离。推送平台是面对伴鱼全部业务线的，不能由于某个业务线的推送量过大，影响到别的业务的使用，如何能够按业务隔离，按推送类型隔离？ 带着这些问题我们技术大陆与台湾团队协力打造了一个高吞吐、低延迟、多业务隔离的的伴鱼推送平台。 推送流程 这里简述下推送的一般处理流程。推送常用的模式有推、拉两种模式，拉的模式消息实时性较差，对客户端的流量、电量消耗都比较大，因而目前很少接受这种模式。下面以推的模式为例引见推送的流程。各推送通道的流程大同小异，这里不具体开放。 推送一般涉及到三个阶段流程：设备绑定；消息推送；消息回执 设备绑定 推送通道一般会为设备安排客户端独一标识（token），用来做为长连接通道的标识，依据这个标识将消息送达到对应的客户端上。推送平台面对业务，是以系统的用户id作为推送标识。推送服务这时候就需要将用户id与客户端标识进行映射。客户端打开 APP 会跟推送通道建立长连接，此时猎取到token。然后将当前用户id和token一起发送给推送服务，推送服务将信息存储完成绑定操作。 消息推送 当推送服务接收到推送恳求时，一般推送恳求是给某个用户id发送消息。推送服务依据用户id猎取到之前绑定的设备标识，针对不同的通道构造不同的消息格式，调用推送通道的接口执行发送。推送通道接收到恳求后，依据设备标识找到对应的长连接，将消息通过长连接通道发送到客户端。客户端进行消息的弹窗呈现等规律处理。 消息回执 客户端在收到消息或者点击的时候，可以调用配置的回执地址（有些推送通道支持，有些是自动恳求推送通道轮训拉取），将该条消息的形态上报到推送服务。 架构设计 伴鱼推送平台全体接受分层的架构设计，如图： 分层引见 全体架构从上而下包括：业务层、网关层、推送服务层、长连接服务层以及依靠的基础资源层 业务层 业务会借助推送的通道力量实现简单的业务功能，其中典型的业务场景就是im。用户在发出im消息之后，借助推送平台进行消息信令的下行投递。im的实现是考虑了消息牢靠性，客户端在收到推送的消息信令或客户端与后端连接服务建立长连接时，会接受拉的方式将消息猎取到。业务上会借助im的这一特点使用特殊的系统号来发送im消息，从而达到牢靠性推送的业务场景。前文提到的系统消息就是借助这一方案实现的。在推送牢靠性相对较低的场景下业务也会使用推送的接口直接下发消息。为了便利运营人员进行营销推送和系统通知，我们开发了运营推送平台。该平台会依据不同的推送场景需求(系统通知/营销消息）选择通过im或者直接调用推送下发。业务层的全部推送流量都会统一接管到推送网关层，由网关层进行下行处理。 网关层 推送网关作为一个网关层处理路由转发、流量把握等基本的网关工作。路由转发针对不同 APP、不同消息类型结合相应下发策略配置，将消息推送到相应的 APP 上。下发规章在网关把握后，业务上的只需要关怀推送消息的业务场景，不用考虑消