每年雙十一，有多少人盼著阿里的系統(tǒng)崩潰？

文末有彩蛋

剛剛的雙十一，天貓的成交額突破 4982 億元，大家都知道，在這背后是阿里巴巴的程序員熬了無(wú)數(shù)個(gè)通宵，不停的對(duì)系統(tǒng)做各種測(cè)試和優(yōu)化才有的成果。

肯定有不少人心里暗暗的想：「哪年雙十一阿里系統(tǒng)可以崩潰一次？看看有什么影響？」（如果你也這么想，請(qǐng)?jiān)谠u(píng)論處寫?“1”）

就像11月5日那天的大斷電一樣，如果再遭遇人為的高等級(jí)破壞，是否還能用非常短的時(shí)間讓災(zāi)備系統(tǒng)自主啟動(dòng)，讓一切服務(wù)快速重啟。會(huì)不會(huì)出現(xiàn)系統(tǒng)癱瘓，商家無(wú)法補(bǔ)貨，用戶不能下單等狀況？

一個(gè)成熟的系統(tǒng)應(yīng)該有兩個(gè)階段，從 0 到 1 是「攻城」階段，在市場(chǎng)或業(yè)務(wù)上完成突破，搶得一席之地；從 0 到 100 則是「守城」階段，如何規(guī)劃，如何迭代，如何優(yōu)化，如何保護(hù)，都是影響成敗的大問(wèn)題。

這里我們可以脫離具體技術(shù)和代碼，講講性能測(cè)試和不該出現(xiàn)的「反模式」。

在有些程序員眼里，優(yōu)化程序性能經(jīng)常被視作一種「暗黑藝術(shù)」。

代碼的性能分析往往也存在神秘感，人們常將其看作孤獨(dú)的「專家們」在絞盡腦汁、深思熟慮之后練就的手藝。

事實(shí)上，對(duì)代碼的性能分析是經(jīng)驗(yàn)主義和心理學(xué)的巧妙融合。其重點(diǎn)在于，一方面是可觀測(cè)指標(biāo)的絕對(duì)數(shù)字，另一方面是最終使用者如何看待這些數(shù)字。

所以，如何測(cè)試代碼的性能是個(gè)常見(jiàn)且多變的問(wèn)題了。

比較常見(jiàn)的錯(cuò)誤之一是籠統(tǒng)地談?wù)摗靶阅軠y(cè)試”而不涉及具體內(nèi)容。事實(shí)上，在一個(gè)系統(tǒng)上可以執(zhí)行多種不同類型的大規(guī)模性能測(cè)試。

延遲測(cè)試：終端到終端的交易時(shí)間是多少?

吞吐量測(cè)試：目前的系統(tǒng)容量能處理多少個(gè)并發(fā)交易?

負(fù)載測(cè)試：系統(tǒng)是否能處理某個(gè)特定的負(fù)載?

壓力測(cè)試：系統(tǒng)的臨界點(diǎn)是什么?

耐久性測(cè)試：系統(tǒng)長(zhǎng)期運(yùn)行時(shí)會(huì)發(fā)現(xiàn)哪些性能異?，F(xiàn)象?

容量規(guī)劃測(cè)試：當(dāng)增加額外的資源時(shí)，系統(tǒng)的規(guī)模是否能按預(yù)期擴(kuò)展?

退化測(cè)試：當(dāng)系統(tǒng)發(fā)生部分故障時(shí)會(huì)出現(xiàn)什么情況呢?

PS：好的性能測(cè)試是量化的。它們提出的問(wèn)題可以得到一個(gè)數(shù)字化的答案，用于作為實(shí)驗(yàn)輸出來(lái)處理并進(jìn)行統(tǒng)計(jì)分析。

1. 延遲測(cè)試

這是最常見(jiàn)的性能測(cè)試類型之一，因?yàn)樗ǔＥc管理層直接感興趣的系統(tǒng)觀測(cè)對(duì)象密切相關(guān):我們的客戶等待交易或頁(yè)面加載的時(shí)間有多長(zhǎng)？

