高性能Nginx服務器

高併發與高可用實戰
補充基礎知識
DNS域名解析
整個過程大體描述如下，其中前兩個步驟是在本機完成的，後8個步驟涉及到真正的域名解析服務器：1、瀏覽器會檢查緩存中有沒有這個域名對應的解析過的IP地址，如果緩存中有，這個解析過程就結束。瀏覽器緩存域名也是有限制的，不僅瀏覽器緩存大小有限制，而且緩存的時間也有限制，通常情況下爲幾分鐘到幾小時不等，域名被緩存的時間限制可以通過TTL屬性來設置。這個緩存時間太長和太短都不太好，如果時間太長，一旦域名被解析到的IP有變化，會導致被客戶端緩存的域名無法解析到變化後的IP地址，以致該域名不能正常解析，這段時間內有一部分用戶無法訪問網站。如果設置時間太短，會導致用戶每次訪問網站都要重新解析一次域名。
2、如果用戶瀏覽器緩存中沒有數據，瀏覽器會查找操作系統緩存中是否有這個域名對應的DNS解析結果。其實操作系統也有一個域名解析的過程，在Windows中可以通過C:\Windows\System32\drivers\etc\hosts文件來設置，在Linux中可以通過/etc/hosts文件來設置，用戶可以將任何域名解析到任何能夠訪問的IP地址。例如，我們在測試時可以將一個域名解析到一臺測試服務器上，這樣不用修改任何代碼就能測試到單獨服務器上的代碼的業務邏輯是否正確。正是因爲有這種本地DNS解析的規程，所以有黑客就可能通過修改用戶的域名來把特定的域名解析到他指定的IP地址上，導致這些域名被劫持。
3、前兩個過程無法解析時，就要用到我們網絡配置中的"DNS服務器地址"了。操作系統會把這個域名發送給這個LDNS，也就是本地區的域名服務器。這個DNS通常都提供給用戶本地互聯網接入的一個DNS解析服務，例如用戶是在學校接入互聯網，那麼用戶的DNS服務器肯定在學校；如果用戶是在小區接入互聯網，那麼用戶的DNS就是再提供接入互聯網的應用提供商，即電信或聯通，也就是通常說的SPA，那麼這個DNS通常也會在用戶所在城市的某個角落，不會很遠。Windows環境下通過命令行輸入ipconfig，Linux環境下通過cat /etc/resolv.conf就可以查詢配置的DNS服務器了。這個專門的域名解析服務器性能都會很好，它們一般都會緩存域名解析結果，當然緩存時間是受到域名的失效時間控制的。大約80%的域名解析到這裏就結束了，所以LDNS主要承擔了域名的解析工作。
4、如果LDNS仍然沒有命中，就直接到Root Server域名服務器請求解析
5、根域名服務器返回給本地域名服務器一個所查詢的主域名服務器（gTLD Server）地址。gTLD是國際頂級域名服務器，如.com、.cn、.org等，全球只有13臺左右
6、本地域名服務器LDNS再向上一步返回的gTLD服務器發送請求
7、接受請求的gTLD服務器查找並返回此域名對應的Name Server域名服務器的地址，這個Name Server通常就是用戶註冊的域名服務器，例如用戶在某個域名服務提供商申請的域名，那麼這個域名解析任務就由這個域名提供商的服務器來完成
8、Name Server域名服務器會查詢存儲的域名和IP的映射關係表，在正常情況下都根據域名得到目標IP地址，連同一個TTL值返回給DNS Server域名服務器
9、返回該域名對應的IP和TTL值，LDNS會緩存這個域名和IP的對應關係，緩存時間由TTL值控制
10、把解析的結果返回給用戶，用戶根據TTL值緩存在本地系統緩存中，域名解析過程結束
在實際的DNS解析過程中，可能還不止這10步，如Name Server可能有很多級，或者有一個GTM來負載均衡控制，這都有可能會影響域名解析過程。

高併發與高可用
大型網站系統應有的特點
高併發，大流量
高併發，大流量：需要面對高併發用戶，大流量訪問。舉個例子，去往迪拜的飛機有200張票，但是有100w人都擠進系統買票，如何讓這100w人能夠看到票務的實時更新，以及順利的買到一張票，都是一個網站架構師應該考慮的問題。這也許對於淘寶的“雙十一”1000w的一分鐘獨立訪問用戶量來說，是個微不足道的數字，但是對於用戶的體驗以及網站的口碑來說，都是一項不小的挑戰。
高可用
高可用：相對於高併發來說，高可用並不是一個比較有規律的參數，7*24 是每個網站的夢想，但是你並不知道，在某一刻，他就沒理由的宕機了。
海量數據
海量數據：存儲，管理海量的數據，需要使用大量的服務器。FaceBook每週上傳的照片接近10億，沒有一個大型的存儲服務器的支撐，相信用戶量不會一直飆升。
用戶分佈廣泛，網絡情況複雜
用戶分佈廣泛，網絡情況複雜：許多大型的互聯網都是爲全球用戶提供服務的，用戶分佈範圍廣，各地網絡情況千差萬別。各個運行商之間的互通，各個國家的數據連接等等。
安全環境惡劣
安全環境惡劣：由於互聯網的開放性，使得互聯網更容易受到攻擊，包括各種省份證信息被竊取等事件屢見不鮮。
漸進式發展
漸進式發展：幾乎所有的大型互聯網網站都是從一個小網站開始，漸進發展起來的，好的互聯網產品都是慢慢運營出來的。
網站架構演變過程
傳統架構
傳統項目分爲三層架構，將業務邏輯層、數據庫訪問層、控制層放入在一個項目中 使用SSH或者SSM技術。
優點:適合於個人或者小團隊開發，不適合大團隊開發。
分佈式架構
根據業務需求進行拆分成N個子系統，多個子系統相互協作才能完成業務流程子系統之間通訊使用RPC遠程通訊技術。
優點:
1.把模塊拆分，使用接口通信，降低模塊之間的耦合度。
2.把項目拆分成若干個子項目，不同的團隊負責不同的子項目。
3.增加功能時只需要再增加一個子項目，調用其它系統的接口就可以。
4.可以靈活的進行分佈式部署。
有優點就有缺點，缺點如下：
1.系統之間交互需要使用遠程通信，接口開發增加工作量。
2.各個模塊有一些通用的業務邏輯無法共用。
爲了解決上面分佈式架構的缺點，我們引入了soa架構，SOA：Service Oriented Architecture面向服務的架構。也就是把工程拆分成服務層、表現層兩個工程。服務層中包含業務邏輯，只需要對外提供服務即可。表現層只需要處理和頁面的交互，業務邏輯都是調用服務層的服務來實現。
SOA架構
SOA是一種軟件架構模式，將共同的業務邏輯抽取出來，封裝成單獨的服務
業務系統分解爲多個組件，讓每個組件都獨立提供離散，自治，可複用的服務能力
通過服務的組合和編排來實現上層的業務流程
作用：簡化維護,降低整體風險,伸縮靈活

微服務架構
微服務是指開發一個單個、小型的但有業務的服務，每個服務都有自己的處理和輕通訊機制，可以部署在單個服務器上，讓專業的人做專業的事情。
微服務與SOA相比，更加輕量級。
SOA與微服務架構區別
OA架構主要針對企業級、採用ESB服務（ESB企業服務總線），非常重，需要序列化和反序列化，採用XML格式傳輸。
微服務架構主要互聯網公司，輕量級、小巧，獨立運行，基於Http+Rest+JSON格式傳輸。
ESB也可以說是傳統中間件技術與XML、Web服務等技術相互結合的產物。

1.在微服務中，與SOA不同，服務可以獨立於其他服務進行操作和部署，因此更容易經常部署新版本的服務和獨立擴張服務，讓專業的人做專業的事情，快速迭代新的產品。
2.在SOA中服務可能共享數據存儲，而微服務中每個服務都具有獨立的數據存儲。
3.SOA與微服務主要區別在於規模和範圍，SOA是一種思想，是面向服務架構體系，微服務繼承 了SOA的優點，去除傳統的ESB消息總線，採用Http+json格式通訊方式，更加輕量級。

高併發設計原則
系統設計不僅需要考慮實現業務功能，還要保證系統高併發、高可用、高可靠等。同時還應考慮系統容量規劃（流量、容量等）、SLA指定（吞吐量、響應時間、可用性、降級方案等）、監控報警（機器負載、響應時間、可用率等）、應急預案（容災、降級、限流、隔離、切流量、可回滾等）。

