移动互联网蓬勃发展的今天，大部分手机 APP 都提供了消息推送功能，如新闻客户端的热点新闻推荐，IM 工具的聊天消息提醒，电商产品促销信息，企业应用的通知和审批流程等等。推送对于提高产品活跃度、提高功能模块使用率、提升用户粘性、提升用户留存率起到了重要作用，作为 APP 运营中一个关键的免费渠道，对消息推送的合理运用能有效促进目标的实现。 推送最早诞生于 Email 中，用于提醒新的消息，而移动互联网时代则更多的运用在了移动客户端程序。要获取服务器的数据，通常有两种方式：第一种是客户端 PULL（拉）方式，即每隔一段时间去服务器获取是否有数据；第二种是服务端 PUSH（推）方式，服务器在有数据的时候主动发给客户端。 很显然，PULL 方案优点是简单但是实时性较差，我们也可以通过提高查询频率来提高实时性，但这又会造电量、流量的消耗过高，反之 PUSH 方案基于 TCP 长连接方式实现，消息实时性好，但是由于要保持 APP 客户端和服务端的长连接心跳，也会带来额外的电量和流量消耗。因此在整体架构设计中需要折中平衡，目前主流的推送实现方式都是基于 PUSH 的方案。 目前移动推送技术实现方式主要有以下三种： 客户端和服务器定期的建立连接，通过消息队列等方式来查询是否有新的消息，需要控制连接和查询的频率，频率不能过慢或过快，过慢会导致部分消息更新不及时，过快会消耗更多的资源（流量、电量等），对用户体验有较大伤害。 通过短信发送推送消息，并在客户端植入短信拦截模块（主要针对 Android 平台），可以实现对短信进行拦截并提取其中的内容转发给 App 应用处理，这个方案借助于运营商的短消息，能够保证最好的实时性和到达率，但此方案对于成本要求较高，开发者需要为每一条 SMS 支付费用。 移动 Push 推送基于 TCP 长连接实现， 客户端主动和服务器建立 TCP 长连接之后, 客户端定期向服务器发送心跳包用于保持连接, 有消息的时候, 服务器直接通过这个已经建立好的 TCP 连接通知客户端。尽管长连接也会造成一定的开销，对于轮询和 SMS 方案的硬伤来说，目前已经是最优的方式，而且通过良好的设计，可以将损耗降至最低。不过，随着客户端数量和消息并发量的上升，对于消息服务器的性能和稳定性要求提出了非常大的考验。因此，就难度而言，此方式代价最高。 基于 TCP 长连接的方式是主流的推送方式，基于该推送方式逐步发展出系统级、应用级一系列的推送解决方案。 iOS 在系统层面与苹果 APNs（Apple Push Notification service）服务器建立连接，应用通过观察者模式向 ioS 系统注册关注的消息，系统收到 APNs Server 消息后转发到相应的应用程序，整个过程很清晰，并且所有 APP 都共用同一个系统级的连接，减少了系统开销，虽然 APNs 能无障碍的访问，但实际使用过程中，发现延时和丢消息的情况偶有发生。 Android 的 C2DM（Android Cloud to Device Messaging）采取与 iOS 类似的机制，都是由系统层面来支持消息推送，但是由于 Google 的服务在国内不能稳定的访问，此方案对于中国用户来说基本是无法使用的。 除了 Google 官方提供的方案，中国众多的手机厂商在其定制的系统中也内置了推送功能，如小米、华为等。 鉴于 Android 平台 C2DM 推送的不可用性，国内涌现出大量的第三方推送服务提供商，采用第三方推送服务的系统流程如下图： 图 1：消息推送流程 目前应用最为广泛的第三方推送服务提供商包括个推、极光、友盟、小米、华为、BAT 等，绝大部分 APP 都会优先考虑采用第三方推送服务。 第三方服务在开发成本和消息到达率上表现都不错，但所有信息会经过第三方服务器，对于信息敏感类 APP 而言，有必要考虑自建一套消息推送服务，能最大化保证安全，但对于自建推送服务，如果从零开始来做需要解决几个难点： 第一，移动推送服务器对 App 客户端海量长连接的维护管理。第二，App 客户端如何保证 Push Service 常驻，对于 Android 我们可以通过发现 push service 不存在可以定时拉起的方式。第三，通信协议的制定，我们可以采用开源的 XMPP 方式实现，也可以自定义协议，不管哪种方式我们都要保证消息传送的到达率的准确性。第四，在移动互联网网络环境下，经常出现弱网环境，特别是 2G、3G 等网络不稳定的情况下，如果保证消息在弱网环境下不重、不丢也是一个挑战。 无论是第三方推送服务，还是自建推送服务，在实际的使用过程中，发现都存在以下问题：
为了解决以上问题，我们考虑基于第三方消息推送服务构建一套移动消息推送中间件平台，该消息平台采用了低耦合的分层架构设计（如图 2 所示），分为三层：接入层、传输层和应用层。其中接入层是业务方调用的入口，我们采用异步消息队列的方式提供了较高的业务系统发送消息的速度，并且具备了消息缓冲功能，即使高峰期的海量消息推送对整个平台冲击较少，保护了推送系统； 传输层会从接入层接收消息并进行解析，对推送消息进行合法性检查校验，如果消息不合法直接丢弃，同时将合法的消息进行协议转换并发送到对应的第三方推送平台；应用层主要是提供统一的 SDK 供业务使用，封装适配第三方推送平台的 SDK 接口到统一的接口 SDK 中，这样业务 APP 使用方只关注统一封装的 SDK 即可实现业务消息的操作，而不需要考虑各种滤重、校验等通用操作。主要功能包括：
整个系统设计由三部分组成：移动推送平台、客户端 SDK、应用管理界面（第三方推送服务和自建推送服务统称为推送服务）。 图 2：系统架构 移动推送平台提供统一的服务，对于应用层屏蔽推送服务接口，且实现推送服务可动态轮替。推送平台将接收到的消息持久化到数据库中，方便进行消息推送失败后的重发，以及后续数据的统计分析。 客户端 SDK 对 App 提供统一的使用接口，屏蔽推送服务 SDK 使用细节，且实现多种推送 SDK 可替换，隐藏 SDK 复杂的接入过程，方便使用。 应用管理系统面向 App 开发人员，实现应用申请，推送服务配置，消息查询与管理，数据统计与分析。 消息推送涉及的主要模块是消息推送平台和客户端 SDK，主要流程如下图所示： 图 3：消息推送中间件核心流程 正常情况下，消息推送过程如下：
对于推送过程中可能出现的异常情况，总结如下：
根据消息发送流程，可以得到消息在生命周期中状态的变迁如下图： 图 4：消息状态机 消息重发主要存在三种场景：系统启动时，查询所有的发送失败或发送成功未收到客户端回执的消息，加载到推送队列重发；系统运行时，后台线程定时查询需要重发的消息，进入推送队列；手动触发时，直接将消息加入推送队列。 由于消息推送中间件服务通常要求高可用，为分布式部署，消息重发必须保证在单一节点执行，且保证只发送一次。需采用分布式锁的方式，保证重发只发一次，主流实现方式有三种：
对于每种锁机制的特点本文不详细介绍，根据实际应用需要任选一种即可。 由于 iOS 平台和 Android 平台的差异，消息重发需要考虑平台差异性。 使用第三方推送时，如果 iOS 应用在前台运行，那么将通过第三方推送维护的长连接，以透传的方式直接下发到 APP，称为应用内消息；而当 APP 在后台时，则第三方推送将消息推送到 APNs，由 APNs 推送到 APP，称为 APNs 通知。当通过 APNs 推送时，手机在收到消息后将在顶部的通知栏出现相关推送内容，这一行为是系统级别的，APP 无法控制。可能会出现这一问题：当 APP 在后台或者手机锁屏的情况下，如果服务端重发了消息，手机的通知栏将出现多条通知。 因此，考虑当 APP 在后台时，针对 iOS 平台的消息不再进行重发；只有当 APP 进入前台，才重新进行重发。APP 的活动状态通过第三方推送服务的 api 可以获取到。 Android 平台不存在该问题。 由于消息重发可能会造成客户端收到重复消息，需要在客户端进行消息去重。服务端为每一条消息分配了一个唯一 id，重发时唯一 id 不变。客户端需要保存收到的每一条消息，在接收到新消息时首先根据唯一 id 判断是否已经收到了这条消息，如收到则不响应。客户端保存消息可以采用 sqlite 数据库。 客户端 SDK 与服务端的通信过程使用 appKey 和 appSecret 进行权限控制。appKey 是服务端为每个 app 分配的唯一标识，appSecret 是服务端为每个 app 分配的秘钥。 客户端 SDK 在请求服务端 HTTP 接口时，会将 appKey appSecret 做一次签名，将签名值作为签名 sign 参数，与其他请求参数（业务参数 appKey）一同传到服务端；服务端拿到请求参数后，也先用 appKey appSecret 做一次签名，比较和客户端传来的 sign 参数是否一致，从而完成权限验证过程。为了能够实现灵活控制推送与否，可实现黑名单管理的功能。处于黑名单内的 app 客户端不再进行消息的推送。黑名单控制的粒度到账号级别，也可以根据实际业务需要进行分组管理。 在某些业务场景中，需要对消息进行过滤，分析，做出相应的处理甚至预警，借助于消息推送平台，都能方便的实现。 客户端 SDK 是基于推送服务的 SDK 封装实现，对外提供统一的使用接口。SDK 的使用者不再关注具体使用了哪些第三方推送、推送服务的接入细节。实现与推送服务的充分解耦，降低开发和使用成本。 由于 iOS 和 Android 平台的差异性，在客户端 SDK 的封装上存在差异，下面分别介绍两个平台的 SDK 封装方式。 SDK 提供启动和停止的方法；同时定义一个 protocol，包含 SDK 提供的接口。SDK 在收到消息或出现错误时将会回调 protocol 中的接口。 由于推送的接入涉及 AppDelegate 的生命周期方法，为避免 SDK 使用者关注这些繁琐的细节，SDK 使用 Aspects 的方式，将推送时相应的处理函数 hook 到 AppDelegate 的生命周期方法上。 在 Android 中使用 Receiver 组件来接收收到的消息。一个基本的配置如下所示： 流程如下：当推送服务的 SDK 在接收到推送过来的消息后，将发送广播，这个广播的用 intent-filter 标识，当应用中的 Receiver 代码注册了这个 intent-filter，就可以接收到广播，并进行后续处理。 图 5：后台管理示意图 消息后台管理系统提供应用申请、应用服务配置、推送服务配置、消息查询与管理等功能。 1、应用申请 填写应用名、应用描述等信息后，生成该应用唯一的 appKey 和 appSecret。 2、应用服务配置 为应用选择要使用的移动端通用服务，可供选择的有推送、反馈、版本发布。 3、推送服务配置 为应用配置推送服务，可供选择个推、极光等；以及推送时使用的优先级顺序。 4、消息查询与管理 查看应用所发出的消息，包括消息所属应用、所属账号、消息的状态、最终发送成功的第三方渠道、消息的来源、发送者 ip 等信息 5、数据统计 通过分析 message 表中的各消息的状态，可统计各应用消息的发送成功率和到达率，以及哪个第三方推送的更优，方便选择。同时，提供每日、每周、每月推送消息量的统计，并提供统计图表。 消息推送平台通过无状态设计、统一存储、冗余部署方式保证了高可用，对应的状态数据统一存储到 MySQL、Redis 中保证各个无状态实例共享数据。 对于消息的接收处理我们通过纯异步、动态多线程的方式提供了推送平台的高性能。同时对于异步接收的消息我们通过 log append 的方式保证消息先落地然后再进行处理，进一步确保系统在异常过程中我们可以随时恢复消息，保证不丢失。 通过质量保障、全方位多维度监控体系（基础监控、错误日志监控、发送数据波动监控、进程监控等监控指标）保障系统在出现问题时实现秒级报警、及时处理保证了消息推送平台的高稳定性。 本文介绍了一种基于第三方或自建推送服务、但又不强依赖特定推送服务的通用移动消息推送中间件平台，可以实现安全、稳定、可靠的消息推送功能，并提供完善的数据统计，在实际应用中，可以结合邮件、短信、网站消息、用户留言等打造成更加通用的企业消息平台。 「作者写书的口吻完全是教条主义，感觉高高在上。」 「作者不让找 KOL 写推荐语？那这书还怎么卖？」 「作者个人履历挺丰富的啊，为什么不同意加作者介绍？十年了，我第一次遇到这情况」 「你确定这作者在 InfoQ 上受欢迎？」 这是一位出版社金牌编辑的原话，他所说的就是 InfoQ 出品的第一本书——《聊聊架构》。社区中并不缺少架构图，而是缺少架构相关的基础知识。我们花了近两年的时间，打磨这本可能注定无法畅销的技术书。不为别的，只希望为这个行业贡献一点点力量，能够引起一些思考也是好的，如果能够帮助一些软件工程师们获得更好的工作效率和工作品质，就超出期望值了。 点击下方图片即可阅读
今日头条 Go 建千亿级微服务的实践
|
|
|
来自： tiger爸爸f54s6 > 《文件夹1》
