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

下游同學反饋我們的服務調用流量不均，最高的實例有 1k+ QPS，最低的才 400+ QPS，相差太大。

流量不均

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

再拉框架的 oncall，詢問是否自己加了流量均衡的策略，也沒加。那就是用的默認的流量調度策略：“加權隨機”。

什么是加權隨機？

加權是指按節點權重進行流量分配，隨機意味著相同權重下的實例隨機選擇。

去查下游各個 host 的 weight 值。發現確實有些 host 的 weight 值相差比較大。有的值是 10，有的值是 50。看起來是符合預期的。

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

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

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

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

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

找到其中 QPS 比較低的這一臺機器，發現部署的 metricsserver CPU 受限很嚴重，說明丟了很多點，于是就造成了流量不均衡的假象。

之后找 metrics 的同學升級了套餐，上線完成之后，打點恢復正常。流量是均衡的。

這樣一個簡單的問題，還花費了一點時間。以后碰到類似的問題，第一時間看監控是否有問題。有些機器上的服務打點多，metricsserver 扛不住，丟點是在所難免的。

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。