這是一把雙刃劍，因?yàn)檠舆t測(cè)試所要回答的量化問(wèn)題似乎非常明顯，以致它可能會(huì)掩蓋識(shí)別其他類型的性能測(cè)試所需要的量化問(wèn)題的必要性。

PS：對(duì)延遲進(jìn)行調(diào)優(yōu)，其目標(biāo)通常是直接改善用戶體驗(yàn)，或者滿足服務(wù)等級(jí)協(xié)議 (SLA)。

然而，即使在最簡(jiǎn)單的情況下，延遲測(cè)試也有一些必須謹(jǐn)慎對(duì)待的微妙之處，其中最值得注意的是，對(duì)于衡量應(yīng)用程序?qū)φ?qǐng)求的響應(yīng)程度而言，簡(jiǎn)單的平均數(shù)并不是很有用。

2. 吞吐量測(cè)試

吞吐量可能是性能測(cè)試時(shí)第二個(gè)常見(jiàn)的觀測(cè)量。在某些意義上，甚至可以將其看作等同于延遲。

例如，當(dāng)進(jìn)行延遲測(cè)試時(shí)，有一點(diǎn)非常重要，即在生成延遲結(jié)果的分布時(shí)，需要說(shuō)明和控制正在進(jìn)行的并發(fā)交易數(shù)。

PS：所觀測(cè)到的系統(tǒng)延遲應(yīng)該在已知和受控的吞吐量水平下給出。

同樣，我們通常在監(jiān)控延遲的同時(shí)進(jìn)行吞吐量測(cè)試，通過(guò)留意延遲分布何時(shí)會(huì)突然發(fā)生變化 —— 實(shí)際上是系統(tǒng)的一個(gè)“臨界點(diǎn)”(也稱為“拐點(diǎn)”)來(lái)判斷“最大吞吐量”。正如我們將看到的，壓力測(cè)試的目的就是確定這樣的點(diǎn)以及它們出現(xiàn)時(shí)的負(fù)載水平。

然而，吞吐量測(cè)試是測(cè)量系統(tǒng)開始降級(jí)之前觀測(cè)到的最大吞吐量。

3. 負(fù)載測(cè)試

負(fù)載測(cè)試與吞吐量測(cè)試(或壓力測(cè)試)的不同之處在于，它通常被定義為二進(jìn)制測(cè)試，即系統(tǒng)能不能處理這個(gè)預(yù)設(shè)的負(fù)載。

在預(yù)期的業(yè)務(wù)事件之前，有時(shí)要實(shí)施負(fù)載測(cè)試，比如新的客戶或市場(chǎng)有可能使應(yīng)用程序的流量激增。

還有一些情況下也需要進(jìn)行此類測(cè)試，比如廣告活動(dòng)、社交媒體事件和“病毒式營(yíng)銷”。

4. 壓力測(cè)試

我們可以把壓力測(cè)試看作一種確定系統(tǒng)還有多少余量空間的方法。該測(cè)試通常是通過(guò)將系 統(tǒng)置于穩(wěn)定的交易狀態(tài)來(lái)進(jìn)行的，也就是在某個(gè)指定的吞吐量水平(通常是當(dāng)前的峰值) 之下。

壓力測(cè)試會(huì)緩慢地增加并發(fā)交易數(shù)，直到我們觀測(cè)的系統(tǒng)數(shù)據(jù)開始下降。

通過(guò)觀測(cè)數(shù)據(jù)剛開始下降時(shí)的值，就可以確定系統(tǒng)在吞吐量測(cè)試中可以達(dá)到的最大吞吐量。

5. 耐久性測(cè)試

