亿级推送，得物是怎么架构的？

说在前面

在40岁老架构师 尼恩的读者交流群(50+)中，很多小伙伴拿到一线互联网企业如阿里、网易、有赞、希音、百度、滴滴的面试资格。

最近，尼恩指导一个小伙伴简历，需要织入亮点项目、黄金项目。

前段时间，指导小伙写了一个《高并发消息推送项目》，帮这个小伙拿到 字节/汽车之家 等优质机会，并且帮他 喜提一个 “中间件王子offer” , 尼恩还对此案例进行了全面复盘：

被裁不慌，9年小伙1个月喜提年薪60W offer，做中间件架构，爽歪了

所以说，《高并发消息推送项目》 是一个牛逼的项目。

为了帮助大家拿到更多面试机会，拿到更多大厂offer， 在此文之前，尼恩还专门有文章对 消息推送的架构进行介绍：

消息推送 架构设计

架构总是无止境的。

前段时间尼恩看到了一个非常优质的案例 《从0到1，亿级消息推送的稳定性保障》, 这个案例，是一个非常优质的案例， 也是是一个亿级推送的生产案例、工业案例。

尼恩对这个案例进行了深入研读/二次分析， 吸纳到咱们的架构体系里面来， 为大家的所用，用于尼恩指导大家做简历改造。

也一并把这个案例，收入咱们的 《尼恩Java面试宝典》V169版本《架构专题》，供后面的小伙伴参考，提升大家的 3高 架构、设计、开发水平。

最新《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》的PDF，请到文末公号【技术自由圈】获取

此文的原创是得物技术的架构师暖树，并不是尼恩。 但是原文不是太好懂 ，尼恩仅仅以学习笔记的形式， 对原文做二次 学习， 把原因改造得尽量浅显易懂。

由于无法联系到作者本人，尼恩的学习和改造也没有获得作者的同意。

特别说明，如果得物技术或者作者暖树本人不同意 尼恩的学习改造， 可以发消息给尼恩， 立马就从尼恩的自媒体扯下来。

推送的巨大价值

从用户的生命周期来看，消息推送对于提高 App 活跃度、提升用户粘性和用户留存率都起到了重要作用。

• 提升新用户次日留存，低成本促活，对平台的短期留存率影响显著。

• 提升老用户活跃度，push 可以通过外部提醒起到拉活的作用。

  很多内容平台类 App 的用户 push 首次启动占比可达 10%以上，因此 push 对 DAU 的增量贡献不容小觑。

• 流失用户召回，当用户流失后，若 push 权限未关闭，通过消息推送的方式，有可能重新唤醒用户。

消息推送每天都在我们的手机上发生，如图所示，除非你的手机没有安装App或关闭了通知栏权限。

通用推送服务功能分析：

• 发送通知

• 对通知进行优先级排序

• 根据客户的保存偏好发送通知

• 支持单个/简单的通知消息和批量通知消息

• 各种通知的分析用例

• 通知消息的报告

一般来说，推送的渠道很多，包括的电子邮件、短信、聊天、钉钉、企业微信和其他公共社交应用：

• 聊天 - 微信Wechat/QQ

• 站内推送通知（移动设备和Web浏览器）

• 站外推送通知（移动设备，APP没有开启）

• 短信（如登录密码、营销活动）

• 电子邮件

• 钉钉

• 企业微信

通用推送系统设计架构：

注意：请点击图像以查看清晰的视图！

推送非功能性需求（NFR）：

• 高性能： qps > 1W

• 高可用性（HA）： 99.99%

• 低延迟: TP99 在10ms以下

• 高扩展：可扩展/可插拔的设计，以便添加更多适配器和提供商，与所有通知模块的API集成以及与客户端和服务提供商/供应商的外部集成

• 跨平台：支持Android/iOS移动设备和桌面/笔记本电脑的Web浏览器

• 自伸缩：可在本地（VMware Tanzu）和 AWS、GCP 或 Azure 等公共云服务上扩展负载

推送的SLA 服务等级指标

SLA（Service-Level Agreement），也就是服务等级协议，指的是系统服务提供者（Provider）对客户（Customer）的一个服务承诺。

SLA（Service-Level Agreement）是衡量一个大型分布式系统是否“健康”的常见方法。在开发设计系统服务的时候，无论面对的客户是公司外部的个人、商业用户，还是公司内的不同业务部门，我们都应该对自己所设计的系统服务有一个定义好的 SLA。