緩存
異步併發
連接池
線程池
擴容
消息隊列
分佈式任務
拆分系統
在我們從零開始做一個新系統的時候，會首先進行系統功能模塊架構設計，那麼是直接做一個大而全的垂直的MVC系統，使用一個war包進行發佈管理，還是需要按一些規則進行模塊拆分，設計成SOA或者微服務系統比較好呢？這個筆者認爲需要依據項目具有什麼樣的人力物力條件以及項目需要支撐多少用戶量和交易量爲基礎。一個好的系統設計應該能夠滿足解決當前的需求和問題，把控實現和進度風險，預測和規劃未來，避免過度設計，在上線一個基礎核心版本之後，再進行不斷迭代和完善。

今天我們來談一談進行SOA、微服務系統架構設計時模塊拆分的一些維度和原則。
系統維度：按照系統功能、業務拆分，如、優惠券、購物車，結算，訂單等系統。
功能維度：對系統功能在做細粒度拆分，優惠券系統分爲 優惠券後臺系統、領券系統、發券系統。
讀寫維度：比如商品系統中，如果查詢量比較大，可以單獨分爲兩個服務，分別爲查詢服務和寫服務,
讀寫比例特徵拆分；讀多，可考慮多級緩存；寫多，可考慮分庫分表.
AOP 維度： 根據訪問特徵，按照 AOP 進行拆分，比如商品詳情頁可分爲 CDN、頁面渲染系統，CDN 就是一個 AOP 系統
模塊維度：對整體代碼結構劃分 Web、Service、DAO

服務化
在分佈式系統中，將業務邏輯層封裝成接口形式，暴露給其他系統調用，那麼這個接口我們可以理解爲叫做服務。
當服務越來越多的時候，就會需要用到服務治理，那麼會用到Dubbo、SpringCloud服務治理框架
後續在深入Dubbo和SpringCloud中會詳細講到。

服務化演進: 進程內服務-單機遠程服務-集羣手動註冊服務-自動註冊和發現服務-服務的分組、隔離、路由-服務治理
考慮服務分組、隔離、限流、黑白名單、超時、重試機制、路由、故障補償等
實踐：利用 Nginx、HaProxy、LVS 等實現負載均衡，ZooKeeper、Consul 等實現自動註冊和發現服務
消息隊列
消息中間件是一個客戶端與服務器異步通訊框架，消息中間件中分爲點對點與發佈訂閱通訊方式，生產者發送消息後，消費者可以無需等待， 異步接受生產者發送消息。
在電商系統中，會使用消息隊列異步推送消息，注意消息失敗重試冪等性問題。
冪等性問題解決方案，使用持久化日誌+全局id記錄。
緩存技術
瀏覽器端緩存
APP客戶端緩存
CDN(Content Delivery Network)緩存
接入層緩存
應用層緩存
分佈式緩存
對於兜底數據或者異常數據，不應該讓其緩存，否則用戶會在很長一段時間裏看到這些數據。
併發化
改串行爲並行。
高可用設計原則

通過負載均衡和反向代理實現分流。
通過限流保護服務免受雪崩之災。
通過降級實現部分可用、有損服務。
通過隔離實現故障隔離。
通過合理設置的超時與重試機制避免請求堆積造成雪崩。
通過回滾機制快速修復錯誤版本。
降級
對於高可用服務，很重要的一個設計就是降級開關，在設計降級開關時，主要依據如下思路：
1.開關集中化管理：通過推送機制把開關推送到各個應用。
2.可降級的多級讀服務：比如服務調用降級爲只讀本地緩存、只讀分佈式緩存、只讀默認降級數據（如庫存狀態默認有貨）。
3.開關前置化：如架構是Nginx–>tomcat，可以將開關前置到Nginx接入層，在Nginx層做開關，請求流量回源後端應用或者只是一小部分流量回源。
4.業務降級：當高併發流量來襲，在電商系統大促設計時保障用戶能下單、能支付是核心要求，並保障數據最終一致性即可。這樣就可以把一些同步調用改成異步調用，優先處理高優先級數據或特殊特徵的數據，合理分配進入系統的流量，以保障系統可用。

限流
目的: 防止惡意請求攻擊或超出系統峯值
實踐：
惡意請求流量只訪問到 Cache
穿透後端應用的流量使用 Nginx 的 limit 處理
惡意 IP 使用 Nginx Deny 策略或者 iptables 拒絕

切流量
目的：屏蔽故障機器
實踐:
DNS: 更改域名解析入口，如 DNSPOD 可以添加備用 IP，正常 IP 故障時，會自主切換到備用地址; 生效實踐較慢
HttpDNS: 爲了繞過運營商 LocalDNS 實現的精準流量調度
LVS/HaProxy/Nginx: 摘除故障節點

可回滾
發佈版本失敗時可隨時快速回退到上一個穩定版本

業務設計原則
防重設計
頁面請求防止重複提交，可以採用防重key、放重表、Token等
採用圖形驗證，防止機器攻擊。
冪等設計
消息中間件:消息中間件中應該注意因網絡延遲的原因，導致消息重複消費
第三方支付接口:在回調接口中，應該注意網絡延遲，沒有及時返回給第三方支付平臺，注意回調冪等性問題。
分佈式系統中，保證生成的訂單號唯一性，定時Job執行的冪等性問題等。

流程定義
複用流程系統，提供個性化的流程服務。
狀態與狀態機
複用流程系統，提供個性化的流程服務。
後臺系統操作可反饋
設計後臺系統時，考慮效果的可預覽、可反饋。
後臺系統審批化
對於有些重要的後臺功能需要設計審批流，比如調整價格，並對操作進行日誌記錄，從而保證操作可追溯、可審計。
文檔註釋
系統發展的最初階段就應該有文檔庫（設計架構、設計思想、數據字典/業務流程、現有問題），業務代碼合特殊需求都要有註釋。
備份
包括代碼和人員的備份。代碼主要提交到代碼倉庫進行管理和備份，代碼倉庫至少應該具備多版本的功能。人員備份指的是一個系統至少應該有兩名開發人員是瞭解的。

環境準備
CentOS7 7.0 64位 以上+一臺外網服務器+一個域名+CDN內容分發
電腦配置 16g以上內存
CentOS7 關閉防火牆

//臨時關閉
systemctl stop firewalld
//禁止開機啓動
systemctl disable firewalld
Removed symlink /etc/systemd/system/multi-user.target.wants/firewalld.service.
Removed symlink /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service.

查詢nginx 進程
ps aux | grep ‘nginx’

殺死進程方式關閉nginx
kill -9 2363

停止nginx服務器
/usr/local/nginx/sbin/nginx -s stop

重啓nginx
/usr/local/nginx/sbin/nginx -s reload

啓動nginx

負載均衡與反向代理

外網映射工具

在做微信開發或者是對接第三方支付接口時，回調接口可能需要外網訪問。
這時候開發者在本地測試的時候，需要用到外網測試工具。
常用的外網測試工具有natapp、ngrok
NatApp簡介
服務器更新:全面支持HTTPS協議以及本地SSL證書,支持WSS協議.同時支持HTTP/2 WEB協議,支持微信小程序本地開發
全面自動支持泛子域名與訪客真實IP地址
Windows用法 natapp -authtoken=9ab6b9040a624f40

相關文檔https://natapp.cn/

負載均衡
負載均衡 建立在現有網絡結構之上，它提供了一種廉價有效透明的方法擴展網絡設備和服務器的帶寬、增加吞吐量、加強網絡數據處理能力、提高網絡的靈活性和可用性。
負載均衡，英文名稱爲Load Balance，其意思就是分攤到多個操作單元上進行執行，例如Web服務器、FTP服務器、企業關鍵應用服務器和其它關鍵任務服務器等，從而共同完成工作任務。
Nginx
Nginx是一款輕量級的Web 服務器/反向代理服務器及電子郵件(IMAP/POP3)代理服務器，並在一個BSD-like 協議下發行。由俄羅斯的程序設計師Igor Sysoev所開發，供俄國大型的入口網站及搜索引擎Rambler(俄文：Рамблер)使用。其特點是佔有內存少，併發能力強，事實上nginx的併發能力確實在同類型的網頁服務器中表現較好.中國大陸使用nginx網站用戶有：新浪、網易、 騰訊等。
Nginx 是一個高性能的 Web 和反向代理服務器, 它具有有很多非常優越的特性:
作爲 Web 服務器：相比 Apache，Nginx 使用更少的資源，支持更多的併發連接，體現更高的效率，這點使 Nginx 尤其受到虛擬主機提供商的歡迎。能夠支持高達 50,000 個併發連接數的響應，感謝 Nginx 爲我們選擇了 epoll and kqueue 作爲開發模型.
作爲負載均衡服務器：Nginx 既可以在內部直接支持 Rails 和 PHP，也可以支持作爲 HTTP代理服務器 對外進行服務。Nginx 用 C 編寫, 不論是系統資源開銷還是 CPU 使用效率都比 Perlbal 要好的多。
作爲郵件代理服務器: Nginx 同時也是一個非常優秀的郵件代理服務器（最早開發這個產品的目的之一也是作爲郵件代理服務器），Last.fm 描述了成功並且美妙的使用經驗。
Nginx 安裝非常的簡單，配置文件 非常簡潔（還能夠支持perl語法），Bugs非常少的服務器: Nginx 啓動特別容易，並且幾乎可以做到7*24不間斷運行，即使運行數個月也不需要重新啓動。你還能夠在 不間斷服務的情況下進行軟件版本的升級。
Nginx一般用戶七層負載均衡，其吞吐量有一定的限制。爲了提高整體的吞吐量，會在DNS和Nginx之間引入LVS（軟件負載均衡器）、F5（硬負載均衡器） 可以做四層負載均衡，首先DNS解析到LVS(F5)，讓後LVS(F5)轉發給Nginx，在有Nginx轉發給真實的服務器

