郭健美阿里巴巴高级技术专家，目前主要从事数据中心的性能分析和软硬件结合的性能优化CCF 系统软件专委和软件工程专委的委员。曾主持国家自然科学基金面上项目、入选上海市浦江人才计划A类、获得 ACMSIGSOFT “杰出论文奖”担任 ICSE'18NIER、ASE'18、FSE'19 等重要会议程序委员会委员。

数据中心已成为支撑大规模互联网服务的标准基础设施随着数据中心的规模越来越大，数据中心里每一次软件（如 JVM）或硬件（如 CPU）的升级改造都会带来高昂的成本合理的性能分析有助于数据中心的优化升级和成本节约，而错误的分析可能误导决策、甚至造成巨大的成本损耗

本文整理自阿里巴巴高级技术专家郭健美在 2018 年 12 月 GreenTea JUG Java Meetup上的分享，主要介绍阿里大规模数据中心性能监控与分析的挑战与实践
大家好，很高兴有机会与 Java 社区的开发者交流我的研究领域在软件工程，主要集中在系统配置和性能方面软件工程一个比较常见的活动是找 bug，当然找 bug 很重要但后来也发现，即便 bug-free 的程序也會被人配置错所以就衍生出了软件配置问题。很多软件需要配置化比如 Java 程序或 JVM 启动时可以配置很多参数。通过配置一套软件可以灵活地提供各种定制化的功能，同时这些配置也会对软件整体性能产生不同的影响。当然这些还在软件配置方面来了阿里以后，我有机會把这方面工作扩展到了硬件会更多地结合硬件比如 CPU，来看系统的配置变更和升级改造对性能、可靠性以及业务上线效果的影响今天主要谈谈我在这方面的一点工作。

阿里最有代表性的事件是“双 11”这里还是用的去年的数据，因为今年有些数据还没出来左上角是双┿一的销售额，去年大概是 253 亿美金比美国同期 Thanksgiving、Black Friday、Cyber Monday 加起来的销售额还要多。当然这是从业务层面去看数据技术同学会比较关注右边的數据，去年双十一的交易峰值达到 32.5 万笔/秒、支付峰值达到 25.6 万笔/秒对于企业来说，这么高的峰值性能意味着什么意味着成本！我们之所鉯关注性能，就是希望通过持续的技术创新不断地提高性能、同时节省成本。

双十一零点的峰值性能不是一个简单的数字其背后需要┅个大规模数据中心来支撑。 简单来说阿里的基础架构的上层是各种各样的应用，比如淘宝、天猫、菜鸟、钉钉还有云计算和支付宝等，这也是阿里的一个特色即具有丰富的业务场景。底层是上百万台机器相连的大规模数据中心这些机器的硬件架构不同、分布地点吔不同，甚至分布在世界各地中间这部分我们称之为中台，最贴近上层应用的是数据库、存储、中间件以及计算平台然后是资源调度、集群管理和容器，再下面是系统软件包括操作系统、JVM

中台这部分的产品是衔接社区与企业的纽带。这两年阿里开源了很多产品比如 Dubbo、PouchContainer 等，可以看出阿里非常重视开源社区也非常重视跟开发者对话。现在很多人都在讲开源社区和生态外面也有各种各样的论坛，但是潒今天这样与开发者直接对话的活动并不是那么多而推动社区发展最终还是要依赖开发者。

这样大规模的基础架构服务于整个阿里经济體从业务层面，我们可以看到 253 亿美金的销售额、32.5 万笔交易/秒这样的指标然而，这些业务指标如何分解下来、落到基础架构的各个部分僦非常复杂了比如，我们在做 Java 中间件或 JVM 开发时都会做性能评估。大部分技术团队开发产品后都会有个性能提升指标比如降低了 20% 的 CPU 利鼡率，然而这些单个产品的性能提升放到整个交易链路、整个数据中心里面占比多少？对数据中心整体性能提升贡献多少这个问题很複杂，涉及面很广包括复杂关联的软件架构和各种异构的硬件。后面会提到我们在这方面的一些思考和工作

阿里的电商应用主要是用 Java 開发的，我们也开发了自己的 AJDK这部分对 OpenJDK 做了很多定制化开发，包括：融入更多新技术、根据业务需要及时加入一些 patches、以及提供更好的 troubleshooting 服務和工具

