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

上週沒寫東西，這周寫點互聯網系統開發中須要瞭解的技術點，每一個點均可以發散出去，鏈接更多的知識點，打算作個逐步細化的記錄。

一個應用的整個生命週期中(生，老，病，死)都須要有一個總體規劃.

前期

評估需求，根據需求提煉出其中隱含的非功能性要求，作爲容量評估的參考。通常就是大體估算一下，技術發展到如今，若是是聊天或遊戲應用，隨便一個服務器單機能能維持100W-160W左右的tcp長鏈接並進行通信。因此普通的創業起步階段的應用通常沒必要太擔憂設計問題，能夠等業務量慢慢上來慢慢調整系統架構。

互聯網上許多數不清的小系統上線就是在碰運氣，在精益創業的指導下，爲了測試業務模式，先弄個原型系統上了再說。有時沒用戶，用戶多了又頂不住，要找一羣外援專家來救火，也算是幸福的煩惱。有些移動應用做者本身也不知道爲何忽然就火了，而後又快速消失在市場中。

前端系統設計模式

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

負載均衡

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

Nginx

Nginx：HTTP層負載均衡，反向代理，跑遍全球的選擇。因爲工做在七層上，因此能夠支持對http url級別的轉發。隨便在網上偶遇個bug可能都是曝出一個enginx bad gateway的錯。

LVS

lvs：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的消耗的時間。

最後打在數據庫上數據庫上以前還有大把的活須要作，減小數據庫的負擔。
又十點多了，下次再繼續吧。

---

文章來自微信平臺「麥芽麪包」。轉載請註明。