增加了一行代碼，讓我們提高了3000%的性能

我們公司運(yùn)維著 15 個(gè) Web 應(yīng)用，主要的工作就是按需交付基于數(shù)據(jù)驅(qū)動(dòng)的 Web 應(yīng)用程序，用于支撐實(shí)時(shí)決策的制定。

這些應(yīng)用的預(yù)期是在高負(fù)載下依然保持高可用。其中的主 Web 應(yīng)用是一個(gè)歷史遺留的大型多服務(wù)系統(tǒng)。系統(tǒng)中的大部分服務(wù)都有超過 15 年的歷史并且經(jīng)過了好幾代人的重構(gòu)。試想一下，負(fù)責(zé)編寫系統(tǒng)代碼的人現(xiàn)在可能已經(jīng)離職或已經(jīng)調(diào)整到其他崗位了。

過去幾年我們團(tuán)隊(duì)的主要目標(biāo)是就是針對(duì)這些服務(wù)進(jìn)行性能優(yōu)化。本次我將和你分享在性能優(yōu)化的過程中，我們的一些主要經(jīng)驗(yàn)總結(jié)和當(dāng)時(shí)決定這么做的原因。

在某次事件中，用戶增加了對(duì)我們應(yīng)用的使用率，導(dǎo)致我們應(yīng)用的數(shù)據(jù)流量大幅增加。在此事件過程中，用戶抱怨我們的應(yīng)用性能實(shí)在太差，以至于無法在應(yīng)用上完成全套的業(yè)務(wù)流程。為此，我們開始利用監(jiān)控工具分析應(yīng)用的性能瓶頸。通過應(yīng)用監(jiān)控工具，我們發(fā)現(xiàn)服務(wù)在獲取 DB 連接上消耗了 90% 的響應(yīng)時(shí)間。

但是 DB 看上去一切正常，所以，我們開始分析應(yīng)用的 DB 連接池。分析發(fā)現(xiàn)，所有的 pod 將連接池中全部可用的連接都使用了。因此我們猜測(cè)服務(wù)在關(guān)閉連接上可能有問題。于是，我們花了幾個(gè)小時(shí)時(shí)間檢查代碼，嘗試找到連接沒有被釋放的地方。最終，我們的一個(gè) TeamLeader 發(fā)現(xiàn)，pod 的存活探針在做一次簡單的 DB 心跳請(qǐng)求之后沒有釋放 DB 連接。隨后，我們立即在 pod 存活探針的請(qǐng)求中增加了一行用于釋放 DB 連接的代碼。影響是可怕的。眨眼間，應(yīng)用的性能就開始穩(wěn)定下來并且用戶也恢復(fù)了正常使用。

就在此次事件的前一天，我們才執(zhí)行過一次負(fù)載測(cè)試，以確保應(yīng)用程序能夠承受預(yù)期的使用量增長，測(cè)試結(jié)果表明應(yīng)用的性能是在正常范圍內(nèi)的。然而事實(shí)證明這個(gè)測(cè)試結(jié)論是錯(cuò)誤的，錯(cuò)誤的測(cè)試結(jié)論誤導(dǎo)我們以為應(yīng)用程序沒有需要修復(fù)的問題。我們深刻認(rèn)識(shí)到了錯(cuò)誤，我們需要做得更好。以下是我們?cè)诖舜问录袑W(xué)習(xí)到的一些經(jīng)驗(yàn)和總結(jié)。

當(dāng)用戶抱怨應(yīng)用響應(yīng)慢的時(shí)候，我們發(fā)現(xiàn)平均等待時(shí)長指標(biāo)并沒有明顯的變化。當(dāng)我們回顧了這些指標(biāo)數(shù)據(jù)的時(shí)候，注意到了一些有趣的事情：之前我們是將平均請(qǐng)求時(shí)間作為服務(wù)等待的主要指標(biāo)，因此，這次我們將 90% 請(qǐng)求等待時(shí)長的數(shù)據(jù)做了一個(gè)圖表，看看這個(gè)圖表能不能反饋些信息。果不其然，在用戶抱怨應(yīng)用慢的時(shí)候，我們觀察到圖表中等待時(shí)長急劇增加。平均等待時(shí)長指標(biāo)之所以沒有明顯變化，是因?yàn)樘嗟目焖僬?qǐng)求將平均值拉下來了。所以我的建議是，不使用平均等待時(shí)長，而使用 50%，90%，95%，99% 的平均等待時(shí)長作為服務(wù)響應(yīng)的指標(biāo)。核查那些遠(yuǎn)遠(yuǎn)超過正常值范圍的“尾部”值是非常重要的。

要保持應(yīng)用的高性能，我們必須具備以下條件：

1. 負(fù)載測(cè)試和負(fù)載場(chǎng)景——具備可用的負(fù)載測(cè)試和負(fù)載場(chǎng)景非常重要。

2. 應(yīng)用監(jiān)控工具（APM）——諸如 Dyanatrace，AppDynamics 和 Epsagon 等工具。APM 在監(jiān)控服務(wù)上可以幫我們節(jié)約大量的時(shí)間。因此在生產(chǎn)環(huán)境安裝至少一個(gè) APM 是非常有必要的。

