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

[[174139]]

張明強(qiáng)，2013年加入陌陌，經(jīng)歷了流量爆發(fā)式增長給技術(shù)架構(gòu)、團(tuán)隊管理帶來的各種問題及其解決過程?，F(xiàn)任技術(shù)保障部總監(jiān)，主要負(fù)責(zé)基礎(chǔ)架構(gòu)、運(yùn)維、安全、信息化等工作，致力于提升服務(wù)穩(wěn)定性與團(tuán)隊開發(fā)效率。

歸類

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

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

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

張明強(qiáng)總結(jié)了五種針對這些故障的具體解決辦法。

分析

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

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

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

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

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

【51CTO原創(chuàng)稿件，合作站點轉(zhuǎn)載請注明原文作者和出處為51CTO.com】