有些問(wèn)題只有在更長(zhǎng)的時(shí)間內(nèi)(通常以天為單位)才會(huì)出現(xiàn)。這些問(wèn)題包括緩慢的內(nèi)存泄漏、高速緩存污染和內(nèi)存碎片化，尤其是對(duì)于使用并發(fā)標(biāo)記和掃描垃圾收集器(CMS)的應(yīng)用程序來(lái)說(shuō)，它們最終可能會(huì)出現(xiàn)并發(fā)模式失敗。

為了檢測(cè)這些問(wèn)題，通常的方法是進(jìn)行耐久性測(cè)試(也稱為浸泡測(cè)試)。這些測(cè)試在平均 (或高)利用率下運(yùn)行，但是系統(tǒng)的負(fù)載要處于觀測(cè)之下。測(cè)試期間要密切監(jiān)控資源利用水平，以發(fā)現(xiàn)任何故障或資源耗盡的情況。

這種類型的測(cè)試在快速響應(yīng)或低延遲的系統(tǒng)中非常常見(jiàn)，因?yàn)檫@些系統(tǒng)通常無(wú)法承受一次 Full GC 周期所造成的 STW 事件的時(shí)間。

6. 容量規(guī)劃測(cè)試

容量規(guī)劃測(cè)試與壓力測(cè)試有許多相似之處，但它們是兩種不同類型的測(cè)試。壓力測(cè)試的作用是找出當(dāng)前系統(tǒng)能夠承受的負(fù)載，而容量規(guī)劃測(cè)試更具前瞻性，旨在確定系統(tǒng)在升級(jí)后能夠承受的負(fù)載。

因此，容量規(guī)劃測(cè)試通常作為常規(guī)計(jì)劃的一部分進(jìn)行，而非應(yīng)對(duì)特定事件或威脅。

7. 退化測(cè)試

退化測(cè)試也稱為部分失效測(cè)試。雖然關(guān)于彈性和失敗恢復(fù)測(cè)試的一般性討論超出了本書的范圍，但是可以這樣說(shuō)，在監(jiān)管和審查最嚴(yán)密的環(huán)境(包括銀行和金融機(jī)構(gòu))中，失敗恢復(fù)測(cè)試不僅會(huì)極為嚴(yán)肅地進(jìn)行，而且通常都會(huì)有細(xì)致深入的規(guī)劃。

就目的而言，這里唯一要考慮的彈性測(cè)試類型是退化測(cè)試。該測(cè)試的基本方法是，當(dāng)系統(tǒng)在相當(dāng)于通常生產(chǎn)量級(jí)的模擬負(fù)載下運(yùn)行時(shí)，一個(gè)組件或整個(gè)子系統(tǒng)突然失去了能力， 此時(shí)觀察系統(tǒng)會(huì)有何表現(xiàn)。

例如，應(yīng)用程序服務(wù)器集群突然丟失機(jī)器、數(shù)據(jù)庫(kù)突然丟失 RAID 磁盤，或網(wǎng)絡(luò)帶寬突然下降等。

在進(jìn)行退化測(cè)試時(shí)，主要觀測(cè)對(duì)象包括交易延遲分布和吞吐量。

部分故障測(cè)試有一個(gè)特別有意思的子類型，叫作混沌猴(chaos monkey)。這是以 Netflix 公司的一個(gè)項(xiàng)目命名的，該項(xiàng)目是為了驗(yàn)證其基礎(chǔ)設(shè)施的健壯性。

混沌猴背后的理念是，在一個(gè)真正的彈性架構(gòu)中，單個(gè)組件的故障不應(yīng)該導(dǎo)致級(jí)聯(lián)故障，也不應(yīng)該對(duì)整個(gè)系統(tǒng)產(chǎn)生實(shí)際影響。

混沌猴試圖通過(guò)隨機(jī)終止生產(chǎn)環(huán)境中實(shí)際使用的活躍進(jìn)程來(lái)演示這一點(diǎn)。

為了成功地實(shí)現(xiàn)混沌猴類型的系統(tǒng)，公司必須具有最高水平的系統(tǒng)衛(wèi)生、服務(wù)設(shè)計(jì)和運(yùn)維優(yōu)勢(shì)。然而，這也是越來(lái)越多的公司和團(tuán)隊(duì)所關(guān)注和向往的領(lǐng)域。