因为 SLA 是一种服务承诺，所以指标可以多种多样。下面是四个常见的SLA指标 ，可用性、准确性、系统容量和延迟。

1. 可用性（Availability）

可用性指的是系统服务能正常运行所占的比例。

例如我们说要搭建一个”100%“的系统服务，也就意味我们要需要保证在任何时候这个系统都能运行，都说可用的，但实际这在现实中，是非常困难的，成本也是非常的高。

对于大部分的系统而言，能保证4个9的可用性（99.99%的可用性）就可以说这个系统是高可用的。

99.99%的可用性是指一天（60×60×24秒），只有8.64秒（60×60×24×0.0001秒）为不可用，一年就是大概有52.56分钟（8.64*365/60分钟）不可用。

99.99% 一天只有8秒左右的不可能用时间，这已经可用满足大部分系统的要求了。

2. 准确性（Accuracy）

准确性指的是我们所设计的系统服务中，是否允许某些数据是不准确或丢失，如果允许那么允许的百分比是多少？

不同系统对准确率都会有一个衡量的指标，大部分系统可以 用错误率来衡量。

错误率怎么计算呢？可以用导致系统内部错误有效请求数除以总的有效请求数而求得。

错误率=导致系统内部错误有效请求数/总的有效请求数

系统一分钟内收到的总的有效请求为100个，其中有10个导致系统内部错误，则我们可以认为错误率为10%

下面我们看下大公司中对系统错误率的对比

Google Cloud Platform 的SLA中，有着这样的定义：

每个月的错误率超过5%的时间要少于0.1%，以每分钟为单位来计算。

亚马逊AWS云计算平台对SLA的准确性定义为：

以每5分钟为单位，错误率不会超过0.1%。

那我们可以通过哪些途径来获取系统的准确性呢？大部分情况我们可以通过软件测试或系统日志来判断。

3. 系统容量（Capacity）

在数据处理中，系统容量通常指的是系统能够支持的预期负载量是多少，一般会以每秒请求数为单位来表示。

我们常常听见某个系统的架构可以处理的QPS（Queries Per Second 系统每秒查询数）是多少或者RPS（Requests Per Second系统每秒请求数）是多少。

4. 延迟（Latency）

延迟指的是系统在收到用户的请求到响应这个请求的时间间隔。

在定义延迟的SLA时，我们常常看到系统的SLA会有p95或者是p99这样的延迟声明。

这里的p指的是percentile（也就是百分比的意思），假设一个p95的系统延迟是1秒，那就表示100个请求里面有95个请求的响应时间是少于1秒的，而剩下的5个大于1秒。

对于消息推送而言，我们主要关注的是消息能否及时可靠的送达给用户，也就是 SLA 中关注的延迟（Latency）、准确性（Accuracy）和可用性（Availability）的问题。

得物推送背景和痛点

消息中心为得物 App 提供了强大、高效的用户触达渠道，推送对于得物 DAU 的贡献有可观的占比，每一条推送消息，这也就意味着都是一次与用户沟通的宝贵机会。

得物推送背景和痛点：

• 延迟（Latency）

与用户主动点击的WEB场景不同，在推送场景，用户是被动参与的。

业务方对于推送的消息什么时候到达没有明确的心理预期。

在这里，可用性的度量是模糊的。

如何提升推送的低延迟，首先需要我们针对消息推送的链路单元耗时进行监控，然后对各个链路单元的耗时做针对性的优化，不断降低延迟。

• 可用性（Availability）

消息推送的稳定性依赖于第三方的推送通道，而三方通道对于我们来讲就是个黑盒子。

如何提升推送的可用性（Availability），关键是要做到三方通道异常及时发现，并且及时止损，也是需要考虑的问题。

从以上两个维度来说，都需要对系统进行全面的监控。

得物推送的深度监控实践

目前消息中心针对实效性和稳定性的开发已经完成并初显成效，下面主要针对时效性和稳定性的监控做一些介绍。

监控系统架构图

监控分为三个维度：

• 第一维度：全链路监控

• 第二维度：厂商监控

厂商的监控代码要从主流程逻辑中解耦，通过旁路流程进行异步的监控。

每天有数亿的消息推送，在这种大规模推送背景下，异步的监控，就不会影响主流程的处理性能。

• 第三维度：业务方监控

