移动性能测试 探秘手淘高可用平台 (三)——热修复和开发流程

安卓绿色联盟 · 2018年12月20日 · 838 次阅读

本系列文章根据手机淘宝客户端基础架构高级开发工程师非台在安卓绿色联盟开发者大会上的分享,共分三篇,介绍手淘技术团队性能和稳定性系统化提升方案 EMAS-MOTU 的设计原理以及实现思路。

本文重点介绍手淘高可用平台的热修复方案和如何全开发流程保障性能及稳定性。

热修复方案

热修复有三个场景,手淘 EMAS-MOTU 平台可以根据场景选择相应的方案进行热修复。

image

第一个场景是由于代码本身不够健壮,从而导致 APP 发生崩溃。针对这个问题,手淘开发了 Dexpatch 框架,可以实时快速对线上问题进行修复。

第二个场景是产品功能不符合项目预期。比如,需要举办一个活动,但这部分活动的功能没有正式上线,针对这个问题,手淘开发了 Atlas 动态容器框架,可以支持业务快速上线新功能。

第三个场景是启动时网络异常导致的崩溃。网络未初始化会导致 Dexpatch 和 Atlas 动态容器无法发挥作用,针对这个问题,手淘开发了安全模式,在启动异常时可以及时修复。

开发流程

开发流程一般分成开发测试、集成、灰度和线上四个阶段,手淘高可用平台在每个阶段是如何保障手淘平台的性能和稳定性的呢?

image

在开发测试阶段,手淘通过代码静态扫描以及测试用例的覆盖来提升高可用性。

在集成阶段,手淘会对历史问题进行回归。通过跟踪,判断历史问题是否全部修复,设置卡口,直至解决所有历史问题,达到持续集成的目的。

在智能灰度阶段,手淘开发了智能灰度机器人,它会根据上一次灰度的体量和性能稳定性数据来制定灰度策略。如果稳定性和性能数据报表符合预期,智能灰度机器人会逐渐放大灰度的用户量,直到正式发布为止。在灰度过程中,它还会监控应用各个模块是否存在异常并及时报警,以便快速定位稳定性性能不能达标的具体原因。如果灰度过程中一切正常,则可以通过这种方式直接发版。

在线上跟踪阶段,手淘数据平台会实时展示版本正式上线后的数据,可以根据数据决定后续的操作。如有异常,数据平台也会对开发同学进行警告,以便快速跟进,并决策是否要对它进行热修复。

手淘高可用平台系列文章已全部分享完成,开发者觉得有哪些值得借鉴和改进的地方呢?欢迎留言说出您的看法~

往期回顾

探秘手淘高可用平台(一)——度量指标及数据平台

探秘手淘高可用平台(二)——性能及稳定性治理方案

暂无回复。
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册