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

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

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

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

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

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

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

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

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

• 限流：我們接口只能支持200的并發，我們的頁面只能支持一萬人同時訪問，那么多余的部分，對不起，我需要限制你們進入；常見的限流算法有：漏桶、令牌桶；
  

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

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

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

我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。