阿里移动云系列第一篇|“移”码平川：移动端高可用性体系

摘要：2017杭州云栖大会阿里移动云峰会专场上，阿里巴巴资深技术专家玄黎带来移动端高可用体系相关演讲。本文主要介绍了为什么要用高可用体系，以及高可用体系具体包括哪些内容，包括自动化、度量&监控、分析和修复体系，最后讲到高可用在阿里的价值。

为什么要用高可用体系？

APP发展到现在，做成一个体验非常好、性能非常快，没有什么问题的APP也是各个公司非常难的事情。大家发现功能完成以后达到高质量成本非常高，一般要做体验非常好、性能非常好APP可能需要非常资深的工程师，而且需要时间很长，才能够保证性能体验做的非常好。

APP的特点都安装在手机上，等客户打电话或者老板反馈APP有问题时，基本上都是大问题了，可能需要花很长时间定位问题。发现问题后，再发一个版本可能也要很长时间，目前来说整个阿里系发版周期非常快，每一周都在发布，那么，阿里内部是怎样做的？

阿里移动高可用体系

我们把高可用体系分为四个部分：

第一，自动化体系。和传统意义上的自动化不太一样，还有一些校验规则；

第二，监控度量体系。移动端APM非常盛行，客户端我们研发了一套低成本方案，帮助研发工程师非常精确地知道体验问题、性能问题、稳定性问题。

第三，修复方案。早于客户投诉之前发现问题，我们开发了一套用户问题感知体系和服务端高灵敏度分析和问题排查体系。

第四，为多维度分析机制。为了解决在移动端发现的问题，开发了自己自营方案以及远程发送配置方案，可以快速降级或者关闭掉一些功能，同时一个功能模块有问题了，可以跳到另外一个模块。

1

自动化体系

目前在阿里内部，我们结合自动化方案可以根据线上用户路径图，在线下根据用户路径进行高效投放，手淘场景下两个小时可以覆盖手淘70%-80%的路径。这套体系在构建的时候嵌入一个SDK，可以在所有空间里自动生成一个ID，你可以在一台机器上操作同步在所有机器上进行回放，通过这套体系可以在一台机器上回放，大屏幕上有几十台机器帮助你做功能回放。其实整个回放比以前自动化脚本便利很多，手淘一天时间可以把所有页面都写完，可以经过一天进行回放。

我们有很多校验规则，同步跑的时候会发现很多性能问题，以前测试发现性能慢，我们希望跑的过程中快速告诉开发者哪行代码有问题，我们集成了很多校验规则，大文件、流量、耗电、Cloud等等。通过这种方式等开发完测试功能以后，可以在3-4小时快速帮助排查出来60%-70%的问题，性能、稳定性问题都可以通过这套手段快速解决。

2

度量、监控体系

卡顿、不流畅、内存爆掉可以通过无痕埋点的方式，开发接入成本极低。比如启动时间，阿里认为用户点击一个页面到展现是完全可操作的，包括所有页面的响应时间、流畅度、崩溃、卡顿、功耗，阿里今天不需要研发做任何代码开发，通过SDK无痕方式可以快速接入。在我们内部已经不再做性能测试，今天可以以非常低的成本感知到用户体验问题、性能问题；精确度高，与用户直接感受接近；通用性强，线下线上都适用。

3

分析体系

在监控SDK基础上开了一套基于大数据非常完善的体系。最简单的是度量体系，比如说通过体验数据、性能数据、稳定性数据可以快速帮助整个应用做一些监控趋势，这个趋势除了APP之外可以分到APP模块业务层面。我们还会根据统计学的原理，有一些常见的规则，如地域关系、网络关系、用户体征关系，我们会智能分析自动告诉你是否是一些客观元素导致整个网络或者整个应用出问题。

如果不知道客观原因，还有移动日志分析，可以非常明确的指导当时用户现场发生的一些问题，比如用户发生问题之前CPU是什么样的，内存信息什么样子，如果你还不知道，突然发现下单不成功，会有一个远程的移动日志，用低成本的方式获取用户所有的网络信息，如果今天发现都不能知道的时候，你也可以通过主动上报的方式或者用户远程下发命令的方式，如果后台做一些解析规则的话，可以自动分析是因为什么问题导致的。

通过这些方式可以在非常短的时间之内让用户有反馈或者监控报警，可以快速的感知到APP是什么问题，如果是性能问题可以快速感知到，如果是稳定性问题影响因子是什么样子，发生概率是什么样子，特别是性能，可以快速感知到是否是某款机型适配问题导致了卡顿和性能低下。

4

修复体系

修复问题是更麻烦的事情，安卓端一周可以做到70%的覆盖，iOS也是这个程度，阿里主要做三个事情：

第一，动态部署。把整个功能进行更新，这是基于开源的体系做。

第二，热修复。可以快速时间之内把所有问题修复掉。

第三，远程配置。需要在开发过程中自己按开关，可以帮助你把功能快速关掉。

在阿里的价值

阿里2009年做无线，真正成熟在2013年、2014年，到去年从原来一个月到两个月发一个版本，现在每一天都在发版本，从测试完成到发布大概需要一天时间，现在灵敏度大概在10秒钟之内，手淘现在每天都在发布，稳定性保持在千分之一，我们重大的问题在一个小时之内可以完全修复掉。

实例如图，一个版本有很多用户，马上用户舆情报警，后台看数据量非常低，可能万分之一或者百万分之一，传统意义上基本没有办法做这个事情，移动端不可能把所有用户日志都存下来。我们发现和用户地域信息有很大关系，舆情自动报出来后，告诉你某个地域有问题，我们根据一些用户下报日志主动下发远程日志请求，一些敏感信息不会存，根据用户日志信息、流水信息可以发现问题，但是机器非常少，可能一台机器有问题，可以马上进行判别，把问题修复掉。

阿里更多借助于灰度体系、CR体系做一些查漏补缺的事情，保证快速交付，不会因为速度加快导致整个质量、性能、体验有很大的差别。

阿里移动云系列第二篇

一站式移动应用研发体系

— 敬请期待 —