从Xinstall运行以来，目前已经累计服务涉及电子商务、新闻阅读、游戏、社交、金融、房地产等40余个行业的App，尤其合作了一些大型企业后，Xinstall统计过的App安装量已经接近10亿次，为企业节省推广费用40%以上

万事开头难，不少客户不知道Xinstall提供的传递智能参数以及渠道统计的服务。也对Xinstall的渠道统计业务产生质疑，随着对客户的耐心解释以及一步步协助客户完成渠道统计SDK的对接，进行测试。经过实际数据测试后，客户才放心并且选择了Xinstall服务。

随着Xinstall客户越来越多，责任也越来越重，这些客户一起见证了Xinstall增长，也渐渐有了千万级以及亿级规模的知名企业客户，随着服务客户的增多，我们运维工程师发现Xinstall某个服务器任务,会在特定极端情况下有出现运行缓慢的情况，尽管是边缘任务,但Xinstall秉持着不忘初心服务号客户的宗旨去查找原因，优化服务器性能，服务好每一位客户。

性能优化起因

为了提高 Xinstall 匹配准确率，当客户使用『托管包』方式进行配置时，我们会针对安装包进行一次包体优化，从而将该种配置方式下的准确率提高至100%（仅限特定条件）。在优化包体代码的执行过程中，会占用服务器部分资源进行操作，而这，也恰恰成为了我们这次优化的契机。

尽管该功能在上线前经过了我们测试团队的"严刑拷打"，但在上线服务了几百位客户后，还是出现了一次体验上的不佳：有一位客户反应他们的安装包有一次在下载前需要经过近2s的等待。

细心的客服部门没有对这种容易忽视的 "小缺陷" 坐视不管，反而第一时间反馈到研发部门。在测试团队的反复测试下，确认了该问题存在，以及出现的概率：0.04%。尽管从出现问题的概率上看，并没有达到我们内部制定的优化阈值概率，但是敏锐的 CTO 凭借丰富的开发经验，断定该问题在未来随着客户数量的上升，一定会放大出现的概率，因此，必须尽快找出出现问题的根源，并进行优化！

问题定位

0.04% 的概率虽然低，可能仅仅是几秒钟出现了短暂的性能问题，而普通监控服务只能通过测算一段时间内固定踩点得出的平均数据，因此很容易忽略掉几秒内出现的性能尖刺。

但好在运维部门在 Xinstall 立项初期，为了应对及其细微的性能尖刺难以捕捉的问题，研发了一套强大的『AI 性能捕捉机』，得益于AI 的学习能力，可以在服务器持续运行的过程中不断学习每台服务器的性能表现，从而能够突破固定踩点的限制，应对不同时段，不同流量下以及更多外界变量导致的性能的细微变化，进而敏锐区分性能尖刺，并记录在案。

通过『AI 性能捕捉机』的日志，结合客户反应的现场情况，运维团队准确定位到了在现象发生时是由于『优化包体』整体操作比预计慢了 1.66s 从而导致这个现象的发生，进而发现当时服务器在 1.66s 内，有 1.43s 出现磁盘吞吐量升高70%的性能尖刺，而其他服务器指标没有超过 AI 在当时时间段推算出的标准上限。

当技术团队接收到这两个信息后，结合服务端日志，发现确实在发生问题的时间段，存在12个并发的『优化包体』操作，所以确实可能导致磁盘吞吐量上升，但还需要证实是否是吞吐量达到瓶颈从而导致变慢。

首先第一步，需要确认的是，现场执行『优化包体』的服务器的磁盘性能。

通过现场的性能日志来看，在性能尖刺的1s时间内，磁盘吞吐量达到了 250MB/s 左右，由于我们的服务器使用的是阿里云ECS，所以技术团队需要确认ECS上挂载的云盘的吞吐量上限。

阿里云官方文档对云盘的性能描述：

以上指标是针对云盘本身的性能进行说明，抛开其他影响因素后，云盘本身所能发挥的最大性能指标。

我们的服务器是500GB系统盘（PL1） + 1000GB的外接云盘（PL1），外接云盘计算吞吐量 = min{120 + 0.5 * 1000, 350} = 350MB/S，应该远远大于现场的 250MB/S，从这里看，应该没有达到磁云盘的最大吞吐量。