Nginx基本安裝
Windows安裝Nginx
解壓:nginx-windows
雙擊: nginx.exe

能看到nginx歡迎界面說明,nginx安裝成功
演示下 nginx做靜態服務器

啓動Nginx
C:\server\nginx-1.0.2>start nginx
或
C:\server\nginx-1.0.2>nginx.exe
注：建議使用第一種，第二種會使你的cmd窗口一直處於執行中，不能進行其他命令操作。
停止Nginx

Linux安裝Nginx

1.安裝gcc gcc-c++(如新環境,未安裝請先安裝)
$ yum install -y gcc gcc-c++
2.安裝wget
$ yum -y install wget

3.安裝PCRE庫
$ cd /usr/local/
$ wget http://jaist.dl.sourceforge.net/project/pcre/pcre/8.33/pcre-8.33.tar.gz
$ tar -zxvf pcre-8.33.tar.gz
$ cd pcre-8.33
$ ./configure
$ make && make install
如果報錯:

在 linux 中執行 wget 命令提示 -bash: wget: command not found 解決方法
解決辦法 yum -y install wget

5.安裝SSL庫
$ cd /usr/local/
$ wget http://www.openssl.org/source/openssl-1.0.1j.tar.gz
$ tar -zxvf openssl-1.0.1j.tar.gz
$ cd openssl-1.0.1j
$ ./config
$ make && make install

6.安裝zlib庫存

$ cd /usr/local/
$ wget http://zlib.net/zlib-1.2.11.tar.gz
$ tar -zxvf zlib-1.2.11.tar.gz
$ cd zlib-1.2.11
$ ./configure
$ make && make install

5.安裝nginx
$ cd /usr/local/
$ wget http://nginx.org/download/nginx-1.8.0.tar.gz
$ tar -zxvf nginx-1.8.0.tar.gz
$ cd nginx-1.8.0
$ ./configure
$ make && make install

6.啓動nginx
/usr/local/nginx/sbin/nginx
ps -aux | grep ‘nginx’

Nginx應用場景
1、http服務器。Nginx是一個http服務可以獨立提供http服務。可以做網頁靜態服務器。
2、虛擬主機。可以實現在一臺服務器虛擬出多個網站，例如個人網站使用的虛擬機。
3、反向代理，負載均衡。當網站的訪問量達到一定程度後，單臺服務器不能滿足用戶的請求時，需要用多臺服務器集羣可以使用nginx做反向代理。並且多臺服務器可以平均分擔負載，不會應爲某臺服務器負載高宕機而某臺服務器閒置的情況。
4、nginz 中也可以配置安全管理、比如可以使用Nginx搭建API接口網關,對每個接口服務進行攔截。

Nginx目錄結構
Nginx-
|_ conf 配置目錄
|_ contrib
|_ docs 文檔目錄
|_ logs 日誌目錄
|_ temp 臨時文件目錄
|_ html 靜態頁面目錄
|_ nginx.exe 主程序
Nginx靜態資源

靜態資源訪問 存放在nginx的html頁面

Nginx虛擬主機配置
1、基於域名的虛擬主機，通過域名來區分虛擬主機——應用：外部網站
2、基於端口的虛擬主機，通過端口來區分虛擬主機——應用：公司內部網站，外部網站的管理後臺
3、基於ip的虛擬主機，幾乎不用。
基於虛擬主機配置域名
實現步驟:
需要建立/data/www /data/bbs目錄，windows本地hosts添加虛擬機ip地址對應的域名解析；對應域名網站目錄下新增index.html文件；

#當客戶端訪問www.test.com,監聽端口號爲80,直接跳轉到data/www目錄下文件
server {
    listen       80;
    server_name  www.test.com;
    location / {
        root   data/www;
        index  index.html index.htm;
    }
}
#當客戶端訪問www.test.com,監聽端口號爲80,直接跳轉到data/bbs目錄下文件
 server {
    listen       80;
    server_name  bbs.test.com;
    location / {
        root   data/bbs;
        index  index.html index.htm;
    }
}

基於端口的虛擬主機
使用端口來區分，瀏覽器使用域名或ip地址:端口號 訪問
#當客戶端訪問www.test.com,監聽端口號爲8080,直接跳轉到data/www目錄下文件
server {
listen 8080;
server_name 8080.test.com;
location / {
root data/www;
index index.html index.htm;
}
}

#當客戶端訪問www.test.com,監聽端口號爲8081,直接跳轉到data/bbs目錄下文件
 server {
    listen       8081;
    server_name  8081.test.com;
    location / {
        root   data/bbs;
        index  index.html index.htm;
    }
}

Nginx配置反向代理
反向代理的作用
反向代理（Reverse Proxy）方式是指以代理服務器來接受internet上的連接請求，然後將請求轉發給內部網絡上的服務器，並將從服務器上得到的結果返回給internet上請求連接的客戶端，此時代理服務器對外就表現爲一個反向代理服務器。
啓動一個Tomcat 127.0.0.1:8080
使用nginx反向代理 8080.test.com 直接跳轉到127.0.0.1:8080

反向代理的好處
反向代理的好處隱藏真實內部ip地址，請求先訪問nginx代理服務器（外網可以訪問到）,在使用nginx服務器轉發到真實服務器中。

反向代理的配置

###當客戶端訪問www.test.com,監聽端口號爲80直接跳轉到真實ip服務器地址 127.0.0.1:8080
server {
listen 80;
server_name www.test.com;
location / {
proxy_pass http://127.0.0.1:8080;
index index.html index.htm;
}
}
###當客戶端訪問www.test.com,監聽端口號爲80直接跳轉到真實ip服務器地址 127.0.0.1:8081
server {
listen 80;
server_name 8081.test.com;
location / {
proxy_pass http://127.0.0.1:8081;
index index.html index.htm;
}
}

Location正則表達式
location的作用
location指令的作用是根據用戶請求的URI來執行不同的應用，也就是根據用戶請求的網站URL進行匹配，匹配成功即進行相關的操作。
location的語法
已=開頭表示精確匹配
如 A 中只匹配根目錄結尾的請求，後面不能帶任何字符串。
^~ 開頭表示uri以某個常規字符串開頭，不是正則匹配
~ 開頭表示區分大小寫的正則匹配;
~* 開頭表示不區分大小寫的正則匹配
/ 通用匹配, 如果沒有其它匹配,任何請求都會匹配到
Location正則案例
#精確匹配,/後面不能帶任何字符
server {
listen 80;
server_name www.test.com;
#精確匹配,註解後面不能帶任何字符
location =/ {
proxy_pass http://127.0.0.1:8080;
index index.html index.htm;
}
}

#匹配所有以/開頭請求
server {
listen 80;
server_name www.test.com;
#匹配所有以/開頭請求
location / {
proxy_pass http://127.0.0.1:8080;
index index.html index.htm;
}
}

以開頭/test_8080攔截 默認開啓不區分大小寫

server {
    listen       80;
    server_name  www.test.com;
	###  以開頭/test_8080 最終跳轉到http://127.0.0.1:8080/;
    location /test_8080/ {
	    proxy_pass http://127.0.0.1:8080/;
        index  index.html index.htm;
    }
	###  以開頭/test_8080 最終跳轉到http://127.0.0.1:8081/;
	location /test_8081/ {
	    proxy_pass http://127.0.0.1:8081/;
        index  index.html index.htm;
    }
}

開頭區分大小寫

