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

[[174139]]

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

歸類

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

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

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

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

分析

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

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

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

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

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

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