《阿里遊戲高可用架構設計實踐》讀後感

　　【轉】文章地址：https://mp.weixin.qq.com/s/iTtpa2zUpboKum6xfgXwQQ【該文章爲李運華老師的演講《阿里遊戲高可用架構設計實踐》文章】

 　　李運華老師將演講文章內容提煉出一句精華之語：「把運維的鍋讓研發去背！」即高可用的系統是設計出來的，不是靠運維保障出來的！

　　在不少時候，系統發生了故障，如機櫃斷電、交換機斷機、服務器斷機、程序Bug等故障，你們認爲硬件設備的問題就跟研發組的同鞋沒有關係，但事實真的如此嗎？通過深刻的討論和分析，最後得出根本緣由仍是系統設計方案有問題，即技術上是比較弱的。獲得根本緣由後解決策略就比較容易看出，即「把運維的鍋讓研發去背！」，由此，能夠肯定一個目標：高可用性便是指幾個九，是99%仍是99.9%仍是99.99%仍是99.999%等等，這個指標的優勢的是業界通用，可是除了技術人員，其餘的同窗不是很能理解這個指標。因此又制定了另外一個目標：3分鐘來定位問題，5分鐘能恢復業務，並且問題的發生頻率不能過高。這個目標的優勢是聚焦業務、容易分解（首先要定位問題，其次是恢復業務，再次是故障的頻率不能過高）、容易衡量（再作方案的時候，不少方案只要拿這個標準一套，基本上就可以判斷這個方案是否可行）。

　　高可用性總體架構能夠分爲用戶層、網絡層、服務層、運維層四層。

　　用戶層包括客戶端重試，若是遇到後端故障，最快的、對用戶影響最小的解決方式是馬上去重試，服務器1有故障的話，咱們從新發一個請求到服務器2，就可以正確處理業務。重試有一個關鍵點須要特別注意，重試的時候必須保證這個請求不要再發到原來有問題的服務器上面，不然這個重試只是浪費時間。

　　網絡層包括HTTP-DNS，即域名和服務器的對應關係，它有三個優勢：①靈活。能夠基於本身的業務特色作不少個性化的東西。②快速。由於它不存在緩存的問題，一旦運維人員甚至是測試同窗把這個服務器下掉後，用戶這個請求可以馬上拿到最新的結果，避免重複返回到原來有故障的機器。③方便。這個系統是運營商本身維護的，想作什麼樣的操做均可以，若是是公共的DNS那沒法實現這個效果。

　　服務層包括架構解耦、業務降級、異地多活，架構解耦包括業務分離和服務中心，業務分離即把系統中的功能分開，由於對於遊戲玩家來講，只有登陸註冊是強相關的，業務分離就是把核心業務和非核心業務拆分到不一樣系統中，調用時經過接口訪問；服務中心相似於DNS，是實現整個內部系統之間服務調用時候的調度功能。業務分離將核心業務和非核心業務分開後，可能會出現一些極端狀況，好比非核心業務啓動不了了，或者數據庫崩了，它就會影響核心業務。可是，在這種比較極端的狀況下，咱們能夠經過人工的方式下發降級指令，把這個非核心業務系統的功能給停掉，這個停掉並非把程序停掉，而是說把其中的一個接口或者url停掉，核心系統去訪問的時候就獲得一個500或者503錯誤。異地多活的優勢有業務層數據業務、二次讀取、可重複生成惟一數據。

　　360°監控總體方案從上到下分爲五層：業務層、應用服務層、接口調用層、基礎組件層、基礎設施層。業務層就是業務上的打點，根據這些打點進行機型統計或者分析；應用服務層就是url的一個訪問狀況；接口調用層就是系統對外部依賴的那些接口的訪問狀況；基礎組件層即便用的一些組件，包括MySQL等；基礎設施層就是最底層的設備，包括操做系統、網絡、磁盤、IO這些設備。

　　通過這些技術的修改，大大提升了系統的可用性，雖然設備仍是會出現故障，可是系統對這些故障的處理很及時，最重要的是不影響用戶的使用。