這周寫點互聯網系統開發中需要了解的技術點，每個點都可以發散出去，連接更多的知識點，打算做個逐步細化的記錄。

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

    前期
    評估需求，根據需求提煉出其中隱含的非功能性要求，做為容量評估的參考。一般就是大致估算一下，技術發展到現在，如果是聊天或游戲應用，隨便一個服務器單機能能維持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的消耗的時間。

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