做一款互聯網產品，人們往往立馬就想到了海量用戶、海量數據、高併發、高性能。所以起初做架構設計時就把性能提到了一個不得不做的地位。我個人是很反對這種“未雨綢繆”的方式的，因爲對於一個新應用來說獲取一個互聯網用戶的成本並不小，而且“海量”不是短期內就會面臨的。所以請建議您最好先在基於投入產出比的考量下對快速實現 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處理模型；如何降低業務邏輯複雜度；如何處理負載；如何優化數據庫......我們還有很長的路要走。
推薦書籍《構建高性能Web站點》,感謝作者 郭欣給大家提供了這麼一本很優秀的國產書籍。