淺談高可用和設計的一些原則(JAVA)

前言

上文說到了關於高併發的一些原則及設計，這篇主要是講講關於高可用這一塊，畢竟都是難兄難弟，誰也離不開誰。

關於高可用？ 高可用的本質就是對系統的不肯定性作預期準備，來保證服務的健康，包括常常聽到的數據丟失、容災、故障等除了不可抗因素外，要達到所謂衡量標準的N個9。 關於N個9的計算方式，例如3個9：(1-99.9%) * 365 * 24=8.76小時，表示該軟件系統在連續運行1年時間裏最多可能的業務中斷時間是8.76小時。

設計高可用原則

1. **降級：**總的來講就是保障數據最終一致性，分散流量，提早預處理或分散處理，前面文章裏面說到的Hystrix熔斷就是實現服務降級與依賴隔離，對訪問down服務進行隔離丟給降級後的服務處理，防止影響到其它服務。這裏說的是服務/業務方面的降級，固然還有不少其它方面。例如：

   

   • 超時降級：相似推薦或者評論啊，暫時不展現或者暫未更新對總體不會有太大的影響。
   • 依賴降級：針對的是一些外部服務，一些不穩定的API。
   • 故障降級：網絡、RPC服務等掛掉了，處理方案能夠經過緩存、默認值、兜底數據來保障。
   • 限流降級：針對一些超大流量作友好處理。

2. **隔離：**將系統或資源分開，服務之間都是有依賴的，很容易因一方面服務故障致使滾雪球，隔離可以保障其它服務不會受影響，把問題控制並下降。

   • 線程隔離：請求分類，不影響其它分類線程池的正常運行。

     

   • 進程隔離：物理分離，部署多個實例，經過負載均衡路由轉發，可是更好的解決方案是將系統拆分爲多個子系統來實現隔離。
   • 讀寫隔離：相似Redis就可用經過主從複製模式將讀和寫進行集羣分離。
   • 動靜隔離：前面說的高併發也提到過，都是相輔相成的，把動態內容和靜態資源分離，靜態資源可用提早作緩存。
   • 爬蟲隔離：主要是爲了防止惡意請求流量，會致使正常流量不可用，因此一方面可用經過限流解決，一方面可用將爬蟲單獨路由到單獨服務上，或者讓爬蟲只能訪問到cache。
   • 熱點隔離：熱點通常都是可以提早預知的，好比秒殺、搶購、大降價等，最好是作成獨立系統或者服務進行隔離，也可用經過緩存和隊列來進行削峯。

3. **限流：**限流主要是防止流量超出系統峯值，是限制流量穿透到後端薄弱的應用層，這個可用從多個方面考慮；最終作到有損服務而不是不服務。經常使用的限流算法有令牌桶、漏桶等。

   • 限制併發/鏈接/請求數：系統都是由閥值（TPS/QPS）的，超過了要麼很是慢，要麼直接被擊垮。
   • 時間內/平滑限流：限制時間內的請求次數，或者每隔多長時間處理一個請求。
   • 接入層限流：接入層也就是請求流量的入口，像Nginx自帶的兩個模塊就能夠，鏈接數限流模塊和請求限流模塊。

4. **分流：**引流就是當某個服務掛了或者某個地方故障了須要把流量引向其餘好的服務或者備用服務上去。

   • 負載均衡與反向代理

5. **超時與重試機制：**設置超時可以避免慢請求累積致使系統雪崩，須要設置合理的重試機制，而且應該和熔斷、快速失敗機制配合。

6. **回滾：**當程序或者數據出錯，可用經過回滾恢復到最近的一個正確版本上，好比事務回滾、代碼庫回滾、更新版本回滾、數據庫回滾、靜態資源回滾等等。

7. **壓測與預案：**評估系統的穩定性和性能，提早作好應急預案。

總結來講經過降級保證服務有損而不是不可用，經過限流保護服務健康避免雪崩，經過分流與隔離保障服務正常並可以對故障實行隔離，設置合理的超時與重試機制避免請求堆積，經過回滾可以快速修復。作到這些每每能實現系統的高可用。

附上設計例圖：

結語

關於例圖裏面的一些詳細示例之後再慢慢補充吧！
推薦：淺談高併發和設計的一些原則(JAVA)
我的博客~
簡書~