如何設計高性能的大型網站系統？在移動互聯網時代，客戶端應用開發本身，並不是體驗的決勝之處，真正對團隊挑戰的地方，還在於后端，無論是承壓能力，還是安全性等方面，如果這些地方過不了關，整個應用的基礎是不扎實的。
提高服務器性能最簡單粗暴的方式，就是增加機器和升級硬件配置。雖然現在的硬件越來越便宜，但是一味地通過增加機器來解決並發量的增長，成本是非常高昂的。結合技術優化方案，才是更有效的解決方法。
一、web端性能
這幾年，用戶數量並沒有出現指數增長，而並發連接數呈指數增長的主要原因是：1、Web頁面元素越來越多，更為豐富；2、主流的本瀏覽器的預加載功能。
（1）、建立長連接。減少反復的創建和銷毀連接行為。但是，連接的保持是會占用Web系統服務端資源的，如果不充分使用這個連接，會導致資源浪費。
（2）、通過緩存減少Web請求。通過Http協議頭中的expire或max-age來控制，將靜態內容放入瀏覽器的本地緩存。但是，這種方案，對首次訪問的用戶無效，同時，也影響部分Web資源的實時性。
（3）、通過版本號減輕Web請求。協商方式是通過Http協議的Last-Modified或Etag來控制，這個時候請求服務器，如果是內容沒有發生變更的情況，服務器會返回304 Not Modified。但是，，但是連接仍然被建立，請求也發生了。
（4）、合並頁面請求。1、合並HTML展示內容。將CSS和JS直接嵌入到HTML頁面內，不通過連接的方式引入。2、Ajax動態內容合並請求。對於動態內容，將10次Ajax請求合並為1次的批量信息查詢。3、小圖片合並，通過CSS的偏移量技術Sprites，將很多小圖片合並為一張。4、壓縮css，js，圖片的大小。
（5）、頁面靜態化。頁面上的大部分內容在很長一段時間內，可能都是沒有變化的。例如一篇新聞報道，一旦發布幾乎是不會修改內容的。這樣的話，通過CGI生成的靜態html頁面緩存到web服務器的磁盤本地。
二、app端性能。
（1）圖片三步加載。從內存、磁盤、網絡三個方面上進行三級緩存的實現。1、在加載一張圖片的時候，先查看內存是否有該圖片的緩存，若無，再查看磁盤時候有該圖片的緩存，若無，才從網絡中加載；2、在網絡加載完成之后，需要把圖片加進到內存和磁盤緩存中；3、根據LRU調度方式對緩存進行管理。
（1）圖片三步加載。從內存、磁盤、網絡三個方面上進行三級緩存的實現。1、在加載一張圖片的時候，先查看內存是否有該圖片的緩存，若無，再查看磁盤時候有該圖片的緩存，若無，才從網絡中加載；2、在網絡加載完成之后，需要把圖片加進到內存和磁盤緩存中；3、根據LRU調度方式對緩存進行管理。
（2）預加載技術。基於歷史瀏覽記錄和對該網頁的安全性判斷，在你沒點擊請求之前，預先加載這個數據。
（3）路由計划表。對用戶每天登陸的上網行為和不同行為連接哪個機房，做了一個路由計划表，推送到客戶終端上。當用戶的網絡發生切換，我們就知道這個網絡情況下他應該連到哪里最快。
（4）上傳加速。在全國部署了超過70個上傳加速節點，讓每個用戶都會選擇他最近的上傳節點上傳他的圖片。同時有啟用多端口、多連接的上傳加速能力，可以盡可能的用盡網絡資源，而不是說在一個連接上不停的等待數據包的重傳等各方面的東西。
三、帶寬
計算帶寬要涉及到兩個指標(頁面平均大小、全天pv), 可以從access日志統計到詳細數據。平均流量 = (全天pv/(24*60*60)) * 頁面平均大小。峰值流量 = 平均流量 * 5。需購買的帶寬等於峰值流量。
但是活動日的峰值流量遠不止這個數。2015年微信紅包除夕搖一搖總次數110億次，峰值1400萬次/秒。應對活動日，需提前在活動當天CDN將准備數百G帶寬應對。
四、后台性能。
大型網站不是設計出來的，而是逐步演化出來的。因為互聯網發展運行有其自己的規律，互聯網歷史已經一再證明“一開始就把網站設計成大型的”這種企圖行不通。另外，演化過程中，需要分清當前哪個點是瓶頸，需要知道哪個點優化的優先級最高。所以，技術架構的演進不一定就是按文章從頭到尾這樣列下來的，要視具體情況來下決定。
從一個小網站說起，一台服務器也就足夠了。演進包括如下：
（1） 數據服務器和應用服務器分離。給應用服務器配置更好的 CPU，內存。而給數據服務器配置更好更大的硬盤。
（2）使用緩存。因為 80% 的業務訪問都集中在 20% 的數據上，如果我們能將這部分數據緩存下來，性能一下子就上來了。空數據也要入緩存，否則會增加數據庫的壓力。
（3）nosql。NoSql數據庫大量應用於微博系統等事務性不強的系統。如：BigTable、MongoDB
（4）服務器集群。需要考慮：負載均衡問題? 負載均衡調度服務器，如nginx。Session 的管理問題。如何讓上傳文件這些類似的功能繼續正常？采用文件服務器統一管理。
（5）數據庫讀寫分離。訂閱和發布。實現一個數據訪問模塊使上層寫代碼的人不知道讀寫分離的存在。需要考慮：時延問題。MySQL數據同步是通過binlog日志。延遲問題通過水平拆分服務來提高性能、多線程同步解決。
（6）數據庫拆分。垂直拆分數據庫時，會遇到的問題：跨業務的事務，應用的配置項多了。數據水平拆分會遇到的問題：SQL 的路由問題，需要知道某個 User 在哪個數據庫上。主鍵的策略會有不同。查詢時的性能問題，如分頁問題。
（7）CDN。分布式文件系統使用 CDN 。將網站的內容發布到最接近用戶的網絡”邊緣”，使用戶可以就近取得所需的內容，解決Internet網絡擁塞狀況，提高用戶訪問網站的響應速度。據統計，采用CDN技術，能處理整個網站頁面的 70%～95％的內容訪問量，減輕服務器的壓力，提升了網站的性能和可擴展性。異地部署一般遵循：核心集中，節點分散。如：網宿、睿江、藍訊，將網站內容同步到全國CDN節點，客戶就近訪問CDN服務器。
（8）分布式拆分。網站的業務日益復雜，建立一個獨立的大型應用來完成這所有的業務變得不實際。從管理角度來，也不方便管理。將系統根據職責進行拆分，同時也能采用大量的廉價機器來支撐着巨大的訪問量和數據量。微服務架構的優勢很明顯：耦合度低、技術選型靈活、發布更加高效、故障隔離。拆分會碰到很多的挑戰：1、拆成分布式后需要提供一個高性能、穩定的通信框架，並且需要支持多種不同的通信和遠程調用方式；2、將一個龐大的應用拆分需要耗費很長的時間，需要進行業務的整理和系統依賴關系的控制等；3、如何運維（依賴管理、運行狀況管理、錯誤追蹤、調優、監控和報警等）好這個龐大的分布式應用。
（9）大系統小做。將功能復雜較大的系統，化大為小，減少模塊耦合，降低關聯性。分成一個個高度自制的小系統，形成高內聚低耦合的格局，每個模塊之間不會過分依賴對方，這樣的好處是不會因為任何一個模塊而影響全部服務，避免牽一發動全身的風險，實現真正的灰度服務。
（10） 硬件負載均衡。一台Nginx服務器的軟負載已經無法承擔巨大的web訪問量了，可以用硬件負載解決F5或應用從邏輯上做一定的分類，然后分散到不同的軟負載集群中。
五、業務方式
有些問題用技術手段並不比用業務手段更有效。12306 的分時賣票就是一個典型例子。
（1）前端緩沖請求。比方說在接入層置入搖紅包邏輯，將每秒千萬級請求轉化為每秒萬級的紅包請求，再傳到紅包服務的后端邏輯，降低雪崩的可能性。
（2）后端采用異步分拆。耗時最長的入賬操作，直接跳過，異步處理。如：“當前人數較多，收到的紅包將稍后入賬零錢”
（3）快速拒絕。在客戶端的版本更新中，將相關的指令和策略埋入，當接受數據獲取異常時，在客戶端自動就降低請求頻率，比如一次請求失敗，用戶肯定想二次再刷，但是可能實際上沒有向后端請求，而是直接返回，請客戶稍安勿躁，如果不提前埋入，到有問題時才處理是來不及的。
（4）流量預加載。從客戶端入手，將語音圖片等極消耗流量的資源提前讓客戶端自動下載預置好，提前將流量洪峰疏導。
（5）資源隔離。避免任意一個支路出問題影響整個服務鏈條，這樣即使部分服務出現問題也不會影響到整個服務的崩塌。
（6）根據業務場景降低圖片質量。1、針對不同終端，下載不同質量圖片。2、研究新的編碼格式，使得圖片在基本同等質量情況下再下降30%。3、應用一些漸進式的傳輸技術，你會首先看到模糊的圖，一會兒清晰的圖就會出現。
（7）回滾機制會造成業務邏輯復雜，容易出錯，可能會出現漏洞。我們應該提高服務的簡單性、高可用性，減少出錯率。對於極少的錯誤，后續對日志進行單獨處理即可。
六、最大連接數限制
（1）全程壓測流程，對整個業務鏈接進行自動提前評估，防止過載。
（2）柔性可用要求我們對各種特性一開始就是分好級別（登錄>文本消息>圖片消息>好友狀態呈現>鍵盤活動提示）。
（3）模塊間調用的超時時間如果設置不合理，會導致柔性策略失效。A調用B是300ms超時，B調用C是500ms超時；B對c有柔性，調用c超時的時候會柔性的繼續往下，但是這個沒有意義。
（4）如果成功率高於95%，才可以重試，否則接口層拒絕。
參考文獻：
1、大型網站技術架構的演進 http://news.cnblogs.com/n/518851/
2、高並發Web服務的演變 http://www.admin10000.com/document/6190.html
3、網站服務架構 http://www.cnblogs.com/jiekzou/p/4677994.html
4、微信產品經理和架構師們是靠什么扛住了10億個紅包？ http://www.woshipm.com/pmd/138987.html
5、解密騰訊億級產品背后的網絡架構故事 http://news.idcquan.com/news/66660.shtml
6、為什么Chrome瀏覽器特愛吃內存 http://www.admin10000.com/document/6318.html
7、大型網站技術架構:核心原理與案例分析，李智慧