【51CTO.com原創稿件】在WOT2016移動互聯網技術峰會上，陌陌技術保障部總監張明強老師表示“業務體系越龐大，高可用保障越困難”。會上，張明強老師以整體視角，來完整的歸納一下之前在高可用保障工作上的方方面面，以及每一方面易踩的坑。

[[174139]]

張明強，2013年加入陌陌，經歷了流量爆發式增長給技術架構、團隊管理帶來的各種問題及其解決過程。現任技術保障部總監，主要負責基礎架構、運維、安全、信息化等工作，致力于提升服務穩定性與團隊開發效率。

歸類

最常見的故障誘因就是掛，掛的出現形式一般分為三種：徹底消失、假死和閃斷。而針對這些故障形式，也有相應的解決方法。在一個復雜的業務架構中，監控是最為核心的一部分，如果沒有監控，這個體系無論技術再強大，絕對不會是高可用。在做好監控之后還要準備“后備軍”，掛了之后切到另外一個去就行，用多實例來解決掛的問題，多實例可以解決所有管的問題，只要設計得當。拆分是整個架構設計中非常重要的一個思路，當體系復雜的時候掛就像生病一樣是無法避免的，這時運用拆分的理念不要讓病原體再擴散，這個思路幾乎可以解決所有的問題。

因為硬件的完善，掛所引起的故障不算太多。但是代碼邏輯寫的不好，設計稍有不慎，或者數據庫太大，就會引起各種各樣慢的問題，慢也有三種表現形式：自身慢、下游慢和上游慢。對于自身慢只要改善自身的問題，完善代碼或者結構就可以有所改善。下游慢是日常運維過程中比較容易出現的一種，多見于數據庫慢導致依賴的某個服務慢了，這時候就要分析問題是出自自身數據庫，還是第三方的問題，分析日志和監控數據變成了很重要的事。上游慢不是很常見，但也不能忽略，其實99%的故障都是非常簡單的，只要能在設計階段能設想到的就能解決掉，主要問題在設計階段能不能想全。解決思路非常簡單，***多實例，第二是緩存，第三是拆分。

還有一種故障誘因是出錯，這是能導致問題最多的一種，也是在設計中最容易忽略的一種，這種設計依賴于下游的模塊，出錯也有兩種表現形式：錯和空。純粹的故障性錯誤是完全可以避免的，但技術卻不是***的，技術解決不了的問題就需要通過管理或其他方式來解決，技術和管理這兩條線都不能放松。其中流程規范是解決錯誤的***解決辦法，團隊中的每個人都有可能犯錯，但是流程規范了這類問題就可以盡量避免。多做實例也是一個非常好的辦法，當一個實例錯了起碼還可以從別的地方恢復過來，多做類似的措施以防止整條線全塌。

張明強總結了五種針對這些故障的具體解決辦法。

分析

***就是監控，監控是基礎，是整個高可用體系的根本。針對監控有三種形式：一個是業務監控，平臺/框架監控，還有硬件監控，業務都會采用很多不同的框架，這三者結合起來才能打造一個完整的監控體系。在監控上容易踩的坑有四點：一，監控=數據+報警，所有數據都必須有報警才能稱之為監控，否則只能說是統計。二，報警是要看的，要保證報警是有效的。三，靠監控自動處理的設計，小心誤報，要依賴多因素驗證。四，監控拖垮服務。

第二是多實例，多實例的核心是有備無患，有三種表現形式：冷備、熱備和多活。冷備的核心是當服務發生故障之后，備份實例沒有辦法立即啟用，需要人工接入，人工接入是冷備的一個核心特點。熱備很簡單，比如通常用的LVS、Keepalived，很多內部設計都是熱備，熱備是出問題之后工程師不用親自管理，程序能自動切。第三部分是多活，多活是多實例里一個***目標，所有實例都在同時跑業務。在多實例上容易踩的坑有三點：一，首先要時刻記得多實例是用來解決什么級別的問題，把握住自己的需求，針對錯誤去解決。二、客戶端會不會切換失敗？要從整體出發，不是只有Server做了就行，客戶端的請求必須能切走。三，要明確知道備機容量夠不夠，這是多實例中最容易出現的問題。

第三個方法是拆分，當所有方法都無計可施了，拆分都可以起作用，把錯誤的、有問題的拆出來單獨部署，這是一個最保底的方案。拆分有兩個表現形式：一個形式是拆入口，通過一定的路由規則把請求路由到不同的服務器上，防止一掛全掛；另一部分是拆階段，把一個同步的請求拆成好多部分，比如常說的異步之類這些詞。

第四種方法是緩存，緩存天生就是用來解決性能問題的，將CPU不停加到L1/L3緩存，來提高速度這是***種辦法；第二種辦法是將單通道改成多核，把一個實例改成多個實例做設計，緩存形式只有一個就是對數據做緩存。緩存容易踩的坑有四點：一，無***率監控，極低而不自知。二，臟數據。三，系統對穿透率支持的太低。四，緩存太散，導致IO次數太多，耗時太長。對于監控來說緩存一定要有***率。緩存還要關心Hits、Miss、性能和容量。

***的方法是流程規范，就像前面講到的，技術并不是***的，所以要將技術和管理二者結合起來。流程規范有兩種形式：一個是強制規范，一個是倡導類的。流程規范容易踩的坑有三點：一，一大堆規范。二，太復雜，難以執行。三，無人遵守，管理上不跟進。對于流程規范來說，上線規范是最重要的，上線規范又是灰度發布最重要的一個環節，這兩個是整個高可用體系***的一道屏障，如果能隨意突破，前面做再多的工作也白搭。

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】