1、背景和現狀
雲集架構整體部署在雲上，其中nginx機器採用8核16g部署，tomcat/dubbo機器採用4核8g部署，基本上都是採用單機單服務部署形式，一般jvm最大記憶體占用4g。從cpu使用率來看，基本負載偏低，從資源利用率來看，伺服器資源可以進一步進行優化。
資源優化需要先對系統容量進行評估，這裡涉及到waf/clb集群、ngninx集群、tomcat接入層、dubbo服務層以及資料層(redis,mysql)等。目前雲集的waf/clb集群都是按照百萬級qps標準來搭建的。
2、目標和方**
由於dubbo層比較欠缺相應的評估方法體系，且生產環境普遍存在資源利用不高的現狀，本文重點**dubbo服務層的容量評估方法。
a)評估難點
要想評估乙個dubbo服務的機器數，核心是要相對準確預估出這個dubbo服務的qps峰值，而這個也是最困難的地方。
如果知道dubbo服務的預估qps峰值，簡單的話可以根據引流壓測的值來計算出機器數量，但這個是理論值沒有實踐參考。要結合實踐的話，通常是將歷史的qps峰值和當時機器負載情況結合來進行分析。比如歷史支撐過100wqps時，使用了10臺機器，但機器負載在20%左右。那麼可以得到當qps還是100w時，使用5臺機器，那機器負載應該上公升到40%左右，然後再通過縮容去驗證。如果縮容後，機器負載其實只上公升到30%附近，則後續再按此實踐作為標準去縮容。這樣每次的結論都是經過歷史的驗證，比較適合在乙個長期相對穩定的dubbo服務中進行評估。目前雲集還欠缺這些歷史資料的積累，只能簡單使用引流壓測計算的理論值作為參考。
要預估dubbo服務的qps峰值，這個跟業務又比較強相關。如果業務邊界劃分比較明確，對該dubbo服務的職能相對明確，且呼叫**相對明確，那麼就可以根據呼叫**分拆，並結合**的特點來逐層進行評估。在實際應用中發現某個**暴增導致自身服務容量超出預估，可以對**進行限流，並重新評估系統容量。呼叫**的特點跟業務也是強相關，如有些是job輪詢，有些是和使用者流量強相關，所以每個dubbo服務的影響因子還各不一樣，核心還是和業務相關。
目前雲集的dubbo服務主要是呼叫**不明確，無法逐層梳理，且job排程觸發的流量沒有明顯的區分，容易造成一些突發流量峰值，所以導致目前dubbo服務大部分靠業務負責人往大預估。
b)根據全站qps峰值預估dubbo服務qps峰值
那麼在此現狀的情況下，我們能否針對某些符合特定場景下的dubbo服務做出一些相對合理的容量評估？儘管每個dubbo服務的qps不好預估，但全站的qps峰值還是可以根據業務活動等來進行預估，如是否有秒殺，業務能吸引的uv大概多少，並略往高評估乙個系統支撐的qps峰值，那麼能不能建立全站qps峰值和dubbo服務的qps峰值的對映關係？這樣當我們已知全站qps峰值的情況下就可以預估出來各個dubbo服務的qps峰值。首先需要假設兩點：
- 假設全站的qps曲線以及dubbo服務的呼叫qps曲線是相對穩定的，這樣我們可以根據歷史的qps情況來預估未來的qps。
- 假設全站的qps曲線和dubbo服務的呼叫qps曲線是相對擬合的，這樣我們認為兩者之間是存在強相關的，可以根據全站來評估到單個dubbo服務的qps峰值。
這兩個假設使得我們不能拿日常的歷史資料來評估某個大促的情況，也不能拿優惠券派發的歷史活動資料來評估乙個預售活動的情況。考慮到大促的資料收集還比較少，不容易有大量的資料用來評估，我們只考慮日常流量的情況。下面我們抽取了某天的全站qps曲線和部分dubbo服務的呼叫次數曲線來分析。
圖1：全站日常流量qps曲線
圖2：userservie服務的呼叫曲線
圖3：categoryprovider服務的呼叫曲線
圖4：gatewaymassageservice服務的呼叫曲線
結合業務來看，userservice目前作為最底層基礎服務，和全站流量存在一定的相關性，故曲線和全站日常流量qps曲線大概擬合；categoryprovider目前呼叫量較多的是job觸發，使用者訪問流量較少，存在明顯的週期性，和全站日常流量qps曲線完全不擬合；gatewaymassageservice服務主要是下發訊息通知，存在明顯的特定時間點爆發呼叫量的情況，和總qps曲線完全不擬合。
目前曲線擬合還主要是依賴業務負責人來觀察對比，暫時沒有自動化的打算。但是計算工具會針對全量的dubbo服務來計算，這就需要業務負責人根據各自業務特點來參考評估結果。
3、計算過程示例
下面針對具體的處理邏輯進行說明。
a) 術語說明
qtotal：在一天的06:00:00~23:59:59間取總qps峰值，主要是為了規避晚上可能存在壓測的情況。
qproject：nginx/tomcat/dubbo的專案峰值。
tqtotal：計算目標總qps峰值，目前按日常目標30wqps來評估。
tqproject：當總qps峰值為tqtotal時，nginx/tomcat/dubbo的專案峰值。
yqproject：nginx/tomcat/dubbo的引流壓測。
mproject：nginx/tomcat/dubbo理論所需機器數。
b) 計算方法
tqproject = (qproject * 1.0 / qtotal) * tqtotal
mproject = tqproject / yqproject
c) 機器數調整
考慮到單個dubbo服務最少需要3臺機器，以保障機器出現故障能正常處理。同時考慮到理論還未經實踐，將機器數統一乘以2倍，盡量往大的方向進行評估，後續實踐後再優化。經連續計算11天的結果，進行排序，取其中的中間值。
2 * mprojet < 3 =》 3
2 * mproject >= 3 =》 2*mproject
sample：
取user-assembly為例，日常流量時間區間取 [1227,1224]，雙12活動時間區間[1211, 1216]
取20191224資料可以計算出mproject = 9.2494。
調整mproject = 9.2494 * 2 = 18
從8天的計算結果排序後，取中間的19作為最終的推薦機器數：[20191224]18;[20191221]18;[20191219]18;[20191217]18;[20191223]19;[20191220]19;[20191218]19;[20191222]20
4、工具化
目前主要考慮專案工程較多，為方便各業務負責人檢視各自的專案，採用django搭建乙個系統來展示最終的資料，另外使用python指令碼來拉取資料並進行計算，計算完資料存放在開發環境的mysql中供django拉取展示。
5、推進縮容
基礎服務集群、營銷服務集群總體縮減的機器比例為26%。
6、2020年流量峰值考驗
縮容後平台在2020-01-28晚上8點搞活動，qps峰值接近一百萬，系統瓶頸出現在ng層面，dubbo服務縮容後普遍峰值cpu使用率基本還在50%以下。user-assembly服務單機機器cpu使用率，雖然縮容按照50wqps來計算，但調整係數為2，故按理是能支撐100wqps，所以cpu使用率接近了引流壓測時的70%。
圖5：user-assembly在總qps為100w時cpu使用率為70%
7、後續優化方向
記錄每次擴縮容的機器變化情況，將預估和實際情況對比記錄，為後續針對單個服務的評估有更細化的資料；根據服務流量峰值和機器運維情況，從而更合理評估機器數。
常用的HTTP服務壓測工具介紹
在專案正式上線之前，我們通常需要通過壓測來評估當前系統能夠支撐的請求量 排查可能存在的隱藏bug，同時了解了程式的實際處理能力能夠幫我們更好的匹配專案的實際需求，節約資源成本。在專案正式上線之前，我們通常需要通過壓測來評估當前系統能夠支撐的請求量 排查可能存在的隱藏bug，同時了解了程式的實際處理能...
常用的HTTP服務壓測工具介紹
在專案正式上線之前，我們通常需要通過壓測來評估當前系統能夠支撐的請求量 排查可能存在的隱藏bug，同時了解了程式的實際處理能力能夠幫我們更好的匹配專案的實際需求，節約資源成本。在專案正式上線之前，我們通常需要通過壓測來評估當前系統能夠支撐的請求量 排查可能存在的隱藏bug，同時了解了程式的實際處理能...
TCP服務端（cmpp sgip壓測工具）介紹
在做tcp客戶端開發的過程中，大家可能都會遇到服務端不穩定性造成我們客戶端發生錯誤的情況，比如因為網路不好造成socket連線斷開，或者服務端主動關閉了你的連線請求。那麼遇到這種情況你的程式該怎麼處理，對，應該做好斷開自動重連機制，而且要保證自動重連的及時性，以及資源消耗率 cpu佔用率都良好。如果...