將性能測(cè)試當(dāng)作軟件開發(fā)生命周期的一部分

有些公司和團(tuán)隊(duì)喜歡把性能測(cè)試看作偶爾的、一次性的活動(dòng)。然而，有經(jīng)驗(yàn)的團(tuán)隊(duì)往往會(huì)持續(xù)進(jìn)行性能測(cè)試，特別是會(huì)把性能回歸測(cè)試當(dāng)作軟件開發(fā)生命周期(SDLC)中不可或缺的一部分。

這需要開發(fā)人員和基礎(chǔ)架構(gòu)團(tuán)隊(duì)之間的協(xié)作，以控制在任何特定時(shí)間內(nèi)性能測(cè)試環(huán)境中要出現(xiàn)的代碼版本。如果沒(méi)有專門的測(cè)試環(huán)境，那么這幾乎是不可能實(shí)現(xiàn)的。

在討論了一些最常見(jiàn)的性能測(cè)試的最佳實(shí)踐之后，現(xiàn)在讓我們把注意力轉(zhuǎn)到團(tuán)隊(duì)可能陷入的陷阱和反模式上。

反模式的頻繁出現(xiàn)，使得人們有了這樣的結(jié)論或懷疑:某些潛在因素要為產(chǎn)生了我們不希望出現(xiàn)的行為負(fù)責(zé)。

有些反模式乍一看似乎是合理的，其不好的方面并不明顯。有些則是不良的項(xiàng)目實(shí)踐隨著時(shí)間的推移慢慢累積的結(jié)果。

在某些情況下，這些行為可能是由于社會(huì)或團(tuán)隊(duì)的限制、常見(jiàn)管理技術(shù)的濫用或者只是人類(開發(fā)人員)的本性導(dǎo)致的。通過(guò)對(duì)這些不希望出現(xiàn)的特性進(jìn)行分類和歸類，我們就可以開發(fā)出一種“模式語(yǔ)言”來(lái)討論它們，并希望將其從項(xiàng)目中消除。

應(yīng)該始終將性能調(diào)優(yōu)視為一個(gè)非?？陀^的過(guò)程，并在計(jì)劃階段的早期就設(shè)定精確的目標(biāo)。但是這說(shuō)起來(lái)容易做起來(lái)難，因?yàn)楫?dāng)一個(gè)團(tuán)隊(duì)面臨壓力時(shí)，或者在合理的情況下都不能正常運(yùn)作時(shí)，很容易就半途而廢了。

很多讀者遇到過(guò)這樣的情況:在一個(gè)新的客戶端將要上線，或者一個(gè)新的特性就要發(fā)布時(shí)意外出現(xiàn)了服務(wù)中斷。

如果幸運(yùn)的話，中斷會(huì)出現(xiàn)在用戶驗(yàn)收測(cè)試(user acceptance testing，UAT)階段；但不幸的是，它經(jīng)常出現(xiàn)在生產(chǎn)環(huán)境中。

這時(shí)團(tuán)隊(duì)就要手忙腳亂地尋找引發(fā)瓶頸的問(wèn)題并加以修復(fù)。導(dǎo)致這樣的結(jié)果通常是因?yàn)闆](méi)有進(jìn)行性能測(cè)試，或者團(tuán)隊(duì)的“專家”假設(shè)了某個(gè)條件，但是這個(gè)條件消失了。

與遵循了良好的性能測(cè)試實(shí)踐并進(jìn)行了開放、理性的對(duì)話的團(tuán)隊(duì)相比，以這種方式工作的團(tuán)隊(duì)更容易成為反模式的犧牲品。就像許多開發(fā)問(wèn)題一樣，往往是人為因素，比如溝通問(wèn)題，而不是任何技術(shù)方面的原因?qū)е聭?yīng)用程序出現(xiàn)問(wèn)題。

