從各個節點去考慮高可用，先從最底層機器就保證高可用，可以透過機器冗餘方式；然後機器上層一般是資料層，比如mysql可以透過雙主雙活叢集方式，在往大一點講就是建立多資料中心，比如二地三中心，同城多活，這二種方式成本都很高，要看業務系統的戰略性；在資料層上面就是服務層，服務層本身就是服務化架構，前提條件服務要是無狀態服務，並且建立叢集分散式服務，這樣在服務不可用時候，其他服務可以接管，以及可以保障效能；應用層要解決的問題就是分散式session，這樣話應用層也能叢集化部署。

什麼是高可用？

高可用描述的是一個系統在大部分時間都是可用的，可以為我們提供服務的。高可用代表系統即使在發生硬體故障或者系統升級的時候，服務仍然是可用的。

一般情況下，我們使用多少個 9 來評判一個系統的可用性，比如 99.9999% 就是代表該系統在所有的執行時間中只有 0.0001% 的時間都是可用的，這樣的系統就是非常非常高可用的了！當然，也會有系統如果可用性不太好的話，可能連 9 都上不了。

哪些情況會導致系統不可用？

駭客攻擊；

硬體故障，比如伺服器壞掉。

併發量/使用者請求量激增導致整個服務宕掉或者部分服務不可用。

程式碼中的壞味道導致記憶體洩漏或者其他問題導致程式掛掉。

網站架構某個重要的角色比如 Nginx 或者資料庫突然不可用。

自然災害或者人為破壞。

有哪些提高系統可用性的方法？

注重程式碼質量，測試嚴格把關

我覺得這個是最最最重要的，程式碼質量有問題比如比較常見的記憶體洩漏、迴圈依賴都是對系統可用性極大的損害。大家都喜歡談限流、降級、熔斷，但是我覺得從程式碼質量這個源頭把關是首先要做好的一件很重要的事情。如何提高程式碼質量？比較實際可用的就是 CodeReview，不要在乎每天多花的那 1 個小時左右的時間，作用可大著呢！

用叢集，減少單點故障

先拿常用的 Redis 舉個例子！我們如何保證我們的 Redis 快取高可用呢？答案就是使用叢集，避免單點故障。當我們使用一個 Redis 例項作為快取的時候，這個 Redis 例項掛了之後，整個快取服務可能就掛了。使用了叢集之後，即使一臺 Redis 例項，不到一秒就會有另外一臺 Redis 例項頂上。

限流

流量控制（flow control），其原理是監控應用流量的 QPS 或併發執行緒數等指標，當達到指定的閾值時對流量進行控制，以避免被瞬時的流量高峰沖垮，從而保障應用的高可用性。

超時和重試機制設定

一旦使用者請求超過某個時間的得不到響應，就丟擲異常。這個是非常重要的，很多線上系統故障都是因為沒有進行超時設定或者超時設定的方式不對導致的。我們在讀取第三方服務的時候，尤其適合設定超時和重試機制。一般我們使用一些 RPC 框架的時候，這些框架都自帶的超時重試的配置。如果不進行超時設定可能會導致請求響應速度慢，甚至導致請求堆積進而讓系統無法在處理請求。重試的次數一般設為 3 次，再多次的重試沒有好處，反而會加重伺服器壓力（部分場景使用失敗重試機制會不太適合）。

熔斷機制

超時和重試機制設定之外，熔斷機制也是很重要的。 熔斷機制說的是系統自動收集所依賴服務的資源使用情況和效能指標，當所依賴的服務惡化或者呼叫失敗次數達到某個閾值的時候就迅速失敗，讓當前系統立即切換依賴其他備用服務。 比較常用的是流量控制和熔斷降級框架是 Netflix 的 Hystrix 和 alibaba 的 Sentinel。

非同步呼叫

非同步呼叫的話我們不需要關心最後的結果，這樣我們就可以使用者請求完成之後就立即返回結果，具體處理我們可以後續再做，秒殺場景用這個還是蠻多的。但是，使用非同步之後我們可能需要 適當修改業務流程進行配合，比如使用者在提交訂單之後，不能立即返回使用者訂單提交成功，需要在訊息佇列的訂單消費者程序真正處理完該訂單之後，甚至出庫後，再透過電子郵件或簡訊通知使用者訂單成功。除了可以在程式中實現非同步之外，我們常常還使用訊息佇列，訊息佇列可以透過非同步處理提高系統性能（削峰、減少響應所需時間）並且可以降低系統耦合性。

