本文為大家?guī)韼讉€非常實(shí)用的編程原則并附案例，讓你一次學(xué)會應(yīng)對編程中的問題，在你的晉升路上越走越順。

一、編程的世界里十面埋伏

編程，是一件容易的事，也是一件不容易的事。說它容易，是因?yàn)檎莆找恍┗镜臄?shù)據(jù)類型和條件語句，就可以實(shí)現(xiàn)復(fù)雜的邏輯；說它不容易，是因?yàn)楦咝阅芨呖捎玫拇a，需要了解的知識有很多很多；編程的世界，也跟掃雷游戲的世界一樣，充滿雷區(qū)，十面埋伏，一不小心，隨時都可能踩雷，隨時都可能Game Over。

而玩過掃雷的人都知道，避免踩雷的最好方法，就是提前識別雷區(qū)并做標(biāo)記(設(shè)防)避免踩踏。

鑒于此，編程的世界里，從輸入到輸出同樣需要處處設(shè)防，步步為營。

1、對輸入的不信任

（1）對空指針的檢查

不只是輸入，只有是使用到指針的地方，都應(yīng)該先判斷指針是否為NULL，而內(nèi)存釋放后，應(yīng)當(dāng)將指針設(shè)置為NULL。

【真實(shí)案例】：注冊系統(tǒng)某段邏輯，正常使用情況下，都有對指針做檢查，在某個錯誤分支，打印日志時，沒檢查就使用了該字符串；結(jié)果可正常運(yùn)行，但當(dāng)訪問某個依賴模塊超時走到改分支，觸發(fā)bug，導(dǎo)致coredump。

（2）對數(shù)據(jù)長度的檢查

使用字符串或某段buf，特別是memcpy/strcpy時，需要盡量對數(shù)據(jù)長度做下檢查和截斷。

【真實(shí)案例】：接手oauth系統(tǒng)后運(yùn)行數(shù)月表現(xiàn)良好，突然有一天，發(fā)生了coredump，經(jīng)查，是某個業(yè)務(wù)不按規(guī)定請求包中填寫了超長長度，導(dǎo)致memcpy時發(fā)生段錯誤，根本原因，還是沒有做好長度檢查。

（3）對數(shù)據(jù)內(nèi)容的檢查

某些場景下，沒有對數(shù)據(jù)內(nèi)容做檢查就直接使用，可能導(dǎo)致意想不到的結(jié)果。

【案例】：sql注入和xss攻擊都是利用了服務(wù)端沒有對數(shù)據(jù)內(nèi)容做檢查的漏洞。

2、對輸出（變更）的不信任

變更的影響一般體現(xiàn)在輸出，有時候輸出的結(jié)果并不能簡單的判斷是否正常，如輸出是加密信息，或者輸出的內(nèi)容過于復(fù)雜。

所以，對于每次變更

（1）修改代碼時，采用不信任編碼，正確的不一定是“對”的，再小的修改也應(yīng)確認(rèn)其對后續(xù)邏輯的影響，有些修正可能改變原來錯誤時的輸出，而輸出的改變，就會影響到依賴該改變字段的業(yè)務(wù)。

（2）發(fā)布前，應(yīng)該對涉及到的場景進(jìn)行測試和驗(yàn)證，測試可以有效的發(fā)現(xiàn)潛在的問題，這是眾所周知的。

（3）發(fā)布過程，應(yīng)該采用灰度發(fā)布策略，因?yàn)闇y試并非總是能發(fā)現(xiàn)問題，灰度發(fā)布，可以減少事故影響的范圍。常見灰度發(fā)布的策略有機(jī)器灰度、IP灰度、用戶灰度、按比例灰度等，各有優(yōu)缺點(diǎn)，需要根據(jù)具體場景選擇，甚至可以同時采用多種的組合。

（4）發(fā)布后，全面監(jiān)控是有效發(fā)現(xiàn)問題的一種方法。因?yàn)闇y試環(huán)境和正式環(huán)境可能存在不一致的地方，也可能測試不夠完整，導(dǎo)致上線后有問題，所以需采取措施補(bǔ)救。

A：如使用Monitor監(jiān)控請求量、成功量、失敗量、關(guān)鍵節(jié)點(diǎn)等

B：使用DLP告警監(jiān)控成功率

C：發(fā)布完，在正式環(huán)境測試一遍

【案例】oauth系統(tǒng)某次修改后編譯時，發(fā)現(xiàn)有個修改不相關(guān)的局部變量未初始化的告警，出于習(xí)慣對變量進(jìn)行了初始化（初始化值和編譯器默認(rèn)賦值不一樣），而包頭某個字段采用了該未初始化的變量，但在測試用例中未能體現(xiàn)，監(jiān)控也沒細(xì)化到每個字段的值，導(dǎo)致測試正常，監(jiān)控正常；但前端業(yè)務(wù)齊齊互動使用了該包頭字段，導(dǎo)致發(fā)布后影響該業(yè)務(wù)。

