大家好，很高興有機(jī)會(huì)與 Java 社區(qū)的開發(fā)者交流。我的研究領(lǐng)域在軟件工程，主要集中在系統(tǒng)配置和性能方面。軟件工程一個(gè)比較常見的活動(dòng)是找 bug，當(dāng)然找 bug 很重要，但后來也發(fā)現(xiàn)，即便 bug-free 的程序也會(huì)被人配置錯(cuò)，所以就衍生出了軟件配置問題。

很多軟件需要配置化，比如 Java 程序或 JVM 啟動(dòng)時(shí)可以配置很多參數(shù)。通過配置，一套軟件可以靈活地提供各種定制化的功能，同時(shí)，這些配置也會(huì)對(duì)軟件整體性能產(chǎn)生不同的影響。當(dāng)然這些還在軟件配置方面，來了阿里以后，我有機(jī)會(huì)把這方面工作擴(kuò)展到了硬件，會(huì)更多地結(jié)合硬件比如 CPU，來看系統(tǒng)的配置變更和升級(jí)改造對(duì)性能、可靠性以及業(yè)務(wù)上線效果的影響。今天主要談?wù)勎以谶@方面的一點(diǎn)工作。

阿里最有代表性的事件是“雙 11”。這里還是用的17年的數(shù)據(jù)，左上角是雙十一的銷售額，17年大概是 253 億美金，比美國同期 Thanksgiving、Black Friday、Cyber Monday 加起來的銷售額還要多。

當(dāng)然這是從業(yè)務(wù)層面去看數(shù)據(jù)，技術(shù)同學(xué)會(huì)比較關(guān)注右邊的數(shù)據(jù)，17年雙十一的交易峰值達(dá)到 32.5 萬筆/秒、支付峰值達(dá)到 25.6 萬筆/秒。對(duì)于企業(yè)來說，這么高的峰值性能意味著什么?意味著成本!我們之所以關(guān)注性能，就是希望通過持續(xù)的技術(shù)創(chuàng)新，不斷地提高性能、同時(shí)節(jié)省成本。

雙十一零點(diǎn)的峰值性能不是一個(gè)簡單的數(shù)字，其背后需要一個(gè)大規(guī)模來支撐。 簡單來說，阿里的基礎(chǔ)架構(gòu)的上層是各種各樣的應(yīng)用，比如淘寶、天貓、菜鳥、釘釘，還有和支付寶等，這也是阿里的一個(gè)特色，即具有豐富的業(yè)務(wù)場(chǎng)景。

底層是上百萬臺(tái)機(jī)器相連的大規(guī)模數(shù)據(jù)中心，這些機(jī)器的硬件架構(gòu)不同、分布地點(diǎn)也不同，甚至分布在世界各地。中間這部分我們稱之為中臺(tái)，最貼近上層應(yīng)用的是數(shù)據(jù)庫、存儲(chǔ)、中間件以及計(jì)算平臺(tái)，然后是資源調(diào)度、集群管理和容器，再下面是系統(tǒng)軟件，包括操作系統(tǒng)、JVM 和虛擬化等。

中臺(tái)這部分的產(chǎn)品是銜接社區(qū)與企業(yè)的紐帶。這兩年阿里開源了很多產(chǎn)品，比如 Dubbo、PouchContainer 等，可以看出阿里非常重視開源社區(qū)，也非常重視跟開發(fā)者對(duì)話?，F(xiàn)在很多人都在講開源社區(qū)和生態(tài)，外面也有各種各樣的論壇，但是像今天這樣與開發(fā)者直接對(duì)話的活動(dòng)并不是那么多，而推動(dòng)社區(qū)發(fā)展最終還是要依賴開發(fā)者。

這樣大規(guī)模的基礎(chǔ)架構(gòu)服務(wù)于整個(gè)阿里經(jīng)濟(jì)體。從業(yè)務(wù)層面，我們可以看到 253 億美金的銷售額、32.5 萬筆交易/秒這樣的指標(biāo)。然而，這些業(yè)務(wù)指標(biāo)如何分解下來、落到基礎(chǔ)架構(gòu)的各個(gè)部分就非常復(fù)雜了。比如，我們?cè)谧?Java 中間件或 JVM 開發(fā)時(shí)，都會(huì)做性能評(píng)估。

