精通業務，善用工具

qps從最開始的1k都頂不住，到1w，再到2w，加上支援大量的ab實驗，排序千人千面，功能越來越複雜，系統越來越龐大，可能這樣的機會都不會常有，在此簡單記錄一下做系統優化的實踐心得。

仔細想想，做優化其實並沒有很多門道，個人總結起來就三個要素：

業務工具

人業務就是你的任務，是優化的目標，業務的複雜性和獨特性決定了你的問題只有自己去解決，網上沒有答案，即使挖個大神來也不能立馬幫到你。

業務不僅僅包括公司對外提供的服務，還包括專案內部的一切細枝末節，比如**的邏輯、伺服器的部署、後台的配置、資料的流轉，甚至不同團隊間的分工合作等等。

我們要做的其實就是優化這些業務，業務中的任何乙個點都可以是優化的方向。

我們能用到的一切手段都是工具，有直接應對線上流量的伺服器、**、jvm、db，也有間接可以幫助我們做優化的輔助工具，監控(prometheus/grafana)、日誌(elk)、壓測(goreplay)、診斷工具(arthas)等等。

只了解業務的人面對問題束手無策，只鑽研技術的人能解決的問題往往被技術限制了天花板。

我們需要的是精通業務，善用工具的人，能從監控資料中發現蛛絲馬跡，能從複雜的業務關係中抽絲剝繭，能利用手上一切工具，發揮它們最大的作用。

拋開搭建環境、壓測、回歸測試等工作，優化步驟最精簡的話只有兩步：

找系統瓶頸

優化，突破瓶頸

找瓶頸就需要有依據，依據就是監控指標。

監控指標的全面對於乙個龐大的系統來說至關重要，不僅包括介面的耗時、jvm的狀態、機器的負載等一些常見的指標，更需要細緻到收集快取的命中率、不同邏輯分支的佔比、每張表的讀寫頻率等具體業務相關的指標。

如果缺少了業務指標的監控，定位問題很可能定位不到根源，能優化的空間也會受到技術的限制。

找到瓶頸之後，看起來問題很快就能解決了，jvm頂不住就調heap，調gc，db頂不住就加副本，優化sql，畢竟我們學習的時候學的就是這些，面試的時候考的也是這些。

然而真正漫長而痛苦的優化過程中，這些直接了當的解決方式往往不會帶來多少提公升，因為簡單的方法可能在我們當初開發功能時都已經做過。

通常想要成倍的提高吞吐量，我們需要做更多看似側面的工作，解決根源上的問題。

幾個例子

當我們吞吐量在1k不到時，jvm頂不住，這時候不管是公升機器配置，還是jvm調優都沒有明顯效果。因為我們有很多慢介面，即使只佔請求總量的1%不到，在大流量下也是拖垮服務的重要因素。我們採用了使用es的一些高階特性，同時將資料準備成便於查詢的結構等一系列措施，消滅了慢查詢介面。

當慢介面處理完，吞吐量提公升到了一定程度，jvm還是狀況不佳，我們就考慮改善快取。原本使用的jvm內快取，嘗試了調整快取引數，使用集中式快取redis等方案後都沒效果。最終通過nginx層的快取和一致性雜湊大幅減輕了壓力。

當介面都很快，db（elasticsearch）開始頂不住，我們嘗試了加機器、擴副本、調堆記憶體大小等手段，最終還是通過將商品詳情的查詢移出es，由單獨的服務通過查redis來提供，減輕了es大半的壓力。

以上的手段未必適合其它專案，但系統的優化就是這樣，從來就沒有標準答案。

我們能做的就只有深入業務，利用好每一種工具，然後充滿信心地迎接下乙個挑戰。