建構高性能服務的考量

做一款網際網路産品，人們往往立馬就想到了海量使用者、海量資料、高并發、高性能。是以起初做架構設計時就把性能提到了一個不得不做的地位。我個人是很反對這種“未雨綢缪”的方式的，因為對于一個新應用來說擷取一個網際網路使用者的成本并不小，而且“海量”不是短期内就會面臨的。是以請建議您最好先在基于投入産出比的考量下對快速實作 OR 性能重要程度做出權衡後再做考慮，最好先實作應用再做優化，過早優化是萬惡之源這句話不是吓唬小孩子的。當然，本文講的就是性能的考量，是以文章以下的講解是在你已經決定要重點考慮性能的基礎上。

性能無非就是為了通過縮短響應時間來獲得良好的使用者體驗，通常我們會說起2/5/10法則：使用者響應在2秒之内是很好的使用者體驗；使用者響應在2-5秒之間是一般的使用者體驗，使用者可以接受；但是使用者響應在5-10秒之間是很糟糕的使用者體驗，已經接近了使用者可接受的極限。是以我們為了減小使用者響應時間必須要分析出可能出現的性能瓶頸在哪裡。

如圖我們可以很清晰的看出使用者在等待的過程中發生了什麼：

資料在網絡上傳輸的時間；

背景伺服器處理請求并生成回應的時間；

用戶端處理回複并進行UI呈現的時間；

因為我們今天講的是建構高性能服務，是以3我們暫時忽略。是以響應時間 = 發送時間 + 傳播時間 + 處理時間。有些人要問了，發送時間是個什麼東東，我們來分析下一次網絡I/O的過程：

将要發送的資料寫入程序的資料緩沖區；

調用系統API，這裡涉及到使用者态到核心态的轉化，将資料存入系統核心緩沖區；

資料從核心緩沖區進入網卡；

資料從網卡傳輸到網絡線路；

資料線上路中轉換成相應的信号通過媒體進行傳輸；

是以發送時間 = 資料量/帶寬，帶寬就是資料的發送速度，就是通常我們所說的Mb/s。那麼傳播時間又與什麼有關呢？很容易想到的就是傳輸距離和傳輸速度，傳輸距離就是我們現實中的從北京到上海的距離(鋪設網線的距離）。傳輸速度指的是信号的傳輸速度，通常接近于光速，我們将其約等于2x10^8m/s。是以傳播時間 = 傳輸距離/傳輸速度。

現在我們得出了響應時間 = 資料量/帶寬 + 傳輸距離/傳輸速度 + 處理時間。到底是哪一個步驟最大的影響了我們的使用者響應呢？我們舉個例子，假如客戶在蘭州，網絡出口帶寬為4Mb/s（實際營運商提供的4Mb的網絡上行帶寬遠遠低于4）；伺服器在北京，網絡出口帶寬為100Mb/s；蘭州距離北京約為2000km；發送回應均為10kB(0.08Mb)資料。

用戶端發送時間 = 0.08/4 = 0.02s

服務端發送時間 = 0.08/100 = 0.0008s

傳播時間 = 2x10^6/2x10^8=0.01s

那麼響應時間 = (0.02+0.0008) + 2x0.01 + 處理時間；

除去處理時間發送時間+傳播時間才為0.04秒，仿佛可以看出影響我們服務性能的仿佛是在處理時間上。其實不然，這裡面哪一項都不能被完全忽略。比如剛才我們舉得就是個很極端的例子，用戶端上行帶寬不低，而且服務端隻給這一個使用者提供服務，是以兩端的發送時間都很小；在傳輸上我們忽略了信号的衰減，各級路由器的轉發，甚至不同營運商的互聯互通問題。但是這兩個問題通常不是我們程式開發者能解決的，這需要科學合理的IDC的支援，而且這個成本是企業非常關注的。

是以我們還是把優化重點轉移到最後一項伺服器的處理時間，這裡才是考驗我們架構師，研發工程師，DBA能力的地方。如何實作服務靈活的擴充，部署；如何設計服務的并發政策；選擇怎樣的I/O處理模型；如何降低業務邏輯複雜度；如何處理負載；如何優化資料庫......我們還有很長的路要走。

本文轉自永遠的朋友部落格51CTO部落格，原文連結http://blog.51cto.com/yaocoder/1351638如需轉載請自行聯系原作者

yaocoder