高性能背景伺服器架構設計

如何設計高性能的大型網站系統？在移動網際網路時代，用戶端應用開發本身，并不是體驗的決勝之處，真正對團隊挑戰的地方，還在于後端，無論是承壓能力，還是安全性等方面，如果這些地方過不了關，整個應用的基礎是不紮實的。

       提高伺服器性能最簡單粗暴的方式，就是增加機器和更新硬體配置。雖然現在的硬體越來越便宜，但是一味地通過增加機器來解決并發量的增長，成本是非常高昂的。結合技術優化方案，才是更有效的解決方法。

一、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排程方式對緩存進行管理。

       （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、大型網站技術架構:核心原理與案例分析，李智慧