天天看點

近期業務大量突增微服務性能優化總結-4.增加對于同步微服務的 HTTP 請求等待隊列的監控增加對于同步微服務的 HTTP 請求等待隊列的監控對于公有雲部署,關注網絡限制的監控

最近,業務增長的很迅猛,對于我們背景這塊也是一個不小的挑戰,這次遇到的核心業務接口的性能瓶頸,并不是單獨的一個問題導緻的,而是幾個問題揉在一起:我們解決一個之後,發上線,之後發現還有另一個的性能瓶頸問題。這也是我經驗不足,導緻沒能一下子定位解決;而我又對我們背景整個團隊有着固執的自尊,不想通過大量水準擴容這種方式挺過壓力高峰,導緻線上連續幾晚都出現了不同程度的問題,肯定對于我們的業務增長是有影響的。這也是我不成熟和要反思的地方。這系列文章主要記錄下我們針對這次業務增長,對于我們背景微服務系統做的通用技術優化,針對業務流程和緩存的優化由于隻适用于我們的業務,這裡就不再贅述了。本系列會分為如下幾篇:

改進用戶端負載均衡算法

開發日志輸出異常堆棧的過濾插件

針對 x86 雲環境改進異步日志等待政策

增加對于同步微服務的 http 請求等待隊列的監控以及雲上部署,需要小心達到執行個體網絡流量上限導緻的請求響應緩慢

針對系統關鍵業務增加必要的侵入式監控

相對于基于 spring-webflux 的異步微服務,基于 spring-webmvc 的同步微服務沒有很好的處理用戶端有請求逾時配置的情況。當用戶端請求逾時時,用戶端會直接傳回逾時異常,但是調用的服務端任務,在基于 spring-webmvc 的同步微服務并沒有被取消,基于 spring-webflux 的異步微服務是會被取消的。目前,還沒有很好的辦法在同步環境中可以取消這些已經逾時的任務。

我們的基于 spring-webmvc 的同步微服務,http 容器使用的是 undertow。在 spring-boot 環境下,我們可以配置處理 http 請求的線程池大小:

其背後的線程池,是 jboss 的線程池:<code>org.jboss.threads.enhancedqueueexecutor</code>,spring-boot 目前不能通過配置修改這個線程池的隊列大小,預設隊列大小是 integer.max

我們需要監控這個線程池的隊列大小,并針對這個名額做一些操作:

當這個任務持續增多的時候,就代表這時候請求處理跟不上請求到來的速率了,需要報警。

當累積到一定數量時,需要将這個執行個體暫時從注冊中心取下,并擴容。

待這個隊列消費完之後,重新上線。

當超過一定時間還是沒有消費完的話,将這個執行個體重新開機。

幸運的是,<code>org.jboss.threads.enhancedqueueexecutor</code> 本身通過 jmx 暴露了 http servlet 請求的線程池的各項名額:

近期業務大量突增微服務性能優化總結-4.增加對于同步微服務的 HTTP 請求等待隊列的監控增加對于同步微服務的 HTTP 請求等待隊列的監控對于公有雲部署,關注網絡限制的監控

我們的項目中,使用兩種監控:

prometheus + grafana 微服務名額監控,這個主要用于報警以及快速定位問題根源

jfr 監控,這個主要用于詳細定位單執行個體問題

對于 http 請求等待隊列監控,我們應該通過 prometheus 接口向 grafana 暴露,采集名額并完善響應操作。

暴露 prometheus 接口名額的代碼是:

之後,調用 <code>/actuator/prometheus</code> 我們就能看到對應的名額:

當發生隊列堆積時,我們能快速的報警,并且直覺地從 grafana 監控上發現:

近期業務大量突增微服務性能優化總結-4.增加對于同步微服務的 HTTP 請求等待隊列的監控增加對于同步微服務的 HTTP 請求等待隊列的監控對于公有雲部署,關注網絡限制的監控

現在的公有雲,都會針對實體機資源進行虛拟化,對于網絡網卡資源,也是會虛拟化的。以 aws 為例,其網絡資源的虛拟化實作即 ena(elastic network adapter)。它會對以下幾個名額進行監控并限制:

帶寬:每個虛拟機執行個體(aws 中為每個 ec2 執行個體),都具有流量出的最大帶寬以及流量入的最大帶寬。這個統計使用一種網絡 i/o 積分機制,根據平均帶寬使用率配置設定網絡帶寬,最後的效果是允許短時間内超過額定帶寬,但是不能持續超過。

每秒資料包 (pps,packet per second) 個數:每個虛拟機執行個體(aws 中為每個 ec2 執行個體)都限制 pps 大小

連接配接數:建立連接配接的個數是有限的

連結本地服務通路流量:一般在公有雲,每個虛拟機執行個體 (aws 中為每個 ec2 執行個體)通路 dns,中繼資料伺服器等,都會限制流量

同時,成熟的公有雲,這些名額一般都會對使用者提供展示分析界面,例如 aws 的 cloudwatch 中,就提供了以下幾個名額的監控:

近期業務大量突增微服務性能優化總結-4.增加對于同步微服務的 HTTP 請求等待隊列的監控增加對于同步微服務的 HTTP 請求等待隊列的監控對于公有雲部署,關注網絡限制的監控

在業務流量突增時,我們通過 jfr 發現通路 redis 有性能瓶頸,但是 redis 本身的監控顯示他并沒有遇到性能瓶頸。這時候就需要檢視是否因為網絡流量限制導緻其除了問題,在我們出問題的時間段,我們發現 networkbandwidthoutallowanceexceeded 事件顯著提高了很多:

近期業務大量突增微服務性能優化總結-4.增加對于同步微服務的 HTTP 請求等待隊列的監控增加對于同步微服務的 HTTP 請求等待隊列的監控對于公有雲部署,關注網絡限制的監控

對于這種問題,就得需要考慮垂直擴容(提升執行個體配置)與水準擴容(多執行個體負載均衡)了,或者減少網絡流量(增加壓縮等)

微信搜尋“我的程式設計喵”關注公衆号,每日一刷,輕松提升技術,斬獲各種offer:
近期業務大量突增微服務性能優化總結-4.增加對于同步微服務的 HTTP 請求等待隊列的監控增加對于同步微服務的 HTTP 請求等待隊列的監控對于公有雲部署,關注網絡限制的監控

繼續閱讀