這篇文章基本總體就是在講系統的可用性問題，即如何從技術層面解決這個問題。在對可用性的解釋，我在之前的《以《**網》為例，描繪質量屬性的六個常見屬性場景》中有解釋到。
可用性：可用性是指系統正常執行時間的比例，是通過兩次故障之間的時間長度或在系統崩潰情況下能夠恢復正常執行的速度來衡量的。在對可用性的使用場景，我在之前的《以《**網》為例，描繪質量屬性的六個常見屬性場景》中有解釋到。
高可用的系統是設計出來的，不是靠運維保障出來的，
但是如何在設計系統的時候如何提高系統的可用性呢？
1.高可用目標-面向業務
可用性的目標是面向整個業務，這個目標就是幾分鐘來定位問題，幾分鐘能恢復業務，而且問題發生的頻率不能太高，幾個月發生一次（其中的「幾」要根據我們的業務目標來定）
2.高可用整體架構（整體架構分為四層：使用者層、網路層、服務層、運維層）
1)使用者層：客戶端重試，即當遇到後端故障的時候，對使用者影響最小的解決方式就是讓使用者重試，如伺服器發生故障的時候，就重新傳送乙個請求到另乙個伺服器，在另乙個伺服器中處理業務
2)網路層：http-dns
3)服務層：架構解耦
·業務分離：業務分離的做法就是把核心業務和非核心業務分拆到不同的系統中，把 兩個系統之間通過介面呼叫，互相訪問，這樣做的好處，加入非核心業務系統出現故障，它並不影響核心業務，因為它們之間是通過介面呼叫的，並不共享相同的資源。
·業務降級：通過犧牲非核心業務系統的功能，盡可能地保證核心業務系統提供的業務
4)運輸層：要對系統實時監控。這是為了更快的找到故障點，這樣的話可以更快的解決故障，增加系統的可用性。比如這篇文章中說：「為了能夠快速處理這個故障，我們進行了詳細的分析，把真正出故障的時候要關注哪些資訊、關注哪些指標，都通過預先的日誌採集、計算、分析完成，放在那裡等我們要處理故障或者問題的時候，直接看就可以了。」其次還要對系統的監控指標進行視覺化展示，比如，今日的訪問量、今日的正確率、最近一分鐘的平均響應時間、錯誤率等，系統的狀態一目了然，這樣的話可以快速的定位問題。
針對可用性對系統架構的設計哲學：
1）面向業務。不單單關注某乙個系統某乙個模組的可靠性和高可用，而是站在整個業務流程的角度去分析一下，未來保證這個業務的高可用，每乙個步驟、每乙個環節、每乙個系統應該怎麼做，需要做哪些改進和優化。
2）技術驅動。整體的方案都從技術的角度去考慮
3）關注核心。非核心業務可以晉級的時候停掉或者關掉，從而盡可能地保證核心業務系統提供的業務。
4）可量化。監控裡的這些指標和分析都是可量化的，整個專案目標是可以量化的。
參考文章：
阿里遊戲高可用架構設計實踐讀後感
閱讀文章 阿里遊戲高可用架構設計實踐 文章 整個演講的內容給我印象最深的就是 把運維的鍋讓研發去背，即高可用的系統是設計出來的，不是靠運維保障出來的。系統設計方案有問題，從技術方面來解決這個問題。高可用目標 傳統方法 確定這個方向之後我們就需要定乙個目標，首先確定乙個目標。高可用其實都是指幾個9，5...
《阿里遊戲高可用架構設計實踐》讀後感
阿里遊戲高可用架構設計實踐 讀後感 在文章當中我印象最深刻的一句話是 高可用的系統是設計出來的，不是靠運維保障出來的！遊戲出現故障會有很多原因，並不是說除了程式bug以外，可能其他都是運維背黑鍋了。其實，這些問題背後真正的原因是系統設計方案有問題，也就是說，技術上是比較弱的。1 高可用目標 傳統方法...
《阿里遊戲高可用架構設計實踐》 閱讀
文章總體在講系統的可用性問題，即如何從技術層面解決這個問題。李運華老師將演講文章內容提煉出一句精華之語 把運維的鍋讓研發去背！即高可用的系統是設計出來的，不是靠運維保障出來的！可用性的目標是面向整個業務，這個目標就是幾分鐘來定位問題，幾分鐘能恢復業務，而且問題發生的頻率不能太高，幾個月發生一次 其中...