二、服務(wù)程序的世界里防不勝防

一般的系統(tǒng)，都會有上下游的存在，正如下圖所示

而上下游的整個鏈路中，每個點(diǎn)都是不能保證絕對可靠的，任何一個點(diǎn)都可能隨時發(fā)生故障，讓你措手不及。

因此，不能信任整個鏈路中的任何一個點(diǎn)，需進(jìn)行設(shè)防。

1、對服務(wù)本身的不信任

主要措施如下：

（1）服務(wù)監(jiān)控

前面所述的請求量、成功量、失敗量、關(guān)鍵節(jié)點(diǎn)、成功率的監(jiān)控，都是對服務(wù)環(huán)節(jié)的單點(diǎn)監(jiān)控。

在此基礎(chǔ)上，可以加上自動化測試，自動化測試可以模擬應(yīng)用場景，實(shí)現(xiàn)對于流程的監(jiān)控。

（2）進(jìn)程秒起

人可能在程序世界里是不可靠的因素（大牛除外），前面的措施，多是依賴人來保證的；所以，coredump還是有可能發(fā)生的，這時，進(jìn)程秒起的實(shí)現(xiàn)，就可以有效減少coredump的影響，繼續(xù)對外提供服務(wù)。

2、對依賴系統(tǒng)的不信任

可采用柔性可用策略，對于根據(jù)模塊的不可或缺性，區(qū)分關(guān)鍵路徑和非關(guān)鍵路徑，并采取不同的策略。

（1）對于非關(guān)鍵路徑，采用柔性放過策略

當(dāng)訪問非關(guān)鍵路徑超時時，簡單的可采取有限制（一定數(shù)量、一定比重）的重試，結(jié)果超時則跳過該邏輯，進(jìn)行下一步；復(fù)雜一點(diǎn)的統(tǒng)計一下超時的比例，當(dāng)比例過高時，則跳過該邏輯，進(jìn)行下一步。

（2）對于關(guān)鍵路徑，提供弱化服務(wù)的柔性策略

關(guān)鍵路徑是不可或缺的服務(wù)，不能跳過；某些場景，可以根據(jù)目的，在關(guān)鍵路徑嚴(yán)重不可用時，提供弱化版的服務(wù)。舉例如派票系統(tǒng)訪問票據(jù)存儲信息嚴(yán)重不可用時，可提供不依賴于存儲的純算法票據(jù)，為彌補(bǔ)安全性的確實(shí)，可采取縮短票據(jù)有效期等措施。

3、對請求的不信任

（1）對請求來源的不信任

有利可圖的地方，就會有黑產(chǎn)時刻盯著，偽造各種請求，對此，可采取如下措施：

A：權(quán)限控制

如ip鑒權(quán)、模塊鑒權(quán)、白名單、用戶登錄態(tài)校驗(yàn)等

B：安全審計

權(quán)限控制僅能打擊一下非正常流程的請求，但壞人經(jīng)常能夠成功模擬用戶正常使用的場景；所以，對于一些重要場景，需要加入安全策略，打擊如IP、號碼等信息聚集，頻率過快等機(jī)器行為，請求重放、劫持等請求）

（2）對請求量的不信任

前端的請求，不總是平穩(wěn)的；有活動時，會暴漲；前端業(yè)務(wù)故障恢復(fù)后，也可能暴漲；前端遭到惡意攻擊時，也可能暴漲；一旦請求量超過系統(tǒng)負(fù)載，將會發(fā)生雪崩，最終導(dǎo)致整個服務(wù)不可用，對此種種突發(fā)情況，后端服務(wù)需要有應(yīng)對措施。

A：頻率限制，控制各個業(yè)務(wù)的最大請求量（業(yè)務(wù)根據(jù)正常請求峰值的2-3倍申請，該值可修改），避免因一個業(yè)務(wù)暴漲影響所有業(yè)務(wù)的情況發(fā)生。

B：過載保護(hù)，雖然有頻率限制，但業(yè)務(wù)過多時，依然有可能某個時間點(diǎn)，所有的請求超過了系統(tǒng)負(fù)載，或者到某個IDC，某臺機(jī)器的請求超過負(fù)載，為避免這種情況下發(fā)生雪崩，將超過一定時間的請求丟棄，僅處理部分有效的請求，使得系統(tǒng)對外表現(xiàn)為部分可用，而非完全不可用。

三、運(yùn)營的世界里不可預(yù)測

1、對機(jī)器的不信任

機(jī)器故障時有發(fā)生，如果服務(wù)存在單點(diǎn)問題，故障時，則服務(wù)將完全不可用，而依賴人工的恢復(fù)是不可預(yù)期的，對此，可通過以下措施解決。

（1）容災(zāi)部署

即至少有兩臺以上的機(jī)器可以隨時對外提供服務(wù)。

（2）心跳探測

用于監(jiān)控機(jī)器是否可用，當(dāng)機(jī)器不可用時，若涉及到主備機(jī)器的，應(yīng)做好主備機(jī)器的自動切換；若不涉及到主備的，禁用故障機(jī)器對外提供服務(wù)即可。

