亿级APP支付宝在移动端的高可用技术实践

　　亿级APP支付宝在移动端的高可用技术实践

　　亿级 APP 在可用性方面的挑战

　　可用性的概念

　　

　　简单而言，可用性就是当用户想要使用 APP 做一个事情，这件事情弄成了就是可用，没有弄成就不可用。

　　为什么没有弄成？可能的诱因有很多，比如有可能使用 APP 的时侯死机了，或者使用支付宝付款的时侯，由于后台某个环节出现错误，导致了这笔支付失败了等，这些都可能导致 APP 的不可用。

　　如果各种各样不可用的情况都没有出现，那么对于顾客而言就是可用的。虽然每位开发人员都希望自己开发的 APP 是 100% 可用的，但是实际上这一点是不可能的。所以开发人员真正须要做的事情就是使 APP 发生不可用的情况越来越少。

　　亿级 APP 的可用性挑战

　　

　　目前，APP 开发技术早已比较成熟了，所以好多开发人员会觉得自己的 APP 可用性应当问题不是很大，因为 APP 都经历了相关的测试流程、灰度验证等保障举措。

　　但是如今情况早已发生变化了，与先前相比，APP 的用户量大了好多，很多的 APP 都达到了亿级用户，所以一点点可用性问题都可能会影响大量的用户。

　　比如 APP 的闪退率下降了千分之一，虽然这一比列并不是很大，但是对于一亿用户而言，乘上千分之一就是 10 万人。

　　大家可以想像一下，如果某三天你们在使用支付宝在商场付款的时侯，其中的 10 万人出现掉帧的情况，这个影响是绝对不可以接受的。

　　现在开发移动端 APP 讲究动态化，业务要求实时动态地实现线上变更，可以说明天的支付宝和今天的支付宝相比就早已形成很大区别了。

　　每一次线上的变更虽然就会降低线上可用性的风险，而且三天中可能会发生很多次变更，在这些情况下风险也会显得很大。尤其对于作为保障 APP 可用性的一线人员而言，压力也会非常大。

　　正是由于面临这么多的问题和挑战，才须要通过移动端的高可用技术体系解决这个问题，保证线上客户端高可用性。

　　APP 线上运维的发展和变迁

　　

　　如上图，是这几年来支付宝客户端在可用性运维上的发展历史，大致分为了三个阶段。随着支付宝的成长，可用性运维也仍然在演化，最后演变到了移动端高可用的状态。

　　第一个阶段就是简单的死机监控。绝大多数的 APP 也做过这个事情，就是本地搜集一些死机信息并进行上报，在 APP 后台对于闪退率进行监控，解决死机比较多的问题，并在 APP 的下一个版本中进行相应的更改，最后让闪退率维持在某一个指标以下。

　　但是现今来看，这个阶段距离实现高可用的要求相差很远，因为用户所遇见不可用问题中死机只抢占其中一部分，所以对可用性而言，解决了死机问题只是改进了一点点而已，还存在着大部分的问题没有解决。

　　

　　第二个阶段，在阿里巴巴内部称作稳定性监控体系，相比于第一个阶段而言，稳定性监控体系可以说前进了特别大的一步。

　　首先，可以监控的问题大大丰富了，通过对多种问题的监控可以了解线上用户稳定性方面的可用情况，而不仅仅是一个用户。

　　第二个方面，稳定性监控体系具有相当程度的确诊能力和修补能力。当发觉问题的时侯，可以通过确诊日志等相应的方式剖析故障缘由并尝试进行修补。

　　稳定性监控体系在最初的时侯疗效比较不错，并且阿里巴巴内部也使用了太长的时间，但是后来问题也渐渐曝露下来。

　　举两个事例，曾经一个版本的 APP 在 X86 一款机器上运行时出现的问题十分多，但是那种型号的用户量太小，所以问题始终都没有被发觉，直到太晚的时侯才通过其他方法发觉了这个问题，也就是说由于只监控具体问题引起早已不能发觉局部人群的问题了。

　　第二个事例，在做象双 11 这样的大促值勤的技术保障的时侯，因为监控的问题比较多，运维人员须要通过不停地翻监控来发觉问题，翻来翻去最后还是不敢确定 APP 的可用性究竟有没有问题，有时候确实会遗漏一些问题。

　　第三个方案就是在发觉了问题以后，能否快速修补还须要碰运气，有可能很快就才能修补，也有可能修补上去不太容易，需要等到下一次发版，这就促使有些问题所影响用户数会特别多。

　　

　　以上就是在 2.0 阶段所碰到的问题，这说明稳定性监控体系也早已不够用了，需要继续进行改进，这也是支付宝决定继续做 3.0 阶段的移动端高可用的动机和动力。