負載均衡的作用

負載均衡 建立在現有網絡結構之上，它提供了一種廉價有效透明的方法擴展網絡設備和服務器的帶寬、增加吞吐量、加強網絡數據處理能力、提高網絡的靈活性和可用性。
負載均衡，英文名稱爲Load Balance，其意思就是分攤到多個操作單元上進行執行，例如Web服務器、FTP服務器、企業關鍵應用服務器和其它關鍵任務服務器等，從而共同完成工作任務。
負載均衡就是，將所有請求先到負載均衡器，在由負載均衡器採用負載均衡算法（輪訓、IP綁定、權重）分發到不同實際的服務器中，這也就是服務器集羣，集羣的目的 是爲了減輕單臺服務器壓力

負載均衡的缺點
使用負載均衡後，實際用到的服務器會被集羣多臺，那麼這時候就會產生很多分佈式相關問題。
比如：
分佈式Session一致性問題
分佈式定時任務調度冪等性問題
分佈式生成全局訂單ID

網絡模型圖

四層和七層負載均衡的區別
四層負載均衡，在網絡模型中的傳輸層中，基於主要是基於tcp協議報文實現負載均衡（比如LVS、haproxy就是四層負載均衡器），使用改寫報文的源地址和目的地址。

七層負載均衡,在網絡模型中應用層中，基於URL或者HTTP協議實現負載均衡，Web服務器。

Upstream Server 負載均衡
Upstream Server 中文翻譯 上游服務器，意思就是負載均衡服務器設置，白話文表示(就是被nginx代理最後真實訪問的服務器)
負載均衡算法：配置多個上游服務器(真實業務邏輯訪問的服務器)的負載均衡機制
失敗重試機制:當上遊服務器(真實業務邏輯訪問的服務器)出現超時或者服務器不存活，是否考慮重試機制(補償機制)
服務器心跳檢測: 當上遊服務器(真實業務邏輯訪問的服務器),監控檢測|心跳檢測

Nginx配置負載均衡
Nginx負載均衡提供上游服務器(真實業務邏輯訪問的服務器),負載均衡、故障轉移、失敗重試、容錯、健康檢查等。
當上遊服務器(真實業務邏輯訪問的服務器)發生故障時，可以轉移到其他上游服務器(真實業務邏輯訪問的服務器)。
Upstream Server配置
upstream 主要配置如下:
IP地址和端口號：配置上游服務器的IP地址和端口
###定義上游服務器(需要被nginx真實代理訪問的服務器) 默認是輪訓機制
upstream backServer{
server 127.0.0.1:8080;
server 127.0.0.1:8081;
}

server {
    listen       80;
    server_name  www.test.com;
    location / {
	    ### 指定上游服務器負載均衡服務器
	    proxy_pass http://backServer;
        index  index.html index.htm;
    }
}

負載均衡算法
1、輪詢（默認）
每個請求按時間順序逐一分配到不同的後端服務，如果後端某臺服務器死機，自動剔除故障系統，使用戶訪問不受影響。
2、weight（輪詢權值）
weight的值越大分配到的訪問概率越高，主要用於後端每臺服務器性能不均衡的情況下。或者僅僅爲在主從的情況下設置不同的權值，達到合理有效的地利用主機資源。
3、ip_hash
每個請求按訪問IP的哈希結果分配，使來自同一個IP的訪客固定訪問一臺後端服務器，並且可以有效解決動態網頁存在的session共享問題。俗稱IP綁定。

4、fair（第三方）
比 weight、ip_hash更加智能的負載均衡算法，fair算法可以根據頁面大小和加載時間長短智能地進行負載均衡，也就是根據後端服務器的響應時間 來分配請求，響應時間短的優先分配。Nginx本身不支持fair，如果需要這種調度算法，則必須安裝upstream_fair模塊。

5、url_hash(第三方)
按訪問的URL的哈希結果來分配請求，使每個URL定向到一臺後端服務器，可以進一步提高後端緩存服務器的效率。Nginx本身不支持url_hash，如果需要這種調度算法，則必須安裝Nginx的hash軟件包。
輪詢（默認）
每個請求按時間順序逐一分配到不同的後端服務，如果後端某臺服務器死機，自動剔除故障系統，使用戶訪問不受影響。

權重Weight
upstream backServer{
server 127.0.0.1:8080 weight=1;
server 127.0.0.1:8081 weight=2;
}

server {
    listen       80;
    server_name  www.test.com;
    location / {
	    ### 指定上游服務器負載均衡服務器
	 proxy_pass http://backServer;
        index  index.html index.htm;
    }
}

IP綁定ip_hash
每個請求按訪問IP的哈希結果分配，使來自同一個IP的訪客固定訪問一臺後端服務器，並且可以有效解決動態網頁存在的session共享問題。俗稱IP綁定。

upstream backServer{
server 127.0.0.1:8080 ;
server 127.0.0.1:8081 ;
ip_hash;
}

server {
    listen       80;
    server_name  www.test.com;
    location / {
	    ### 指定上游服務器負載均衡服務器
	    proxy_pass http://backServer;
        index  index.html index.htm;
    }
}

Nginx配置故障轉移
當上遊服務器(真實訪問服務器),一旦出現故障或者是沒有及時相應的話，應該直接輪訓到下一臺服務器，保證服務器的高可用。
Nginx配置代碼
server {
listen 80;
server_name www.test.com;
location / {
### 指定上游服務器負載均衡服務器
proxy_pass http://backServer;
###nginx與上游服務器(真實訪問的服務器)超時時間 後端服務器連接的超時時間_發起握手等候響應超時時間
proxy_connect_timeout 1s;
###nginx發送給上游服務器(真實訪問的服務器)超時時間
proxy_send_timeout 1s;
### nginx接受上游服務器(真實訪問的服務器)超時時間
proxy_read_timeout 1s;
index index.html index.htm;
}
}

nginx rewrite

Nginx提供的全局變量或自己設置的變量，結合正則表達式和標誌位實現url重寫以及重定向。rewrite只能放在server{},location{},if{}中，並且只能對域名後邊的除去傳遞的參數外的字符串起作用。
Rewrite主要的功能就是實現URL的重寫，Nginx的Rewrite規則採用Pcre，perl兼容正則表達式的語法規則匹配，如果需要Nginx的Rewrite功能，在編譯Nginx之前，需要編譯安裝PCRE庫。
通過Rewrite規則，可以實現規範的URL、根據變量來做URL轉向及選擇配置。
Rewrite全局變量
nginx的rewrite規則就是使用正則匹配請求的url，然後根據定義的規則進行重寫和改變，需ngx_http_rewrite_module模塊來支持url重寫功能，該模塊是標準模塊，默認已經安裝。

判斷IP地址來源

如果訪問的ip地址爲192.168.5.165,則返回403

 if  ($remote_addr = 192.168.5.166) {  
     return 403;  
 }  

限制瀏覽器訪問

不允許谷歌瀏覽器訪問 如果是谷歌瀏覽器返回500

if ($http_user_agent ~ Chrome) {
return 500;
}

Linux 環境下 使用Nginx
Linux 環境下修改host文件
host文件位置：/etc/hosts
vi /etc/hosts即可編輯
修改方式類似windows.
Linux 環境下配置負載均衡

###定義上游服務器(需要被nginx真實代理訪問的服務器) 默認是輪訓機制
upstream backServer{
server 192.168.212.1:8080;
server 192.168.212.1:8081;
}
server {
listen 80;
server_name www.test.com;
location / {
### 指定上游服務器負載均衡服務器
proxy_pass http://backServer;
index index.html index.htm;
}
}

Windows 環境配置DNS解析到Linux
host文件新增: 192.168.212.128 www.test.com

阿里雲環境配置Nginx
http://seo.chinaz.com/meitedu.com 查詢網站信息

準備環境

備課環境域名
客戶端輸入testbbs. meitedu.com.com 使用Nginx 轉發到 bbs.test.com
客戶端輸入testwww. test.com.com使用Nginx 轉發到bbs.test.com

上課環境域名
案例域名:test.com 對應生產環境Linux服務器 103.218.2.206
需求:
客戶端輸入testbbs.test.com.com 使用Nginx 轉發到 bbs.test.com
客戶端輸入testwww. meitedu.com.com使用Nginx 轉發到bbs.test.com

阿里雲服務器上安裝Nginx配置
### 配置 beikewww.test.com 反向代理跳轉到http://www.
server {
listen 80;
server_name beikewww.test.com;

    location / {
        proxy_pass http://www.test.com;
        index  index.html index.htm;
    }
}
	### 配置 beikebbs.test.com 反向代理跳轉到http://www.test.com
  server {
    listen       80;
    server_name  beikebbs.test.com;
    location / {
        proxy_pass http://bbs.test.com;
        index  index.html index.htm;
    }
}

