高可用性（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開發、架構設計、程序員職業發展等方面的見解，希望能得到妳的關註。