　　移动端高可用的定义、目标、核心打法

　　高可用在移动端的重新定义

　　高可用本来属于服务端的概念，阿里巴巴的服务端都在讲高可用。服务端的高可用重点讲的是停机时间短、服务不可用时间短。

　　移动端的高可用从服务端借鉴过来以后进行了重新定义，因为客户端不存在停机时间概念。

　　所以，移动端高可用的定义是指通过专门的设计，结合整套技术体系，保证用户所遇见的技术不可用总次数太低。

　　

　　移动端高可用的目标

　　简单来说，移动端高可用的目标就是实现可用率达到 99.99%，这里的可用率是支付宝自己定义的概念，指的就是用户在使用 APP 的时侯，可用次数在使用次数当中的占比，可用率达到 99.99%。

　　也就意味着用户使用 1 万次支付宝中的 9999 次都必须是可用的，最多只有一次不可用。为了实现这一目标，还会将任务拆解成为不同的子目标分别攻破。

　　

　　移动端高可用的核心打法

　　

　　目标的实现还是比较困难的，因为使可用率达到 99.99% 是一个很高的指标。而为了才能努力实现这个目标，支付宝也自创了一套核心打法。

　　主要分为以下四个部份：

　　支付宝在移动端高可用技术实践

　　

　　如上图所示，是支付宝实现的移动端高可用技术构架图，大家可以看见支付宝移动端高可用的技术构架设计也是围绕上述的四个核心打法展开的。

　　客户端可用性监控

　　

　　问题采集

　　客户端可用性监控的第一步就是问题采集，当 APP 发生不可用时必须才能感知和采集到问题，这是基础的基础，如果没有这个基础后续哪些都不能实现。

　　怎样确保当用户出现了不可用情况时才能采集到问题？这是比较困难的，因为我们不能保证一定可以采集到所有类型的不可用问题，但是还是会通过多种方式尽量地实现全面覆盖。

　　支付宝把不可用问题分为稳定性不可用和业务不可用两个方面。对于稳定性不可用而言，通过 2.0 阶段的逐步摸索以及各类反馈渠道、问题采集渠道的补充，现在早已可以把各种各样稳定性的不可用问题采集得比较全了。

　　比如传统的死机、卡死等以及不容易被监控的蓝屏、白屏以及非死机类型的异常退出等。

　　目前早已采集到了大部分的问题，当然可能就会存在遗漏，对于那些遗漏的问题，还须要通过不停地采集并补充到这个体系中。

　　对于业务不可用而言，在开发时会对于业务不可用问题进行埋点，只须要将业务不可用埋点列入到系统上面来，就能够基本覆盖最重要的业务不可用问题。

　　统一管控

　　当问题采集上来以后，需要通过统一管控产生客户端可用率指标。通过这个指标可以全面地评估线上某一个人群中的可用情况，而不需要象曾经那样逐一检测各个指标并在最后给一个不太确切的评估结果。通过统一管控可以设计出整体的监控和报案机制以及各类算法模型，并且其扩展性更好。

　　埋点上报

　　埋点上报这一功能是特别核心的，因为后续还要借助不可用埋点做高灵敏，所以埋点的实时性、准确性、到达率的要求非常高。

　　并且对于不可用埋点而言，当客户端早已发生了不可用时才须要进行上报，而在这个时侯客户端情况太可能十分恶劣，甚至此时客户端可能早已未能启动了，即便是这样也要保证埋点才能上报。

　　为了实现这一点，我们借助了一些小技巧，比如对于 Android 系统而言，支付宝通过独立的轻量级进程来单独上报埋点，即便主进程早已死掉了，但是埋点也就能实时上报上来。

　　对于 iOS 系统而言，采取在线上 hold 住进程让其报完埋点再退出去的形式，并且后续还有补偿机制，即使出现遗漏埋点的情况也才能让其最终能否上报上来。

　　通过问题采集、统一管控和埋点上报，基本上可以保障当用户碰到不可用问题时可以搜集问题并上报服务端，做好了第一步的基础。

　　高灵敏度系统模型

　　

　　在问题搜集到的情况下须要用高灵敏系统模型做监控和报案。监控和报案在 2.0 时代就早已存在了，比如当盘面上监控的闪退率出现异常情况时才会进行报案。

　　但是高灵敏系统模型要做的是在线上问题刚才出现端倪的时侯就可以发觉，而不是等到盘面出现波动才发觉。