域名配置二級域名DNS解析

Http動態負載均衡
什麼是動態負載均衡
傳統的負載均衡，如果Upstream參數發生變化，每次都需要重新加載nginx.conf文件,
因此擴展性不是很高，所以我們可以採用動態負載均衡，實現Upstream可配置化、動態化，無需人工重新加載nginx.conf。
這類似分佈式的配置中心

動態負載均衡實現方案

1. Consul+Consul-template
   每次發現配置更改需要raload nginx，重啓Nginx。
2. Consul+OpenResty 實現無需raload動態負載均衡
3. Consul+upsync+Nginx 實現無需raload動態負載均衡

常用服務器註冊與發現框架
常見服務發現框架 Consul、Eureka、 ZooKeeper以及Etcd ZooKeeper是這種類型的項目中歷史最悠久的之一，它起源於Hadoop。它非常成熟、可靠，被許多大公司（YouTube、eBay、雅虎等）使用。
etcd是一個採用HTTP協議的健/值對存儲系統，它是一個分佈式和功能層次配置系統，可用於構建服務發現系統。其很容易部署、安裝和使用，提供了可靠的數據持久化特性。它是安全的並且文檔也十分齊全。
Consul快速入門
Consul是一款開源的分佈式服務註冊與發現系統，通過HTTP API可以使得服務註冊、發現實現起來非常簡單，它支持如下特性。

服務註冊：服務實現者可以通過HTTP API或DNS方式，將服務註冊到Consul。
服務發現：服務消費者可以通過HTTP API或DNS方式，從Consul獲取服務的IP和PORT。
故障檢測：支持如TCP、HTTP等方式的健康檢查機制，從而當服務有故障時自動摘除。
K/V存儲：使用K/V存儲實現動態配置中心，其使用HTTP長輪詢實現變更觸發和配置更改。
多數據中心：支持多數據中心，可以按照數據中心註冊和發現服務，即支持只消費本地機房服務，使用多數據中心集羣還可以避免單數據中心的單點故障。
Raft算法：Consul使用Raft算法實現集羣數據一致性。
通過Consul可以管理服務註冊與發現，接下來需要有一個與Nginx部署在同一臺機器的Agent來實現Nginx配置更改和Nginx重啓功能。我們有Confd或者Consul-template兩個選擇，而Consul-template是Consul官方提供的，我們就選擇它了。其使用HTTP長輪詢實現變更觸發和配置更改（使用Consul的watch命令實現）。也就是說，我們使用Consul-template實現配置模板，然後拉取Consul配置渲染模板來生成Nginx實際配置。
Consul環境搭建

1.下載consul_0.7.5_linux_amd64.zip
wget https://releases.hashicorp.com/consul/0.7.5/consul_0.7.5_linux_amd64.zip

2.解壓consul_0.7.5_linux_amd64.zip
unzip consul_0.7.5_linux_amd64.zip
如果解壓出現該錯誤
-bash: unzip: 未找到命令
解決辦法
yum -y install unzip

3. 執行以下 ./consul 出現以下信息就說明安裝成功
   [root@localhost soft] ./consul
   usage: consul [–version] [–help] []
   Available commands are:
   agent Runs a Consul agent
   configtest Validate config file
   event Fire a new event
   exec Executes a command on Consul nodes
   force-leave Forces a member of the cluster to enter the “left” state
   info Provides debugging information for operators
   join Tell Consul agent to join cluster
   keygen Generates a new encryption key
   keyring Manages gossip layer encryption keys
   kv Interact with the key-value store
   leave Gracefully leaves the Consul cluster and shuts down
   lock Execute a command holding a lock
   maint Controls node or service maintenance mode
   members Lists the members of a Consul cluster
   monitor Stream logs from a Consul agent
   operator Provides cluster-level tools for Consul operators
   reload Triggers the agent to reload configuration files
   rtt Estimates network round trip time between nodes
   snapshot Saves, restores and inspects snapshots of Consul server state
   version Prints the Consul version
   watch Watch for changes in Consul

4.啓動consul
我的linux Ip地址192.168.212.131
./consul agent -dev -ui -node=consul-dev -client=192.168.212.131

5.臨時關閉防火牆systemctl stop firewalld

6.瀏覽器訪問192.168.212.131:8500

7.使用PostMan 註冊Http服務
http://192.168.212.131:8500/v1/catalog/register
參數1
{“Datacenter”: “dc1”,
“Node”:“tomcat”, “Address”:“192.168.5.165”,“Service”: {“Id” :“192.168.5.165:8080”, “Service”: “test”,“tags”: [“dev”], “Port”: 8080}}
參數2
{“Datacenter”: “dc1”, “Node”:“tomcat”, “Address”:“192.168.5.165”,“Service”: {“Id” :“192.168.5.165:8081”, “Service”: “test”,“tags”: [“dev”], “Port”: 8081}}

Datacenter指定數據中心，Address指定服務IP，Service.Id指定服務唯一標識，Service.Service指定服務分組，Service.tags指定服務標籤（如測試環境、預發環境等），Service.Port指定服務端口。

7.發現Http服務
http://192.168.212.131:8500/v1/catalog/service/item_jd_tomcat

nginx-upsync-module
注意：清除之前Nginx環境，重新安裝。

nginx-upsync-module簡介
Upsync是新浪微博開源的基於Nginx實現動態配置的三方模塊。Nginx-Upsync-Module的功能是拉取Consul的後端server的列表，並動態更新Nginx的路由信息。此模塊不依賴於任何第三方模塊。Consul作爲Nginx的DB，利用Consul的KV服務，每個Nginx Work進程獨立的去拉取各個upstream的配置，並更新各自的路由。
nginx-upsync-module安裝
下載文件

1. 安裝Nginx
   wget http://nginx.org/download/nginx-1.9.10.tar.gz
   作用:實現反向代理、負載負載庫
2. 安裝consul
   wget https://releases.hashicorp.com/consul/0.7.1/consul_0.7.1_linux_amd64.zip
   作用:對動態負載均衡均配置實現註冊
3. 安裝nginx-upsync-module
   wget https://github.com/weibocom/nginx-upsync-module/archive/master.zip
   作用:nginx動態獲取最新upstream信息
   解壓安裝
   unzip master.zip
   unzip consul_0.7.1_linux_amd64.zip
   如果解壓出現該錯誤
   -bash: unzip: 未找到命令
   解決辦法
   yum -y install unzip

安裝Nginx
解壓Nginx

tar -zxvf nginx-1.9.10.tar.gz

配置Nginx

groupadd nginx
useradd -g nginx -s /sbin/nologin nginx
mkdir -p /var/tmp/nginx/client/
mkdir -p /usr/local/nginx

編譯Nginx

cd nginx-1.9.0

./configure --prefix=/usr/local/nginx --user=nginx --group=nginx --with-http_ssl_module --with-http_flv_module --with-http_stub_status_module --with-http_gzip_static_module --with-http_realip_module --http-client-body-temp-path=/var/tmp/nginx/client/ --http-proxy-temp-path=/var/tmp/nginx/proxy/ --http-fastcgi-temp-path=/var/tmp/nginx/fcgi/ --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi --http-scgi-temp-path=/var/tmp/nginx/scgi --with-pcre --add-module=…/nginx-upsync-module-master
make && make install

編譯的是報錯
./configure: error: SSL modules require the OpenSSL library.
解決辦法
yum -y install openssl openssl-devel
Upstream 動態配置
##動態去consul 獲取註冊的真實反向代理地址
upstream test{
server 127.0.0.1:11111;
upsync 192.168.212.134:8500/v1/kv/upstreams/test upsync_timeout=6m upsync_interval=500ms upsync_type=consul strong_dependency=off;
upsync_dump_path /usr/local/nginx/conf/servers/servers_test.conf;
}

server {
    listen       80;
    server_name  localhost;

    location / {
        proxy_pass http://test;
        index  index.html index.htm;
    }
}