但是，经过更多文档的查阅，我们发现阿里云ECS本身也有一个磁盘吞吐量上限，这个上限区别与云盘自身的吞吐量，ECS 最终的吞吐量上限是 min{云盘吞吐量上限, ECS自身吞吐量上线}。

根据阿里云官方文档，ECS实例存储I/O性能对比：

我们的服务器为 ecs.hfc6.2xlarge 型号，对应最大IOPS为2.5万，最大吞吐量为：250MB/s。

从这里来看，我们其实不单单要关心最大吞吐量，还需要关心一下另一个指标：【最大 IOPS】，两个指标都可能影响到我们的『优化包体』操作。

我们关心的指标是：【最大 IOPS】 和 【最大吞吐量】 这两个，这两个指标符合短板效应，即最大指标为：min{ESC最大值, 云盘最大值}。

从而我们可以计算出我们这台打包机的理论最大指标：

系统盘 IOPS：min{25000, min{1800 + 50 * 500, 50000}} = 25000

系统盘 吞吐量：min{250, min{120 + 0.5 * 500, 350}} = 250 MB/s

外接磁盘 IOPS：min{25000, min{1800 + 50 * 1000, 50000}} = 25000

外接磁盘 吞吐量：min{250, min{120 + 0.5 * 1000, 350}} = 250 MB/s

从上述计算可知，我们当前在这磁盘吞吐量指标上发挥的最大性能已经被 ECS 本身的实例所限制，并且符合现场的性能状况。

所以理论上如果我们需要防止业务增长带来的高并发进而影响到『优化包体』这一操作，那么必须升级 ECS 的配置，否则单单升级云盘盘性能已经没有作用了。

测试验证性能指标

当然，上述仅仅是阿里云给出的文档数据，有可能存在文档更新不及时，甚至是文档与实际服务器性能不匹配的情况。所以，为了确当前服务器真实的磁盘吞吐量，我们毕竟通过种方式，自行进行验证。

测试方案：使用阿里云官方测试方案

该方案使用到了 fio 工具进行磁盘性能测试，该工具是目前 Linux 系统上使用比较广泛的磁盘性能测试工具，并且官方给到了各种测试用例。

我们针对不同容量、不同性能级别的云盘、不同 ECS 性能分别进行了多次测试，来直接印证阿里云官方文档给出的数据是否准确。

【测试结果表】

通过单一变量对照测试，我们可以对比得出：

1. 主磁盘（系统盘）和外接磁盘（外接云盘）没有本质上的性能区分，均遵从阿里云官方文档的计算公式。

 > 测试变量：ECS型号相同、主磁盘（系统盘）和外接磁盘（外接云盘）容量相同、主磁盘和外接磁盘均为PL1，测试命令相同。

2. 磁盘容量大小确实会影响磁盘性能。

> 测试变量：ECS型号相同、均使用主磁盘、主磁盘均为PL1、测试命令相同、两次测试容量不同。

3. ECS 型号确实会影响磁盘性能。

> 测试变量：ECS型号不同、均使用主磁盘、主磁盘均为PL1、主磁盘容量相同、测试命令相同。

[注]：测试数据为 FIO 测试工具的报告给出，相比使用 iotop 工具肉眼观察测试过程中的数据采样会偏大一点，比如 263MiB/s 在实际采样中为 250MiB/s，29.3k 在实际采样中为 26.3k。

『优化包体』性能优化

既然确定了磁盘吞吐量为性能瓶颈，那么下一步所能做的优化无非两步：

1. 硬件性能优化

2. 软件性能优化

1. 硬件性能优化

硬件性能优化其实已经非常明了，从上面的文档以及测试结果来看，目前能够优化的点只有升级 ECS 的型号，来提高磁盘吞吐量的上限，俗称氪金。

2. 软件性能优化

软件层面，由于大量的并发可能导致多个任务同时进行，进而占用磁盘资源，导致各个任务的速度均受到影响。那么，在有限的磁盘资源的情况下，我们能做的，就是加快每次『优化包体』的速度。