使用快取

如果我們的系統屬於併發量比較高的話，如果我們單純使用資料庫的話，當大量請求直接落到資料庫可能資料庫就會直接掛掉。使用快取快取熱點資料，因為快取儲存在記憶體中，所以速度相當地快！

最最重要的永遠是程式碼質量，程式碼質量好了，出現問題的機率會降低很多。其他的再靠硬體、軟體、快取、叢集、CDN，反向代理 等配合上，才會有一個穩定的系統。

高可用虛擬化層面vnware的FT比較好用。

高可用硬體層面配置好後需要進行不定期切換以保證有效性，尤其是windows的高可用。有可能由於補丁不一致造成不可用。

架構上講究“三高”（3H），這裡的“三高”可不是我們日常生活中說的“三高”，而是指：高併發、高可用、高效能。

那什麼是系統架構的高可用呢？

高可用性指的是系統在架構上透過某些手段，使得當發生異常時，最大程度減少服務中斷時間，從而保證了服務的高度可用性。

舉個例子來說明一下：有兩個網站平臺A和B，A和B是競爭對手關係，向用戶提供的都是類似的服務。此時又出現一個C想和A與B競爭，C使用了某種手段向A與B發起了攻擊，結果A網站掛了，B網站依舊堅挺，我們就說B較A而言更具高可用性。

具體在平臺架構中該如何實施才能提高整個平臺的高可用性呢？結合我的架構經驗給出一些方案供大家參考：

1、業務分層

我們知道，一個大型平臺業務是很複雜的，而且各個業務間還有複雜的呼叫關係。如果把所有業務的實現全部放在一起（程式碼上放在一起、部署時放在一起）的話，那耦合度就太高了，很容易導致一個問題影響整個平臺的穩定性。

所以我們在架構實施初期就會考慮將業務分層，根據業務不同將整個系統橫向切割為多個部分，比如：使用者中心、訂單系統、支付系統、後臺系統、訊息系統、日誌系統等。

另外站在技術角度上我們可以將整個系統再劃分為三大層，即：應用層、服務層、資料層，這3層的具體定位是：

應用層：前端檢視展示，前後端使用者看到的介面性操作都劃到此類；

服務層：為應用層提供服務支援與呼叫的，比如API；

資料層：底層資料的儲存與互動，主要是：各類資料庫、各類快取等。

分層的好處就是方便後期的擴充套件，比如說分散式部署。

2、分散式部署

上面說到，我們可以將大型系統進行模組和業務上的分層，當分層後我們就可以分散式部署了。分散式部署能夠解決傳統集中式部署帶來的伺服器效能瓶頸問題。

分散式的實施有很多方面，如：

應用及服務的分散式：將不同模組分別部署在不同伺服器上、將資料庫和API部署在不同伺服器上；

動靜分離：將網站系統上所用到的靜態資源（如：CSS/JS/圖片/檔案）等使用單獨的域名來部署，不和當前系統根域名相同，以此將動態指令碼請求與靜態資源請求分離，這樣就可以減小應用伺服器的負載了。

資料庫分散式：將服務庫分散式部署，去中心化。

3、叢集部署

說到叢集和分散式，可能很多人分不清楚兩者區別。簡單的說，兩者區別是：

分散式：將一個大業務拆分為多個子業務，部署在不同的伺服器上，各司其職完成了一件事；

叢集：同一個業務，部署在多臺伺服器上；

分散式是邏輯上的形態，叢集是物理上的形態。

舉個例子：如果你是一個飯店老闆，客人上門時：前臺迎客、下單員下單、服務員端水擦桌、廚師做菜、收銀員結帳，這就是分散式；你不可能只招1個廚師吧，你招了10個廚師來做菜，這就是叢集，萬一哪天有個廚師生病了，還有其它廚師來做菜。

在架構中我們通常將資料庫叢集部署，這樣可以避免單臺伺服器的效能瓶頸。

4、負載均衡

負載均衡機制主要是用來處理高併發的，但這種分流機制在一定程度上也涉及到了高可用性。

5、非同步任務

假設有這樣一個場景，使用者註冊我們平臺後，需要傳送郵件給客戶確認、客戶確認後給這個使用者贈送初始的積分。通常我們是這樣做的：