　　所以这个模型的关键在于剖析决策的过程中，它会基于用户的人群特点、问题特点把线上采集到的不可用问题进行聚合再进行剖析，通过预制的一些算法模型和规则来判定是否形成了异常，如果最终判定的确有异常形成了则会输出一个异常风波。

　　举个事例，比如线上的某个业务发布了一个新的 H5 离线包版本，其中某一个页面的卡死率很高。那么使用这个页面的用户都会产生一个特点人群，这个特点人群的页面卡死率就有异常的波动，这个时侯才会输出异常风波。

　　但是此时盘面并没有很大波动，因为特点人群的人数并不多，但是后台可以捕获到异常风波。

　　当异常风波输出然后，可以通过附送信息准确地匹配到相应的负责人以及开发、测试人员，告警系统会告知负责人进行处理，并且会依照问题的严重程度采取不同的告警形式，可能会采取电邮、钉钉或则电话等方法进行告警。

　　在问题十分严重的情况下，如果几分钟之内没有响应就有人打电话给负责人了。通过这样的告警机制就可以保证无论哪些时间，只要线上出现异常问题就可以迅速地感知到。

　　高可用容灾平台

　　通过上述的内容，我们早已可以实现对于可用性问题的感知了。接下来分享怎样通过高可用容灾平台修补异常问题。

　　这里通过整体的故障容灾过程进行分享，如下图所示，当一个故障进来了，会向相应的负责人发出告警，这时负责人须要检测这个故障是如何形成的，到底是因为线上变更引起的，还是因为客户端本身的 Bug 导致的。

　　如果是由于线上变更引起的则比较好办，因为现今的系统比较灵敏，只要故障刚一发生，在短时间内负责人员就可以收到告警。

　　之后就可以到发布记录中检测这段时间内发生了哪几次变更，可以很快地基本了解是哪一次变更引起的故障，并采取相应的处理策略。

　　如果可以回滚就进行回滚操作，不能回滚就须要进行紧急发布，如果不能紧急发布就要依赖客户端进行修补。

　　

　　比较麻烦的是和变更没有关系的情况，此时就须要通过异常携带的确诊信息或则通过获取一些日志来检测问题为何形成，问题的形成有时候是因为兼容性问题。

　　比如某个厂商灰度发布了一批和支付宝兼容性不太好的系统，导致出现了各种各样的问题，这种情况下就要通过动态修补解决。

　　也可能一些顾客本地出现了严重错误，比如说形成了一些脏数据，或者安装时由于市场的临时性 Bug 导致了大量安装失败，最终造成支付宝打不开。

　　对于这些情况而言，可以通过本地容灾做一些恢复工作，进而实现客户端的手动恢复。

　　总之，通过上述的过程，可以让故障得到解决。从右图中可以看出，支付宝在高可用容灾中致力于两点：

　　

　　高可用的动态修补体系

　　移动端高可用和服务端高可用的重大区别就是移动端的发布比较困难，所以须要借助动态修补技术。

　　动态修补并不是新的概念，像 hotpatch 等技术都早已十分成熟了，目前也有好多可选的动态修补方案。

　　但是，虽然在高可用的动态修补体系中，hotpatch 属于比较重要的点，但是并不是最主要的点，因为它也存在一定的局限性，也有不适宜的时侯。目前，支付宝基于多种修补手段搭建了高可用的动态修补体系。

　　

　　支付宝的高可用动态修补体系主要由以下三部份构成：

　　修复手段

　　修复手段有很多种，并且有轻有重。轻的手段在线上进行一些配置就可以解决线上不可用的问题，重的手段可以把整个模块完全重新布署下去。具体应当选择哪一种修补手段应当按照故障的情况来看，选择效率最高、风险最低的修补方法。

　　下发通道

　　这一点与埋点上报的要求有一点类似，也须要高实时性和高可靠性。当用户早已不可用了，常规方法拉不到线上的修补方案的时侯，能够解决的办法再多也是没有用的，所以须要保障无论面对多么恶劣的情况下都还能把修补方案拉出来。

　　下发通道的实现方法有很多种，最终实现只要才能联网一定可以将修补方案拉出来，如果暂时不能联网，那么一定要在联网以后将修补方案拉出来。

　　发布平台

　　设计动态修补的发布平台的时侯特别关注的一点就是把修补方案推送给真正须要它的用户，也就是把修补方案推给早已出现或则可能出现这个问题的用户。

　　这样做的缘由是每一次的动态修补虽然也是一次线上变更，本身也是存在风险的，如果对于所有用户都进行推送则须要比较长的时间进行灰度来保证安全，但是假如才能只对目标的冷门人群、特征人群推送方案，这样灰度时间会太短，修复时间也会太短。

