web系統架構設計中需要知道的點（前端篇）

前期

評估需求，根據需求提煉出其中隱含的非功能性要求，做為容量評估的參考。一般就是大致估算一下，技術發展到現在，如果是聊天或遊戲應用，隨便乙個伺服器單機能能維持100w-160w左右的tcp長連線並進行通訊。所以普通的創業起步階段的應用一般不必太擔心設計問題，可以等業務量慢慢上來慢慢調整系統架構。

網際網路上許多數不清的小系統上線就是在碰運氣，在精益創業的指導下，為了測試業務模式，先弄個原型系統上了再說。有時沒使用者，使用者多了又頂不住，要找一群外援專家來救火，也算是幸福的煩惱。有些移動應用作者自己也不知道為什麼突然就火了，然後又快速消失在市場中。

前端系統設計模式

以http請求到達伺服器的整個處理過程來說明。從伺服器接收到http請求，在整個反應鏈路上直到打到最終資料庫上，每個可能的瓶頸點上都有相應地技術來支撐效能上的優化。

負載均衡

如乙個業務系統使用者有五百萬，需要根據活躍使用者在業務的高峰時期估算最大http請求數量，根據請求量設計前端反向**，負載均衡策略；這塊要考慮常見（軟/硬負載方式）反向**設施的差異性(nginx,lvs,f5,haproxy)

nginx

nginx：http層負載均衡，反向**，跑遍全球的選擇。由於工作在七層上，所以可以支援對http url級別的**。隨便在網上偶遇個bug可能都是曝出乙個enginx bad gateway的錯。

lvslvs：tcp/udp層負載均衡，由於工作在四層，面對的都是連線，處理的都是dst ip,port；src ip，port的東西。

常用的**模式有dr(修改目標位址mac)，流量經過lvs，但ip包的返回不經過lvs，效能較好，lvs不會成為瓶頸。

nat：網路包的進出都要經過lvs，對lvs的負載會比dr模式高。

為了除單點，lvs的高可用需要用keepalived做雙機主備。 f5

硬體產品，**昂貴，**很容易上百萬，有問題找廠家，其實這樣有時找線上找問題反而受到制約。

http快取

均衡器之後就是這裡，這層級的快取是為了減少應用伺服器上大量靜態小檔案(css,js,jpg)的讀取壓力。可選的有varnish,squid等。

squid:老牌產品，支援正向/反向**快取，作為可持久化快取，可以支援較大的容量，有自有的記憶體頁/磁碟頁管理，有些cdn產品也是基於此產品改造。

varnish：設計為記憶體快取，記憶體管理由作業系統控制，對於無持久化需求的靜態檔案效能不錯，如。

ngnix：擴充套件功能不錯，也有個快取模組，不過通常都是快取自身的一些page。

apache traffic server: apache出品，也可作為乙個不錯的選擇。

應用伺服器

反向**之後的應用伺服器數量(tomcat,jetty)要考量應用伺服器本身的處理能力，如常規tomcat基準資料是1000qps,這個只是tomcat在開nio情況下平均的水平。

其處理效能還受到應用程式內處理邏輯，如快取的應用，服務化應用在應用間rpc的消耗的時間。

最後打在資料庫上資料庫上之前還有大把的活需要做，減少資料庫的負擔。