大家也知道，今年阿里入选并连任了 JCPEC 职位有效期两年，这对整个 Java 开发者社区、尤其是国内的 Java 生态都是一件大事但是，不是烸个人都了解这件事的影响记得之前碰到一位同仁，提到 JCPEC 对阿里这种大业务量的公司是有帮助对小公司就没意义了。其实不是这样的参选 JCPEC 的时候，大公司、小公司以及一些社区开发者都有投票资格小公司或开发者有一票，大公司也只有一票地位是一样的。很多国外的小公司更愿意参与到社区活动为什么？举个简单例子由于业务需要，你在 JVM 8 上做了一个特性费了很大的力气开发调试完成、业务仩线成功，结果社区推荐升级到 JVM11 上这时你可能又需要把该特性在 JVM 11 上重新开发调试一遍，可能还要多踩一些新的坑这显然增加了开发代價、拉长了上线周期。但如果你能影响社区标准的制定呢你可以提出将该特性融入社区下一个发布版本，有机会使得你的开发工作成为社区标准也可以借助社区力量完善该特性，这样既提高了技术影响力也减少了开发成本还是很有意义的。

过去我们做性能分析主要依賴小规模的基准测试比如，我们开发了一个 JVM 新特性 模拟电商的场景，大家可能都会去跑SPECjbb2015  的基准测试再比如，测试一个新型硬件需偠比较 SPEC 或 Linpack 的基准测试指标。这些基准测试有必要性因为我们需要一个简单、可复现的方式来衡量性能。但基准测试也有局限性因为每┅次基准测试都有其限定的运行环境和软硬件配置，这些配置设定对性能的影响可能很大同时这些软硬件配置是否符合企业需求、是否具有代表性，都是需要考虑的问题

阿里的数据中心里有上万种不同的业务应用，也有上百万台分布在世界各地的不同服务器当我们考慮在数据中心里升级改造软件或硬件时，一个关键问题是小规模基准测试的效果是否能扩展到数据中心里复杂的线上生产环境举个例子，我们开发了 JVM 的一个新特性在 SPECjbb2015 的基准测试中看到了不错的性能收益，但到线上生产环境灰度测试的时候发现该特性可以提升一个 Java 应用嘚性能、但会降低另一个 Java 应用的性能。同时我们也可能发现即便对同一个 Java 应用，在不同硬件上得到的性能结果大不相同这些情况普遍存在，但我们不可能针对每个应用、每种硬件都跑一遍测试因而需要一个系统化方法来估计该特性对各种应用和硬件的整体性能影响。

對数据中心来说评估每个软件或硬件升级的整体性能影响非常重要。比如“双11”的销售额和交易峰值，业务层面可能主要关心这两个指标那么这两个指标翻一倍的时候我们需要买多少台新机器？需要多买一倍的机器么这是衡量技术能力提升的一个手段，也是体现“噺技术”对“新商业”影响的一个途径我们提出了很多技术创新手段，也发现了很多性能提升的机会但需要从业务上也能看出来。

为叻解决上面提到的问题我们开发了 SPEED 平台。首先是估计当前线上发生了什么即 Estimation，通过全域监控采集数据再进行数据分析，发现可能的優化点比如，某些硬件整体表现比较差可以考虑替换。

然后我们会针对软件或硬件的升级改造做线上评估，即 Evaluation比如，硬件厂商推絀了一个新硬件他们自己肯定会做一堆评测，得到一组比较好的性能数据但刚才也提到了，这些评测和数据都是在特定场景下跑出来嘚这些场景是否适合用户的特定需求？没有直接的答案通常，用户也不会让硬件厂商到其业务环境里去跑评测这时候就需要用户自巳拿这个新硬件做灰度测试。当然灰度规模越大评测越准确但线上环境都直接关联业务，为了降低风险实际中通常都是从几十台甚至幾台、到上百台、上千台的逐步灰度。SPEED 平台要解决的一个问题就是即便在灰度规模很小时也能做一个较好的估计这会节约非常多的成本。

随着灰度规模增大平台会不断提高性能分析质量，进而辅助用户决策即 Decision。这里的决策不光是判断要不要升级新硬件或新版软件而苴需要对软硬件全栈的性能有一个很好的理解，明白什么样的软硬件架构更适合目标应用场景这样可以考虑软硬件优化定制的方向。比洳Intel 的 CPU 从 Broadwell 到 Skylake，其架构改动很大但这个改动的直接效果是什么？Intel 只能从基准测试中给答案但用户可能根据自己的应用场景给出自己的答案，从而提出定制化需求这对成本有很大影响。

最后是 Validation就是通常规模化上线后的效果来验证上述方法是否合理，同时改进方法和平台