Carey Flichel 在一篇名為“Why Developers Keep Making Bad Technology Choices”的博客文章中提供了一種有趣的分類，文中特別指出了導(dǎo)致開發(fā)人員做出錯(cuò)誤選擇的 5 大原因，接下來(lái)我們依次看一下。

# 厭倦

大多數(shù)開發(fā)人員有過(guò)在某個(gè)角色中感到厭倦的經(jīng)歷，對(duì)一些人來(lái)說(shuō)，這種情況并不會(huì)持續(xù)很長(zhǎng)時(shí)間，因?yàn)樗麄儠?huì)在公司或其他地方尋求新的挑戰(zhàn)或角色。但是，公司里可能沒(méi)有其他的機(jī)會(huì)，換個(gè)地方可能也沒(méi)有。

大家也許遇到過(guò)這樣的優(yōu)秀程序員，他們能夠克服困難，甚至可能積極尋求更輕松的生活。然而，感到厭倦的開發(fā)人員可能會(huì)以多種方式給項(xiàng)目帶來(lái)?yè)p害。

例如，他們可能會(huì)引入不必要的代碼復(fù)雜性，比如直接在代碼中寫一個(gè)排序算法，而這本來(lái)使用簡(jiǎn)單的 Collections.sort() 就夠了。他們也可能會(huì)使用未知的或不適合當(dāng)前場(chǎng)景的技術(shù)來(lái)構(gòu)建組件，只是希望有個(gè)機(jī)會(huì)用這些技術(shù)，以此來(lái)解決他們的厭倦感。這又會(huì)導(dǎo)致出現(xiàn)下面的問(wèn)題。

# 填充簡(jiǎn)歷

偶爾，技術(shù)的過(guò)度使用并不是因?yàn)閰捑?，而是因?yàn)殚_發(fā)人員想找到一個(gè)機(jī)會(huì)，在簡(jiǎn)歷上增加使用某項(xiàng)技術(shù)的經(jīng)驗(yàn)。在這種情況下，開發(fā)人員會(huì)積極嘗試提高自己的潛在薪資和市場(chǎng)競(jìng)爭(zhēng)力，因?yàn)樗麄兗磳⒅匦逻M(jìn)入就業(yè)市場(chǎng)。在一個(gè)運(yùn)作良好的團(tuán)隊(duì)內(nèi)部，很多人不太可能靠這個(gè)僥幸成功，不過(guò)項(xiàng)目確實(shí)可能會(huì)因?yàn)檫@個(gè)原因而進(jìn)入不必要的路徑。

由于開發(fā)人員的厭倦，或?yàn)榱颂畛浜?jiǎn)歷而增加了一項(xiàng)不必要的技術(shù)，其影響可能是深遠(yuǎn)而持久的，在原來(lái)的開發(fā)人員另謀高就后還會(huì)持續(xù)數(shù)年。

#?同儕壓力

儕（chái）

在做出選擇時(shí)，如果關(guān)注點(diǎn)沒(méi)有得到表達(dá)或討論，那所做出的技術(shù)決策往往是最糟糕的。問(wèn)題有可能通過(guò)幾種方式表現(xiàn)出來(lái)。

比如，也許某個(gè)初級(jí)開發(fā)人員不想在團(tuán)隊(duì)中的高級(jí)成員面前犯錯(cuò)(“負(fù)擔(dān)癥候群”)，或者某個(gè)開發(fā)人員擔(dān)心遇到對(duì)某個(gè)特定主題不了解的情況。

另一種特別有害的同儕壓力，這是來(lái)自存在競(jìng)爭(zhēng)關(guān)系的團(tuán)隊(duì)，大家都希望表現(xiàn)出更高的開發(fā)速度，因此會(huì)在沒(méi)有充分探討所有后果的情況下就倉(cāng)促做出關(guān)鍵決定。

#?缺乏理解