使用者註冊資訊寫入資料庫；

然後呼叫郵件傳送服務，等待郵件傳送成功後；

再來給這個使用者進行積分贈送操作。

這樣做就是同步操作，是阻塞式的，如果傳送郵件時超時了，後面的任務可能就無法繼續了，顯然，這是不合理的。

我們可以將一件事拆分為多件事讓不同的人去做，做好了你再來通知我。這樣非同步操作可以節省整體事務完成的時間。

6、合理利用快取

利用快取，我們可以將熱點資料快取下來，這樣在一段時間內就避免去資料庫中查詢。快取的目的就是減輕伺服器的計算壓力。

常見快取實施種類也很多，比如說有：

靜態資源走CDN加速；

客戶端快取策略，可以減少客戶端對於伺服器的請求次數；

NoSQL儲存熱點資料，緩解資料庫壓力，就算資料庫掛了，在快取期內不必去查詢資料庫，這樣呼叫方不會出錯。

高可用性（HA），顧名思義，就是儘可能地減少系統不能提供服務的時間；如果一個系統能夠一直保持工作狀態，可以對外提供服務，那麼我們就說系統的可用性是100%；大部分公司不會把話說這麼滿，所以經常會提出三個9、四個9的目標，也就是全年系統可用性為99.9%、99.99%。

那麼如何保證系統的高可用呢？我認為核心的思想就是【防止單點，增加冗餘】，先讓我們看看傳統的架構是什麼樣的，哪裡會有風險。

可以看到，架構的每一個部分都是單點的話，簡直是風險重重，任何一個環節出現了問題，可能會造成整個系統垮掉（快取部分可能不會直接影響系統，但往往快取失去效果之後，會拖垮資料庫），解決方法也很容易，其實就是把系統的每個部分都增加冗餘：

客戶端到Web應用：要增加Web應用，首先要增加反向代理層，也就是負載均衡，比如Nginx；不過如果只部署一個Nginx的話，它又是一個單點了，通常我們會部署多臺，一臺提供服務，另外的相當於“備胎”，透過keepalived的方式監控工作中的Nginx是否存活，當主伺服器發生故障無法對外提供服務時，動態將virtual IP(虛IP)切換到備用機，繼續提供服務。

負載均衡到Web應用：搭建多個Web應用，在負載均衡如Nginx中配置多個Web端的地址，並且可以監控多個Web端的存活性，當監控到某臺應用掛掉，那麼Nginx不在將請求分發到這臺機器上。

Web應用到服務層：這裡有很多種實現方式，比如服務層前端也掛負載均衡，或者走客戶端內的負載均衡（這裡Web應用就是客戶端，相當於配置多個服務層的地址，每次請求按照一定規則，選取連線來訪問下游服務，並使用service-connection-pool監控服務層應用的存活性）；也可以使用服務註冊發現的方式（可提供服務的應用才會出現在註冊中心）。

服務層到快取：快取的存在，本身就是一種冗餘；快取層也可以透過叢集來解決快取層的高可用問題。以Redis為例，支援主從同步，而且有sentinel哨兵機制，來做Redis的存活性檢測。

服務層到資料庫：資料庫一般會採用主從架構；資料庫【讀】的高可用，通常使用db-connection-pool來保證自動故障轉移；而【寫】操作，通常需要keepalived+virtual IP(虛IP)自動切換。

以上都是保證系統高可用的方案，儘量做到客戶端所有的請求都可以響應，但是系統資源不可能無限投入，所以需要一些方案保證系統的高可用，不過需要【犧牲】部分使用者：

限流：我們介面只能支援200的併發，我們的頁面只能支援一萬人同時訪問，那麼多餘的部分，對不起，我需要限制你們進入；常見的限流演算法有：漏桶、令牌桶；

降級：犧牲非核心的業務功能，保證核心功能的穩定執行；

熔斷：當服務鏈路中（A調B，B調C，C調D），某個服務響應時間過長或失敗，會進行服務的降級，進而熔斷該節點服務的呼叫，快速返回錯誤資訊；不過嘛，我從來沒有見過誰敢用熔斷...

灰度釋出：將部分流量導到新上線的應用上，來驗證新的功能修改，如果上線後有BUG，也可以快速回滾，儘可能降低釋出的風險。

高可用（High Availability），主要是指減少系統的故障時間，保持系統的高度可用性。下面說一下個人的一些理解：