大部分技術(shù)團(tuán)隊(duì)開發(fā)產(chǎn)品后都會(huì)有個(gè)性能提升指標(biāo)，比如降低了 20% 的 CPU 利用率，然而這些單個(gè)產(chǎn)品的性能提升放到整個(gè)交易鏈路、整個(gè)數(shù)據(jù)中心里面，占比多少?對(duì)數(shù)據(jù)中心整體性能提升貢獻(xiàn)多少?這個(gè)問題很復(fù)雜，涉及面很廣，包括復(fù)雜關(guān)聯(lián)的軟件架構(gòu)和各種異構(gòu)的硬件。后面會(huì)提到我們?cè)谶@方面的一些思考和工作。

阿里的電商應(yīng)用主要是用 Java 開發(fā)的，我們也開發(fā)了自己的 AJDK，這部分對(duì) OpenJDK 做了很多定制化開發(fā)，包括：融入更多新技術(shù)、根據(jù)業(yè)務(wù)需要及時(shí)加入一些 patches、以及提供更好的 troubleshooting 服務(wù)和工具。

大家也知道，18年阿里入選并連任了 JCP EC(Java Community Process – Executive Committee) 職位，有效期兩年，這對(duì)整個(gè) Java 開發(fā)者社區(qū)、尤其是國內(nèi)的 Java 生態(tài)都是一件大事。但是，不是每個(gè)人都了解這件事的影響。記得之前碰到一位同仁，提到 JCP EC 對(duì)阿里這種大業(yè)務(wù)量的公司是有幫助，對(duì)小公司就沒意義了。

其實(shí)不是這樣的，參選 JCP EC 的時(shí)候，大公司、小公司以及一些社區(qū)開發(fā)者都有投票資格，小公司或開發(fā)者有一票，大公司也只有一票，地位是一樣的。很多國外的小公司更愿意參與到社區(qū)活動(dòng)，為什么?

舉個(gè)簡單例子，由于業(yè)務(wù)需要，你在 JVM 8 上做了一個(gè)特性，費(fèi)了很大的力氣開發(fā)調(diào)試完成、業(yè)務(wù)上線成功，結(jié)果社區(qū)推薦升級(jí)到 JVM11 上，這時(shí)你可能又需要把該特性在 JVM 11 上重新開發(fā)調(diào)試一遍，可能還要多踩一些新的坑，這顯然增加了開發(fā)代價(jià)、拉長了上線周期。但如果你能影響社區(qū)標(biāo)準(zhǔn)的制定呢?你可以提出將該特性融入社區(qū)下一個(gè)發(fā)布版本，有機(jī)會(huì)使得你的開發(fā)工作成為社區(qū)標(biāo)準(zhǔn)，也可以借助社區(qū)力量完善該特性，這樣既提高了技術(shù)影響力也減少了開發(fā)成本，還是很有意義的。

過去我們做性能分析主要依賴小規(guī)模的基準(zhǔn)測(cè)試。比如，我們開發(fā)了一個(gè) JVM 新特性， 模擬電商的場(chǎng)景，大家可能都會(huì)去跑 SPECjbb2015 的基準(zhǔn)測(cè)試。再比如，測(cè)試一個(gè)新型硬件，需要比較 SPEC 或 Linpack 的基準(zhǔn)測(cè)試指標(biāo)。

這些基準(zhǔn)測(cè)試有必要性，因?yàn)槲覀冃枰粋€(gè)簡單、可復(fù)現(xiàn)的方式來衡量性能。但基準(zhǔn)測(cè)試也有局限性，因?yàn)槊恳淮位鶞?zhǔn)測(cè)試都有其限定的運(yùn)行環(huán)境和軟硬件配置，這些配置設(shè)定對(duì)性能的影響可能很大，同時(shí)這些軟硬件配置是否符合企業(yè)需求、是否具有代表性，都是需要考慮的問題。

阿里的數(shù)據(jù)中心里有上萬種不同的業(yè)務(wù)應(yīng)用，也有上百萬臺(tái)分布在世界各地的不同服務(wù)器。當(dāng)我們考慮在數(shù)據(jù)中心里升級(jí)改造軟件或硬件時(shí)，一個(gè)關(guān)鍵問題是小規(guī)模基準(zhǔn)測(cè)試的效果是否能擴(kuò)展到數(shù)據(jù)中心里復(fù)雜的線上生產(chǎn)環(huán)境?

舉個(gè)例子，我們開發(fā)了 JVM 的一個(gè)新特性，在 SPECjbb2015 的基準(zhǔn)測(cè)試中看到了不錯(cuò)的性能收益，但到線上生產(chǎn)環(huán)境灰度測(cè)試的時(shí)候，發(fā)現(xiàn)該特性可以提升一個(gè) Java 應(yīng)用的性能、但會(huì)降低另一個(gè) Java 應(yīng)用的性能。同時(shí)，我們也可能發(fā)現(xiàn)即便對(duì)同一個(gè) Java 應(yīng)用，在不同硬件上得到的性能結(jié)果大不相同。這些情況普遍存在，但我們不可能針對(duì)每個(gè)應(yīng)用、每種硬件都跑一遍測(cè)試，因而需要一個(gè)系統(tǒng)化方法來估計(jì)該特性對(duì)各種應(yīng)用和硬件的整體性能影響。

對(duì)數(shù)據(jù)中心來說，評(píng)估每個(gè)軟件或硬件升級(jí)的整體性能影響非常重要。比如，“雙11”的銷售額和交易峰值，業(yè)務(wù)層面可能主要關(guān)心這兩個(gè)指標(biāo)，那么這兩個(gè)指標(biāo)翻一倍的時(shí)候我們需要買多少臺(tái)新機(jī)器?需要多買一倍的機(jī)器么?這是衡量技術(shù)能力提升的一個(gè)手段，也是體現(xiàn)“新技術(shù)”對(duì)“新商業(yè)”影響的一個(gè)途徑。我們提出了很多技術(shù)創(chuàng)新手段，也發(fā)現(xiàn)了很多性能提升的機(jī)會(huì)，但需要從業(yè)務(wù)上也能看出來。

為了解決上面提到的問題，我們開發(fā)了 SPEED 平臺(tái)。首先是估計(jì)當(dāng)前線上發(fā)生了什么，即 Estimation，通過全域監(jiān)控采集數(shù)據(jù)，再進(jìn)行數(shù)據(jù)分析，發(fā)現(xiàn)可能的優(yōu)化點(diǎn)。比如，某些硬件整體表現(xiàn)比較差，可以考慮替換。

然后，我們會(huì)針對(duì)軟件或硬件的升級(jí)改造做線上評(píng)估，即 Evaluation。比如，硬件廠商推出了一個(gè)新硬件，他們自己肯定會(huì)做一堆評(píng)測(cè)，得到一組比較好的性能數(shù)據(jù)，但剛才也提到了，這些評(píng)測(cè)和數(shù)據(jù)都是在特定場(chǎng)景下跑出來的，這些場(chǎng)景是否適合用戶的特定需求?

沒有直接的答案。通常，用戶也不會(huì)讓硬件廠商到其業(yè)務(wù)環(huán)境里去跑評(píng)測(cè)。這時(shí)候就需要用戶自己拿這個(gè)新硬件做灰度測(cè)試。當(dāng)然灰度規(guī)模越大評(píng)測(cè)越準(zhǔn)確，但線上環(huán)境都直接關(guān)聯(lián)業(yè)務(wù)，為了降低風(fēng)險(xiǎn)，實(shí)際中通常都是從幾十臺(tái)甚至幾臺(tái)、到上百臺(tái)、上千臺(tái)的逐步灰度。SPEED 平臺(tái)要解決的一個(gè)問題就是即便在灰度規(guī)模很小時(shí)也能做一個(gè)較好的估計(jì)，這會(huì)節(jié)約非常多的成本。

隨著灰度規(guī)模增大，平臺(tái)會(huì)不斷提高性能分析質(zhì)量，進(jìn)而輔助用戶決策，即 Decision。這里的決策不光是判斷要不要升級(jí)新硬件或新版軟件，而且需要對(duì)軟硬件全棧的性能有一個(gè)很好的理解，明白什么樣的軟硬件架構(gòu)更適合目標(biāo)應(yīng)用場(chǎng)景，這樣可以考慮軟硬件優(yōu)化定制的方向。

比如，Intel 的 CPU 從 Broadwell 到 Skylake，其架構(gòu)改動(dòng)很大，但這個(gè)改動(dòng)的直接效果是什么?Intel 只能從基準(zhǔn)測(cè)試中給答案，但用戶可能根據(jù)自己的應(yīng)用場(chǎng)景給出自己的答案，從而提出定制化需求，這對(duì)成本有很大影響。

最后是 Validation，就是通常規(guī)?；暇€后的效果來驗(yàn)證上述方法是否合理，同時(shí)改進(jìn)方法和平臺(tái)。

數(shù)據(jù)中心里軟硬件升級(jí)的性能分析需要一個(gè)全局的性能指標(biāo)，但目前還沒有統(tǒng)一的標(biāo)準(zhǔn)。Google 今年在 ASPLOS 上發(fā)表了一篇論文，提出了一個(gè)叫 WSMeter 的性能指標(biāo)，主要是基于 CPI 來衡量性能。

在 SPEED 平臺(tái)里，我們也提出了一個(gè)全局性能指標(biāo)，叫資源使用效率 RUE。基本思想很簡單，就是衡量每個(gè)單位 Work Done 所消耗的資源。這里的 Work Done 可以是電商里完成的一個(gè) Query，也可以是處理里的一個(gè) Task。而資源主要涵蓋四大類：CPU、內(nèi)存、存儲(chǔ)和網(wǎng)絡(luò)。通常我們會(huì)主要關(guān)注 CPU 或內(nèi)存，因?yàn)槟壳斑@兩部分消費(fèi)了服務(wù)器大部分的成本。

RUE 的思路提供了一個(gè)多角度全面衡量性能的方法。舉個(gè)例子，業(yè)務(wù)方反映某臺(tái)機(jī)器上應(yīng)用的 response time 升高了，這時(shí)登錄到機(jī)器上也看到 load 和 CPU 利用率都升高了。這時(shí)候你可能開始緊張了，擔(dān)心出了一個(gè)故障，而且很可能是由于剛剛上線的一個(gè)新特性造成的。

然而，這時(shí)候應(yīng)該去看下 QPS 指標(biāo)，如果 QPS 也升高了，那么也許是合理的，因?yàn)槭褂酶噘Y源完成了更多的工作，而且這個(gè)資源使用效率的提升可能就是由新特性帶來的。所以，性能需要多角度全面地衡量，否則可能會(huì)造成不合理的評(píng)價(jià)，錯(cuò)失真正的性能優(yōu)化機(jī)會(huì)。

下面具體講幾個(gè)數(shù)據(jù)中心性能分析的挑戰(zhàn)，基本上是線上碰到過的具體問題，希望能引起大家的一些思考。

首先是性能指標(biāo)。可能很多人都會(huì)說性能指標(biāo)我每天都在用，這有什么好說的。其實(shí)，真正理解性能指標(biāo)以及系統(tǒng)性能本身并不是那么容易。舉個(gè)例子，在數(shù)據(jù)中心里最常用的一個(gè)性能指標(biāo)是 CPU 利用率，給定一個(gè)場(chǎng)景，數(shù)據(jù)中心里每臺(tái)機(jī)器平均 CPU 利用率是 50%，假定應(yīng)用需求量不會(huì)再增長、并且軟件之間也不會(huì)互相干擾，那么是否可以把數(shù)據(jù)中心的現(xiàn)有機(jī)器數(shù)量減半呢?

這樣，理想情況下 CPU 利用率達(dá)到 100% 就可以充分利用資源了，是否可以這樣簡單地理解 CPU 利用率和數(shù)據(jù)中心的性能呢?肯定不行。就像剛才說的，數(shù)據(jù)中心除了 CPU，還有內(nèi)存、存儲(chǔ)和網(wǎng)絡(luò)資源，機(jī)器數(shù)量減半可能很多應(yīng)用都跑不起來了。