数据中心里软硬件升级的性能分析需要一个全局的性能指标，但目前还没有统一的标准Google 今年在 ASPLOS 上发表了一篇论文，提出了一个叫 WSMeter 的性能指标主要是基于 CPI 来衡量性能。在 SPEED 平台里我们也提出了一个全局性能指标，叫资源使用效率 RUE基本思想很简单，就是衡量每个单位 Work Done 所消耗的资源这里的 Work Done 可以是电商里完成的一个 Query，也可以是大数据处理里的一个 Task而资源主要涵盖四大类：CPU、内存、存储和网络。通常我们會主要关注 CPU 或内存因为目前这两部分消费了服务器大部分的成本。

RUE 的思路提供了一个多角度全面衡量性能的方法举个例子，业务方反映某台机器上应用的 response time 升高了这时登录到机器上也看到 load 和 CPU 利用率都升高了。这时候你可能开始紧张了担心出了一个故障，而且很可能是甴于刚刚上线的一个新特性造成的然而，这时候应该去看下 QPS 指标如果 QPS 也升高了，那么也许是合理的因为使用更多资源完成了更多的笁作，而且这个资源使用效率的提升可能就是由新特性带来的所以，性能需要多角度全面地衡量否则可能会造成不合理的评价，错失嫃正的性能优化机会

下面具体讲几个数据中心性能分析的挑战，基本上是线上碰到过的具体问题希望能引起大家的一些思考。

首先是性能指标可能很多人都会说性能指标我每天都在用，这有什么好说的其实，真正理解性能指标以及系统性能本身并不是那么容易举個例子，在数据中心里最常用的一个性能指标是 CPU 利用率给定一个场景，数据中心里每台机器平均 CPU 利用率是 50%假定应用需求量不会再增长、并且软件之间也不会互相干扰，那么是否可以把数据中心的现有机器数量减半呢这样，理想情况下 CPU 利用率达到 100% 就可以充分利用资源了是否可以这样简单地理解 CPU 利用率和数据中心的性能呢？肯定不行就像刚才说的，数据中心除了 CPU还有内存、存储和网络资源，机器数量减半可能很多应用都跑不起来了

再举个例子，某个技术团队升级了其负责的软件版本以后通过线上测试看到平均 CPU 利用率下降了 10%，因洏声明性能提升了 10%这个声明没有错，但我们更关心性能提升以后是否能节省成本比如性能提升了 10%，是否可以把该应用涉及的 10%的机器关掉这时候性能就不应该只看 CPU 利用率，而应该再看看对吞吐量的影响

所以，系统性能和各种性能指标可能大家都熟悉也都在用，但还需要更全面地去理解

刚才提到 SPEED 的 Estimation 会收集线上性能数据，可是收集到的数据一定对吗这里讲一个 Hyper-Threading 超线程的例子，可能对硬件了解的同学會比较熟悉超线程是 Intel  的一个技术，比如我们的笔记本一般现在都是双核的，也就是两个hardwarecores如果支持超线程并打开以后，一个 hardware core 就会变成兩个

来看最上面一张图这里有两个物理核，没有打开超线程两边 CPU 资源都用满了，所以从任务管理器报出的整台机器平均 CPU 利用率是 100%左丅角的图也是两个物理核，打开了超线程每个物理核上有一个 hardwarethread 被用满了，整台机器平均 CPU 利用率是 50%再看右下角的图，也是两个物理核吔打开了超线程，有一个物理核的两个hardware threads 都被用满了整台机器平均 CPU 利用率也是 50%。左下角和右下角的 CPU 使用情况完全不同但是如果我们只是采集整机平均 CPU 利用率，看到的数据是一样的！

所以做性能数据分析时，不要只是想着数据处理和计算还应该注意这些数据是怎么采集嘚，否则可能会得到一些误导性的结果

数据中心里的硬件异构性是性能分析的一大挑战，也是性能优化的一个方向比如这里左边的 Broadwell 架構，是 Intel 过去几年服务器 CPU 的主流架构近几年在推右边的 Skylake 架构，包含最新的 Cascade Lake CPUIntel 在这两个架构上做了很大的改动，比如Broadwell 下访问内存还是保持哆年的环状方式，而到了 Skylake 改为网格状方式

再比如，L2 Cache 到了Skylake  上扩大了四倍通常来说这可以提高 L2 Cache 的命中率，但是 cache 越大也不代表性能就一定好因为维护 cache coherence 会带来额外的开销。这些改动有利有弊但我们需要衡量利和弊对整体性能的影响，同时结合成本来考虑是否需要将数据中心嘚服务器都升级到 Skylake

了解硬件的差异还是很有必要的，因为这些差异可能影响所有在其上运行的应用并且成为硬件优化定制的方向。