由于『优化包体』整体操作主要消耗磁盘的步骤为：拷贝原始包 -> 拷贝解压缩后的原始包 这两步，所以我需要测试不同编程语言执行这两步时，是否有速度上的差异：

* cp 命令测试 [纯 cp 脚本 拷贝原包和解压后的包]

* node.js 直接拷贝测试 [纯 nodejs 代码 拷贝原包和解压后的包]

* node.js 调用 cp 拷贝测试 [在 nodejs 代码中调用 cp 命令 拷贝原包和解压后的包]

* scp 命令测试 [纯 scp 脚本 拷贝原包和解压后的包]

* rsync 命令测试 [纯 rsync 脚本 拷贝原包和解压后的包]

* cp + unzip 命令测试 [cp 脚本 拷贝原包，再使用 unzip 解压原包]

* oss 下载原包 + unzip 命令测试 [通过内网从 oss 下载原包，再使用 unzip 解压原包]

使用上述7中不同方式进行测试时，我们同时也考虑到下面两个影响因素：

   * 包大小对速度的影响

   * 主磁盘（系统盘）和外接磁盘（外接云盘）之间传输对速度的影响

所以，在进行每一项测试时，我们的测试用例基本是这样子的（-> 代表拷贝方向）：

【小包速度测试】

主磁盘 -> 主磁盘

主磁盘 -> 外接磁盘

外接磁盘 -> 外接磁盘

外接磁盘 -> 主磁盘

【大包速度测试】

主磁盘 -> 主磁盘

主磁盘 -> 外接磁盘

外接磁盘 -> 外接磁盘

外接磁盘 -> 主磁盘

经过技术同学耐心的测试，数据悦然纸上：

【测试结果表】

【结论】：软件层面还是受制于硬件瓶颈，无法通过不同的软件工具加快拷贝速度。

1. 各种方式对包的操作均与磁盘吞吐量有紧密关系，但目前不同方式之间的拷贝速度差异不大（除了非拷贝操作：unzip 和 oss download）

2. 目前可以看到 8v16g（ecs.hfc6.2xlarge）在各种方式下拷贝大包基本稳定在 30s 左右，经过测试阶段人工观察（iotop 工具），磁盘吞吐量也是达到了 ECS 自身的吞吐量瓶颈。

3. 为了进一步验证 ESC 吞吐量瓶颈是否跟随 ECS 型号提高，我们测试了下 ecs.hfc6.3xlarge 型号，发现速度大幅提升，吞吐量也是达到了该 ECS 自身的吞吐量瓶颈。

4. 外接磁盘和主磁盘之间的文件操作不会受到两块云盘带来的影响（速度和 单一磁盘内部操作一致）

【最终，我们的运维团队依以上测试所得的信息，最终采用了如下方案进行优化】：

1. 单机服务器型号升级，支持最大 625MB/S 的磁盘吞吐量，大幅缩短单次任务所消耗的时间

2. 『优化包体』微服务化，分散到我们全球各地区每个服务器上，让每个服务器都拥有该服务的能力

3. 运维团队内部研发落地一个新系统：『AI 服务调度系统』（内部代号：治水），结合全球各个服务器内部的『AI 性能捕捉机』实时上报的日志，分析出能够执行本次『优化包体』任务的最优服务器，从而进行任务派发。

优化成果

这套优化方案在执行的同时，测试团队同时也研发出一套『AI 拟真压力测试系统』（内部代号：泄洪），通过 AI 学习线上日志，模拟出高并发下场景下的客户请求情况（并非传统压测工具直接进行高并发请求），用来测试这套优化方案。

最终测试结果：

『AI 服务调度系统』承受住最高 1043次/s 的『优化包体』任务（远远高于线上实际并发量），且单次任务最多耗时 0.75s，单机服务器峰值时间均 < 1s，做到了 100% 任务在 1s 内完成的指标！

对于支持我们的用户，我们绝不对降低服务质量，无论从哪个角度看，都有义务保证Xinstall服务的高质量，随着Xinstall客户量的增加，同时也是Xinstall成为客户严格要求的对象，我们感受到了越来越重的责任，也会对自己要求越来越严格。感谢支持！