历时 1 年,上百万行代码!首次揭秘手淘全链路性能优化(一)

阅读数:11 2019 年 12 月 23 日 18:18

历时1年,上百万行代码!首次揭秘手淘全链路性能优化(一)

历时1年,上百万行代码!首次揭秘手淘全链路性能优化(一)

导读:自阿里在 11 年提出 All in 无线之后,手淘慢慢成长为承载业务最多,体量巨大的航母级移动端应用。与之相应的,手淘离轻量,快速,敏捷这些关键词却越来越远,启动慢,使用卡逐步成为用户使用过程中的主要体验问题。为此,手淘的技术团队启动了极速版项目,其目标是还给用户一个更加流畅的淘宝。整个项目历时近 1 年,横跨几十个团队,经历了数百次的数据实验,涉及代码上百万行,最终使得手淘的性能有一个质的飞跃。

下面,我们一起来看手淘团队在性能优化过程中的一些思考和实践。

启动框架的思考

▐ 启动框架在手淘的意义

启动性能,是用户在使用 APP 过程中的第一感观,可见是相当重要的。相信很多同学都能说出一些常规的手段,比如只加载必要的模块,延迟加载等。从大的策略上说,是没有问题的,也是手淘做启动性能优化的一个方向,也得了一些效果,但仍存在一些问题。

前面提到,手淘承载的业务非常多,为了更好支撑业务,使用了动态化技术及一些非常复杂的策略,就首页本身依赖的模块和任务就非常多,相互关系也复杂,只加载必要任务,仍然是一笔不小的开销。于是,为了更加极致的优化,我们不得不继续思考性能优化的本质。

通常我们为了更快的达到目标,把与目标无关的事情,提到完成目标之后,通过减少执行代码从而减少执行时间的方式,叫着软优化。相对的,对于提升系统的吞吐效率,对于相同的代码用更少的执行时间完成,叫着硬优化。硬优化是面向硬件资源,包括 CPU,内存,网络,磁盘 IO 等的调度,减少等待时间,最大化利用硬件资源,保持系统负载在合理范围内。

这次优化我们有一个大的原则,要求基本不能影响业务需求,也就是要在不减任何业务代码的情况下进行优化。

对手淘而言,因为启动包含很多基础 SDK,SDK 的初始化有着一定的先后顺序;业务 SDK 又是围绕着多个基础 SDK 建立的。

那么如何保证这些 SDK 在正确的阶段、按照正确的依赖顺序、高效地初始化?怎么合理调度任务,才不至于让系统负载过高?如何最大化利用设备的性能,承接越来越多的业务?

其实启动框架就是一个任务调度系统,是手淘启动的“大管家”。各个业务模块我们称之为启动任务,管家要做的事情就是把它们的关系梳理得明明白白,有条不紊,合理安排位置、调度时间,同时提升硬件资源的利用率。

▐ 启动框架的思路

总结下来无非就是两点:一是 如何保证时序 ;二是 怎么控制拥塞,提高吞吐,充实不瞎忙。我们先看一组实验数据,在并发下面的 IO 性能。

启动任务 高并发 IO 耗时 低并发 IO 耗时
历时1年,上百万行代码!首次揭秘手淘全链路性能优化(一)

由表上的数据可以看到降低 IO 的并发,整体的执行时间大幅降低。

我们借鉴了很多任务调度系统。比如谷歌新出的 WorkManager,再比如 Spark 的 DAGScheduler。

从 Spark 的 DAGScheduler 中领悟到它的核心思想,面向阶段调度(Stage-Oriented Scheduler):把应用划分成一个个的阶段(Stage),再把任务(Task)安排到各个阶段中去,任务的编排则是通过构建 有向无环图(DAG),把任务依赖通过图的方式梳理得 井井有条。因为它分阶段执行,先集中资源把阶段一搞定,再齐心协力去执行阶段二,这样即能控制拥塞,又能保证时序,还能并发执行,让设备性能尽可能得到发挥,岂不美哉:

历时1年,上百万行代码!首次揭秘手淘全链路性能优化(一)

本文转载自淘系技术公众号。

原文链接: https://mp.weixin.qq.com/s/PiqnHezWKWUU0byEhrboRg

评论

发布