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