這次筆記主寫接入層，根據我們的實際項目出發，經驗淺薄，可能有不對之處，還望指出。下回寫邏輯層和存儲層相關的筆記。
首先要知道我們的目的是什么？
- 保證系統的7*24小時可用
- 保證用戶訪問響應時間
- 保證系統的安全性
- 統一接入層，規范應用系統部署
一般而言，有Nginx就可以了，但當流量具有一定規模時候，這樣的架構就變得不穩定了，如：用戶響應時間過長、偶爾來個癱瘓什么的。所以為了提高可用性及整體的吞吐量，會引入接入層，這里使用LVS四層負載均衡，DNS解析到LVS的IP地址，然后LVS轉發至Nginx，最后到后端的RS。如圖：
很多公司都是從開始的單點服務，即一台服務搞定了一切->到后來服務隔離，引入Nginx，保證高可用->Nginx/LVS/F5/HAProxy 進行負載均衡，還有分流、削峰填谷、熱點緩存，這些東西下個筆記會涉及頗多。
我們接着看這張：
看完這張圖你或許會無語，為什么這么搞？LVS+HAProxy+Nginx 這幾個好像可以做同樣的事情，目前使用最廣泛的三種負載均衡軟件都被你們用了，有沒有？其實不然，這層架構體系，也是運維部根據公司具體的業務流量迭代出來的。
先看下訪問過程：
- 用戶在瀏覽器輸入域名回車
- 如果本地緩存里沒有該域名對應的ip地址（瀏覽器緩存+本地緩存，谷歌瀏覽器中輸入：chrome://net-internals/#dns 看到緩存頁面，本地的緩存在hosts中）
- 那么到DNS進行域名解析，DNS將域名的解析權交給CNAME指向的CDN專用DNS服務器
- 為了得到實際IP，瀏覽器向CDN的全局負載均衡設備發起內容URL訪問請求。
- 全局負載均衡DNS根據用戶IP，將當時最接近的節點IP返回給用戶瀏覽器（這里不考慮CDN中設置的URL相關策略）
- 瀏覽器得到IP，進行訪問，然后到LVS這層。
我們知道LVS處於四層，HAProxy基於四層和七層，提供TCP和HTTP應用的負載均衡綜合解決方案，這里我們使用七層。Nginx七層。基於他們各個特點可以去Google一下，這里不做詳細筆記了。四層的負載是根據三層的IP地址（VIP）+四層的端口號來實現，我們實際只實現了高可用並沒有進行負載均衡，真正的負載放到了HAProxy，LVS做了一件事就是分發即分流作用，訪問不同的業務，走不同的服務。后期流量增大可考慮負載，也可以很方便的進行擴展，即它的伸縮性很強。需要認識的一點是請求的響應不走LVS。項目實施LVS/DR+Keepalived實現雙機熱備。
HAProxy實現負載均衡，策略：static-rr根據權重進行輪詢，對HTTP反向代理，設置鏈接拒絕、虛擬主機、會話保持，還有它的監控服務，我們制定的實現當服務異常或宕機之后會向運維部發送短信和郵件，當然，業務服務也一樣，不過有更健全監控系統。從實際效率來講要比Nginx出色的多，且穩定性接近F5。
而Nginx的實現是一個Nginx對應一Tomcat服務，Nginx和Tomact在同一服務器上，每個服務都兩台，進行互備，提高可用性。具體作用如下：緩存功能，增加命中率，減少回源。接口訪問過濾策略，每個接口都會帶有版本號及Token等信息。日志記錄功能，訪問日志，對於這個信息爆炸式的年代，日志重要性不言而喻；錯誤日志，正確的檢測不僅可以發現服務性能的瓶頸，亦可及時發現問題，以及日志分割等。這里可以直接搭建ELK平台，對日志進行友好的查詢和展示。
以上內容，只是我們為什么這么做，並不是應該這么做或者說我們用到的只是它們的一部分功能，可能還有的東西理解不到位。公司使用架構方案是根據網站的規模、不同階段來使用不同的技術。你的QPS就幾十個，有必要選用硬件負載F5、Radware、Array、NetScaler嗎？有錢也需要從實際出發，要不然后期我們優化什么？