upsync指令指定從consul哪個路徑拉取上游服務器配置；upsync_timeout配置從consul拉取上游服務器配置的超時時間；upsync_interval配置從consul拉取上游服務器配置的間隔時間；upsync_type指定使用consul配置服務器；strong_dependency配置nginx在啓動時是否強制依賴配置服務器，如果配置爲on，則拉取配置失敗時nginx啓動同樣失敗。upsync_dump_path指定從consul拉取的上游服務器後持久化到的位置，這樣即使consul服務器出問題了，本地還有一個備份。
注意:替換 consul 註冊中心地址
創建upsync_dump_path
mkdir /usr/local/nginx/conf/servers/
upsync_dump_path指定從consul拉取的上游服務器後持久化到的位置，這樣即使consul服務器出問題了，本地還有一個備份。
啓動consul
臨時關閉防火牆systemctl stop firewalld
我的linux Ip地址192.168.212.131
./consul agent -dev -ui -node=consul-dev -client=192.168.212.131

添加nginx Upstream服務
1.使用linux命令方式發送put請求
curl -X PUT http://192.168.212.134:8500/v1/kv/upstreams/test/192.168.212.1:8081
curl -X PUT http://192.168.212.134:8500/v1/kv/upstreams/test/192.168.212.1:8081

2.使用postmen 發送put請求
http://192.168.212.134:8500/v1/kv/upstreams/test/192.168.212.1:8081 http://192.168.212.134:8500/v1/kv/upstreams/test/192.168.212.1:8081

負載均衡信息參數
{“weight”:1, “max_fails”:2, “fail_timeout”:10, “down”:0}
啓動Nginx
Nginx
Nginx 基於1.9實現四層負載均衡

網絡模型

Socket入門
什麼是Socket？
Socket就是爲網絡服務提供的一種機制。
通訊的兩端都有Sokcet
網絡通訊其實就是Sokcet間的通訊
數據在兩個Sokcet間通過IO傳輸。

TCP與UDP在概念上的區別：
udp: a、是面向無連接, 將數據及源的封裝成數據包中,不需要建立連接
b、每個數據報的大小在限制64k內
c、因無連接,是不可靠協議
d、不需要建立連接,速度快
tcp：
a、建議連接，形成傳輸數據的通道.
b、在連接中進行大數據量傳輸，以字節流方式
c 通過三次握手完成連接,是可靠協議
d 必須建立連接m效率會稍低
Http協議組成部分
http協議基於TCP協議封裝成超文本傳輸協議，http分爲請求與響應，http協議分爲請求參數和方法類型、請求頭、請求體，響應分爲 響應狀態、響應頭、響應體等。

四層負載均衡與七層負載均衡區別
四層負載均衡，在網絡模型中的傳輸層中，基於主要是基於tcp協議報文實現負載均衡（比如LVS、haproxy就是四層負載均衡器），使用改寫報文的源地址和目的地址。

七層負載均衡,在網絡模型中應用層中，基於URL或者HTTP協議實現負載均衡，Web服務器。
環境準備
測試環境 CentOS7
Nginx1.9開始支持tcp層的轉發，通過stream實現的，而socket也是基於tcp通信。
stream模塊默認不安裝的，需要手動添加參數：–with-stream，官方下載地址：download，根據自己系統版本選擇nginx1.9或以上版本
./configure --add-module=…/yaoweibin-nginx_tcp_proxy_module-121c026

安裝軟件

