一、背景
移动互联网蓬勃发展的明天，大部分手机 APP 都提供了消息推送功能，推送技术将传统靠"主动拉"获取信息的方法弄成了信息主动寻觅用户的方法，这更适宜在联通网路中满足用户个性化信息的需求。好医生APP推送功能主要应用于医患交流和订阅类关系的消息通知场景，基于医患交流的特殊性，用户愈发看重消息的送达率和即时性。所以，好医生离线消息推送系统的演化之路，其实质就是通过建设稳定、高效的消息推送系统，不断提高和保障推送服务的可用性和推送消息的送达率。
二、系统高可用性建设之路1.服务雏型 -- 推送工具
我们常说的一个词称作：“迭代”，通常称作“小步试错，快速迭代”，这刚好也与好大夫离线消息推送系统的演变过程相对应。在初始阶段，推送服务也是本着“先完成，再完美”的实践原则落地。
最初，消息推送只是简单得被视为一个通知类工具，在医患交流过程中提醒接收方查看新的讯息，工作流程大致如下图所示：
初代推送服务也是为满足上述需求而设计，由PHP语言实现，推送构架设计十分简单，如图：
如果我们以面向功能实现的角度看待里面设计，那么足以实现当时业务的需求。但随着好医生业务的发展及对服务质量要求的不断提高，尤其近些年来，医生会诊线上服务的回复效率成为评判大夫服务质量的关键性指标之一，患者对大夫的回复更是满腔期盼，所以，消息提醒服务的稳定性及可靠性越来越被大夫和病人所看重，在这么背景下，上面简易的推送设计其中隐藏的众多问题便骤然暴露无遗，引发用户大量投诉。
随着各种投诉问题纷至沓来，同时在生产实践中，我们也发觉好多须要改善的地方，大概汇总如下：
等等以上问题急待解决，这在当时那种阶段是我们不得不面对的挑战，为彻底解决上述问题，我们下定决心将推送服务进行构建。
当然，这部份内容仅作为经验之谈和对过去的总结，也是希望各位读者才能避而远之。
2.服务进化 -- 推送系统2.1 需求梳理
在大张旗鼓得进行服务构建时，我们觉得随着公司业务发展，提升推送服务的稳定性已经成为构建目标中的重中之重。在构建前，结合业务场景重新考量消息推送这一基础服务，我们除了要解决历史遗留性问题，更要从边沿性服务的历史地位上将其界定下来，将消息推送作为一个完整系统看待，而不仅仅是一个工具类。
那么，何为系统？“系统是由相互作用相互依赖的若干组成部份结合而成的，具有特定功能的有机整体” -- 钱学森。换句话说，为了提供愈发稳定、可靠、高效的消息推送服务，推送系统不仅要保障将消息确切有效地下发到用户之外，我们又具象出基础功能、用户体验和营运服务三个层面，赋予了它更多的职能。
反思：如果继续将推送当作一个工具使用会有哪些后果？
如果只把推送当作一个工具，缺乏对消息推送的管理意识，只管将业务触发的消息统统下发，那么随着时间的推移，业务逻辑的累积，势必会导致好多无意义的消息和用户无感的内容频繁推给用户，最终造成用户不堪重负主动关掉通知权限，甚至会直接卸载App，从而流式用户。
所以，我们希望通过新推送系统的构建来防止上述问题，实现从消息推送发起到最终用户是否收到、是否点击进行全方位的数据剖析，同时实现服务稳定性监控，以及通过消息点击率的数据走势最终彰显出用户偏好，使产品的迭代优化更具目的性和可观测性。
2.2 技术选型
在明晰了需求以后，我们选择技术生态更为完善的 Java 体系作为初始环境，再然后更为关键的一步便是推送技术选型。结合旧有推送服务的营运经验，我们在推送技术选型时根据“能直接依赖厂商服务则直接依赖”的原则，制定了如下推送方案。
在做前期督查时，我们就会了解到例如极光推送、个推、友盟、百度云等第三方推送服务，通过简单嵌入一个SDK即可实现消息推送功能。这里有人可能会问：“直接使用第三方推送服务，不仅开发成本低，而且成熟稳定，还提供了建立的后台功能，为什么不用来直接使用呢？”
正如上图对比剖析，第三方服务即使接入愈发方便，开发成本低，但是基于服务稳定性和数据安全两个方面，我们还是选择了直接对接厂商服务的技术方案。
Tip：为什么厂商推送服务愈发稳定？
这里主要指安卓端，由于国外对 Google 限制， 导致了Android GCM推送服务在国外不可用， 所以国外的终端厂商大部分移除了 GCM 模块，然后推出各自系统级别的推送服务， 例如小米系统的 MIPush， 华为系统HuaWeiPush， 魅族系统的 FlyMePush 等。作为订制系统的手机厂商， 从系统级别进行了推送支持。厂商推送的进程为系统常驻进程，这个进程不会被系统回收，而且一键清理也不会关掉，所以稳定。
而第三方服务，例如百度推送，作为非手机厂商的推送，它的核心原理是多个App共享一个长链接，只要有一个App存活这么推送就可以正常发送，这种全家桶式的推送服务因为集成用户多，相互唤起机率较大，以此实现长联接的保活，实现相对稳定的推送服务。
此时我们还须要考虑另外两个问题：
1.灵活程度：如果确认是第三方服务不支持的功能或Bug造成用户投诉，而版本迭代修补须要较长周期，那么在此期间，我们该怎么处理用户投诉？ 例如，我们在使用友盟服务给魅族设备推送时期，因其不支持小米设备，面对小米设备用户的投诉只能将红米厂商服务列入推送体系中来，但是已发行的客户端版本仍然面临用户投诉的挑战。
2.成本问题：若轻度依赖第三方服务，随着企业业务深入发展，第三方提供的免费版本注定将不再适用，转向中级付费版本势必成为必然选择，那么企业是否乐意承当其高额支出？ 例如，友盟免费通道为诸多APP共享通道，其发布QPS有最大限制，所以假如使用免费通道，受多方影响，我们势必会面临被限流的问题且不受控制。限流会导致推送消息发布失败或延后，给用户带去不好的体验。此时第三方则会提供VIP独享通道的解决方案。
由于安卓型号种类繁杂，各家厂商服务一次性全部接入的工作量巨大。所以为了兼容冷门型号，全家桶式的推送服务我们仍然须要引入，同时作为兜底的推送渠道使用。在督查第三方推送服务时，各家服务简略对比如下（仅供参考）：
注：第三方服务也是在不断升级迭代的，有些历史问题可能早已随着版本升级得到有效解决，详情请查阅最新官方文档。
综上所述，我们最终采用“尽量直接对接厂商服务，第三方服务兜底”的策略来支撑推送服务（第三方服务采用友盟推送）。于是，便产生了如下的推送基础构架模型：
2.3 推送通道高可用性优化
当然，很容易发觉上述基础模型中各种型号都是单通道发送，并无高可用性相关设计。在生产实践中，我们遇见过两次推送故障，分别如下：
厂商服务故障：华为厂商API服务忽然异常，期间造成华为推送全部失败。事后反馈是因为华为推送灰度上线异常造成。机房网路故障：好医生线上机房通往海外链路网路异常，导致恳求APNS服务失败，期间iOS设备的消息推送全部失效，机房运维人员自动将联通出口切换至移动出口后服务恢复正常。
以上故障假如没有经过生产实践，很难在系统设计初就将其考虑进来，为实现推送系统的高可用性，我们在基础模型上衍生出了链路备份的演化策略，具体如下图：
在优化通往海外APNS服务的链路时，我们借助阿里云机房多地布署的优势实现iOS推送的多出口，同时支持流量按比列实时调配，发送失败时支持多通道手动切换重试。而在解决安卓推送厂商通道故障或异常的问题时，我们则使用友盟自建通道作为其他厂商备份通道的方法，尽可能的保障消息可达。
2.4 如何保障推送消息不遗失
在互联网环境中参杂着好多低几率风波，如"网络故障"、“机器故障”及“自然灾害”等等。然而，小概率事件并非零机率风波。一旦发生，如果应对不善，突如其来的“黑天鹅”事件也会导致系统性风险、产生严重后果。原有的推送构架在系统防御性方面的设计不足，如遇网路波动等情形时，接口调用失败便会导致推送消息遗失。
所以，在好医生推送系统高可用建设中，我们面临的另一个挑战就是——“如何尽可能的保障推送消息不遗失?" 答案是 ——“消息队列”，通过使用消息队列除了提高了系统整体吞吐量，而且嫁接使用了消息队列中间件的稳定性和失败重试功能。
说明：消息队列作为公司级中间件应用，其稳定性要求高达99.99%以上，围绕消息队列中间件稳定性我们做了大量相关工作和资源投入，如补偿机制、重试机制、吞吐量等，以及覆盖范围愈加全面的监控告警等等，这里不再展开表述。
写到这儿，好医生离线消息推送系统早已进一步演变为一个相对比较成熟稳定的微服务系统，其核心构架大致如下：
2.5 其他优化
“魔鬼存在于细节之中（Devils in the details)”，对于推送系统的优化，重构只是最粗细度的手段，而实际上更多的优化常常是去深挖潜藏的细节。在细节优化过程中，我们也投入了相当一部分精力，大致阐述如下：
三、系统稳定性营运建设之路
从唯物辩证法来看，推动新事物的形成和发展，从根本上讲就是不断认识矛盾、解决矛盾的过程。同样，对好医生离线消息推送系统而言，在可用性建设告一段落以后，新的矛盾和问题也便骤然浮出了海面。在生产实践过程中，我们又遇见了好多新的问题，譬如：
《韩非子》中有句至理名言：“圣人见微以知著，见端以知末，故见象箸而怖，知天下不足也”，借指运用以小见大、见微知著的眼神看待问题。同样，关于推送系统提及的上述三个问题，我们也可轻易看出其实质蕴涵的问题：
3.1 系统监控告警建设
离开了监控系统，我们就无法分辨一个服务是不是在正常提供服务；没有一套设计周全的监控体系，就好似蒙着耳朵飞奔；监控系统是服务运维中不可或缺的一部分。—— 《Google SRE 解密》
当然，这里并不是想要塑造一款监控系统，对于微服务应用本身更为关键的是怎样提炼出关键性指标来监控服务的运行质量，Google SRE 建议我们，在实践时，应该思索从用户最关心的方面入手，对于消息推送系统而言，有以下两个方面对用户影响最大。
所以，针对以上两个方面，我们设计了以下告警项(仅展示部份供参考)来检测推送服务的稳定性，同时结合告警系统的on-call机制，随时有值勤人员第一时间作出应急响应，及时干预补仓。
3.2 系统可观测性建设
一个正在运行的系统不仅提供业务功能，产生业务数据的同时都会形成好多“运行时”数据，我们可以将这种运行时数据分为：Metrics，tracing和logging。
Logging：用于记录离散的风波，包含程序执行到某一点或某一阶段的详尽信息.
Metrics：可聚合的数据微信能否接到离线消息，且一般是固定类型的时序数据，包括 Counter、Gauge、Histogram 等.
Tracing：记录单个恳求的处理流程，其中包括服务调用和处理时长等信息.
系统画像建设实际上就是基于Metrics，tracing和logging数据，通过一些测度剖析和可视化工具对以上三类数据做搜集、处理和剖析展示，从而达到服务的“可视化”，以便让研制、测试、运维和技术管理者能拥有服务的全局视角，在一个管理后台中见到多个或单个应用的相关信息。感兴趣的朋友可以参考我们之前的系列文章：《SRE实战(01) 初识+探索SRE怎么推动好大夫在线技术债权整修》，《解构服务风险整治》。
好医生离线消息推送系统的服务画像也是基于上述原理实现，我们采用的是 Prometheus + Grafana + Clickhouse 的技术体系（参考：《SRE实战(02)Clickhouse在好医生服务整治中的落地应用》），以全局到局部的设计思路分别勾画了以下画像：
No1.画像首页
主要从全局视角提供一个聚合页面，含推送系统本身的基础数据以及各端推送相关数据，如插口信噪比、推送达到率、点击率等。
No2.终端分类剖析
根据设备分类进行详尽剖析，如首页中发觉大夫版APP安卓端推送送达率较低，那么本页即可具体剖析是华为、小米、VIVO还是OPPO造成，以及低的缘由是否为通知栏开关关掉。
经数据剖析，用户主动将消息通知栏开关关掉是影响消息到达率的一个关键诱因，所以引导用户打开APP通知栏开关是提高消息到达率很关键的一项优化举措。
继续深入，还可依据消息存根Code分布进行愈发详尽的根因剖析：
No3.长期趋势剖析
长期趋势是对各项指标的常年统计，用于某段历史的回溯查验。数据储存主要是应用了Clickhouse的稀疏索引能力，从而实现在数据量巨大时仍可查询显示常年范围内的数据趋势，我们可对任何须要常年关注的指标进行类似处理，部分截图如下：
No4.服务风险分析
风险画像主要用于对服务面临的恐吓、存在的脆弱性、现有防护举措及综合作用带来风险的发生可能性进行评估。我们主要梳理了一些可能会影响服务稳定性及业务使用合理性的指标进行综合审视。
No5.服务异常剖析
服务异常表示应用程序当前不能正常提供服务，例如插口异常、队列消费者死掉等等，如图：
若厂商API接口服务异常，则可继续深入进行根因剖析，以苹果推送为例如下：
No6.iOS出口流量剖析
因APNS服务布署在美国，为防止运营商网路问题，我们使用了多个出口进行对外链路恳求，所以需对各链路健康状态及流量配比进行实时监控，从而专门勾画此图：
No7.JMX画像&No8.资源画像
基础资源画像略，可参考Grafana官方提供的 expoter 实现。
No9.推送周报
移动互联时代，每天守在PC端盯住Dashboard查看是不现实的。所以我们会定期将关键指标勾画为周报的方式，以手机图片规格发布至工作群以便随时随地查看，部分截图如下，仅做参考：
No10.其他
当然，我们也初步探求了对消息点击的剖析，通过点击剖析挖掘用户对各业务的关注度, 以及活跃用户APP版本分布等有用信息：
3.3 故障确诊平台建设
故障确诊的目标是确定某功能不能按预期工作的缘由以及怎样解决该问题。在日常工作中，出于种种缘由仍然会收到用户关于消息推送相关的建议和投诉，而排查问题常常是由营运侧反馈到开发侧，开发查完再解释给营运，来回沟通除了效率低，而且大多数时侯是重复性问题占用开发资源。为解决该类问题，我们设计了推送故障确诊平台专为营运服务微信能否接到离线消息，主要实现了如下功能：
模型示例如图：
在日常处理推送相关的意见建议或投诉时，可以通过故障确诊平台进行“一键确诊”，以快速定位并解决问题，使用门槛几乎为0，大大提高了营运和测试朋友的工作效率，得到好评。
四、总结
“不积跬步无以至千里，不积小流无以成江海”。好医生离线消息推送系统也是在生产实践中不断积累，由最初简单的一个通知工具演变为目前相对复杂的系统工程。作为好医生业务发展背景下的一个终端营运产物，我们分别从技术和营运角度看待。
从技术角度看，历经可用性建设及稳定性营运建设两个阶段，目前基本满足了用户需求。
从营运角度看，消息推送是我们可以与用户直接进行有效交互的渠道和手段，属于用户激活形式中不可或缺的重要一环，切记慎重使用，除功能性推送外，在不引起用户打搅的同时要尽可能的降低营销通知类推送，尽可能的结合用户偏好做到精准推送。同时，要意识到推送并不是一个工具，将消息推到设备即完成使命，更要关注后续数据的转化，并结合转化结果不断迭代产品方案，这样就能最大化借助推送这一神器。
五、后续规划
从Android8到iOS15早已步入了推送博弈红海阶段，未来开发者面临通知服务的多项挑战。厂商通道通过通知分类逐渐深化通知限额，通知作为历来被粗放漫灌的触达能力亟需回归 ROI(投资回报率)本质，解决成本问题。与往年对送达率的一味追求不同，未来考验如何用更少的通知发送，更弱的用户打搅度，获取更高的用户积极反馈。
长期以来，开发者在通知场景中主要关注送达率，历史中不乏通过流氓进程、频繁自启、链式激起等手段一味追求高送达率。近些年，更多开发者尤其是行业TOP级产品将目标转向了点击率和实际业务正反馈（如唤起率）。这对通知营运提出了更高的要求：业务愈发关注推送通知所带来的业务疗效，用户体验更是重中之重。所以，未来好医生推送服务的加码点大约如下：
参考文献：
【作者简介】
刘伟：好大夫系统构架部工程师，专注于SRE、消息整治，负责好医生客户端消息推送、消息中间件稳定性建设，以及好医生Push PaaS、MQ PaaS平台的设计与实现。
来源:微信公众号:HaoDF技术团队
出处:
