大型網站系統架構實踐（五）深刻探討web應用高可用方案

        從上篇文章到這篇文章，中間用了一段時間準備，主要是想把東西講透，同時但願你們給與一些批評和建議，這樣我纔能有所進步，也但願喜歡我文章的朋友，給個贊，這樣我才能更有激情，呵呵。

因爲本篇要寫的內容有點多，我就分爲幾篇博客進行了詳細描述。

Haproxy提升web應用的高可用

       上一篇文章講到了haproxy+tomcat的方案，文章地址：大型網站系統架構的演進（四）http層負載均衡之haproxy實踐篇（一）

你們能夠先溫習一下，

       文中提到了高可用，該集羣方案也能夠提升應用系統的高可用，若是tomcat應用出現故障，或者tomcat應用服務器出現故障，haproxy會檢測到（這裏指的是按期心跳檢查），並將應用從可用列表中刪除，打開監控頁面http://192.168.1.227/haproxy-stats

能夠看到有2個web應用運行，若是將webA停掉，能夠看到webA顯示down

這樣客戶端請求就不會分發給webA，下面模擬一下webA宕機的狀況

這裏對sessionId增長了一個後綴作標記

webA：jvm3

webB：jvm2

1. webA正常的狀況，客戶請求被分發到webA

此時產生的sessionId爲jvm3

2. 停掉webA，刷新瀏覽器

能夠看到請求被轉發到webB

也就是說web應用出現故障，haproxy會作切換，所以能夠保證web應用的高可用。

Haproxy自己的高可用

      若是haproxy自己出現故障，那麼網站將不可用，因此咱們接下來要作的事情就是解決haproxy單點故障的問題。

咱們能夠運用虛擬ip技術，將haproxy部署在2臺服務器上，一臺作爲master，正常運營，一臺爲backup，

當master出現問題的時候，接管master。

      首先有一個虛擬ip暴露給客戶端，虛擬ip對應的mac地址爲master服務器，

用戶向虛擬ip發送一個請求，該請求會被分發到master服務器上，當master出現故障時，被backup檢測到，則backup成爲master,

且發送消息將arp緩存虛擬ip對應的mac地址backup的mac地址，這樣發送到虛擬ip的報文會被轉發到backup 。

架構圖：

該方案解決了haproxy單點故障的問題，具體用keepalived實現，詳細請參考文章：

Keepalived 實現雙機熱備

Keepalived + haproxy雙機高可用方案

若是想實踐的朋友，請按照上面2篇文章安裝和配置haproxy和keepalived

系統分佈以下：

ha主機 192.168.1.227:80

ha備機 192.168.1.246

keepalived 主機 192.168.1.227

keepalived備機 192.168.1.246

web1 http://192.168.1.226:8081/login

web2 http://192.168.1.246:8888/login

虛擬ip 192.168.1.99

安裝好haproxy和keepalived後，啓動haproxy和keepalived

Haproxy訪問地址：

http://192.168.1.99/haproxy-stats

注意pid爲9644，這是master上的haproxy

應用訪問地址

http://192.168.1.99/login/

注意sessionId的後綴爲jvm3

查看虛擬ip1.99對應的mac地址

接下來，咱們停掉master上的haproxy服務

kill -9 9644

查看haproxy http://192.168.1.99/haproxy-stats

發現haproxy的pid變成backup機器上的了

刷新web的訪問頁面http://192.168.1.99/login/

發現sessionId沒有變化

查看虛擬ip1.99對應的mac地址

mac地址已經變爲backup機器上的了

若是咱們直接關閉主機服務器或者關閉主機的keepalived，發現測試結果也是同樣的

所以該方案實現了haproxy的高可用，解決了haproxy的單點故障問題。

會話保持問題

那麼這裏我還要提出一個疑問，爲何sessionId也沒有變化呢？

也就是說切換到backup服務器的haproxy以後，

能夠保持用戶的會話，那麼它是怎麼實現的呢？

這裏就要回到上篇文章講的負載均衡時保持會話的策略

會話保持的流程

1.客戶端首次請求，通過haproxy到web服務端時，web服務端set-cookie並響應到haproxy

2.haproxy在cookie後插入SRV=A，並響應客戶端

3.客戶端第二次請求，通過haproxy時，haproxy將srv後綴去掉，而後請求服務端

這種保持會話的方法是無狀態的，也就說主要haproxy配置的負載均衡策略相同，無論在哪臺機器上運行

將獲得一樣的結果

 

上篇文章 大型網站系統架構的演進（四）http層負載均衡之haproxy實踐篇（一）

目錄 大型網站系統架構的演進目錄

下篇 大型網站系統架構實踐（六）深刻探討web應用集羣Session保持