第一维度：全链路监控

1. 链路的拆分

首先，需要对全链路进行细粒度的拆分。 在拆分之前咱们先从宏观维度，看看 得物推送后台的 消息流转流程，宏观上包括 下面的四个阶段：

• 业务发消息
• 推送预处理编排
• 目标通道接入
• 目标通道完成消息推送

具体如下图：

如何做到全链路时效性的无死角监控？

首先，对消息推送的整个流程进行深入解耦，解耦出若干个独立的、可监控单元链路单元。

整个推送流程，主要会经历：

• 推送鉴权

• 用户查询

• 防疲劳过滤

• 防重复过滤等

这些业务单元，每个单元的逻辑的处理是相互独立且无依赖的，可以按照单元进行拆分，对每一个单元进行监控。

这样就可以做到拆分无遗漏，监控无死角，拆分后的具体链路单元如下：

2. 链路单元耗时的计算

具体的链路单元耗时逻辑的计算如下图：

每一个链路单元，都设计多个 核心时间节点，比如 操作开始时间，操作完成时间。

3. 链路单元指标的制定

既然需要监控的链路单元已经拆分明确了，那针对这些链路单元我们监控哪些指标才是有意义的呢。

目前消息推送高峰耗时较长，业务域对于消息的到达时间也没有心理预期，所以涉及另个核心指标：

• 链路单元的推送耗时

• 链路单元的推送量/阻塞量

链路单元耗时的计算公式：

  这一个操作完成时间  -   上一个操作完成的时间 ，

例如

防疲劳耗时=T7(antiFatigueConsumeTime)-T6(checkrepeatConsumeTime)

链路单元阻塞量的计算：

记录链路单元消息推送的瞬时阻塞量，

例如防疲劳链路单元阻塞量 =

 防疲劳的总量-防疲劳已经处理的量

链路单元的阻塞量，是度量是否有积压的核心指标，如果存在积压，就需要扩容。

当然，在大促期间，消息的推送量也会达到一个高峰，往往都存在积压问题，需要进行提前扩容。

考虑到消息推送是有优先级的并且区分单推和批量推，所以我们要针对不同的优先级和推送方式设置不同的标准，消息推送耗时的具体标准如下。

4. 全链路技术方案的实现

首先，要考虑高并发、高吞吐场景。

消息中心每天推送大量消息给得物用户，SLA 全链路监控，一定不嵌入主流程， 任何一个操作嵌入主流程中都可能导致消息推送的延迟。

这也就要求监控和主流程进行隔离，主流程的归主流程，SLA 的归 SLA。

SLA 监控代码从主流程逻辑中剥离出来，彻底避免 SLA 代码对主流程代码的污染。

SLA 逻辑技术方案的实现的要求：

• 独立于推送业务的主流程进行异步计算，防止 SLA 监控拖垮整个主流程

• 使用非入侵的方式，我们使用的是 Spring AOP注解的方式

SLA 逻辑技术方案的 技术方案：Spring AOP+Spring Event。

主要链路单元包括鉴权、风控、用户查询、防疲劳、防重复、厂商调用，通过链路单元拆分，一单出现指标异常，可以很快定位到异常发生的具体位置。

5. 全链路监控结果

时效性链路单元监控：

时效性链路单元告警：

消息推送实效性监控做完之后，实现了 指标化和预警化：

• 指标化：关键链路单元耗时的指标化，

• 预警化：对服务链路单元耗时异常可以及时感知，同时也完成了预警的对接

第二维度： 厂商推送监控

1. 监控指标制定

对 厂商推送监控， 主要涉及到三个核心指标：

• 推送成功率
• 回执成功率
• 点击率

如果出现推送成功率跌零、回执成功率跌零、点击率的跌零， 就需要进行技术的预警，这种情况下整个推送通道都挂掉了，我们要及时通知厂商进行修复，

另外，如果没有跌零，是不是也要监控呢？ 是的。

一般来说，厂商的推送成功率、回执成功率、点击率都稳定在一定的的区间。如果厂商推送的指标数据偏离这个区间则说明推送有异常，也要进行告警和排查。

厂商监控监控告警的维度大致如下：

对这些指标，可以通过 Prometheus+grafana指标平台，进行时序展示：

2. 厂商推送监控技术方案实现

在落地面，监控技术方案首先不能影响主流程中处理，

因为每天有数亿的消息推送，如果影响到核心流程，那么核心流程性能会大大降低。