3. 有效的日志——有效的日志是生產(chǎn)服務(wù)中斷調(diào)查和性能問題調(diào)查的基本條件。因此你必須確保應(yīng)用的日志是清晰且有用的。

4. 日志分析工具——你不能從很多文件中讀取和搜索日志，尤其當(dāng)你的服務(wù)是集群的時(shí)候，通過文件讀取日志將變得更加困難。因此，花時(shí)間投產(chǎn)一個(gè)諸如 ELK，Grafana 或 Splunk 的日志收集器和分析工具是非常有必要的。

5. 專業(yè)的人力支撐——對(duì)于上面提到的知識(shí)或者工具，如果你的團(tuán)隊(duì)沒有相關(guān)的專業(yè)人才，那么你將什么也干不了。

因此，針對(duì)復(fù)雜的系統(tǒng)，我建議投入專門的人和時(shí)間來處理。（例如，SRE 團(tuán)隊(duì)就能很好的勝任此項(xiàng)工作）

作為人類，我們都有創(chuàng)造新事物的沖動(dòng)和欲望，并且對(duì)創(chuàng)造出來的產(chǎn)品有一種所有權(quán)感。在軟件的世界里，在我們需要處理的矛盾中，有時(shí)候也會(huì)包含這樣的矛盾。一方面，有一個(gè)老系統(tǒng)需要我們維護(hù)；而另一方面，有一個(gè)炫酷的新系統(tǒng)我們想要去開發(fā)。那么這個(gè)時(shí)候，我們就需要決定將時(shí)間投入到那塊。當(dāng)我們面對(duì)這樣的矛盾時(shí)，我們必須記住，如果我們不繼續(xù)在老系統(tǒng)上進(jìn)行開發(fā)和添加新功能，那么對(duì)老系統(tǒng)的了解會(huì)隨著時(shí)間的推移而消失。因此，當(dāng)我們面對(duì)系統(tǒng)故障或客戶新需求時(shí)，由于缺少對(duì)老系統(tǒng)的了解或者能力問題，將無法達(dá)成目標(biāo)。換句話說，當(dāng)我們失去對(duì)于老系統(tǒng)的了解之后，系統(tǒng)的 MTTR(平均修復(fù)時(shí)間) 上升了。

因此，我的建議是，要時(shí)常克制想要?jiǎng)?chuàng)造一個(gè)新的、炫酷事物的沖動(dòng)，將時(shí)間投入到對(duì)老維護(hù)系統(tǒng)的熟悉和提升解決問題的能力上。另外，保持對(duì)老系統(tǒng)熟悉度的最佳方式就是嘗試在老系統(tǒng)中添加代碼。

有時(shí)，當(dāng)我們?cè)诰帉懘a的時(shí)候，我們可能會(huì)忘記這些代碼最終運(yùn)行將在生產(chǎn)環(huán)境中，并為一個(gè)真實(shí)用戶的真實(shí)工作服務(wù)。上面提到的我們親身經(jīng)歷的案例中，僅僅只是因?yàn)槌绦騿T忘記了釋放 DB 連接（一行代碼而已），就可以干擾一個(gè)用戶的正常工作（那些工作受影響的用戶估計(jì)很不愿意給我們付錢）。

我的建議是：

想象一下（雖然很難），在世界的另一端，某個(gè)用戶的工作完全依賴你編寫的代碼，同時(shí)試想一下，你寫的每一行代碼都將影響其使用應(yīng)用的體驗(yàn)。

在 CI 或者 CD 環(huán)節(jié)執(zhí)行負(fù)載測(cè)試。如果你想確保代碼高可用，那么就針對(duì)每個(gè)即將投產(chǎn)的 PR 或版本都進(jìn)行負(fù)載測(cè)試。

當(dāng)你發(fā)現(xiàn)性能問題的時(shí)候，請(qǐng)懷疑每一行代碼——據(jù)我們的經(jīng)驗(yàn)，代碼中的每個(gè)字符都有可能是導(dǎo)致性能的瓶頸。

此文章闡述了我們?cè)谙到y(tǒng)性能優(yōu)化上的全部經(jīng)驗(yàn)教訓(xùn)和體會(huì)心得，我希望通過此文章能夠幫助你意識(shí)到系統(tǒng)性能缺陷所存在的潛在風(fēng)險(xiǎn)。

我認(rèn)為，應(yīng)用的性能應(yīng)該被視為最高優(yōu)先處理事項(xiàng)。因?yàn)楹徒K端用戶不能使用系統(tǒng)相比，漂亮的 UI 和炫酷的產(chǎn)品都顯得微不足道。

我寫的這些結(jié)論都是我根據(jù)日常性能優(yōu)化的經(jīng)驗(yàn)總結(jié)而來，因此，在我看來，上面的所有結(jié)論都是每一次成功的性能優(yōu)化的基石。所以，我也希望你能發(fā)現(xiàn)它們的用處。

原文鏈接：

https://medium.com/@ilechowicer/how-every-code-line-matters-we-improved-performance-by-3000-c9ce858c39a8