高可用和負載均衡架構設計模式

下面總結一下常見的高可用和負載均衡架構模式。

 

1. 客戶端切換。

客戶端配置多個服務器地址。若是發生某個服務器沒法訪問或者使用異常，客戶端就切換到其它服務器上。

優勢：簡單，高效，能夠在業務層面檢測服務可用性

缺點：須要提早配置。

 

Mysql connect 這樣作load balance 和failed over .在JDBC鏈接上能夠配置多個服務器。

 

http://dev.mysql.com/doc/connector-j/en/connector-j-reference-configuration-properties.html#connector-j-reference-url-format

 

 

# Connection URL for a server failover setup: 
jdbc:mysql//primaryhost,secondaryhost1,secondaryhost2/test

 

 

 

 

2. DNS映射

DNS服務返回不一樣的IP來達到切換和負載均衡的效果。因爲DNS會緩存，實際使用中問題會比較多。.

優勢：對使用者是透明，

缺點：因爲DNS緩存問題，可能切換不及時

 

3. 服務註冊發現

註冊服務器（zookeeper）用來管理當前能夠用的服務提供。dubbo使用這種方式來實現。

     優勢：可使用複雜的負載均衡策略，能夠實現服務路由。

     缺點：實現複雜

 

 

http://shiyanjun.cn/archives/325.html

 

4. keepalive+浮動IP

 

若是正在使用的機器出問題，外網Ip能夠根據狀況，分配到另一臺主機上。這樣IP切換對外部訪問者是透明的。不過要實現浮動IP，對底層網絡的支持。在如今的雲服務器中沒法使用。

 

優勢： 高效，對客戶端透明

缺點： 對主機網絡有要求，沒法在雲服務器中使用。

 

5 代理服務器(nginx ,lVS,Haproxy)

代理服務器檢測上游服務器是否可用。而且會根據必定策略來路由前端過來的請求。爲了不代理服務器出現故障，致使系統沒法被訪問。因此通常都要結合keepalive+vip一塊兒使用。

優勢： 支持大量服務器，能夠配置複雜路由規則

缺點：代理服務器有單點問題，故障檢測不及時

 

總結以上模式主要區別在：

1. 服務器信息誰維護，客戶端，代理服務器或者註冊服務

2. 故障發現手段。通用的檢測方式只能檢查端口能不能鏈接，若是出現服務器殭屍狀況經常不能及時被發現。

3. 服務器利用率。