再舉個(gè)例子，某個(gè)技術(shù)團(tuán)隊(duì)升級(jí)了其負(fù)責(zé)的軟件版本以后，通過線上測(cè)試看到平均 CPU 利用率下降了 10%，因而聲明性能提升了 10%。這個(gè)聲明沒有錯(cuò)，但我們更關(guān)心性能提升以后是否能節(jié)省成本，比如性能提升了 10%，是否可以把該應(yīng)用涉及的 10% 的機(jī)器關(guān)掉?這時(shí)候性能就不應(yīng)該只看 CPU 利用率，而應(yīng)該再看看對(duì)吞吐量的影響。

所以，系統(tǒng)性能和各種性能指標(biāo)，可能大家都熟悉也都在用，但還需要更全面地去理解。

剛才提到 SPEED 的 Estimation 會(huì)收集線上性能數(shù)據(jù)，可是收集到的數(shù)據(jù)一定對(duì)嗎?這里講一個(gè) Hyper-Threading 超線程的例子，可能對(duì)硬件了解的同學(xué)會(huì)比較熟悉。超線程是 Intel 的一個(gè)技術(shù)，比如我們的筆記本，一般現(xiàn)在都是雙核的，也就是兩個(gè) hardware cores，如果支持超線程并打開以后，一個(gè) hardware core 就會(huì)變成兩個(gè) hardware threads，即一臺(tái)雙核的機(jī)器會(huì)有四個(gè)邏輯 CPU。

來看最上面一張圖，這里有兩個(gè)物理核，沒有打開超線程，兩邊 CPU 資源都用滿了，所以從任務(wù)管理器報(bào)出的整臺(tái)機(jī)器平均 CPU 利用率是 100%。左下角的圖也是兩個(gè)物理核，打開了超線程，每個(gè)物理核上有一個(gè) hardware thread 被用滿了，整臺(tái)機(jī)器平均 CPU 利用率是 50%。

再看右下角的圖，也是兩個(gè)物理核，也打開了超線程，有一個(gè)物理核的兩個(gè)hardware threads 都被用滿了，整臺(tái)機(jī)器平均 CPU 利用率也是 50%。左下角和右下角的 CPU 使用情況完全不同，但是如果我們只是采集整機(jī)平均 CPU 利用率，看到的數(shù)據(jù)是一樣的!

所以，做性能數(shù)據(jù)分析時(shí)，不要只是想著數(shù)據(jù)處理和計(jì)算，還應(yīng)該注意這些數(shù)據(jù)是怎么采集的，否則可能會(huì)得到一些誤導(dǎo)性的結(jié)果。

數(shù)據(jù)中心里的硬件異構(gòu)性是性能分析的一大挑戰(zhàn)，也是性能優(yōu)化的一個(gè)方向。比如這里左邊的 Broadwell 架構(gòu)，是 Intel 過去幾年服務(wù)器 CPU 的主流架構(gòu)，近幾年在推右邊的 Skylake 架構(gòu)，包含最新的 Cascade Lake CPU。Intel 在這兩個(gè)架構(gòu)上做了很大的改動(dòng)，比如，Broadwell 下訪問內(nèi)存還是保持多年的環(huán)狀方式，而到了 Skylake 改為網(wǎng)格狀方式。

再比如，L2 Cache 到了Skylake 上擴(kuò)大了四倍，通常來說這可以提高 L2 Cache 的命中率，但是 cache 越大也不代表性能就一定好，因?yàn)榫S護(hù) cache coherence 會(huì)帶來額外的開銷。這些改動(dòng)有利有弊，但我們需要衡量利和弊對(duì)整體性能的影響，同時(shí)結(jié)合成本來考慮是否需要將數(shù)據(jù)中心的服務(wù)器都升級(jí)到 Skylake。

了解硬件的差異還是很有必要的，因?yàn)檫@些差異可能影響所有在其上運(yùn)行的應(yīng)用，并且成為硬件優(yōu)化定制的方向。

