架構層面高併發解決方案選擇----項目架構模式選擇

Web項目，尤爲是面向C端的項目，作到中後期每每要解決高併發的問題。本文經過對三種架構的併發性能分析，爲這一階段的開發和重構提供參考。

基本概念

併發：在操做系統中，是指一個時間段中有幾個程序都處於已啓動運行到運行完畢之間，且這幾個程序都是在同一個處理機上運行，但任一個時刻點上只有一個程序在處理機上運行。

併發訪問：同一時間對系統的訪問。

QPS：每秒請求數。日常所謂的高併發是指QPS值。

 PV：綜合瀏覽量（PageView），即頁面瀏覽量或者點擊量，一個訪客在24小時內訪問的頁面數量。

UV：獨立訪客（UniqueVisitor），即必定時間範圍內相同訪客屢次訪問網站，只計算爲1個獨立訪客。

系統容量預估

預估步驟：

（1）       註冊用戶數-日均UV量-每日的PV量-天天的併發量；

（2）       峯值預估：日常量的2~3倍；

（3）       根據併發量（併發，事務數），存儲容量計算系統容量。

 

項目需求：3~5年用戶數達到1000萬註冊用戶；

 

每秒併發數預估：

（1）       天天的UV爲200萬（二八原則）；

（2）       每日天天點擊瀏覽30次；

（3）       PV量：200*30=6000萬；

（4）       集中訪問量：24*0.2=4.8小時會有6000萬*0.8=4800萬（二八原則）；

（5）       每分併發量：4.8*60=288分鐘，每分鐘訪問4800/288=16.7萬（約等於）；

（6）       每秒併發量：16.7萬/60=2780（約等於）；

（7）       假設：高峯期爲日常值的三倍，則每秒的併發數能夠達到8340次。

（8）       1毫秒=1.3次訪問；

結論：按一臺web服務器，支持每秒1000個併發訪問計算。日常須要3臺服務器， 高峯期須要9臺服務器（不過多考慮硬件和網絡條件）。

 

幾種Web系統架構模式

(一)       單體式架構

打包、部署後，運行在同一臺服務器的同一進程中，功能、代碼和數據集中，這樣的應用稱爲單體式架構應用。

單體式架構應用，應從代碼以及數據庫層面提高併發性能。

 

(二)         集羣架構

計算機集羣簡稱」集羣」，是一種計算機系統，它經過一組鬆散集成的計算機軟件和/或硬件鏈接起來高度緊密地協做完成計算工做。在某種意義上，他們能夠被看做是一臺計算機。集羣系統中的單個計算機一般稱爲節點，一般經過局域網鏈接，但也有其它的可能鏈接方式。集羣計算機一般用來改進單個計算機的計算速度和/或可靠性。通常狀況下集羣計算機比單個計算機，工做站或超級計算機性能價格比要高得多。

爲了提升性能，當單體式架構應用達到當前服務器硬件極限時，應考慮增長服務器的方式，也就是構建服務器和數據庫集羣，來提高併發性能。這種架構，在原有的單體式架構基礎上增長負載均衡層，將原有的代碼部署在多臺服務器上，經過負載均衡層分發請求。單體式架構的項目能夠平滑升級爲集羣架構。另外，集羣架構還具備如下幾個優秀特性。

性價比：幾臺普通服務器能夠勝任價格高昂的單臺高性能服務器的工做

可伸縮性：集羣系統中的結點數目能夠增加到幾千個，乃至上萬個，其伸縮性遠超過單臺超級計算機。當服務器負載壓力增加的時候，系統可以擴展來知足需求，且不下降服務質量。

高可用性：在硬件和軟件上都有冗餘，經過檢測軟硬件的故障，將故障屏蔽，由存活結點提供服務，可實現高可用性。

技術門檻低：相比分佈式架構，集羣架構的不用考慮多進程通信、分佈式事務等棘手問題，技術門檻較低

 

 

 

 

(三)         分佈式（微服務）集羣架構

分佈式（微服務）架構能夠實現將整個項目按業務拆分紅獨立的多個服務（子項目），多個服務能夠獨立部署。這種架構雖然美好，但結構複雜、技術門檻高、開發運維難度大，不適合中小型項目。

另外，大部分分佈式相關技術解決方案和技術文檔，包括分佈式框架、多進程通訊和分佈式事務等，都是親Java的。雖然不能說其餘語言不能作分佈式，可是若是你用的不是Java，並且尚未大佬帶，仍是不要考慮這種架構了。

 

 

 

小結：

根據上面的系統容量預估分析，單體式架構項目運行在一臺普通的服務器上，能夠支撐一百萬註冊用戶的1000併發。在考慮集羣以前，應先作好代碼和數據庫層面的性能提高，也就是作到服務器硬件所能容納併發的極限。

在代碼和數據庫層面作了足夠的優化，用戶數接近單服務器支撐極限時，考慮負載均衡加集羣的架構進一步提高併發性能，固然有實力的團隊能夠直接考慮分佈式架構。