一、反向代理
1.面向服務開發
模塊化，解耦的開發，提高團隊合作效率。
2.正向代理與反響代理的區別
代理是的方向是就客戶端而言的，對於翻牆來說，是正向代理，Client訪問不了服務器，這時候需要一個代理服務器代理我們訪問服務器，這就是正向代理，代理服務器代理客戶端。對於分佈式架構業務服務，來說反向代理服務器其實做的是反響代理的工作，因爲反響代理服務器代理的是Client訪問的後臺服務器而不是Client本身，這就是反向代理。
3.存在的意義
在面向服務編程角度來考慮，則是將整體服務進行解耦，模塊化。即便於開發，也便於維護和擴展。而這最終的體現就是成本的降低。
4.可以做反向代理的服務器：
（1）.httpd（tomcat）：httpd是可以做反向代理，但是tomcat是一個容器級別服務器，不是一個輕量級，在高併發性能瓶頸上有着不可避免的缺陷，雖然可以通過硬件強行提升，但是對於成本有着非常高的需求。所以httpd不適合做反向代理
（2）.nginx：nginx是很適合做反向代理，官方給出的併發量是5w，但是阿里封裝的nginx——>tengine可以達到10w很輕鬆（這是業務需求，硬件匹配，服務器參數調優等多方面因素設置得當纔可以達到）。
5.Nginx和Tengine
（1）Nginx和apache的優缺點：
（2）Nginx和apache的模型對比
進程對比：Nginx是CPU有多少個核心，就有多少個進程，而apache則是一個連接一個進程。
二、高併發
1.用別的可以做反向代理的服務器做反向代理存在高併發的問題
-
從業務分佈式解決高併發：我們假設存在一種反向代理服務器（A）也可以承擔5w的併發量，並根據業務功能的不同對搭載不同業務的tomcat做服務分發，這從一定角度上解決了高併發的問題，但是隻是從服務業務的不同角度來解決了高併發問題。
-
從業務分佈式解決不了的高併發：如果客戶端有2000個都是搜索方面的請求，那麼這些流量和請求都會由A轉發給搜索服務器的tomcat，tomcat承受不了2000的併發量，所以會崩潰。這時候就需要在反向代理服務器和搜索服務器tomcat之間搭建負載均衡，並將搜索服務器配置成tomcat集羣。
2.使用nginx做反向代理服務器可以解決負載均衡和反向代理的問題
nginx的特點和可以解決的問題：nginx不僅僅可以做反向代理，還可以做負載均衡，也就是說他是反向代理+LVS。nginx這一特點就可以從業務分佈式角度、單一業務的流量對該業務服務器造成壓力的角度，這兩個角度來解決高併發問題，算是一舉兩得。
3.高併發的體會和理解
高併發問題絕對不是一個從單一角度就可以解決的問題，我們現在所討論的是從服務器架構角度解決高併發問題，這個角度的解決的出發點是客戶端的大量流量會給服務器造成巨大壓力，也會給服務器造成巨大性能損耗，同時也考慮到了I/O速度和數據傳輸流量等問題。高併發的問題會出現在服務器架構和軟件架構的各個分層之間，比如dubbo是解決軟件層面表示層和業務層之間的併發問題，redis則是在業務層和持久層這兩層來解決併發與效率問題，而sql索引和分庫分表和sql語句的書寫則是在持久層這一層解決效率問題。而我們的LVS和nginx則是在網絡流量如何均攤這一層來解決，屬於是在軟件層面外，在操作系統這一層面，網絡傳輸這一層面來解決高併發問題（因爲LVS本身就是linux內核所帶的，nginx工作在應用層也就是要建立TCP連接的）。
三、LVS+nginx的實現負載均衡
1.知識補充
nginx工作流程：如圖1所示，也就是1——4的過程，更加說明nginx是要和客戶端建立握手連接的，這點與LVS是不同的！
用戶體驗：互聯網對3秒比較敏感，如果請求的數據能夠在3秒之內發送到，則用戶體驗會很好，這3秒客戶端和RealServer(RS)之間發生的交互首先是客戶端先和nginx建立連接成功，然後nginx在此基礎上對url進行解析並交給後面RS做業務處理，最後RS將結果返回給nginx，nginx再返回給客戶端。整個過程要3秒內完成。
2.LVS+nginx的優點
- 突破nginx性能瓶頸：nginx是5w，如果併發量是50w呢，這時候則需要部署nginx集羣，並在nginx集羣前部署LVS，nginx數量（10臺）*5w，就可以實現50w的併發量了，如圖1。
- 改善LVS瞎子負載缺點：LVS由於是4層技術，不能建立TCP連接，也就解析不了URL,那麼就不能根據客戶的實際請求做正確的負載均衡（有時候會碰巧碰到LVS做出了正確的負載均衡，是因爲LVS碰巧把數據包轉發給了正確的RealServer，因爲LVS會保持握手>>數據傳輸>>揮手的原子性，所以後續的數據包如果連接沒有中斷，是會正確的返還給客戶端的，但是如果一開始LVS在握手包建立過程中就將數據包發送給了不相匹配的業務的RealServer，則整個連接就錯誤的），而nginx則解決了這一點。
圖1
3.LVS+nginx的缺點
在之前的LVS:DR模型我們可以知道的是，RealServer可以直接向客戶端返回數據包，解決了網絡流帶寬數據傳輸的瓶頸問題。但是LVS+nginx則不可以，數據包只能由nginx返回。因爲LVS:DR模型我們通過MAC地址欺騙和隱藏VIP等方式可以讓客戶端和RealServer直接建立握手連接，那麼Client——RS之間的握手>>數據傳輸>>揮手整個過程是完整獨立的。但是LVS+nginx的負載均衡模型中，客戶端是和nginx之間建立握手連接，nginx和RS之間建立握手連接，那麼客戶端沒有和RS建立TCP連接，則RS不能直接將數據發送給客戶端，只能轉交給nginx，由nginx發送給客戶端，那麼流量的限制就體現在nginx服務器的個數和端口上了，而不是nginx後面數以萬計RS身上了。