閱讀文章：阿里遊戲高可用架構設計實踐
文章**：
整個演講的內容給我印象最深的就是：把運維的鍋讓研發去背，即高可用的系統是設計出來的，不是靠運維保障出來的。
系統設計方案有問題，從技術方面來解決這個問題。
高可用目標——傳統方法
確定這個方向之後我們就需要定乙個目標，首先確定乙個目標。高可用其實都是指幾個9，5個9的話可能就是電信級或者金融級的，網際網路大部分是3個9到4個9。這個目標的優點是業界通用，高技術的大家都接受了這個目標。缺點是除了技術人員，其他同學不是很好理解，他們沒有辦法將4個9或者5個9轉換成直觀的理解。所以，在定專案目標的時候並沒有這樣去定。
高可用目標——面向業務
最終確定的目標跟幾個9的目標有乙個比較大的區別，幾個9的目標主要是從系統的角度去考慮的，就是說這個系統的可靠性是幾個9。而我們的目標是面向整個業務，這個目標就是3分鐘來定位問題，5分鐘能恢復業務，而且問題的發生頻率不能太高，2個月發生一次。
這個目標的優點：
（1）聚焦業務
（2）容易分解。目標本身就是我們的工作方向，首先要定位問題，其次是恢復業務，第三是故障的頻率不能太高。
（3）容易衡量。後來再做方案的時候，很多方案只要拿這個標準一套，基本上就能夠判斷這個方案是否可行。
整個目標最終折算下來，對應的差不多是4個9左右，比4個9高一點點。
高可用整體架構，整體架構一共分為四層：使用者層、網路層、服務層、運維層。
客戶端重試，在遊戲接入階段，遊戲裡會嵌入sdk，對於sdk內的產品來說，如果遇到後端故障，最快、對使用者影響最小的解決方式是立刻去重試，伺服器1有故障的話，重新發乙個請求到伺服器2，就能夠正確處理業務。重試裡面有乙個關鍵點需要特別注意，重試的時候必須保證這個請求不要再發到原來有問題的伺服器上面，否則這個重試只是浪費時間。
傳統dns問題，在重試的時候，要盡量保證重試的伺服器跟原來的伺服器不一樣，但是傳統的dns正好在這方面存在天然的缺陷，dns存在三個方面的問題：（1）dns劫持（2）dns汙染（3）dns快取。
http-dns系統有三個優點：
（1）靈活。因為這個走的是http的協議，而且是私有的，可以基於自己的業務特點做很多個性化的東西。
（2）快速。因為它不存在快取這個問題，一旦運維人員甚至是測試同學把這個伺服器下掉後，使用者這個請求能夠立刻拿到最新的結果，避免重複返回到原來有故障的機器。
（3）方便。這個系統是我們自己維護的，想做什麼樣的操作都可以，如果是公共的dns那就做不了。
架構解耦，業務分離的做法就是把核心業務和非核心業務分拆到不同的系統中，把兩個系統之間通過介面呼叫，互相訪問。
業務降級，整個系統拆分成核心業務系統和非核心業務系統，在一些緊急情況下，比如說非核心業務系統重啟也沒有辦法，甚至說某個資料庫搞掛了，它又影響業務核心系統。在這種比較極端的情況下，我們可以通過人工的方式下發降級指令，把這個非核心業務系統的功能給停掉，這個停掉並不是把程式停掉，而是說把其中的乙個介面或者url停掉，核心系統去訪問的時候就得到乙個500或者503錯誤。降級的時候並不是對整個系統或者整個功能進行降級，我們可以做到介面或者url這個級別的降級。通過犧牲非核心業務系統的功能，我們盡最大努力地去保證核心業務系統提供的業務。
異地多活，為了解決全域性單點、跨機房同步時延的問題，提出了一套新架構。
新架構與舊架構相比。最大的特點是：
（1）業務層資料同步。
（2）二次讀取。
（3）可重複生成全域性唯一資料。
360度監控，整體方案從上到下分為五層：業務層、應用服務層、介面呼叫層、基礎元件層、基礎設施層。
阿里遊戲高可用架構設計實踐 讀後感
這篇文章基本總體就是在講系統的可用性問題，即如何從技術層面解決這個問題。在對可用性的解釋，我在之前的 以 網 為例，描繪質量屬性的六個常見屬性場景 中有解釋到。可用性 可用性是指系統正常執行時間的比例，是通過兩次故障之間的時間長度或在系統崩潰情況下能夠恢復正常執行的速度來衡量的。在對可用性的使用場景...
《阿里遊戲高可用架構設計實踐》讀後感
阿里遊戲高可用架構設計實踐 讀後感 在文章當中我印象最深刻的一句話是 高可用的系統是設計出來的，不是靠運維保障出來的！遊戲出現故障會有很多原因，並不是說除了程式bug以外，可能其他都是運維背黑鍋了。其實，這些問題背後真正的原因是系統設計方案有問題，也就是說，技術上是比較弱的。1 高可用目標 傳統方法...
《阿里遊戲高可用架構設計實踐》 閱讀
文章總體在講系統的可用性問題，即如何從技術層面解決這個問題。李運華老師將演講文章內容提煉出一句精華之語 把運維的鍋讓研發去背！即高可用的系統是設計出來的，不是靠運維保障出來的！可用性的目標是面向整個業務，這個目標就是幾分鐘來定位問題，幾分鐘能恢復業務，而且問題發生的頻率不能太高，幾個月發生一次 其中...