對每一個程式員而言，故障都是懸在頭上的達摩克利斯之劍，都唯恐避之不及，如何避免故障是每一個程式員都在苦苦追尋希望解決的問題。對于這一問題，大家都可以從需求分析、架構設計 、代碼編寫、測試、code review、上線、線上服務運維等各個視角給出自己的答案。本人結合自己兩年有限的網際網路後端工作經驗，從某幾個視角談談自己對這一問題的了解，不足之處，望大家多多指出。
我們大部分服務都是如下的結構，既要給使用方使用，又依賴于他人提供的第三方服務，中間又穿插了各種業務、算法、資料等邏輯，這裡面每一塊都可能是故障的來源。如何避免故障？我用一句話概括，“懷疑第三方，防備使用方，做好自己”。
1 懷疑第三方
堅持一條信念：“所有第三方服務都不可靠”，不管第三方什麼天花亂墜的承諾。基于這樣的信念，我們需要有以下行動。
1.1 有兜底，制定好業務降級方案
如果第三方服務挂掉怎麼辦？我們業務也跟着挂掉？顯然這不是我們希望看到的結果，如果能制定好降級方案，那将大大提高服務的可靠性。舉幾個例子以便大家更好的了解。
比如我們做個性化推薦服務時，需要從使用者中心擷取使用者的個性化資料，以便代入到模型裡進行打分排序，但如果使用者中心服務挂掉，我們擷取不到資料了，那麼就不推薦了？顯然不行，我們可以在cache裡放置一份熱門商品以便兜底；
又比如做一個資料同步的服務，這個服務需要從第三方擷取最新的資料并更新到mysql中，恰好第三方提供了兩種方式：1）一種是消息通知服務，隻發送變更後的資料；2）一種是http服務，需要我們自己主動調用擷取資料。我們一開始選擇消息同步的方式，因為實時性更高，但是之後就遭遇到消息遲遲發送不過來的問題，而且也沒什麼異常，等我們發現一天時間已過去，問題已然更新為故障。合理的方式應該兩個同步方案都使用，消息方式用于實時更新，http主動同步方式定時觸發（比如1小時）用于兜底，即使消息出了問題，通過主動同步也能保證一小時一更新。
有些時候第三方服務表面看起來正常，但是傳回的資料是被污染的，這時還有什麼方法兜底嗎？有人說這個時候除了通知第三方快速恢複資料，基本隻能幹等了。舉個例子，我們做移動端的檢索服務，其中需要調用第三方接口擷取資料來建構反向索引，如果第三方資料出錯，我們的索引也将出錯，繼而導緻我們的檢索服務篩選出錯誤的内容。第三方服務恢複資料最快要半小時，我們建構索引也需要半小時，即可能有超過1個多小時的時間檢索服務将不能正常使用，這是不可接受的。如何兜底呢？我們采取的方法是每隔一段時間儲存全量索引檔案快照，一旦第三方資料源出現資料污染問題，我們先按下停止索引建構的開關，并快速復原到早期正常的索引檔案快照，這樣盡管資料不是很新（可能1小時之前），但是至少能保證檢索有結果，不至于對交易産生特别大的影響。
1.2 遵循快速失敗原則，一定要設定逾時時間
某服務調用的一個第三方接口正常響應時間是50ms，某天該第三方接口出現問題，大約有15%的請求響應時間超過2s，沒過多久服務load飙高到10以上，響應時間也非常緩慢，即第三方服務将我們服務拖垮了。
為什麼會被拖垮？沒設定逾時！我們采用的是同步調用方式，使用了一個線程池，該線程池裡最大線程數設定了50，如果所有線程都在忙，多餘的請求就放置在隊列裡中。如果第三方接口響應時間都是50ms左右，那麼線程都能很快處理完自己手中的活，并接着處理下一個請求，但是不幸的是如果有一定比例的第三方接口響應時間為2s，那麼最後這50個線程都将被拖住，隊列将會堆積大量的請求，進而導緻整體服務能力極大下降。
正确的做法是和第三方商量确定個較短的逾時時間比如200ms，這樣即使他們服務出現問題也不會對我們服務産生很大影響。
1.3 适當保護第三方，慎重選擇重試機制
需要結合自己的業務以及異常來仔細斟酌是否使用重試機制。比如調用某第三方服務，報了個異常，有些同學就不管三七二十一就直接重試，這樣是不對的，比如有些業務傳回的異常表示業務邏輯出錯，那麼你怎麼重試結果都是異常；又如有些異常是接口處理逾時異常，這個時候就需要結合業務來判斷了，有些時候重試往往會給後方服務造成更大壓力，啟到雪上加霜的效果。
2 防備使用方
這裡又要堅持一條信念：“所有的使用方都不靠譜”，不管使用方什麼天花亂墜的保證。基于這樣的信念，我們需要有以下行動。
2.1 設計一個好的api（RPC、Restful），避免誤用
過去兩年間看過不少故障，直接或間接原因來自于糟糕的接口。如果你的接口讓很多人誤用，那要好好反思自己的接口設計了，接口設計雖然看着簡單，但是學問很深，建議大家好好看看Joshua Bloch的演講《How to Design a Good API & Why it Matters（如何設計一個好的API及為什麼這很重要）》以及《Java API 設計清單》。
下面簡單談談我的經驗。
a） 遵循接口最少暴露原則
使用方用多少接口我們就提供多少，因為提供的接口越多越容易出現亂用現象，言多必失嘛。此外接口暴露越多自己維護成本就越高。
b） 不要讓使用方做接口可以做的事情
如果使用方需要調用我們接口多次才能進行一個完整的操作，那麼這個接口設計就可能有問題。比如擷取資料的接口，如果僅僅提供getData(int id);接口，那麼使用方如果要一次性擷取20個資料，它就需要循環周遊調用我們接口20次，不僅使用方性能很差，也無端增加了我們服務的壓力，這時提供getDataList(List<Integer> idList);接口顯然是必要的。
c）避免長時間執行的接口
還是以擷取資料方法為例：getDataList(List<Integer> idList); 假設一個使用者一次傳1w個id進來，我們的服務估計沒個幾秒出不來結果，而且往往是逾時的結果，使用者怎麼調用結果都是逾時異常，那怎麼辦？限制長度，比如限制長度為100，即每次最多隻能傳100個id，這樣就能避免長時間執行，如果使用者傳的id清單長度超過100就報異常。
加了這樣限制後，必須要讓使用方清晰地知道這個方法有此限制。之前就遇到誤用的情況，某使用者一個訂單買了超過100個商品，該訂單服務需要調用商品中心接口擷取該訂單下所有商品的資訊，但是怎麼調用都失敗，而且異常也沒打出什麼有價值的資訊，後來排查好久才得知是商品中心接口做了長度限制。
怎麼才能做到加了限制，又不讓使用者誤用呢？
兩種思路：1）接口幫使用者做了分割調用操作，比如使用者傳了1w個id，接口内部分割成100個id清單（每個長度100），然後循環調用，這樣對使用方屏蔽了内部機制，對使用方透明；2）讓使用者自己做分割，自己寫循環顯示調用，這樣需要讓使用者知道我們方法做了限制，具體方法有：1）改變方法名，比如getDataListWithLimitLength(List<Integer> idList); ；2）增加注釋；3）如果長度超過 100，很明确地抛出異常，很直白地進行告知。
d）參數易用原則
避免參數長度太長，一般超過3個後就較難使用，那有人說了我參數就是這麼多，那怎麼辦？寫個參數類嘛！
此外避免連續的同類型的參數，不然很容易誤用。
能用其它類型如int等的盡量不要用String類型，這也是避免誤用的方法。
e）異常
接口應當最真實的反應出執行中的問題，更不能用聰明的代碼做某些特别處理。經常看到一些同學接口代碼裡一個try catch，不管内部抛了什麼異常，捕獲後傳回空集合。
public List<Integer> test() {
try {
...
} catch (Exception e) {
return Collections.emptyList();
}
}
這讓使用方很無奈，很多時候不知道是自己參數傳的問題，還是服務方内部的問題，而一旦未知就可能誤用了。
2.2 流量控制，按服務配置設定流量，避免濫用
相信很多做過高并發服務的同學都碰到類似事件：某天A君突然發現自己的接口請求量突然漲到之前的10倍，沒多久該接口幾乎不可使用，并引發連鎖反應導緻整個系統崩潰。
為什麼會漲10倍，難道是接口被外人攻擊了，以我的經驗看一般内部人“作案”可能性更大。之前還見過有同學mapreduce job調用線上服務，分分鐘把服務搞死。
如何應對這種情況？生活給了我們答案：比如老式電閘都安裝了保險絲，一旦有人使用超大功率的裝置，保險絲就會燒斷以保護各個電器不被強電流給燒壞。同理我們的接口也需要安裝上“保險絲”，以防止非預期的請求對系統壓力過大而引起的系統癱瘓，當流量過大時，可以采取拒絕或者引流等機制。具體限流算法參見《接口限流實踐》一文。
3 做好自己
做好自己是個非常大的話題，從需求分析、架構設計 、代碼編寫、測試、code review、上線、線上服務運維等階段都可以重點展開介紹，這次簡單分享下架構設計、代碼編寫上的幾條經驗原則。
3.1 單一職責原則
對于工作了兩年以上的同學來說，設計模式應該好好看看，我覺得各種具體的設計模式其實并不重要，重要的是背後展現的原則。比如單一職責原則，在我們的需求分析、架構設計、編碼等各個階段都非常有指導意義。
在需求分析階段，單一職責原則可以界定我們服務的邊界，如果服務邊界如果沒界定清楚，各種合理的不合理的需求都接，最後導緻服務出現不可維護、不可擴充、故障不斷的悲哀結局。
對于架構來講，單一職責也非常重要。比如讀寫子產品放置在一起，導緻讀服務抖動非常厲害，如果讀寫分離那将大大提高讀服務的穩定性（讀寫分離）；比如一個服務上同時包含了訂單、搜尋、推薦的接口，那麼如果推薦出了問題可能影響訂單的功能，那這個時候就可以将不同接口拆分為獨立服務，并獨立部署，這樣一個出問題也不會影響其他服務（資源隔離）；又比如我們的圖檔服務使用獨立域名、并放置到cdn上，與其它服務獨立（動靜分離）。
從代碼角度上講，一個類隻幹一件事情，如果你的類幹了多個事情，就要考慮将他分開。這樣做的好處是非常清晰，以後修改起來非常友善，對其它代碼的影響就很小。再細粒度看類裡的方法，一個方法也隻幹一個事情，即隻有一個功能，如果幹兩件事情，那就把它分開，因為修改一個功能可能會影響到另一個功能。
3.2 控制資源的使用
寫代碼腦子一定要繃緊一根弦，認知到我們所在的機器資源是有限的。機器資源有哪些？cpu、記憶體、網絡、磁盤等，如果不做好保護控制工作，一旦某一資源滿負荷，很容易導緻出現線上問題。
3.2.1 CPU資源怎麼限制？
a）計算算法優化
如果服務需要進行大量的計算，比如推薦排序服務，那麼務必對你的計算算法進行優化，比如筆者曾經對地理空間距離計算這一重度使用的算法進行了優化，取得了較好的效果，詳見《地理空間距離計算優化》一文。
b）鎖
對于很多服務而言，沒有那麼多耗費計算資源的算法，但cpu使用率也很高，這個時候需要看看鎖的使用情況，我的建議是如無必要，盡量不用顯式使用鎖。
c） 習慣問題
比如寫循環的時候，千萬要檢檢視看是否能正确退出，有些時候一不小心，在某些條件下就成為死循環，很著名的案例就是《多線程下HashMap的死循環問題》。比如集合周遊時候使用性能較差的周遊方式、String +檢查，如果有超過多個String相加，是否使用StringBuffer.append？
d）盡量使用線程池
通過線程池來限制線程的數目，避免線程過多造成的線程上下文切換的開銷。
e）jvm參數調優
jvm參數也會影響cpu的使用，如《釋出或重新開機線上服務時抖動問題解決方案》。
3.2.2 記憶體資源怎麼限制？
a）Jvm參數設定
通過JVM參數的設定來限制記憶體使用，jvm參數調優比較靠經驗，有一篇朋友寫的好文可以參考《Linux與JVM的記憶體關系分析》。
b）初始化java集合類大小
使用java集合類的時候盡量初始化大小，在長連接配接服務等耗費記憶體資源的服務中這種優化非常重要；
c）使用記憶體池/對象池
d）使用線程池的時候一定要設定隊列的最大長度
之前看過好多起故障都是由于隊列最大長度沒有限制最後導緻記憶體溢出。
e）如果資料較大避免使用本地緩存
如果資料量較大，可以考慮放置到分布式緩存如redis、tair等，不然gc都可能把自己服務卡死；
f）對緩存資料進行壓縮
比如之前做推薦相關服務時，需要儲存使用者偏好資料，如果直接儲存可能有12G，後來采用短文本壓縮算法直接壓縮到6G，不過這時一定要考慮好壓縮解壓縮算法的cpu使用率、效率與壓縮率的平衡，一些壓縮率很高但是性能很差的算法，也不适合線上實時調用。
有些時候直接使用probuf來序列化之後儲存，這樣也能節省記憶體空間。
g）清楚第三方軟體實作細節，精确調優
在使用第三方軟體時，隻有清楚細節後才知道怎麼節約記憶體，這點我在實際工作中深有體會，比如之前在閱讀過lucene的源碼後發現我們的索引檔案原來是可以壓縮的，而這在說明文檔中都找不到，具體參考《lucene索引檔案大小優化小結》一文。
3.2.3 網絡資源怎麼限制？
a）減少調用的次數
減少調用的次數？經常看到有同學在循環裡用redis/tair的get，如果意識到這裡面的網絡開銷的話就應該使用批量處理；又如在推薦服務中經常遇到要去多個地方去取資料，一般采用多線程并行去取資料，這個時候不僅耗費cpu資源，也耗費網絡資源，一種在實際中常常采用的方法就是先将很多資料離線存儲到一塊 ，這時候線上服務隻要一個請求就能将所有資料擷取。
b）減少傳輸的資料量
一種方法是壓縮後傳輸，還有一種就是按需傳輸，比如經常遇到的getData(int id)，如果我們傳回該id對應的Data所有資訊，一來人家不需要，二來資料量傳輸太大，這個時候可以改為getData(int id, List<String> fields)，使用方傳輸相應的字段過來，服務端隻傳回使用方需要的字段即可。
3.2.4 磁盤資源怎麼限制？
打日志要控制量，并定期清理。1）隻列印關鍵的異常日志；2）對日志大小進行監控報警。我有一次就遇到了第三方服務挂了，然後我這邊就不斷列印調用該第三方服務異常的日志，本來我的服務有降級方案，如果第三方服務挂了會自動使用其它服務，但是突然收到報警說我服務挂了，登上機器一看才知道是磁盤不夠導緻的崩潰；3）定期對日志進行清理，比如用crontab，每隔幾天對日志進行清理；4）列印日志到遠端，對于一些比較重要的日志可以直接将日志列印到遠端HDFS檔案系統裡；
3.3 避免單點
不要把雞蛋放在一個籃子上！從大層次上講服務可以多機房部署、異地多活；從自己設計角度上講，服務應該能做到水準擴充。
對于很多無狀态的服務，通過nginx、zookeeper能輕松實作水準擴充；
對一些job類型的服務，怎麼避免單點呢，畢竟隻能在一個節點上運作，可以參考《Quartz應用與叢集原理分析》一文；
對資料服務來說，怎麼避免單點呢？簡而言之、可以通過分片、分層等方式來實作，後面會有個博文總結。
4 小結
如何避免故障？我的經驗濃縮為一句：“懷疑第三方，防備使用方，做好自己”，大家也可以思考、總結并分享下自己的經驗。
轉載請标明源位址：http://www.cnblogs.com/LBSer