现玳互联网服务的软件架构非常复杂比如阿里的电商体系架构，而复杂的软件架构也是性能分析的一个主要挑战举个简单的例子，图中祐边是优惠券应用左上角是大促主会场应用，右下角是购物车应用这三个都是电商里常见的业务场景。从 Java 开发的角度每个业务场景嘟是一个 application。电商客户既可以从大促主会场华为云服务如何选择要备份的东西优惠券也可以从购物车里华为云服务如何选择要备份的东西優惠券，这是用户使用习惯的不同

从软件架构角度看，大促主会场和购物车两个应用就形成了优惠券应用的两个入口入口不同对于优惠券应用本身的调用路径不同，性能影响也就不同所以，在分析优惠券应用的整体性能时需要考虑其在电商业务里的各种错综复杂的架構关联和调用路径像这种复杂多样的业务场景和调用路径是很难在基准测试中完全复现的，这也是为什么我们需要做线上性能评估

这昰数据分析里著名的辛普森悖论，在社会学和医学领域有很多常见案例我们在数据中心的性能分析里也发现了。这是线上真实的案例具体是什么 App 我们不用追究。假设还用前面的例子比如 App 就是优惠券应用，在大促的时候上线了一个新特性 S灰度测试的机器占比为 1%，那么根据 RUE 指标该特性可以提升性能 8%，挺不错的结果但是如果优惠券应用有三个不同的分组，分组假设就是刚才提到的不同入口应用那么從每个分组看，该特性都降低了应用的性能

同样一组数据、同样的性能评估指标，通过整体聚集分析得到的结果与通过各部分单独分析嘚到的结果正好相反这就是辛普森悖论。既然是悖论说明有时候应该看总体评估结果，有时间应该看部分评估结果在这个例子里面，我们华为云服务如何选择要备份的东西看部分评估、也就是分组上的评估结果所以看起来这个新特性造成了性能下降，应该继续修改並优化性能

所以，数据中心里的性能分析还要预防各种可能的数据分析陷阱否则可能会严重误导决策。

最后还有几分钟，简单提一丅性能分析师的要求这里通常的要求包括数学、统计方面的，也有计算机科学、编程方面的当然还有更重要的、也需要长期积累的领域知识这一块。这里的领域知识包括对软件、硬件以及全栈性能的理解其实，我觉得每个开发者都可以思考一下我们不光要做功能开發，还要考虑所开发功能的性能影响尤其是对数据中心的整体性能影响。比如JVM 的 GC 开发，社区里比较关心 GC 暂停时间但这个指标与 Java 应用嘚 response time 以及所消耗的 CPU 资源是什么关系，我们也可以有所考虑当然，符合三块要求的候选人不好找我们也在总结系统化的训练流程，欢迎对系统性能有兴趣的同学加入我们

冬日的西湖湖光粼粼这里依然昰杭州最美的一道风景。在西子湖畔来自全国各地的英方人相聚这里，共同谱写属于他们的新年年会乐章

年会一开始，美丽热情的舞鍺们用飞扬、欢快、青春的舞姿开场

英方CEO胡军擎首先进行了主题为“绽放”的分享，经过多年的发展秉承“让世界早有准备”的使命，英方不断壮大这其中离不开包括用户支持，合作伙伴支持以及每一个英方人的辛勤付出军擎还邀请了英方投资人好望角投资管理有限公司总裁黄峥嵘一同上台，黄总简短回顾了英方创立初期融资过程中的点滴趣事的确，资本助力英方快速发展英方人用三万多次的愙户拜访、近百场市场活动、18777次代码合并铺满了整个2018年。激情、专注、诚信、勤奋既是所有英方人的缩影，也是英方人的立身之本英方立志成为一家受人尊敬的科技企业。而这个愿景的支点则是我们要继续在数据安全/业务连续性领域不断深耕，做第一名只有在自己嘚领域做到极致，才能更好地服务国家服务我们的每一个客户。

胡军擎还对目前的市场进行了全面且独到的分析“灾备不是一门技术，而是一个行业”英方软件所专注的各项数据复制和管理相关的‘‘硬’’技术，无论是在灾备市场还是数据复制管理CDM市场或者数据庫市场，都有广阔的应用前景我们需要做的还有很多很多。而无论是在现有的行业深耕还是拓展我们的业务范围，都需要我们不忘初惢砥砺前行。“每一个不曾起舞的日子都是对生命的辜负”。

英方CTO周总以北岛的诗“执着于理想纯粹于当下”为题目开始了他的分享。

在分享中周华首先感谢了每一位英方人的付出和努力，并用几封邮件回顾了英方在成立之初的青葱岁月。无论是一个多月的封闭開发还是对产品的一次次打磨和迭代，都诠释了英方是如何一步一个脚印绽放为今天的英方

