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

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

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

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

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

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

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

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

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

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

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

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

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

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

這些基準(zhǔn)測試有必要性，因為我們需要一個簡單、可復(fù)現(xiàn)的方式來衡量性能。但基準(zhǔn)測試也有局限性，因為每一次基準(zhǔn)測試都有其限定的運行環(huán)境和軟硬件配置，這些配置設(shè)定對性能的影響可能很大，同時這些軟硬件配置是否符合企業(yè)需求、是否具有代表性，都是需要考慮的問題。

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

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

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

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

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

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

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

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

最后是 Validation，就是通常規(guī)模化上線后的效果來驗證上述方法是否合理，同時改進方法和平臺。

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

在 SPEED 平臺里，我們也提出了一個全局性能指標(biāo)，叫資源使用效率 RUE?；舅枷牒芎唵?，就是衡量每個單位 Work Done 所消耗的資源。這里的 Work Done 可以是電商里完成的一個 Query，也可以是處理里的一個 Task。而資源主要涵蓋四大類：CPU、內(nèi)存、存儲和網(wǎng)絡(luò)。通常我們會主要關(guān)注 CPU 或內(nèi)存，因為目前這兩部分消費了服務(wù)器大部分的成本。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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