這周寫點互聯(lián)網(wǎng)系統(tǒng)開發(fā)中需要了解的技術(shù)點，每個點都可以發(fā)散出去，連接更多的知識點，打算做個逐步細化的記錄。

    一個應用的整個生命周期中(生，老，病，死)都需要有一個整體規(guī)劃.

    前期
    評估需求，根據(jù)需求提煉出其中隱含的非功能性要求，做為容量評估的參考。一般就是大致估算一下，技術(shù)發(fā)展到現(xiàn)在，如果是聊天或游戲應用，隨便一個服務器單機能能維持100W-160W左右的tcp長連接并進行通訊。所以普通的創(chuàng)業(yè)起步階段的應用一般不必太擔心設計問題，可以等業(yè)務量慢慢上來慢慢調(diào)整系統(tǒng)架構(gòu)。

    互聯(lián)網(wǎng)上許多數(shù)不清的小系統(tǒng)上線就是在碰運氣，在精益創(chuàng)業(yè)的指導下，為了測試業(yè)務模式，先弄個原型系統(tǒng)上了再說。有時沒用戶，用戶多了又頂不住，要找一群外援專家來救火，也算是幸福的煩惱。有些移動應用作者自己也不知道為什么突然就火了，然后又快速消失在市場中。

    前端系統(tǒng)設計模式
    以http請求到達服務器的整個處理過程來說明。從服務器接收到http請求，在整個反應鏈路上直到打到最終數(shù)據(jù)庫上，每個可能的瓶頸點上都有相應地技術(shù)來支撐性能上的優(yōu)化。

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

    Nginx
    Nginx：HTTP層負載均衡，反向代理，跑遍全球的選擇。由于工作在七層上，所以可以支持對http url級別的轉(zhuǎn)發(fā)。隨便在網(wǎng)上偶遇個bug可能都是曝出一個enginx bad gateway的錯。

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

    常用的轉(zhuǎn)發(fā)模式有DR(修改目標地址MAC)，流量經(jīng)過lvs，但ip包的返回不經(jīng)過lvs，性能較好，lvs不會成為瓶頸。

    NAT：網(wǎng)絡包的進出都要經(jīng)過lvs，對lvs的負載會比DR模式高。

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

    F5
    硬件產(chǎn)品，價格昂貴，價格很容易上百萬，有問題找廠家，其實這樣有時找線上找問題反而受到制約。

    http緩存
    均衡器之后就是這里，這層級的緩存是為了減少應用服務器上大量靜態(tài)小文件(css,js,jpg)的讀取壓力。可選的有varnish,squid等。

    Squid:老牌產(chǎn)品，支持正向/反向代理緩存，作為可持久化緩存，可以支持較大的容量，有自有的內(nèi)存頁/磁盤頁管理，有些cdn產(chǎn)品也是基于此產(chǎn)品改造。

    Varnish：設計為內(nèi)存緩存，內(nèi)存管理由操作系統(tǒng)控制，對于無持久化需求的靜態(tài)文件性能不錯，如圖片。

    ngnix：擴展功能不錯，也有個緩存模塊，不過通常都是緩存自身的一些page。

    Apache Traffic Server: Apache出品，也可作為一個不錯的選擇。

    應用服務器
    反向代理之后的應用服務器數(shù)量(tomcat,jetty)要考量應用服務器本身的處理能力，如常規(guī)tomcat基準數(shù)據(jù)是1000qps,這個只是tomcat在開nio情況下平均的水平。

    其處理性能還受到應用程序內(nèi)處理邏輯，如緩存的應用，服務化應用在應用間rpc的消耗的時間。

    最后打在數(shù)據(jù)庫上數(shù)據(jù)庫上之前還有大把的活需要做，減少數(shù)據(jù)庫的負擔。