所以，和第一个维度链路的监控类似，厂商的监控代码要从主流程逻辑中剥离出来，避免监控拖垮主流程，同样避免监控异常影响到推送的主流程。

如何解耦呢？这里使用的是有界内存队列实现。

3. 结果

消息推送厂商监控上线之后，可以及时感知到厂商推送的异常信息，对于厂商推送的异常和厂商规则的更改等可以做到及时的感知。

第三维度：业务方监控

这里涉及到业务方的调用速率、消息的发送数量（单条和批量发生）、成功比例进行监控和预警。

这里得物原文没有给出方案， 应该是有遗漏了。

得物推送监控带来的收益

1. 及时发现线上异常

监控上线后，能及时发现厂商的很多线上以上：

• 推送线程关闭失败
• 厂商推送跌零
• 厂商营销消息规则更改
• 厂商通道偶发不可用
• 等问题

及时发现异常后，就可以做到了及时的止损。

• 在时效性监控上线之后，发现了因厂商推送线程创建关闭失败导致线程数逐渐上升问题，避免了线上故障的发生。

• 厂商异常导致推送跌零，监控发现后及时通知到厂商并止损。

• 发现厂商营销消息规则更改的异常，

并及时经梳理各大厂商文档后，发现除了多个厂商通道在未来一个月内也会有规则的更改，消息平台团队对规则进行优化及时适应了厂商规则，接入厂商系统通道，做到了及时止损。

2. 帮助连接池和连接时间参数优化

通过全链路的有效性监控，发现了多个服务可以优化的点，

比如，发现多个厂商和推送链路单元在高峰推送时耗时较高，发现厂商推送 SDK 连接池和连接时间参数需要优化, 优化后消息推送整体的吞吐量实现了翻倍的提升。

得物推送监控总结

得物推送监控上线后，带来的收益还是比较可观的，

展望未来，后续可以从以下点丰富现有监控。

• 后续将针对各个链路单元的推送异常、漏斗转化率、服务性能等做监控，进一步丰富消息平台的监控体系。

• 后续将对推送的转化率问题进行监控

• 后续将对卸载、屏蔽等指标也是我们需要监控的点，

总之，通过对业务指标进行扩展，及时感知推送的效果，做到精细化的管控。

说在最后：有问题找老架构取经

推送系统，是一个很黄金的系统。

如果写入简历，并且面试的时候能对答如流，如数家珍， 面试官会被你 震惊到、吸引到。

最终，让面试官爱到 “不能自已、口水直流”。

offer， 也就来了。

在面试之前，建议大家系统化的刷一波5000页《尼恩Java面试宝典PDF》 ，里边有大量的大厂真题、面试难题、架构难题。很多小伙伴刷完后， 吊打面试官， 大厂横着走。

在刷题过程中，如果有啥问题，大家可以来 找 40岁老架构师尼恩交流。

金三银四挪窝的黄金时期到了，建议大家简历上织入一个 《推送系统》， 当然如果不知道怎么织入，可以找尼恩来改简历、做帮扶。

遇到职业难题，找老架构取经， 可以省去太多的折腾，省去太多的弯路。尼恩指导了大量的小伙伴上岸，前段时间，刚指导一个40岁+被裁小伙伴，拿到了一个年薪100W的offer。

狠狠卷，实现 “offer自由” 很容易的， 前段时间一个武汉的跟着尼恩卷了2年的小伙伴， 在极度严寒/痛苦被裁的环境下， offer拿到手软， 实现真正的 “offer自由” 。

尼恩技术圣经系列PDF

• 《NIO圣经：一次穿透NIO、Selector、Epoll底层原理》
• 《Docker圣经：大白话说Docker底层原理，6W字实现Docker自由》
• 《K8S学习圣经：大白话说K8S底层原理，14W字实现K8S自由》
• 《SpringCloud Alibaba 学习圣经，10万字实现SpringCloud 自由》
• 《大数据HBase学习圣经：一本书实现HBase学习自由》
• 《大数据Flink学习圣经：一本书实现大数据Flink自由》
• 《响应式圣经：10W字，实现Spring响应式编程自由》
• 《Go学习圣经：Go语言实现高并发CRUD业务开发》

……完整版尼恩技术圣经PDF集群，请找尼恩领取

《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》PDF，请到下面公号【技术自由圈】取↓↓↓