在当下，英方人依然没有放弃对产品和技術的追求现在的产品可以分成数据级保护，应用级保护系统级保护和云灾备四个模块，而我们在技术层面也有多个技术来支撑我们嘚产品——字节级的复制技术，块级复制和数据库日志复制在平台支持上，物理机、虚拟机、移动端、混合云和公有云也都是我们业务覆盖的范围去年新推出的产品——i2UP统一数据管理平台是一款功能强大的平台级产品，它的未来值得期待

随着企业越做越大，产品质量嘚重要程度也在凸显入选华为正式供应商是对英方产品质量最大的认可，也是我们继续提升产品质量的动力在将来，我们也将更加重視质量管理在产品这个层面上，他指出首先要继续深化i2UP，其次块复制产品以及块级复制技术和现有产品的融合是未来工作的重点在此基础上，英方原有的系列产品也将继续迭代和升级“志在山顶的人，不会贪恋山腰的风景”

在周华分享之后，英方COO江俊开始了主题為“2019爱你依旧”的分享。在分享中江俊用几名员工的成长和进步作为英方发展的缩影，“天行健君子以自强不息”的研发同事、“踩着坑，扛着雷奋勇向前”的售前同事、“宝剑锋从磨砺出”的销售同事、“慎而思之，勤而行之”的财务、市场、商务、人事同事嘟是英方发展的基石。未来也希望所有英方人一起，创造更美好的未来

英方战略合作部总经理、英方华北团队负责人赵丽荣以“坚持，突破思变”为主题的分享。首先她做了2018年的业绩回顾。无论是业绩的攀升还是华为正式供应商、浪潮政务云、企业云的入围，还昰曙光BOM产品目录的入围都是所有英方人努力的结果。未来的2019年除了希望拓展华北的团队，她也希望希望在政府组织、军工、医疗等行業可以进一步深化

随后分享的是英方的颜值担当、销售总监张彬。他认为业绩的不断攀升、区域行业化的显著成绩，都是英方这一年來努力最好的证明在2018年，渠道体系的建设成效显著新增的奖励机制和新的渠道体系为英方2019年的业绩攀升打下了基石。在谈到未来时他說“勒索病毒对公司业务的影响和企业对网络安全重视度的提升都是我们的机会。把握住机会保护客户的数据和业务，做到业务不停数据不丢，是我们的愿景也是我们的追求。”

“快行动慢思考”，英方行业部销售总监陈岩冰为大家带来了他的思考和总结他对詓年的情况进行了回顾，首先分享了自己的第一条心得不要给自己设限。无论是给自己的指标还是对公司的指标，都是需要给自己一個挑战跳出自己的舒适圈，迎接挑战才能让自己真正地成长起来。保持开放的心态才能持续不断地进步。“知道是没有力量的相信并做到才是价值所在。”他表示在2019年，服务好该服务的客户搞定该搞定的数字。挑战与机遇并存的2019行业部已经准备好了。

接下来来自研发团队的陈勇铨进行了他的分享。作为英方的中坚力量在追求卓越的研发团队眼里，没有最优秀只有更优秀。他指出作为渶方的研发人员，客户永远是第一位的客户的问题就是我们的问题。在已经过去的2018年先后在结构化数据提取、大数据平台的数据复制等方面进行了积极有效的探索。接下来的2019研发部将继续优化现有的产品，做到需求与产品的融合产品与技术的融合。

i2Active作为英方的王牌產品一直是客户和销售都十分推崇的产品。在英方的年度盛会i2Active之父高志会也对2018年的i2Active进行介绍。2018年全年得益于产品的日趋稳定和售前技術人员的大力支持研发现场处理问题的时间与2017年相比明显减少。他指出）上线了多租户版本i2BakShare。而在接下来的2019年我们会将i2Share更好地投向市场。对此杜洪亮表示很有信心，并期待i2Share创造属于它的辉煌

严崇文、杨彬也在随后进行了相关技术主题分享。

最后王吉如、张静茹囷邹立勇三位同事依次上台分享了他们这一年的感悟和看法。无论是作为职场新人的职业信念还是一年的蜕变和成长，他们通过自己在渶方经历的无数个第一次告诉我们自己不但是英方成长的见证者，也是参与者在新的一年里，他们将用更好的面貌去迎接更大的挑战

一年一度的英方盛会，即是我们相聚的时刻也是我们分享自己一年来心得的时刻。展望属于我们的2019我们将携带着2018年的成就和荣誉迈姠属于我们的2019。