構建高性能服務的考量

作一款互聯網產品，人們每每立馬就想到了海量用戶、海量數據、高併發、高性能。因此起初作架構設計時就把性能提到了一個不得不作的地位。我我的是很反對這種「未雨綢繆」的方式的，由於對於一個新應用來講獲取一個互聯網用戶的成本並不小，並且「海量」不是短時間內就會面臨的。因此請建議您最好先在基於投入產出比的考量下對快速實現 OR 性能重要程度作出權衡後再作考慮，最好先實現應用再作優化，過早優化是萬惡之源這句話不是嚇唬小孩子的。固然，本文講的就是性能的考量，因此文章如下的講解是在你已經決定要重點考慮性能的基礎上。

---

性能無非就是爲了經過縮短響應時間來得到良好的用戶體驗，一般咱們會提及2/5/10法則：用戶響應在2秒以內是很好的用戶體驗；用戶響應在2-5秒之間是通常的用戶體驗，用戶能夠接受；可是用戶響應在5-10秒之間是很糟糕的用戶體驗，已經接近了用戶可接受的極限。因此咱們爲了減少用戶響應時間必需要分析出可能出現的性能瓶頸在哪裏。

如圖咱們能夠很清晰的看出用戶在等待的過程當中發生了什麼：

• 數據在網絡上傳輸的時間；

• 後臺服務器處理請求並生成迴應的時間；

• 客戶端處理回覆並進行UI呈現的時間；

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

1. 將要發送的數據寫入進程的數據緩衝區；

2. 調用系統API，這裏涉及到用戶態到內核態的轉化，將數據存入系統內核緩衝區；

3. 數據從內核緩衝區進入網卡；

4. 數據從網卡傳輸到網絡線路；

5. 數據在線路中轉換成相應的信號經過介質進行傳輸；

因此發送時間 = 數據量/帶寬，帶寬就是數據的發送速度，就是一般咱們所說的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處理模型；如何下降業務邏輯複雜度；如何處理負載；如何優化數據庫......咱們還有很長的路要走。

推薦書籍《構建高性能Web站點》,感謝做者 郭欣給你們提供了這麼一本很優秀的國產書籍。