　　支付宝在客户端恳求修补方案的时侯，会依照客户端的人群特点、是否发生过这个问题以及有没有发生这个问题的可能来判定是否把这个修补方案推送给她们，这样可以很快地完成推送过程。这在图中称之为“智能修补”，其实称之为“定向修补”更为确切一些。

　　高可用实战经验

　　在这里和你们分享支付宝在高可用实战中的两个案例，其中一个处理的比较成功，另外一个则不是太成功。

　　

　　案例 1：一个业务营运推送了一个错误的菜单配置，而客户端没有做好保护。在营运推送配置的 10 分钟之内，相关的负责人都收到了报案，并且很快地查到是这个配置造成的。

　　之后营运将马上对于配置进行了回滚，这个过程所影响用户数比较少，所以是一个比较成功的案例。

　　这也是支付宝最期望的运维过程，实现了及时发觉、很快修补而且影响用户数极少。

　　案例 2：在一次大促的时侯，一个业务开启了限流，客户端弹出一个限流的页面，这个页面有 Bug，会导致死机，进而造成用户难以进行操作。

　　但是因为当时的可用性监控不健全，所以这个问题没有被监控到，最后是因为用户的反馈才晓得出现了问题，到问题出现的第三天，反馈量早已积累到一个显著的程度了，才发觉这个问题。

　　之后，我们迅速地对于这个问题进行了剖析和解决，最后定位到限流的问题，一个小时之内确定了问题所在，并暂时把限流先关闭，后来把这个 Bug 修复掉了以后再将限流打开，这样客户端才恢复正常。

　　虽然最终把问题建立地解决了，但是这一过程存在十分显著的缺陷。首先是发觉的很晚了，这是因为可用性问题没有覆盖到。

　　另外，因为没有足够的信息促使决策的过程比较慢，花了 1 个小时进行剖析能够够止血，直到现今我们也不知道这一天究竟影响了多少用户，但是这一风波肯定对支付宝的可用性导致了不小的伤害。

　　而如今，支付宝实现了移动端的高可用，以后象这样的事情不会再发生了，当出现故障时，支付宝可以在第一天太短的时间内就可以搞定问题。

　　故障演习

　　

　　有这样一句话“避免故障最好的形式就是不断演习故障”，所以我们要通过可控的成本在线上真实地模拟一些故障，进行故障演习，检验高可用体系是否可靠，同时也使相应的朋友对系统、工具和流程愈发熟悉，当真正发生问题的时侯可以快速地处理。

　　为了更好的检验这套东西，支付宝采用了攻守对抗演习的形式，成立了一个虚拟小组，他们会想办法模拟线上可能出现的故障情况，而另外一组人则借助移动端高可用技术接招，把对方研制的问题快速地处理掉。

　　这样做好准备之后，当真正出现故障须要进行处理的时侯，我们也早已才能熟练地应对了。

　　在前进中探求

　　

　　最后再谈一下对客户端可用性运维未来的思索：

　　智能化

　　前面提及了高灵敏的模型，大家可以看见在决策的过程中常常须要依赖预设的算法模型、规则以及数值等，这些都缘于长期积攒出来的经验。

　　但是这也存在一些缺点：一是有可能出现误报；二是为了避免误报太多，这个模型不敢做的太短，所以模型的灵敏度属于比较灵敏，而不是极其灵敏。

　　我们期盼通过智能化的形式，通过人工智能、机器学习的方式实现决策过程的智能化，可以做得愈加灵敏，将问题发觉的时间再提高一节，而且这目前早已不仅仅是一个看法了，在支付宝的好多场景中早已开始使用智能报案了，我们也在督查和尝试接入这个东西。

　　自动化

　　这部份主要指的是容灾过程的自动化。我们想把上面展示的容灾过程做的太顺滑，但是其中好多步骤都须要人来做，这样时间成本、决策成本会很高。

　　所以我们希望把尽量多的步骤转成自动化形式，至少是*敏*感*词*化的方法，这样就能使容灾过程愈发顺滑，使得修补时间形成本质的飞跃。

　　产品化

　　我们希望当客户端可用性愈发成熟以后赋能给其他类似的 APP，通过这个过程积攒更多的经验，发现更多的问题。并且在未来合适的时间，或者 3.0 版本的客户端可用性不能满足需求的时侯再去建设 4.0 可用性运维体系。

　　作者：竹光

　　简介：蚂蚁金服中级技术专家。2015 年加入支付宝，主要负责客户端的稳定性和高可用，曾多次参与双 11、双 12、春节红包等大促的技术保障工作，主要负责保证活动期间支付宝客户端的稳定性以及可用性。