在彈性容器化環(huán)境中，擁有低效代碼是非常昂貴的。通過向左監(jiān)控方法和可觀測(cè)性解決方案，可以幫助解決這個(gè)問題。

向左移動(dòng)（Shift-left）是一種軟件開發(fā)和運(yùn)維的方法，強(qiáng)調(diào)在軟件開發(fā)生命周期的早期進(jìn)行測(cè)試、監(jiān)控和自動(dòng)化。向左移動(dòng)的目標(biāo)是在問題出現(xiàn)之前及時(shí)發(fā)現(xiàn)并迅速解決，以防止問題的發(fā)生。

當(dāng)您早期識(shí)別到可擴(kuò)展性問題或錯(cuò)誤時(shí)，解決起來更快、更具成本效益。將低效代碼轉(zhuǎn)移到云容器中可能非常昂貴，因?yàn)樗赡軙?huì)激活自動(dòng)擴(kuò)展功能，增加您的月度費(fèi)用。此外，在您能夠識(shí)別、隔離和修復(fù)問題之前，您將處于緊急狀態(tài)。

問題陳述

我想給您演示一個(gè)案例，我們成功地避免了一個(gè)潛在的應(yīng)用程序問題，在生產(chǎn)環(huán)境中可能會(huì)造成重大影響。

2022年我們的Kubernetes報(bào)告提供了關(guān)于團(tuán)隊(duì)如何利用Kubernetes、AI中的K8s、集群可觀測(cè)性方面的見解等內(nèi)容。

我正在審查最近應(yīng)用程序更改后的UAT基礎(chǔ)架構(gòu)的性能報(bào)告。這是一個(gè)使用MariaDB作為后端、運(yùn)行在Apache反向代理和AWS應(yīng)用負(fù)載均衡器后面的Spring Boot微服務(wù)。新功能成功集成，并且通過了所有UAT測(cè)試用例。然而，我注意到MariaDB性能儀表板中的性能圖表與部署前的模式有所偏離。

以下是事件的時(shí)間軸。

8月6日14:13，應(yīng)用程序使用包含嵌入式Tomcat的新Spring Boot jar文件重新啟動(dòng)。

14:52，MariaDB的查詢處理速率從每秒0.1增加到88次查詢/秒，然后增加到301次查詢/秒。

此外，系統(tǒng)CPU利用率從1%提高到6%。

最后，JVM在G1 Young Generation Garbage Collection上花費(fèi)的時(shí)間從0%增加到0.1%，并保持在這個(gè)水平。

該應(yīng)用程序在UAT階段異常地發(fā)出300次查詢/秒，遠(yuǎn)遠(yuǎn)超出了其設(shè)計(jì)要求。新功能導(dǎo)致數(shù)據(jù)庫(kù)連接增加，因此查詢量顯著增加。然而，監(jiān)控儀表板顯示，在部署新版本之前，問題措施是正常的。

解決方案

這是一個(gè)使用JPA查詢MariaDB的Spring Boot應(yīng)用程序。該應(yīng)用程序的設(shè)計(jì)是在兩個(gè)容器上運(yùn)行以實(shí)現(xiàn)最小負(fù)載，但可以擴(kuò)展到十個(gè)容器。

如果一個(gè)單獨(dú)的容器可以生成每秒300次查詢，那么如果所有十個(gè)容器都運(yùn)行，它可以處理每秒3000次查詢嗎？數(shù)據(jù)庫(kù)能否擁有足夠的連接來滿足應(yīng)用程序其他部分的需求？

我們別無選擇，只能返回開發(fā)人員的工作臺(tái)，檢查Git中的更改。

新的更改將從一個(gè)表中獲取少量記錄并進(jìn)行處理。這是我們?cè)诜?wù)類中觀察到的代碼。

List<X> findAll = this.xRepository.findAll();

不，使用Spring的CrudRepository的findAll()方法而沒有分頁(yè)是低效的。分頁(yè)有助于減少?gòu)臄?shù)據(jù)庫(kù)檢索數(shù)據(jù)所需的時(shí)間，通過限制獲取的數(shù)據(jù)量。這是我們主要的關(guān)系型數(shù)據(jù)庫(kù)（RDBMS）教育所教導(dǎo)我們的。此外，分頁(yè)有助于保持內(nèi)存使用低，以防止應(yīng)用程序由于數(shù)據(jù)過載而崩潰，并減少Java虛擬機(jī)的垃圾回收工作量，正如前面問題陳述中提到的。

這個(gè)測(cè)試是在一個(gè)容器中使用2000條記錄進(jìn)行的。如果這段代碼被部署到生產(chǎn)環(huán)境中，其中每個(gè)容器有約20萬(wàn)條記錄，那么可能會(huì)給團(tuán)隊(duì)帶來很大的壓力和憂慮。

應(yīng)用程序在將方法添加WHERE子句后重新構(gòu)建。

List<X> findAll =
this.xRepository.findAllByY(Y);

恢復(fù)了正常運(yùn)行。每秒查詢數(shù)從300降至30，垃圾收集的工作量恢復(fù)到原始水平。此外，系統(tǒng)的CPU使用率降低。

學(xué)習(xí)和總結(jié)

任何從事站點(diǎn)可靠性工程（SRE）工作的人都會(huì)理解這個(gè)發(fā)現(xiàn)的重要性。我們能夠在不提高嚴(yán)重性1級(jí)別的情況下采取行動(dòng)。如果這個(gè)有缺陷的軟件包部署到生產(chǎn)環(huán)境中，可能會(huì)觸發(fā)客戶的自動(dòng)擴(kuò)展閾值，即使沒有額外的用戶負(fù)載，也會(huì)啟動(dòng)新的容器。

這個(gè)故事有三個(gè)主要的要點(diǎn)。

首先，最好從一開始就啟用一個(gè)可觀測(cè)性解決方案，因?yàn)樗梢蕴峁┦录臍v史記錄，用于識(shí)別潛在問題。如果沒有這個(gè)歷史記錄，我可能不會(huì)認(rèn)真對(duì)待0.1%的垃圾回收百分比和6%的CPU消耗，代碼可能會(huì)發(fā)布到生產(chǎn)環(huán)境中，造成災(zāi)難性的后果。擴(kuò)大監(jiān)控解決方案的范圍到UAT服務(wù)器有助于團(tuán)隊(duì)在問題發(fā)生前識(shí)別潛在根本原因并防止問題發(fā)生。

其次，在測(cè)試過程中應(yīng)存在與性能相關(guān)的測(cè)試用例，并由具有可觀測(cè)性經(jīng)驗(yàn)的人員進(jìn)行審查。這將確保對(duì)代碼的功能和性能進(jìn)行測(cè)試。

第三，云原生的性能跟蹤技術(shù)對(duì)于接收有關(guān)高利用率、可用性等方面的警報(bào)非常有用。為了實(shí)現(xiàn)可觀測(cè)性，您可能需要準(zhǔn)備合適的工具和專業(yè)知識(shí)。祝編碼愉快！