現(xiàn)代互聯(lián)網(wǎng)服務(wù)的軟件架構(gòu)非常復(fù)雜，比如阿里的電商體系架構(gòu)，而復(fù)雜的軟件架構(gòu)也是性能分析的一個(gè)主要挑戰(zhàn)。舉個(gè)簡單的例子，圖中右邊是優(yōu)惠券應(yīng)用，左上角是大促主會(huì)場(chǎng)應(yīng)用，左下角是購物車應(yīng)用，這三個(gè)都是電商里常見的業(yè)務(wù)場(chǎng)景。從 Java 開發(fā)的角度，每個(gè)業(yè)務(wù)場(chǎng)景都是一個(gè) application。電商客戶既可以從大促主會(huì)場(chǎng)選擇優(yōu)惠券，也可以從購物車?yán)镞x擇優(yōu)惠券，這是用戶使用習(xí)慣的不同。

從軟件架構(gòu)角度看，大促主會(huì)場(chǎng)和購物車兩個(gè)應(yīng)用就形成了優(yōu)惠券應(yīng)用的兩個(gè)入口，入口不同對(duì)于優(yōu)惠券應(yīng)用本身的調(diào)用路徑不同，性能影響也就不同。

所以，在分析優(yōu)惠券應(yīng)用的整體性能時(shí)需要考慮其在電商業(yè)務(wù)里的各種錯(cuò)綜復(fù)雜的架構(gòu)關(guān)聯(lián)和調(diào)用路徑。像這種復(fù)雜多樣的業(yè)務(wù)場(chǎng)景和調(diào)用路徑是很難在基準(zhǔn)測(cè)試中完全復(fù)現(xiàn)的，這也是為什么我們需要做線上性能評(píng)估。

這是數(shù)據(jù)分析里著名的辛普森悖論，在社會(huì)學(xué)和醫(yī)學(xué)領(lǐng)域有很多常見案例，我們?cè)跀?shù)據(jù)中心的性能分析里也發(fā)現(xiàn)了。這是線上真實(shí)的案例，具體是什么 App 我們不用追究。

假設(shè)還用前面的例子，比如 App 就是優(yōu)惠券應(yīng)用，在大促的時(shí)候上線了一個(gè)新特性 S，灰度測(cè)試的機(jī)器占比為 1%，那么根據(jù) RUE 指標(biāo)，該特性可以提升性能 8%，挺不錯(cuò)的結(jié)果。但是如果優(yōu)惠券應(yīng)用有三個(gè)不同的分組，分組假設(shè)就是關(guān)聯(lián)剛才提到的不同入口應(yīng)用，那么從每個(gè)分組看，該特性都降低了應(yīng)用的性能。

同樣一組數(shù)據(jù)、同樣的性能評(píng)估指標(biāo)，通過整體聚集分析得到的結(jié)果與通過各部分單獨(dú)分析得到的結(jié)果正好相反，這就是辛普森悖論。既然是悖論，說明有時(shí)候應(yīng)該看總體評(píng)估結(jié)果，有時(shí)間應(yīng)該看部分評(píng)估結(jié)果。在這個(gè)例子里面，我們選擇看部分評(píng)估、也就是分組上的評(píng)估結(jié)果，所以看起來這個(gè)新特性造成了性能下降，應(yīng)該繼續(xù)修改并優(yōu)化性能。

所以，數(shù)據(jù)中心里的性能分析還要預(yù)防各種可能的數(shù)據(jù)分析陷阱，否則可能會(huì)嚴(yán)重誤導(dǎo)決策。

最后，還有幾分鐘，簡單提一下性能分析師的要求。這里通常的要求包括數(shù)學(xué)、統(tǒng)計(jì)方面的，也有計(jì)算機(jī)科學(xué)、編程方面的，當(dāng)然還有更重要的、也需要長期積累的領(lǐng)域知識(shí)這一塊。這里的領(lǐng)域知識(shí)包括對(duì)軟件、硬件以及全棧性能的理解。

其實(shí)，我覺得每個(gè)開發(fā)者都可以思考一下，我們不光要做功能開發(fā)，還要考慮所開發(fā)功能的性能影響，尤其是對(duì)數(shù)據(jù)中心的整體性能影響。比如，JVM 的 GC 開發(fā)，社區(qū)里比較關(guān)心 GC 暫停時(shí)間，但這個(gè)指標(biāo)與 Java 應(yīng)用的 response time 以及所消耗的 CPU 資源是什么關(guān)系，我們也可以有所考慮。