因?yàn)闆](méi)有了解當(dāng)前工具的全部功能，所以開發(fā)人員可能會(huì)尋求引入新的工具來(lái)幫助解決問(wèn)題。使用適合執(zhí)行某個(gè)具體任務(wù)的新的、令人興奮的技術(shù)組件往往很有誘惑力。然而，引入更多技術(shù)復(fù)雜性也必須考慮與當(dāng)前工具的實(shí)際功能相平衡。

例如，Hibernate 有時(shí)被看作簡(jiǎn)化領(lǐng)域?qū)ο蠛蛿?shù)據(jù)庫(kù)之間轉(zhuǎn)換的解決方案。如果團(tuán)隊(duì)對(duì) Hibernate 的理解相當(dāng)有限，那么開發(fā)人員可能會(huì)基于在另一個(gè)項(xiàng)目中看過(guò)的 Hibernate 的 使用情形而對(duì)其適用性做出假設(shè)。

缺乏理解會(huì)導(dǎo)致 Hibernate 的用法過(guò)度復(fù)雜，甚至導(dǎo)致無(wú)法恢復(fù)的生產(chǎn)環(huán)境中斷。

相比之下，使用簡(jiǎn)單的 JDBC 調(diào)用來(lái)重寫整個(gè)數(shù)據(jù)層，可以讓開發(fā)人員停留在熟悉的領(lǐng)域中。本書的一位作者曾經(jīng)講授過(guò)一門 Hibernate 課程，課上有位代表就遇到了完全一樣的情況。

他試圖學(xué)習(xí)足夠多的 Hibernate 知識(shí)，看看是否能讓應(yīng)用程序從中斷中恢復(fù)過(guò)來(lái)，但最終不得不用一個(gè)周末的時(shí)間把 Hibernate 去掉了，這可不是值得羨慕的事。

# 被錯(cuò)誤理解的問(wèn)題 or 不存在的問(wèn)題

開發(fā)人員可能經(jīng)常會(huì)使用某種技術(shù)來(lái)解決某個(gè)特定的問(wèn)題，但是對(duì)問(wèn)題空間本身并沒(méi)有進(jìn)行充分研究。如果沒(méi)有測(cè)量獲得的性能值，那就幾乎不可能理解特定解決方案是否成功。通常，整理這些性能指標(biāo)有助于更好地理解問(wèn)題。

為了避免出現(xiàn)反模式，要確保關(guān)于技術(shù)問(wèn)題的交流對(duì)團(tuán)隊(duì)的所有參與者公開，并鼓勵(lì)大家踴躍參與，這非常重要。

在事情不清楚的地方，收集事實(shí)證據(jù)和研究原型可以幫助指導(dǎo)團(tuán)隊(duì)做出決策。

一項(xiàng)技術(shù)可能看起來(lái)很有吸引力，但是如果原型不符合要求，那么團(tuán)隊(duì)可也以做出更明智的決策。

一個(gè)系統(tǒng)的性能測(cè)試必須根據(jù)不同的原因而進(jìn)行不同類型的測(cè)試，但性能測(cè)試并不是那么暢通無(wú)阻，一些可能會(huì)困擾性能測(cè)試的問(wèn)題或反模式問(wèn)題，只有那些有足夠經(jīng)驗(yàn)的資深程序員才會(huì)真正了解。

性能優(yōu)化是資深程序員必不可少的技能，也是很多大廠招高級(jí)技術(shù)崗位必備的條件之一，如果你在這方面還沒(méi)有突破的話，這里推薦這本《Java性能優(yōu)化實(shí)踐》。

—?【 THE END 】—
本公眾號(hào)全部博文已整理成一個(gè)目錄，請(qǐng)?jiān)诠娞?hào)里回復(fù)「m」獲取！

3T技術(shù)資源大放送！包括但不限于：Java、C/C++，Linux，Python，大數(shù)據(jù)，人工智能等等。在公眾號(hào)內(nèi)回復(fù)「1024」，即可免費(fèi)獲?。?！