文章總體在講系統的可用性問題，即如何從技術層面解決這個問題。李運華老師將演講文章內容提煉出一句精華之語：「把運維的鍋讓研發去背！」即高可用的系統是設計出來的，不是靠運維保障出來的！
可用性的目標是面向整個業務，這個目標就是幾分鐘來定位問題，幾分鐘能恢復業務，而且問題發生的頻率不能太高，幾個月發生一次（其中的「幾」要根據我們的業務目標來定）高可用性整體架構可以分為使用者層、網路層、服務層、運維層四層。
使用者層包括客戶端重試，如果遇到後端故障，最快的、對使用者影響最小的解決方式是立刻去重試，伺服器1有故障的話，我們重新發乙個請求到伺服器2，就能夠正確處理業務。重試有乙個關鍵點需要特別注意，重試的時候必須保證這個請求不要再發到原來有問題的伺服器上面，否則這個重試只是浪費時間。
網路層包括http-dns，即網域名稱和伺服器的對應關係，它有三個優點：①靈活。可以基於自己的業務特點做很多個性化的東西。②快速。因為它不存在快取的問題，一旦運維人員甚至是測試同學把這個伺服器下掉後，使用者這個請求能夠立刻拿到最新的結果，避免重複返回到原來有故障的機器。③方便。這個系統是運營商自己維護的，想做什麼樣的操作都可以，如果是公共的dns那無法實現這個效果。
服務層包括架構解耦、業務降級、異地多活，架構解耦包括業務分離和服務中心，業務分離即把系統中的功能分開，因為對於遊戲玩家來說，只有登入註冊是強相關的，業務分離就是把核心業務和非核心業務拆分到不同系統中，呼叫時通過介面訪問；服務中心類似於dns，是實現整個內部系統之間服務呼叫時候的排程功能。業務分離將核心業務和非核心業務分開後，可能會出現一些極端情況，比如非核心業務啟動不了了，或者資料庫崩了，它就會影響核心業務。但是，在這種比較極端的情況下，我們可以通過人工的方式下發降級指令，把這個非核心業務系統的功能給停掉，這個停掉並不是把程式停掉，而是說把其中的乙個介面或者url停掉，核心系統去訪問的時候就得到乙個500或者503錯誤。異地多活的優點有業務層資料業務、二次讀取、可重複生成唯一資料。
運輸層：要對系統實時監控。這是為了更快的找到故障點，這樣的話可以更快的解決故障，增加系統的可用性。比如這篇文章中說：「為了能夠快速處理這個故障，我們進行了詳細的分析，把真正出故障的時候要關注哪些資訊、關注哪些指標，都通過預先的日誌採集、計算、分析完成，放在那裡等我們要處理故障或者問題的時候，直接看就可以了。」其次還要對系統的監控指標進行視覺化展示，比如，今日的訪問量、今日的正確率、最近一分鐘的平均響應時間、錯誤率等，系統的狀態一目了然，這樣的話可以快速的定位問題。
經過這些技術的修改，大大提高了系統的可用性，雖然裝置還是會出現故障，但是系統對這些故障的處理很及時，最重要的是不影響使用者的使用。
阿里遊戲高可用架構設計實踐 讀後感
這篇文章基本總體就是在講系統的可用性問題，即如何從技術層面解決這個問題。在對可用性的解釋，我在之前的 以 網 為例，描繪質量屬性的六個常見屬性場景 中有解釋到。可用性 可用性是指系統正常執行時間的比例，是通過兩次故障之間的時間長度或在系統崩潰情況下能夠恢復正常執行的速度來衡量的。在對可用性的使用場景...
阿里遊戲高可用架構設計實踐讀後感
閱讀文章 阿里遊戲高可用架構設計實踐 文章 整個演講的內容給我印象最深的就是 把運維的鍋讓研發去背，即高可用的系統是設計出來的，不是靠運維保障出來的。系統設計方案有問題，從技術方面來解決這個問題。高可用目標 傳統方法 確定這個方向之後我們就需要定乙個目標，首先確定乙個目標。高可用其實都是指幾個9，5...
《阿里遊戲高可用架構設計實踐》讀後感
阿里遊戲高可用架構設計實踐 讀後感 在文章當中我印象最深刻的一句話是 高可用的系統是設計出來的，不是靠運維保障出來的！遊戲出現故障會有很多原因，並不是說除了程式bug以外，可能其他都是運維背黑鍋了。其實，這些問題背後真正的原因是系統設計方案有問題，也就是說，技術上是比較弱的。1 高可用目標 傳統方法...