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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在 SPEED 平臺里，我們也提出了一個全局性能指標，叫資源使用效率 RUE?；舅枷牒芎唵危褪呛饬棵總€單位 Work Done 所消耗的資源。這里的 Work Done 可以是電商里完成的一個 Query，也可以是處理里的一個 Task。而資源主要涵蓋四大類：CPU、內存、存儲和網絡。通常我們會主要關注 CPU 或內存，因為目前這兩部分消費了服務器大部分的成本。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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