高可用架構的6大常規方案

什麼是高可用架構

在介紹高可用架構的方案以前，先說一下什麼是高可用架構，高可用架構應具有但不限於如下特徵：

1. 主從切換

   很好理解，當其中一臺機器的服務宕機後，對於服務調用者來講，可以迅速的切換到其餘可用服務，從服務升級爲主服務，這種切換速度應當控制在秒級別（幾秒鐘）。

   當宕機的服務恢復以後，自動變爲從服務，主從服務角色切換。主從切換必定是要付出代價的，因此當主服務恢復以後，也就再也不替換現有的主服務。

2. 負載均衡

   當服務的請求量比較高的時候，一臺服務不能知足需求，這時候須要多臺機器提供一樣的服務，將全部請求分發到不一樣機器上。

   高可用架構中應該具備豐富的負載均衡策略和易調節負載的方式。

   甚至能夠自動化智能調節，例如因爲機器性能的緣由，響應時間可能不同，這時候能夠向性能差的機器少一點分發量，保證各個機器響應時間的均衡。

3. 易橫向擴展

   當用戶量愈來愈多，已有服務不能承載更多的用戶的時候，便須要對服務進行擴展，擴展的方式最好是不觸動原有服務，對於服務的調用者是透明的。

業務中接觸到的6種高可用方案

LVS+Keepalive

LVS的全稱是linux visural server，即虛擬的linux機器，這個名稱再恰當不過了。該方案的實現大概是這樣的。

在多臺linux機器上安裝IPVS和keepalive，IPVS其實是一個虛擬的linux服務，具備linux機器的部分功能，各個機器上分別啓動一個Linux虛擬服務（虛擬機），這些linux虛擬服務（虛擬機）設置爲同一個IP（稱之爲虛IP），這樣在一個內網中就只能有一個linux虛擬服務可以搶佔到這個虛擬IP。全部的請求都指向這一個虛IP，假如搶佔到虛IP的機器掛了，這時候其餘linux虛擬服務就會有其中一個搶佔到虛IP，對於服務調用者來講，仍然能夠訪問到服務。keepalive的做用就是用來檢測linux虛擬服務是否正常的。頭條插入代碼實在不方便，須要詳細的配置方案的能夠私信我。

---

NIGNX

nginx本是一個反向代理服務器，但因爲豐富的負載均衡策略，經常被用於客戶端可真實的服務器之間，做爲負載均衡的實現。

說一下什麼是反向代理和正向代理：

正向代理：被代理的是客戶端，好比經過XX代理訪問國外的某些網站，實際上客戶端沒有權限訪問國外的網站，客戶端請求XX代理服務器，XX代理服務器訪問國外網站，將國外網站返回的內容傳給真正的用戶。用戶對於服務器是隱藏的，服務器並不知道真實的用戶。

反向代理：被代理的是服務器，也就是客戶端訪問了一個所謂的服務器，服務器會將請求轉發給後臺真實的服務器，真實的服務器作出響應，經過代理服務器將結果返給客戶端。服務器對於用戶來講是隱藏的，用戶不知道真實的服務器是哪一個。

關於正向代理和反向代理，聽起來比較繞，仔細理解，體會也不難明白究竟是什麼意思。

用nginx作實現服務的高可用，nginx自己可能成爲單點，碰見的兩種解決方案，一種是公司搭建本身的DNS，將請求解析到不一樣的NGINX，另外一隻是配合keepalive實現服務的存活檢測。

zookpeer

想必接觸過度布式服務的應該對zookeeper都有所瞭解，最起碼也據說過吧！zookeeper自己實現了高可用，zookeeper自己的高可用及原理在這兒不詳細介紹，這裏只介紹若是經過zookeeper管理服務。

zookeeper自己能夠存儲數據，服務啓動以後能夠向zookeeper註冊，調用者能夠到zookeeper上發現服務。提供服務的一直保持與zookeeper的通訊，經過心跳證實服務的可用性。當服務掛掉以後，對應註冊的接點會消失，這時候調用者就不能找到已經失效的服務。

關於zookeeper實現服務高可用，之後會詳細介紹。

---

由客戶端實現的高可用方案

以memcache 爲例，客戶端同時與好幾個服務保持鏈接，按照必定的規則去調用服務，當服務掛掉以後，從新調整規則。固然，若是服務器不作主從備份的話，可能會形成部分數據丟失。感興趣的能夠關注之後發的關於對memache的詳細介紹的文章。

服務之間通訊實現高可用

這種經典的案例就是redis了，各個redis之間保持通訊，當主服務掛掉以後從服務就會升爲主服務。對於客戶端來講幾乎是透明的。

經過中間件實現高可用

這裏暫時不詳細介紹，說一下我瞭解的幾個中間價：mycat 實現mysql高可用的中間價。

早期版本redis不支持集羣，那時候redis的高可用也是基於中間件來作的。

---

總結

文章對常見的高可用方案作了簡單的介紹，因爲高可用涉及內容較多，短短一篇文章不能很詳細的介紹，好比：前兩種高可用方案只適用於無狀態服務，如何將有狀態服務變爲無狀態服務將會在後面的微服務相關的文章中介紹！