什么是高可用架構
在介紹高可用架構的方案之前，先說一下什么是高可用架構，高可用架構應具備但不限於以下特征：
-
主從切換
很好理解，當其中一台機器的服務宕機后，對於服務調用者來說，能夠迅速的切換到其他可用服務，從服務升級為主服務，這種切換速度應當控制在秒級別（幾秒鍾）。
當宕機的服務恢復之后，自動變為從服務，主從服務角色切換。主從切換一定是要付出代價的，所以當主服務恢復之后，也就不再替換現有的主服務。
-
負載均衡
當服務的請求量比較高的時候，一台服務不能滿足需求，這時候需要多台機器提供同樣的服務，將所有請求分發到不同機器上。
高可用架構中應該具有豐富的負載均衡策略和易調節負載的方式。
甚至可以自動化智能調節，例如由於機器性能的原因，響應時間可能不一樣，這時候可以向性能差的機器少一點分發量，保證各個機器響應時間的均衡。
-
易橫向擴展
當用戶量越來越多，已有服務不能承載更多的用戶的時候，便需要對服務進行擴展，擴展的方式最好是不觸動原有服務，對於服務的調用者是透明的。
業務中接觸到的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的高可用也是基於中間件來做的。
總結
文章對常見的高可用方案做了簡單的介紹，由於高可用涉及內容較多，短短一篇文章不能很詳細的介紹，比如：前兩種高可用方案只適用於無狀態服務，如何將有狀態服務變為無狀態服務將會在后面的微服務相關的文章中介紹！