1.安裝Nginx
wget http://nginx.org/download/nginx-1.9.10.tar.gz
作用:實現反向代理、負載負載庫
2.安裝nginx_tcp_proxy_module 插件
wget https://github.com/yaoweibin/nginx_tcp_proxy_module/tarball/master
tar -zxvf master
nginx 支持TCP轉發和負載均衡的支持
編譯Nginx
編譯Nginx
1.解壓nginx文件
tar -zxvf nginx-1.9.10.tar.gz
2.進入到Nginx目錄
cd nginx-1.9.10
3.下載tcp.patch最新補丁
patch -p1 < …/yaoweibin-nginx_tcp_proxy_module-121c026/tcp.patch
如果報錯
-bash: patch: 未找到命令 執行 yum -y install patch 安裝即可。
4.編譯Nginx
./configure --add-module=…/yaoweibin-nginx_tcp_proxy_module-121c026
5.make && make install
如果報錯
In file included from …/nginx_tcp_proxy_module-master/ngx_tcp.h:32,
from …/nginx_tcp_proxy_module-master/ngx_tcp.c:5:
…/nginx_tcp_proxy_module-master/ngx_tcp_upstream.h:144: error: expected specifier-qualifier-list before ‘ngx_resolver_addr_t’
make[1]: *** [objs/addon/nginx_tcp_proxy_module-master/ngx_tcp.o] Error 1
make[1]: Leaving directory `/opt/apps_install/nginx-1.9.9’
make: *** [build] Error 2

修改第三方模塊包裏的頭文件，ngx_tcp_upstream.h 144 行將ngx_resolver_addr_t 改爲 ngx_addr_t
Cd /usr/local/yaoweibin-nginx_tcp_proxy_module-121c026
Vi

5.繼續 make && make install
6.修改Nginx.conf配置文件
worker_processes 1;
events {
worker_connections 1024;
}

修改爲TCP模塊

tcp {

定義多個上游服務器

upstream test{
### 定義TCP模塊上游服務器
server 192.168.5.165:80001;
server 192.168.5.165:80002;
}
server {
listen 9999;
server_name 192.168.212.137;
### 反向代理upstream
proxy_pass test;
}
}

7.啓動Nginx服務器

8.創建兩個Sokcet服務器端

Ngxin連接反向代理TCP服務器

lvs+keepalived+nginx實現高性能負載均衡集羣
LVS作用
LVS是一個開源的軟件，可以實現傳輸層四層負載均衡。LVS是Linux Virtual Server的縮寫，意思是Linux虛擬服務器。目前有三種IP負載均衡技術（VS/NAT、VS/TUN和VS/DR）；八種調度算法（rr,wrr,lc,wlc,lblc,lblcr,dh,sh）。
Keepalived作用
LVS可以實現負載均衡，但是不能夠進行健康檢查，比如一個rs出現故障，LVS 仍然會把請求轉發給故障的rs服務器，這樣就會導致請求的無效性。keepalive 軟件可以進行健康檢查，而且能同時實現 LVS 的高可用性，解決 LVS 單點故障的問題，其實 keepalive 就是爲 LVS 而生的。

keepalived和其工作原理
keepalived是一個類似於Layer2,4,7交換機制的軟件。是Linux集羣管理中保證集羣高可用的一個服務軟件，其功能是用來防止單點故障。

keepalived的工作原理：
keepalived是基於VRRP協議實現的保證集羣高可用的一個服務軟件，主要功能是實現真機的故障隔離和負載均衡器間的失敗切換，防止單點故障。在瞭解keepalived原理之前先了解一下VRRP協議。

VRRP協議：Virtual Route

Redundancy Protocol虛擬路由冗餘協議。是一種容錯協議，保證當主機的下一跳路由出現故障時，由另一臺路由器來代替出現故障的路由器進行工作，從而保持網絡通信的連續性和可靠性。在介紹VRRP之前先介紹一些關於VRRP的相關術語：

虛擬路由器：由一個 Master 路由器和多個 Backup 路由器組成。主機將虛擬路由器當作默認網關。
VRID：虛擬路由器的標識。有相同 VRID 的一組路由器構成一個虛擬路由器。
Master 路由器：虛擬路由器中承擔報文轉發任務的路由器。
Backup 路由器： Master 路由器出現故障時，能夠代替 Master 路由器工作的路由器。
虛擬 IP 地址：虛擬路由器的 IP 地址。一個虛擬路由器可以擁有一個或多個IP 地址。
IP 地址擁有者：接口 IP 地址與虛擬 IP 地址相同的路由器被稱爲 IP 地址擁有者。
虛擬 MAC 地址：一個虛擬路由器擁有一個虛擬 MAC 地址。虛擬 MAC 地址的格式爲 00-00-5E-00-01-{VRID}。通常情況下，虛擬路由器迴應 ARP 請求使用的是虛擬 MAC 地址，只有虛擬路由器做特殊配置的時候，纔回應接口的真實 MAC 地址。

優先級： VRRP 根據優先級來確定虛擬路由器中每臺路由器的地位。
非搶佔方式：如果 Backup 路由器工作在非搶佔方式下，則只要 Master 路由器沒有出現故障，Backup 路由器即使隨後被配置了更高的優先級也不會成爲Master 路由器。
搶佔方式：如果 Backup 路由器工作在搶佔方式下，當它收到 VRRP 報文後，會將自己的優先級與通告報文中的優先級進行比較。如果自己的優先級比當前的 Master 路由器的優先級高，就會主動搶佔成爲 Master 路由器；否則，將保持 Backup 狀態。

虛擬路由示意圖：

  VRRP將局域網內的一組路由器劃分在一起，形成一個VRRP備份組，它在功能上相當於一臺路由器的功能，使用虛擬路由器號進行標識（VRID）。虛擬路由器有自己的虛擬IP地址和虛擬MAC地址，它的外在變現形式和實際的物理路由完全一樣。局域網內的主機將虛擬路由器的IP地址設置爲默認網關，通過虛擬路由器與外部網絡進行通信。

  虛擬路由器是工作在實際的物理路由器之上的。它由多個實際的路由器組成，包括一個Master路由器和多個Backup路由器。 Master路由器正常工作時，局域網內的主機通過Master與外界通信。當Master路由器出現故障時， Backup路由器中的一臺設備將成爲新的Master路由器，接替轉發報文的工作。（路由器的高可用）

VRRP的工作工程：
(1) 虛擬路由器中的路由器根據優先級選舉出 Master。 Master 路由器通過發送免費 ARP 報文，將自己的虛擬 MAC 地址通知給與它連接的設備或者主機，從而承擔報文轉發任務；
(2) Master 路由器週期性發送 VRRP 報文，以公佈其配置信息（優先級等）和工作狀況；
(3) 如果 Master 路由器出現故障，虛擬路由器中的 Backup 路由器將根據優先級重新選舉新的 Master；
(4) 虛擬路由器狀態切換時， Master 路由器由一臺設備切換爲另外一臺設備，新的 Master 路由器只是簡單地發送一個攜帶虛擬路由器的 MAC 地址和虛擬 IP地址信息的ARP 報文，這樣就可以更新與它連接的主機或設備中的ARP 相關信息。網絡中的主機感知不到 Master 路由器已經切換爲另外一臺設備。
(5) Backup 路由器的優先級高於 Master 路由器時，由 Backup 路由器的工作方式（搶佔方式和非搶佔方式）決定是否重新選舉 Master。
VRRP優先級的取值範圍爲0到255（數值越大表明優先級越高）

環境服務配置
兩臺Nginx服務器
Nginx 主服務器 192.168.212.143
Nginx 備服務器 192.168.212.144
Lvs 虛擬VIP 192.168.212.110
前面三個一定要相同

環境搭建
1.下載keepalived
wget http://www.keepalived.org/software/keepalived-1.2.18.tar.gz
2.解壓安裝：
tar -zxvf keepalived-1.2.18.tar.gz -C /usr/local/
3.下載插件openssl
yum install -y openssl openssl-devel（需要安裝一個軟件包）
4.開始編譯keepalived
cd keepalived-1.2.18/ && ./configure --prefix=/usr/local/keepalived
5.make一下
make && make install

報錯: eepalived執行./configure --prefix=/usr/local/keepalived時報錯：configure: error: Popt libraries is required
出現此錯誤的原因：
未安裝popt的開發包
解決方法：
yum install popt-devel
安裝好popt的開發包。重新./configure 即可。

keepalived安裝成Linux系統服務

將keepalived安裝成Linux系統服務，因爲沒有使用keepalived的默認安裝路徑（默認路徑：/usr/local）,安裝完成之後，需要做一些修改工作：
首先創建文件夾，將keepalived配置文件進行復制：
mkdir /etc/keepalived
cp /usr/local/keepalived/etc/keepalived/keepalived.conf /etc/keepalived/
然後複製keepalived腳本文件：
cp /usr/local/keepalived/etc/rc.d/init.d/keepalived /etc/init.d/
cp /usr/local/keepalived/etc/sysconfig/keepalived /etc/sysconfig/
ln -s /usr/local/sbin/keepalived /usr/sbin/
ln -s /usr/local/keepalived/sbin/keepalived /sbin/
可以設置開機啓動：chkconfig keepalived on，到此我們安裝完畢!
keepalived 常用命令
service keepalived start
service keepalived stop

啓動報錯Starting keepalived (via systemctl): Job for keepalived.service failed. See ‘systemctl status keepalived.service’ and ‘journalctl -xn’ for details.
解決辦法
[root@edu-proxy-01 sbin]# cd /usr/sbin/
[root@edu-proxy-01 sbin]# rm -f keepalived
[root@edu-proxy-01 sbin]# cp /usr/local/keepalived/sbin/keepalived /usr/sbin/

使用keepalived虛擬VIP
vi /etc/keepalived/keepalived.conf

vrrp_script chk_nginx {
script “/etc/keepalived/nginx_check.sh” #運行腳本，腳本內容下面有，就是起到一個nginx宕機以後，自動開啓服務
interval 2 #檢測時間間隔
weight -20 #如果條件成立的話，則權重 -20
}

定義虛擬路由，VI_1 爲虛擬路由的標示符，自己定義名稱

vrrp_instance VI_1 {
state MASTER #來決定主從
interface ens33 # 綁定虛擬 IP 的網絡接口，根據自己的機器填寫
virtual_router_id 121 # 虛擬路由的 ID 號， 兩個節點設置必須一樣
mcast_src_ip 192.168.212.140 #填寫本機ip
priority 100 # 節點優先級,主要比從節點優先級高
nopreempt # 優先級高的設置 nopreempt 解決異常恢復後再次搶佔的問題
advert_int 1 # 組播信息發送間隔，兩個節點設置必須一樣，默認 1s
authentication {
auth_type PASS
auth_pass 1111
}
# 將 track_script 塊加入 instance 配置塊
track_script {
chk_nginx #執行 Nginx 監控的服務
}

virtual_ipaddress {
    192.168.110.110 # 虛擬ip,也就是解決寫死程序的ip怎麼能切換的ip,也可擴展，用途廣泛。可配置多個。
}

}

關閉防火牆 systemctl stop firewalld

nginx+keepalived簡單雙機主從熱備
雙機主從熱備概述
可以兩臺機子互爲熱備，平時各自負責各自的服務。在做上線更新的時候，關閉一臺服務器的tomcat後，nginx自動把流量切換到另外一臺服務的後備機子上，從而實現無痛更新，保持服務的持續性，提高服務的可靠性，從而保證服務器7*24小時運行。
Nginx Upstream 實現簡單雙機主從熱備
upstream testproxy {
server 127.0.0.1:8080;
server 127.0.0.1:8081 backup;
}

server {
    listen       80;
    server_name  localhost;



    location / {
        proxy_pass   http://testproxy;
        index  index.html index.htm;
    }
     ###nginx與上游服務器(真實訪問的服務器)超時時間 後端服務器連接的超時時間_發起握手等候響應超時時間
      proxy_connect_timeout 1s;
	 ###nginx發送給上游服務器(真實訪問的服務器)超時時間
     proxy_send_timeout 1s;
      ### nginx接受上游服務器(真實訪問的服務器)超時時間
     proxy_read_timeout 1s;

}

只要在希望成爲後備的服務器 ip 後面多添加一個 backup 參數，這臺服務器就會成爲備份服務器。
在平時不使用，nginx 不會給它轉發任何請求。只有當其他節點全部無法連接的時候，nginx 纔會啓用這個節點。
一旦有可用的節點恢復服務，該節點則不再使用，又進入後備狀態
Nginx+keepalived簡單雙機主從熱備
每個服務虛擬安裝keepalived 虛擬一個VIP ，配置主從關係，當主掛了,直接走備機。
Keepalived虛擬VIP 地址 192.168.212.110
A 服務器 192.168.212.142
B 服務器 192.168.212.143

修改主keepalived信息
修改主Nginx服務器keepalived文件, /etc/keepalived/keepalived.conf
State 爲MASTER

! Configuration File for keepalived

vrrp_script chk_nginx {
script “/etc/keepalived/nginx_check.sh” #運行腳本，腳本內容下面有，就是起到一個nginx宕機以後，自動開啓服務
interval 2 #檢測時間間隔
weight -20 #如果條件成立的話，則權重 -20
}

定義虛擬路由，VI_1 爲虛擬路由的標示符，自己定義名稱

vrrp_instance VI_1 {
state MASTER #來決定主從
interface ens33 # 綁定虛擬 IP 的網絡接口，根據自己的機器填寫
virtual_router_id 121 # 虛擬路由的 ID 號， 兩個節點設置必須一樣
mcast_src_ip 192.168.212.141 #填寫本機ip
priority 100 # 節點優先級,主要比從節點優先級高
nopreempt # 優先級高的設置 nopreempt 解決異常恢復後再次搶佔的問題
advert_int 1 # 組播信息發送間隔，兩個節點設置必須一樣，默認 1s
authentication {
auth_type PASS
auth_pass 1111
}
# 將 track_script 塊加入 instance 配置塊
track_script {
chk_nginx #執行 Nginx 監控的服務
}

virtual_ipaddress {
    192.168.212.110 # 虛擬ip,也就是解決寫死程序的ip怎麼能切換的ip,也可擴展，用途廣泛。可配置多個。
}

}

修改從keepalived信息
修改主Nginx服務器keepalived文件, /etc/keepalived/keepalived.conf
State 爲BACKUP

! Configuration File for keepalived

vrrp_script chk_nginx {
script “/etc/keepalived/nginx_check.sh” #運行腳本，腳本內容下面有，就是起到一個nginx宕機以後，自動開啓服務
interval 2 #檢測時間間隔
weight -20 #如果條件成立的話，則權重 -20
}

定義虛擬路由，VI_1 爲虛擬路由的標示符，自己定義名稱

vrrp_instance VI_1 {
state BACKUP #來決定主從
interface ens33 # 綁定虛擬 IP 的網絡接口，根據自己的機器填寫
virtual_router_id 121 # 虛擬路由的 ID 號， 兩個節點設置必須一樣
mcast_src_ip 192.168.212.141 #填寫本機ip
priority 100 # 節點優先級,主要比從節點優先級高
nopreempt # 優先級高的設置 nopreempt 解決異常恢復後再次搶佔的問題
advert_int 1 # 組播信息發送間隔，兩個節點設置必須一樣，默認 1s
authentication {
auth_type PASS
auth_pass 1111
}
# 將 track_script 塊加入 instance 配置塊
track_script {
chk_nginx #執行 Nginx 監控的服務
}

virtual_ipaddress {
    192.168.212.110 # 虛擬ip,也就是解決寫死程序的ip怎麼能切換的ip,也可擴展，用途廣泛。可配置多個。
}

}

nginx+keepalived實現高可
寫入nginx_check.sh腳本 /etc/keepalived/nginx_check.sh

#!/bin/bash
A=ps -C nginx –no-header |wc -l
if [ $A -eq 0 ];then
/usr/local/nginx/sbin/nginx
sleep 2
if [ ps -C nginx --no-header |wc -l -eq 0 ];then
killall keepalived
fi
fi

注意該腳本一定要授權
chmod 777 nginx_check.sh。

lvs與Nginx區別
LVS的負載能力強，因爲其工作方式邏輯非常簡單，僅進行請求分發，而且工作在網絡的第4層，沒有流量，所以其效率不需要有過多的憂慮。

LVS基本能支持所有應用，因爲工作在第4層，所以LVS可以對幾乎所有應用進行負載均衡，包括Web、數據庫等。

注意：LVS並不能完全判別節點故障，比如在WLC規則下，如果集羣裏有一個節點沒有配置VIP，將會導致整個集羣不能使用。還有一些其他問題，目前尚需進一步測試。

Nginx工作在網路第7層，所以可以對HTTP應用實施分流策略，比如域名、結構等。相比之下，LVS並不具備這樣的功能，所以Nginx可使用的場合遠多於LVS。並且Nginx對網絡的依賴比較小，理論上只要Ping得通，網頁訪問正常就能連通。LVS比較依賴網絡環境。只有使用DR模式且服務器在同一網段內分流，效果才能得到保證。

Nginx可以通過服務器處理網頁返回的狀態嗎、超時等來檢測服務器內部的故障，並會把返回錯誤的請求重新發送到另一個節點。目前LVS和LDirectd 也支持對服務器內部情況的監控，但不能重新發送請求。

比如用戶正在上傳一個文件，而處理該上傳信息的節點剛好出現故障，則Nginx會把上傳請求重新發送到另一臺服務器，而LVS在這種情況下會直接斷掉。Nginx還能支持HTTP和Email（Email功能很少有人使用），LVS所支持的應用在這個電商比Nginx更多。

Nginx同樣能承受很高負載並且能穩定運行，由於處理流量受限於機器I/O等配置，所以負載能力相對較差。

Nginx 安裝、配置及測試相對來說比較簡單，因爲有相應的錯誤日誌進行提示。LVS的安裝、配置及測試所花的時間比較長，因爲LVS對網絡以來比較大，很多時候有可能因爲網絡問題而配置不能成功，出現問題時，解決的難度也相對較大。Nginx本身沒有現成的熱備方案，所以在單機上運行風險較大，建議KeepAlived配合使用。另外，Nginx可以作爲LVS的節點機器使用，充分利用Nginx的功能和性能。當然這種情況也可以直接使用Squid等其他具備分發功能的軟件。

具體應用具體分析。如果是比較小型的網站（每日PV小於100萬），用戶Nginx就完全可以應對，如果機器也不少，可以用DNS輪詢。LVS後用的機器較多，在構建大型網站或者提供重要服務且機器較多時，可多加考慮利用LVS。
注意阿里雲默認不支持虛擬VIP技術
阿里雲默認不支持虛擬VIP技術，
https://yq.aliyun.com/ask/61502
Nginx+Tomcat動靜分離
動態頁面與靜態頁面區別
靜態資源： 當用戶多次訪問這個資源，資源的源代碼永遠不會改變的資源。
動態資源：當用戶多次訪問這個資源，資源的源代碼可能會發送改變。

什麼是動靜分離
動靜分離是讓動態網站裏的動態網頁根據一定規則把不變的資源和經常變的資源區分開來，動靜資源做好了拆分以後，我們就可以根據靜態資源的特點將其做緩存操作，這就是網站靜態化處理的核心思路

動靜分離簡單的概括是：動態文件與靜態文件的分離。
爲什麼要用動靜分離
在我們的軟件開發中，有些請求是需要後臺處理的（如：.jsp,.do等等），有些請求是不需要經過後臺處理的（如：css、html、jpg、js等等文件），這些不需要經過後臺處理的文件稱爲靜態文件，否則動態文件。因此我們後臺處理忽略靜態文件。這會有人又說那我後臺忽略靜態文件不就完了嗎。當然這是可以的，但是這樣後臺的請求次數就明顯增多了。在我們對資源的響應速度有要求的時候，我們應該使用這種動靜分離的策略去解決。

動靜分離將網站靜態資源（HTML，JavaScript，CSS，img等文件）與後臺應用分開部署，提高用戶訪問靜態代碼的速度，降低對後臺應用訪問。這裏我們將靜態資源放到nginx中，動態資源轉發到tomcat服務器中。

因此，動態資源轉發到tomcat服務器我們就使用到了前面講到的反向代理了。

動靜分離的原理
動靜分離的原理很簡單，通過location對請求url進行匹配即可，具體配置如下：

###靜態資源訪問
server {
listen 80;
server_name static.test.com;
location /static/imgs {
root F:/;
index index.html index.htm;
}
}
###動態資源訪問
server {
listen 80;
server_name www.test.com;

  location / {
     proxy_pass http://127.0.0.1:8080;
	 index  index.html index.htm;
   }
}

靜態資源緩存
實際項目中在發佈版本的時候，可能由於瀏覽器緩存導致與服務器端代碼發生衝突。
這時候可以在靜態資源請求後面加上時間戳，對應每次發佈版本的時間。
火狐瀏覽器 F5 刷新
火狐瀏覽器 CTRL 強制刷新

HTTP 304狀態碼
客戶端在請求一個文件的時候，發現自己緩存的文件有 Last Modified ，那麼在請求中會包含 If Modified Since ，這個時間就是緩存文件的 Last Modified 。因此，如果請求中包含 If Modified Since，就說明已經有緩存在客戶端。服務端只要判斷這個時間和當前請求的文件的修改時間就可以確定是返回 304 還是 200 。
對於靜態文件，例如：CSS、圖片，服務器會自動完成 Last Modified 和 If Modified Since 的比較，完成緩存或者更新。但是對於動態頁面，就是動態產生的頁面，往往沒有包含 Last Modified 信息，這樣瀏覽器、網關等都不會做緩存，也就是在每次請求的時候都完成一個 200 的請求。
因此，對於動態頁面做緩存加速，首先要在 Response 的 HTTP Header 中增加 Last Modified 定義，其次根據 Request 中的 If Modified Since 和被請求內容的更新時間來返回 200 或者 304 。雖然在返回 304 的時候已經做了一次數據庫查詢，但是可以避免接下來更多的數據庫查詢，並且沒有返回頁面內容而只是一個 HTTP Header，從而大大的降低帶寬的消耗，對於用戶的感覺也是提高

高併發服務限流特技
高併發服務降級特技

常見名稱
高併發
高可用
冪等性
心跳檢測
隔離技術
限流技術
降級技術
雪崩效應
超時機制
防重設計
重試機制
補償機制
回滾機制
註冊中心
服務化
拆分
命中率
多級緩存
異步併發
平滑擴容
可伸縮
敏捷迭代
無狀態