一、很多系統架構的高可用性，理解為雙機熱備。當然雙機熱備又可以分為主備方式，雙主方式，雙主方式主要是指互為主備。例如，使用比較多的是keepalived，透過keepalived配置雙機熱備的最大好處是，你無須對你的軟體系統做任何程式碼改動，即可實現雙機熱備。

二、當然藉助負載均衡實現系統高可用性。實現負載均衡的第三方軟體也較多。例如LVS，Engix等。這方面的配置方式的資料也比較多，有興趣的同學，可以直接從網上查閱，此處不做詳細介紹。

三、混合方式。雙機熱備+負載均衡的方式。例如keepalived+LVS實現更加好的高可用性。如下例所示：主要增加了負載均衡器的雙機熱備功能，避免了負載均衡器的單點故障，增加了系統的高可用性。

四、藉助zookeeper分散式框架，實現高可用。現在好多框架藉助zookeeper實現高可用。例如Dubbo微服務架構，HADOOP等，都採用zookeeper這種輕量級的分散式框架實現高可用。這種方式就需要涉及到程式碼程式設計。

看一下Dubbo:

上圖是Dubbo的框架，主要是使用zookeeper實現註冊器功能，生產者透過zookeeper的api介面向註冊器寫入服務提供者資訊，消費者同樣透過zookeeper的api介面從註冊中心獲取服務資訊，藉助zookeeper的分散式，實現Dubbo的高可用，這就涉及到程式碼的層面的實現。

本人具有多年的java開發經驗，熟悉多種框架，熟悉網路程式設計，熟悉java安全程式設計，熟悉大資料，熟悉多種安全協議，熟悉併發程式設計，有興趣的同學可以互相關注，互相學習！！！

1 一個公式

高可用方案千變萬化，但是萬變不離其宗。高可用核心公式如下：

高可用 = 冗餘 + 自動故障轉移 + 降級 + 隔離

2 兩種思路

我們來思考一個問題，怎樣保證一個工程系統的高可用性？有以下兩種做法：

思路1：考慮到所有意外情況，針對每一個意外的異常情況分別處理。

思路2：接受無法預料到所有意外情況的現實，把兜底方案做好，保證即使出現極端情況，系統也不會崩潰。

3 反脆弱

我們仔細分析思路1，會發現這其實是一個悖論。

所謂意外情況，就是意料之外的情況，無法預料的情況。如果被考慮到了，那麼也就不能稱之為意外情況了。

塔勒布在經典著作《反脆弱》一直想告訴我們的是，黑天鵝事件是無法預測的，極端的意外情況是無法預測的，尾部風險雖然機率微小，但是破壞力卻極大。

我們能做的就是保護好系統，讓系統在極端情況下不要崩潰。

4 冗餘

冗餘又分冷備份和熱備份。我們以資料庫為例。

冷備份是指定時將資料庫的資料備份，歸檔，供後續查閱和校對。

熱備份最常見的就是主從模式。主從資料實時同步，一來可以做讀寫分離，提高訪問效率，二來當主庫宕機，從庫可以頂上去繼續提供服務。

5 自動故障轉移

繼續以資料庫為例。當主庫宕機，肯定不能人工去切換成備庫，這樣對故障處理的響應時間肯定會增加，而應該自動切換為備庫。

這樣的例子還有很多，比如當nginx掛時keepalived能夠探測到會自動的進行故障轉移，Redis中的哨兵機制。

6 降級

所謂降級策略，就是當系統遇到無法承受的壓力時，選擇暫時關閉一些非關鍵的功能，或者延時提供一些功能，把此刻所有的資源都提供給現在最關鍵的服務。

在秒殺場景中，下訂單就是最核心最關鍵的功能。當系統壓力將要到達臨界值時，可以暫時先關閉一些非核心功能如查詢功能。

還有一種降級策略，當系統依賴的下游服務出現錯誤，甚至下游服務已經完全不可用了，那麼此時就不能再呼叫這個下游服務了，否則可能導致雪崩。所以直接返回兜底方案，把下游服務直接降級。

7 隔離

物理隔離：兩個應用分別部署在不同的物理機、不同的機房，資源不會互相影響。

執行緒隔離：不同的請求進行分類，交給不同的執行緒池處理，當一類請求出現高耗時和異常，不影響另一類請求的訪問。