2、對機(jī)房的不信任

現(xiàn)實(shí)生活中，整個機(jī)房不可用也是有發(fā)生過的，如2015年的天津?yàn)I海新區(qū)爆炸事故，導(dǎo)致騰訊在天津的多個機(jī)房不能對外提供正常服務(wù)，對此采取的措施有：

（1）異地部署

不同IDC、不同城市、不同國家等部署，可用避免整個機(jī)房不可用時，有其他機(jī)房的機(jī)器可以對外提供服務(wù)。

（2）容量冗余

對于類似QQ登陸這種入口型的系統(tǒng)，必須保持兩倍以上的冗余；如此，可以保證當(dāng)有一個機(jī)房故障時，所有請求遷移到其他機(jī)房不會引發(fā)系統(tǒng)過載。

3、對電力的不信任

雖然我們越來越離不開電力，但電力卻不能保證一直在為我們提供服務(wù)。斷電時，其影響和機(jī)器故障、機(jī)房故障類似，機(jī)器會關(guān)機(jī)，數(shù)據(jù)會丟失，所以，需要對數(shù)據(jù)進(jìn)行備份。

（1）磁盤備份

來電后，機(jī)器重啟，可以從磁盤中恢復(fù)數(shù)據(jù)，但可能會有部分?jǐn)?shù)據(jù)丟失。

（2）遠(yuǎn)程備份

機(jī)器磁盤壞了，磁盤的數(shù)據(jù)會丟失，使用對于重要系統(tǒng)，相關(guān)數(shù)據(jù)應(yīng)當(dāng)考慮采用遠(yuǎn)程備份。

4、對網(wǎng)絡(luò)的不信任

（1）不同地方，網(wǎng)絡(luò)時延不一樣

一般來說，本地就近的機(jī)器，時延要好于異地的機(jī)器, 所以，比較簡單的做法就是近尋址，如CMLB。

也有部分情況，是異地服務(wù)的時延要好于本地服務(wù)的時延，所以，如果要做到較好的最優(yōu)路徑尋址，就需要先做網(wǎng)絡(luò)探測，如Q調(diào)。

（2）常有網(wǎng)絡(luò)有波動或不可用情況

和機(jī)器故障一樣處理，應(yīng)當(dāng)做到自動禁用；但網(wǎng)絡(luò)故障和機(jī)器故障又不一樣，經(jīng)常存在某臺機(jī)器不可用，但別的機(jī)器可以訪問的情況，這時就不能在服務(wù)端禁用機(jī)器了，而應(yīng)當(dāng)采用本地回包統(tǒng)計策略，自動禁用服務(wù)差機(jī)器；同時需配合定時探測禁用機(jī)器策略，自動恢復(fù)可正常提供服務(wù)機(jī)器。

5、對人的不信任

人的因素在運(yùn)營的世界里其實(shí)是不穩(wěn)定的因素（大牛除外），所以，不能對人的操作有過多的信任。

（1）操作備份

每一步操作都有記錄，便于發(fā)生問題時的回溯,重要的操作需要review，避免個人考慮不周導(dǎo)致事故。

（2）效果確認(rèn)

實(shí)際環(huán)境往往和測試環(huán)境是存在一些差異，所有在正式環(huán)境做變更后，應(yīng)通過視圖review和驗(yàn)證來確認(rèn)是否符合預(yù)期。

（3）變更可回滾

操作前需對舊程序、舊配置等做好備份，以便發(fā)生故障時，及時恢復(fù)服務(wù)。

（4）自動化部署

機(jī)器的部署，可能有一堆復(fù)雜的流程，如各種權(quán)限申請，各種客戶端安裝等，僅靠文檔流程操作加上測試驗(yàn)證時不夠的，可能某次部署漏了某個步驟而測試又沒測到，上線后就可能發(fā)生事故若能所有流程實(shí)現(xiàn)自動化，則可有效避免這類問題。

（5）一致性檢查

現(xiàn)網(wǎng)的發(fā)布可能因某個節(jié)點(diǎn)沒同步導(dǎo)致漏發(fā)，也就是不同的機(jī)器服務(wù)不一樣；對此，有版本號的，可通過版本號監(jiān)控發(fā)現(xiàn)；沒版本號的，則需借助進(jìn)程、配置等的一致性檢查來發(fā)現(xiàn)問題。

備注：以上提到的不信任策略，有的不能簡單的單條使用，需要結(jié)合其他的措施一起使用的。

學(xué)習(xí)C/C++編程知識，提升自己的C/C++編程能力，歡迎關(guān)注博主的微信公眾號：C語言編程學(xué)習(xí)基地，一起來學(xué)習(xí)吧！

來自：java那些事

程序員大咖整理發(fā)布，版權(quán)歸原作者所有，轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)

總結(jié)

以上是生活随笔為你收集整理的程序员职场：3 大原则让你的编程之路越走越顺，新手来了解一下的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。