講一個這周排查的訪問流量不均的事兒。

下游同學(xué)反饋我們的服務(wù)調(diào)用流量不均，最高的實(shí)例有 1k+ QPS，最低的才 400+ QPS，相差太大。

流量不均

于是拉了平臺的 oncall，詢問是否開了 mesh，沒開。那就是框架的事了。

再拉框架的 oncall，詢問是否自己加了流量均衡的策略，也沒加。那就是用的默認(rèn)的流量調(diào)度策略：“加權(quán)隨機(jī)”。

什么是加權(quán)隨機(jī)？

加權(quán)是指按節(jié)點(diǎn)權(quán)重進(jìn)行流量分配，隨機(jī)意味著相同權(quán)重下的實(shí)例隨機(jī)選擇。

去查下游各個 host 的 weight 值。發(fā)現(xiàn)確實(shí)有些 host 的 weight 值相差比較大。有的值是 10，有的值是 50。看起來是符合預(yù)期的。

這時又提出有兩個 host 的 weight 值一樣，但 QPS 相差 4 倍。

有同學(xué)說，直接去 access 日志里撈一下就行了。一行日志代表一個訪問，積累出每秒鐘的訪問量，結(jié)果不就出來了嗎？

grep?'2021-11-20?10:01'?xxx.log?|?awk?'{print?substr($3,1,8)}'?|?sort?|?uniq?-c

結(jié)果會打印出在 10:01 這一分鐘每秒的請求數(shù)，即 QPS。

果然，前面提到的這兩臺 host 訪問量基本相同。看起來是監(jiān)控打點(diǎn)出了問題。

找到其中 QPS 比較低的這一臺機(jī)器，發(fā)現(xiàn)部署的 metricsserver CPU 受限很嚴(yán)重，說明丟了很多點(diǎn)，于是就造成了流量不均衡的假象。

之后找 metrics 的同學(xué)升級了套餐，上線完成之后，打點(diǎn)恢復(fù)正常。流量是均衡的。

這樣一個簡單的問題，還花費(fèi)了一點(diǎn)時間。以后碰到類似的問題，第一時間看監(jiān)控是否有問題。有些機(jī)器上的服務(wù)打點(diǎn)多，metricsserver 扛不住，丟點(diǎn)是在所難免的。

之前也碰到過幾次打點(diǎn)不準(zhǔn)的問題，查了半天，最后發(fā)現(xiàn)烏龍了。因此對于一些不太符合常理（例如本文的訪問流量不均）的問題，先要確定打點(diǎn)沒有問題。

總結(jié)

以上是生活随笔為你收集整理的一次流量不均衡问题的排查记录的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。