↑ ???? 萬字長文不想看，那就聽一聽叭 ↑

為什么你的程序總是出現(xiàn) bug？

憑什么讓改 bug 占據(jù)了你大部分的時(shí)間？

看完本文，保證你能設(shè)計(jì)出更穩(wěn)定的程序，擺脫 bug 的纏繞，做項(xiàng)目更安心！

---

記得我在學(xué)校的時(shí)候，做的那些項(xiàng)目，不是為了應(yīng)付課程作業(yè)，就是為了參加比賽時(shí)展示用，因此對(duì)項(xiàng)目的質(zhì)量要求非常低。

到底有多低呢？

大部分的項(xiàng)目，只要基本的功能可以使用，就算完成了，完全不考慮任何的異常情況。甚至只要能成功運(yùn)行一次，讓我截幾張圖放到 PPT 或者實(shí)驗(yàn)報(bào)告里，足夠向老師交差或者應(yīng)付比賽答辯就行。

那項(xiàng)目出現(xiàn) bug 怎么辦呢？

• 如果測試的時(shí)候發(fā)現(xiàn)有些功能不可用，那很簡單，不管他，直接 PS 一張正常運(yùn)行的圖就行。

• 如果比賽的時(shí)候發(fā)現(xiàn)有些功能不可用，那也很簡單，把鍋甩給 “現(xiàn)場網(wǎng)絡(luò)不好” 就行。

但是，這些 “小技巧” 在企業(yè)中是行不通的，企業(yè)級(jí)項(xiàng)目必須為企業(yè)帶來實(shí)際的價(jià)值，容不得半點(diǎn)馬虎和欺騙。

我第一次進(jìn)入企業(yè)實(shí)習(xí)時(shí)，還保留著自己在學(xué)校開發(fā)項(xiàng)目的狼性 ????，只要能夠完成基本功能就行，保證以最快的速度完成開發(fā)。

有一天，當(dāng)我洋洋得意準(zhǔn)備早點(diǎn)下班時(shí)，測試同學(xué)走過來跟我說。

“喂，你的程序有 bug，這里用戶下單怎么金額是負(fù)的？”

寫個(gè) bug

對(duì)于我一個(gè)初入職場的小白，這是人生中第一次有人說我的代碼有 bug，我有問題，我不對(duì)勁。

當(dāng)時(shí)，我腦海的第一個(gè)念頭竟然是怎么把這個(gè) bug 糊弄過去，而不是怎么去更正！看來我已經(jīng)養(yǎng)成了非常不好的習(xí)慣。

那之后幾天，我又連續(xù)收到了測試提出的多個(gè) bug，然后將他們一個(gè)個(gè)改正。如果將這樣一個(gè)漏洞百出的程序發(fā)布上線，帶來的損失是不可估量的，現(xiàn)在想想仍心有余悸。

二八原則 開發(fā) 1 天，改 bug 4 天

這件事之后，我意識(shí)到，在企業(yè)中開發(fā)項(xiàng)目，不能只追求開發(fā)時(shí)的效率，還要注重項(xiàng)目的穩(wěn)定性，否則帶來的額外返工時(shí)間遠(yuǎn)比開發(fā)時(shí)節(jié)省的時(shí)間要長，而且會(huì)影響同事對(duì)你的看法。如果將開發(fā)時(shí)產(chǎn)生的 bug 遺留到線上，后果更是不堪設(shè)想！

后來，在字節(jié)跳動(dòng)和騰訊這兩家大公司工作后，我進(jìn)一步認(rèn)識(shí)到了項(xiàng)目穩(wěn)定性有多重要，并且積累了更多只有在大公司才能學(xué)到的提升項(xiàng)目穩(wěn)定性的經(jīng)驗(yàn)。

我總結(jié)了 10 個(gè)開發(fā)中通常不會(huì)考慮到的風(fēng)險(xiǎn)點(diǎn)，以及 16 個(gè)減少風(fēng)險(xiǎn)、提升項(xiàng)目穩(wěn)定性的方法，分享給大家~

在分享這些之前，先講個(gè)故事。

達(dá)摩克利斯之劍

古希臘傳說中，達(dá)摩克利斯是公元前 4 世紀(jì)意大利敘拉古的僭主（古希臘統(tǒng)治者獨(dú)有的稱號(hào)）狄奧尼修斯二世的朝臣，他非常喜歡奉承狄奧尼修斯。

他奉承道：“作為一個(gè)擁有權(quán)力和威信的偉人，狄奧尼修斯實(shí)在很幸運(yùn)。”

于是狄奧尼修斯提議與他交換一天的身份，那他就可以嘗試到首領(lǐng)的命運(yùn)。

在晚上舉行的宴會(huì)里，達(dá)摩克利斯非常享受成為國王的感覺。當(dāng)晚餐快結(jié)束的時(shí)候，他抬頭才注意到王位上方僅用一根馬鬃懸掛著的利劍。他立即失去了對(duì)美食和美女的興趣，并請(qǐng)求僭主放過他，他再也不想得到這樣的幸運(yùn)。

達(dá)摩克利斯之劍

這個(gè)故事告訴我們什么呢？

在和平安寧之后，時(shí)刻存在著危險(xiǎn)與不安。

當(dāng)一個(gè)人獲取多少榮譽(yù)和地位，他都要付出同樣多的代價(jià)。

地位越高，看似越安全，實(shí)則越危險(xiǎn)。

居安思危，對(duì)隨時(shí)可能帶來的嚴(yán)重后果，要做到謹(jǐn)慎。

那么這和軟件開發(fā)又有什么關(guān)系呢？下面就讓我來揭秘軟件開發(fā)中的達(dá)摩克利斯之劍。

危機(jī)四伏

“在和平安寧之后，時(shí)刻存在著危險(xiǎn)與不安。”

軟件開發(fā)正是如此，表面上機(jī)器是 “死” 的，只會(huì)按照人輸入的指令或編好的程序來執(zhí)行，一成不變，聽話的很。好像我們寫好代碼扔到機(jī)器上后，就可以高枕無憂。

但真的是這樣么？我們真的可以信任機(jī)器和程序么？

其實(shí)，在程序世界中危機(jī)四伏，人為因素、環(huán)境因素等可能都會(huì)對(duì)我們的程序產(chǎn)生影響。因此，我們必須時(shí)刻堅(jiān)守軟件開發(fā)的不信任原則，保持 overly pessimistic（過于悲觀），把和程序有關(guān)的一切請(qǐng)求、服務(wù)、接口、返回值、機(jī)器、框架、中間件等等都當(dāng)做不可信的，步步為營、處處設(shè)防。

程序世界里的不信任原則

那為什么寫個(gè)代碼要這么小心翼翼，什么都不信任呢？

大項(xiàng)目的苦衷

“當(dāng)一個(gè)人獲取多少榮譽(yù)和地位，他都要付出同樣多的代價(jià)。”

軟件開發(fā)中，項(xiàng)目價(jià)值越大，需要承受的壓力也越大，來聽聽大項(xiàng)目的苦衷吧。

我是一個(gè)身價(jià)過億的大項(xiàng)目，每天服務(wù)著上千萬的用戶，幫助他們獲得知識(shí)與快樂。

我的小伙伴們只看到我身上的光環(huán)和榮耀，但是他們看不到我背負(fù)的壓力和風(fēng)險(xiǎn)，今天終于有機(jī)會(huì)和大家傾訴我的苦衷了。

記得很多年前，我還是個(gè)孩子，只有幾個(gè)小主人開發(fā)我，那段時(shí)間，我成長的很快。雖然只有幾十個(gè)人使用我，但我感到非常輕松和快樂，偶爾偷會(huì)兒懶，也不會(huì)被人發(fā)現(xiàn)。

后來，我的功能越來越多，越來越強(qiáng)大。每天有數(shù)之不盡的新面孔來和我打招呼，并享受我提供的服務(wù)。漸漸地，更多開發(fā)者在我身上留下了印記，我感覺自己正在變得復(fù)雜，也開始感受到了壓力。我再也找不到機(jī)會(huì)偷懶，因?yàn)槲乙坏┬菹?#xff0c;就會(huì)讓我的主人們損失一比不小的財(cái)富。

如今，我已經(jīng)是一個(gè)成熟的大項(xiàng)目了，每天有上千萬的用戶依賴我，我終于擁有了更大的價(jià)值，卻也增加了很多煩惱，感受到了更大的危險(xiǎn)。

首先，同時(shí)服務(wù)千萬用戶，每秒鐘都可能會(huì)有幾十萬、甚至幾百萬個(gè)請(qǐng)求需要我來處理，因此我必須每時(shí)每刻無休止地高負(fù)載工作，且不說休息，哪怕稍微慢了一點(diǎn)，就會(huì)遭到用戶的投訴，主人們也會(huì)因此受到批評(píng)。

我的運(yùn)行，必須依靠很多兄弟們的支撐，因此我必須和兄弟們好好相處，哪怕一個(gè)兄弟倒了，我都會(huì)受到影響。

在我強(qiáng)大的實(shí)力背后，有一顆非常脆弱的心。經(jīng)歷了那么多次的強(qiáng)化和改造，我的功能逐漸變多的同時(shí)，也因此被植入了各種框架和插件，體積像滾雪球一般越來越大，不知道什么時(shí)候就會(huì)爆炸。以至于主人們每次改動(dòng)我時(shí)都要萬分謹(jǐn)慎，我的成長也變得十分緩慢。

復(fù)雜

然而最讓我感到恐懼的，是那些壞家伙們！

他們和正常的用戶不同，有的不斷制造請(qǐng)求，試圖將我擊垮。有的繞到我的背后，試圖直接控制我。有的對(duì)我虎視眈眈，監(jiān)視并記錄我的一舉一動(dòng)。還有的嘗試各種非法操作，想從我身上牟取暴利。

作為一個(gè)大項(xiàng)目真是太累了，我不知道我還能堅(jiān)持多久。

真的可信么？

“地位越高，看似越安全，實(shí)則越危險(xiǎn)。”

如今是一個(gè)軟件開源和共享的時(shí)代，我們在開發(fā)項(xiàng)目時(shí)，或多或少會(huì)使用到網(wǎng)上現(xiàn)有的資源，比如依賴包、工具、組件、框架、接口、現(xiàn)成的云服務(wù)等等，這些資源能夠大大提升我們的開發(fā)效率。

就拿云服務(wù)來說，幾乎已經(jīng)成了我們開發(fā)必備的資源，以前我們想要做一個(gè)網(wǎng)站，可能需要自己買一臺(tái)物理服務(wù)器，然后連通網(wǎng)絡(luò)，再把項(xiàng)目部署上去。而如今，直接登錄大公司的云官網(wǎng)（像騰訊云、阿里云），然后租一臺(tái)云服務(wù)器就行了，非常省事。

云服務(wù)

再說說現(xiàn)在主流的開發(fā)框架，以前做一個(gè)簡單的網(wǎng)站界面可能只會(huì)使用 HTML、CSS、JavaScript 這三種最基礎(chǔ)的技術(shù)，而如今，網(wǎng)站的樣式和交互越來越復(fù)雜，我們不得不使用一些知名的框架來提升開發(fā)效率，比如 Vue 和 React。

聽起來好像沒有任何問題，你也根本不會(huì)去懷疑什么，因?yàn)?strong>我們天生帶著對(duì)大公司，或者說是對(duì)名氣的信任。

但是，你知道么，當(dāng)你決定使用其他人的資源時(shí)，你就已經(jīng)把項(xiàng)目系統(tǒng)的部分掌控權(quán)、甚至可能是半條命，都交出去了。

那么不妨思考一下，你使用的這些資源，真的可信么？

下面 10 個(gè)問題，可能改變你對(duì)開發(fā)的認(rèn)知。

1. 開發(fā)工具可信么？

我們通常是在大而全的開發(fā)工具中編寫代碼，比如 JetBrains IDEA 或者 Vscode。很多剛開始寫代碼的同學(xué)、甚至是一些經(jīng)驗(yàn)豐富的老手，都對(duì)開發(fā)工具保持絕對(duì)的信任。

比如你在鍵盤上敲擊 a，那編輯器界面上顯示的一定是 a。

但是，由于內(nèi)存不足等種種原因，開發(fā)工具其實(shí)也會(huì)抽風(fēng)。

比如你想要調(diào)用某個(gè)函數(shù)，通常敲擊函數(shù)名前幾個(gè)字母后，開發(fā)工具就會(huì)自動(dòng)給你提示完整的函數(shù)名，但如果開發(fā)工具沒有給你提示，你首先懷疑的是這個(gè)函數(shù)不存在，而不是編輯器沒有按預(yù)期給出提示。遇到這種情況，可以稍等編輯器一下，或者進(jìn)一步確認(rèn)函數(shù)是否真的不存在，而不是立刻創(chuàng)建一個(gè)新的函數(shù)。

又或是項(xiàng)目無法運(yùn)行，怎么排查都覺得沒問題，這時(shí)不妨重新啟動(dòng)下開發(fā)工具，或者清理一下緩存，說不定項(xiàng)目就能正常運(yùn)行了！

還有很多非常有意思的情況，比如編輯器一片大紅，各種提示錯(cuò)誤，但是項(xiàng)目依然能成功運(yùn)行。

為什么不能運(yùn)行？為什么能運(yùn)行？

因此，不要絕對(duì)相信開發(fā)工具。

2. 開源項(xiàng)目可信么？

現(xiàn)在是一個(gè)軟件開源的時(shí)代，在 GitHub 等開源項(xiàng)目平臺(tái)上能夠找到大量優(yōu)秀的開源項(xiàng)目，好的開源項(xiàng)目甚至可以得到 10 萬多個(gè)關(guān)注，那這些知名的開源項(xiàng)目可信么？

不完全可信！從每個(gè)開源項(xiàng)目的 Issues 就能看出這點(diǎn)，而且通常越大的項(xiàng)目，被發(fā)現(xiàn)的問題越多，比如 Vue 項(xiàng)目，累積提出并關(guān)閉了 8000 多個(gè)問題。

Vue 項(xiàng)目的問題

我記得自己有一次使用知名的開源服務(wù)器 Tomcat，就遇到了 bug，每次接受到特定的請(qǐng)求都會(huì)報(bào)錯(cuò)。剛開始我根本沒有懷疑是 Tomcat 的問題，而是絞盡腦汁地想自己的代碼哪里寫錯(cuò)了。后來經(jīng)過反復(fù)的排查和搜索，終于確認(rèn)了就是 Tomcat 本身的 bug！

雖然開源項(xiàng)目并不完全可信，但是相對(duì)于私有項(xiàng)目而言，所有對(duì)項(xiàng)目感興趣的同學(xué)可以共同發(fā)現(xiàn)項(xiàng)目中的問題，并加以解決，在一定程度上還是能夠提高項(xiàng)目的可靠性的。

3. 依賴庫可信么？

我們在開發(fā)項(xiàng)目時(shí)，通常會(huì)用到大量的依賴庫。直接在官方依賴源（比如 Maven 和 npm）搜索依賴庫，然后使用包管理器，用一行命令或者編寫配置文件就能夠讓其自動(dòng)安裝依賴，非常方便。

但是，這些發(fā)布到官方源的依賴庫，就可信么？

且不說基本每個(gè)開發(fā)者都有機(jī)會(huì)發(fā)布依賴庫到官方，就算是互聯(lián)網(wǎng)大公司的依賴庫，也未必可信。

給我印象最深刻的就是阿里巴巴的 JSON 序列化類庫 fastjson，幾乎無人不知、無人不曉，因?yàn)槠錁O快的解析速度廣受好評(píng)。但是，這個(gè)庫被多次曝光存在高危漏洞，可以讓攻擊者遠(yuǎn)程執(zhí)行命令！一般的開發(fā)者根本不會(huì)發(fā)現(xiàn)這點(diǎn)，從而給項(xiàng)目帶來了極大的危害。

因此，在選用依賴庫的時(shí)候，要做好充分的調(diào)研，盡量確認(rèn)依賴庫的安全，并且保證不要和已有的依賴沖突。

4. 編程語言可信么？

Java 是一種強(qiáng)類型語言，具有健壯性。這句話我相信所有學(xué)過 Java 的同學(xué)都再熟悉不過了。但是，強(qiáng)類型編程語言就一定可信么？

這里可能有同學(xué)就要表示懷疑了，如果我們一直使用的最基礎(chǔ)最底層的編程語言都存在 bug，那我們怎么去相信建立在這些編程語言上的框架呢？

然而真相是，所有的編程語言都有 bug！而且基本每次編程語言發(fā)布新版本時(shí)都會(huì)對(duì)一些歷史 bug 進(jìn)行修正。就 Java 而言，甚至還有一個(gè)專門記錄 bug 的數(shù)據(jù)庫！

Java Bug 數(shù)據(jù)庫

但是，對(duì)于大多數(shù)開發(fā)者來說，我相信即使在程序中偶然觸發(fā)了編程語言本身的 bug，也沒有足夠的自信去質(zhì)疑，而是直接修改代碼來繞過。

確實(shí)，質(zhì)疑編程語言需要一定的基礎(chǔ)和知識(shí)儲(chǔ)備，但是一旦發(fā)現(xiàn)了程序中莫名其妙的問題，建議大家不要直接忽略，可以花一些時(shí)間去探索研究，說不定你就成功地發(fā)現(xiàn)了一個(gè)重大的 bug，也能夠加深對(duì)這門編程語言的理解。

5. 服務(wù)器可信么？

服務(wù)器是項(xiàng)目賴以生存的宿主，服務(wù)器的性能和穩(wěn)定性將直接影響到項(xiàng)目進(jìn)程。

無論是個(gè)人開發(fā)者還是企業(yè)，通常都會(huì)直接租用大公司提供的云服務(wù)器來部署項(xiàng)目，省去了自己搭建和維護(hù)的麻煩。

但是大公司的云服務(wù)器就可信么？

不完全可信！即使現(xiàn)在的云服務(wù)器提供商都承諾自己的服務(wù) SLA（服務(wù)級(jí)別協(xié)議）可以達(dá)到 5 個(gè) 9（99.999% 一年約宕機(jī) 5 分鐘），甚至 6 個(gè) 9（99.9999% 一年約宕機(jī) 30 秒），但是仍然存在一定的風(fēng)險(xiǎn)。

有一個(gè)非常有名的案例，在 2013 年，中國最大的社交通訊軟件出現(xiàn)大規(guī)模的故障，多達(dá)幾億用戶受到影響。原因竟然是，市政道路建設(shè)的一個(gè)不注意，把網(wǎng)絡(luò)光纜挖斷了，就導(dǎo)致該軟件所在服務(wù)器的無法訪問。

除了可用性的不可信之外，可能還有一些安全隱私方面的問題。當(dāng)然云服務(wù)商通常是不會(huì)獲取用戶的數(shù)據(jù)的，但也沒有辦法絕對(duì)相信他們。畢竟數(shù)據(jù)的隱私對(duì)企業(yè)至關(guān)重要，這也是為什么大的公司都會(huì)搭建屬于自己的服務(wù)器機(jī)房和網(wǎng)絡(luò)。

機(jī)房

6. 數(shù)據(jù)庫可信么？

企業(yè)中的大多數(shù)業(yè)務(wù)數(shù)據(jù)都是存放在數(shù)據(jù)庫中的，通過項(xiàng)目后端程序來操作和查詢數(shù)據(jù)庫中的數(shù)據(jù)。

和服務(wù)器一樣，我們可以使用軟件自己搭建數(shù)據(jù)庫，比如 MySQL，也可以直接租用大公司的云數(shù)據(jù)庫，那么數(shù)據(jù)庫可信么？

其實(shí)在企業(yè)后端項(xiàng)目中，數(shù)據(jù)庫通常是性能瓶頸，相對(duì)比較脆弱，當(dāng)訪問并發(fā)量大一點(diǎn)時(shí)，數(shù)據(jù)庫的查詢性能就會(huì)下降，嚴(yán)重時(shí)可能整個(gè)宕機(jī)！即使是大公司提供的云數(shù)據(jù)庫服務(wù)，遇到慢查詢（需要較長時(shí)間的查詢）時(shí)，可能也無從應(yīng)對(duì)。

數(shù)據(jù)庫中的數(shù)據(jù)其實(shí)也未必可信，有時(shí)管理員的一個(gè)誤操作，不小心刪除數(shù)據(jù)或添加了一條錯(cuò)誤數(shù)據(jù)，可能就會(huì)影響用戶，造成損失。更有甚者，竟然刪庫跑路，不講碼德！

刪庫跑路

因此，不要過于信任數(shù)據(jù)庫，應(yīng)當(dāng)使用緩存之類的技術(shù)幫助數(shù)據(jù)庫分擔(dān)壓力，并定期備份。否則一旦數(shù)據(jù)庫宕機(jī)或數(shù)據(jù)丟失，帶來的損失是不可估量的！

7. 緩存服務(wù)可信么？

緩存是開發(fā)高性能程序必備的技術(shù)，通過將數(shù)據(jù)庫等查詢較慢的數(shù)據(jù)存放在內(nèi)存中，直接從內(nèi)存中讀取數(shù)據(jù)，以提升查詢性能。有了緩存之后，項(xiàng)目不僅能夠支持更多人同時(shí)查詢數(shù)據(jù)，還能夠保護(hù)數(shù)據(jù)庫。

目前比較主流的緩存技術(shù)有 Redis、Memcached 等，可以自己在服務(wù)器搭建，也可以直接租用大公司提供的云緩存服務(wù)。

存儲(chǔ)鍵值對(duì)的緩存

那么緩存服務(wù)是否可信呢？

項(xiàng)目的并發(fā)量不是特別大的話，一般的緩存技術(shù)就足以支持了，但是如果項(xiàng)目的量級(jí)很大，可能緩存也無法承受住壓力，嚴(yán)重時(shí)就會(huì)宕機(jī)。而一旦緩存掛掉，大量的查詢命令會(huì)直接請(qǐng)求數(shù)據(jù)庫，于是數(shù)據(jù)庫也會(huì)在瞬間掛掉，嚴(yán)重時(shí)還會(huì)導(dǎo)致整個(gè)項(xiàng)目癱瘓！

因此，在使用緩存時(shí)，需要對(duì)并發(fā)量進(jìn)行評(píng)估，通過搭建集群和數(shù)據(jù)同步保證高可用性。此外，還要預(yù)防緩存雪崩、緩存穿透、緩存擊穿等問題，簡單解釋一下。

緩存雪崩：指大量緩存在同一時(shí)間過期，請(qǐng)求都訪問不到緩存，全部打到數(shù)據(jù)庫上，導(dǎo)致數(shù)據(jù)庫掛掉。

緩存穿透：持續(xù)訪問緩存中不存在的 key 導(dǎo)致請(qǐng)求直接打到數(shù)據(jù)庫上，導(dǎo)致數(shù)據(jù)庫掛掉。

緩存擊穿：一個(gè)被大量請(qǐng)求高頻訪問的熱點(diǎn) key 突然過期，導(dǎo)致請(qǐng)求瞬間全部打到數(shù)據(jù)庫上，導(dǎo)致數(shù)據(jù)庫掛掉。

如果不預(yù)防這三個(gè)問題，即使是租用大公司的緩存服務(wù)，也一樣吹彈可破。

雪崩

8. 對(duì)象存儲(chǔ)可信么？

項(xiàng)目中，經(jīng)常會(huì)有用戶上傳圖片或文件的功能，這類數(shù)據(jù)通常較大，用數(shù)據(jù)庫存儲(chǔ)不太方便。雖然我們可以將文件直接存到服務(wù)器上，但更好的做法是使用專門的對(duì)象存儲(chǔ)服務(wù)。

可以簡單地把對(duì)象存儲(chǔ)當(dāng)做一個(gè)大的文件夾，我們可以通過它直接上傳和下載文件。大的云服務(wù)商也都提供了專業(yè)的對(duì)象存儲(chǔ)服務(wù)，而無需自己搭建，那么對(duì)象存儲(chǔ)可信么？

一般情況下，上傳到對(duì)象存儲(chǔ)的文件是不會(huì)缺失或丟失的，而且還可以將已上傳的數(shù)據(jù)進(jìn)行跨園區(qū)同步，起到備份的作用。

跨園區(qū)同步

但是，記得有一次，上傳到對(duì)象存儲(chǔ)上的文件和源文件竟然不一致，大小足足少了 1M。起初我以為是文件上傳到對(duì)象存儲(chǔ)時(shí)，會(huì)自動(dòng)被壓縮，但是將對(duì)象存儲(chǔ)中的文件下載到本地后，發(fā)現(xiàn)的確和源文件不一致！雖然出現(xiàn)這種情況的概率極其小，但從那一刻起，我再也不相信對(duì)象存儲(chǔ)了。

再用自己的真實(shí)經(jīng)歷來聊聊對(duì)象存儲(chǔ)的跨園區(qū)同步。因?yàn)閭€(gè)人負(fù)責(zé)的業(yè)務(wù)比較重要，萬一單個(gè)機(jī)房整體掛掉，可能分分鐘是幾十萬元的損失！因此我為對(duì)象存儲(chǔ)配置了自動(dòng)跨園區(qū)同步，將文件先上傳至廣州機(jī)房，然后數(shù)據(jù)會(huì)自動(dòng)同步到上海機(jī)房，且運(yùn)維同學(xué)承諾自動(dòng)同步的延遲不超過 15 分鐘。

我相信大部分開發(fā)者配置數(shù)據(jù)同步后也就不管了，相信它一定會(huì)自動(dòng)同步的。結(jié)果后面我編寫程序去做同步監(jiān)控、對(duì)比數(shù)據(jù)時(shí)，發(fā)現(xiàn)經(jīng)常出現(xiàn)數(shù)據(jù)未同步的情況，比例高達(dá) 10%！

因此，不能完全相信對(duì)象存儲(chǔ)，雖然大部分情況下大公司的對(duì)象存儲(chǔ)服務(wù)很可靠，但不能確保萬無一失。尤其是同步備份的場景下，是否真的同步成功了，又有多少同學(xué)關(guān)心過呢？不妨寫個(gè)程序去驗(yàn)證和保障。

9. API 接口可信么？

在開發(fā)中，我們經(jīng)常會(huì)調(diào)用其他系統(tǒng)提供的 API 接口來輕松實(shí)現(xiàn)某種功能。比如查詢某地的天氣，可以直接調(diào)用其他人提供的天氣查詢接口，而無需自己編寫。我們也可以提供 API 接口給其他人使用，尤其是在微服務(wù)架構(gòu)中，各服務(wù)之間都是以接口調(diào)用的形式實(shí)現(xiàn)交互協(xié)作的。

幾乎所有的 API 接口提供者都會(huì)說自己的接口有多安全、請(qǐng)放心使用，那么 API 接口真的可信么？

其實(shí)，API 接口是最不可信的資源！

首先，API 接口的提供方可以是任何開發(fā)者，很難通過他們的一面之詞來確定接口的穩(wěn)定性和安全性。

即使這個(gè)接口性能很高、也很安全，但是你并不了解有多少人和你在同時(shí)使用這個(gè)接口，也許只有你，又也許是 100 萬個(gè)其他的開發(fā)者呢？在這個(gè)競爭條件下，接口的 qps（query per second 每秒查詢數(shù)）還能達(dá)到預(yù)期么？接口返回時(shí)長真的不會(huì)超時(shí)么？

更有甚者，偷偷地把 API 接口改動(dòng)了，卻沒有給調(diào)用者發(fā)送通知，這樣接口的調(diào)用方全部都會(huì)調(diào)用失敗，嚴(yán)重影響項(xiàng)目的運(yùn)行！

因此，我們在調(diào)用第三方 API 接口時(shí)，一定要慎重、慎重、再慎重！

此外，如果我們是 API 接口的提供者，也要注意保護(hù)好自己的 API 接口，避免同時(shí)被太多的開發(fā)者調(diào)用，導(dǎo)致接口掛掉。

API 存在復(fù)雜的調(diào)用關(guān)系

10. Serverless 可信么？

如果說服務(wù)器不可信，那我們干脆就不租服務(wù)器了，直接租用大公司提供的 Serverless 服務(wù)來作為項(xiàng)目的后臺(tái)不就行了？

Serverless 指無服務(wù)器架構(gòu)，并不是真的不需要服務(wù)器，而是將項(xiàng)目接口的部署、運(yùn)維等需要對(duì)服務(wù)器的操作交給服務(wù)商去做，讓開發(fā)者無需關(guān)心服務(wù)器，專心寫代碼就好。

docker 容器

聽起來非常爽，那 Serverless可信么？

使用 Serverless，雖然能夠大大提升開發(fā)和運(yùn)維效率，但是其相對(duì)服務(wù)器等資源而言，更不可信！

首先，Serverless 本身就是部署在服務(wù)器上的，難免會(huì)受到服務(wù)器的影響。

其次，Serverless 服務(wù)不會(huì)長期保持應(yīng)用的狀態(tài)，而是隨著請(qǐng)求的到來而啟動(dòng)，存在冷啟動(dòng)時(shí)期，雖然也有很多相關(guān)的優(yōu)化和解決方案，但仍無法精確地保證接口的性能，尤其是在高并發(fā)場景下，性能往往達(dá)不到預(yù)期。

最重要的是，當(dāng)你選擇使用 Serverless 服務(wù)時(shí)，你就和某云服務(wù)提供商綁定了，后續(xù)想要遷移是非常困難的！試想一下，你項(xiàng)目的所有功能都交給別人來維護(hù)，真的是好事么？一旦云服務(wù)提供商改造了架構(gòu)或接口，你的代碼也要隨之改動(dòng)，而這種改動(dòng)卻不是由自己控制的！

當(dāng)然，Serverless 具有非常多的優(yōu)點(diǎn)，也是云計(jì)算技術(shù)發(fā)展的必然趨勢，只是希望大家在使用前，考慮到那些可能的風(fēng)險(xiǎn)，并做好應(yīng)對(duì)措施。

云計(jì)算時(shí)代

總結(jié)：正是因?yàn)槲覀兲^信任那些名氣大、看似安全的資源，所以其背后的危險(xiǎn)才更難以被察覺，帶來的后果往往也更致命！

防御性編程

“居安思危，對(duì)隨時(shí)可能帶來的嚴(yán)重后果，要做到謹(jǐn)慎。”

在軟件開發(fā)中，雖然項(xiàng)目表面上能夠正常運(yùn)行，但風(fēng)險(xiǎn)無處不在，因此我們要學(xué)習(xí)防御性編程思想。把自己當(dāng)成一個(gè)杠精，不要相信任何人，盡力去發(fā)現(xiàn)程序中的風(fēng)險(xiǎn)，積極防御。

下面給大家分享 16 個(gè)防御性編程的方法，學(xué)習(xí)之后，能夠大大減少程序中的風(fēng)險(xiǎn)。

祈禱性編程

1. 編程習(xí)慣

要減少程序中的風(fēng)險(xiǎn)，首先要養(yǎng)成良好的編程習(xí)慣。

首先，在寫代碼時(shí)，一定要保持良好的心態(tài)，不要倉促或者以完成任務(wù)的心態(tài)去寫代碼。如果僅僅是為了完成需求，那么很有可能不會(huì)注意到代碼中的風(fēng)險(xiǎn)，甚至是發(fā)現(xiàn)了風(fēng)險(xiǎn)也懶得去修補(bǔ)，這樣確實(shí)能夠節(jié)約開發(fā)的時(shí)間，但是后面出現(xiàn)問題后，你還是要花費(fèi)更多的時(shí)間去排查、溝通和修復(fù) bug。拔苗助長，適得其反。

在寫代碼時(shí)，如果在一個(gè)地方多次使用相同且復(fù)雜的變量名或字符串，建議不要手動(dòng)去敲，而是用大家最喜歡的 “復(fù)制粘貼”，防止因?yàn)槭终`而導(dǎo)致的 bug。

復(fù)制粘貼一把梭

此外，我們在代碼中應(yīng)該加強(qiáng)對(duì)返回值的檢查，并且選擇安全的語法和數(shù)據(jù)結(jié)構(gòu)，避免使用被廢棄的語法。不同的編程語言也有不同的最佳編程習(xí)慣，比如在 Java 語言中，應(yīng)該對(duì)所有可能為 NULL 的變量進(jìn)行檢查，防止 NPE（NULL Pointer Error 空指針異常），在開發(fā)多線程程序時(shí)，選用線程安全的 ConcurrentHashMap 而不是 HashMap 等等。還可以利用 Assert（斷言）來保證程序運(yùn)行中的變量值符合預(yù)期。

推薦使用一個(gè)自帶檢查功能的編輯器來書寫代碼，在我們編寫代碼時(shí)會(huì)自動(dòng)檢查出錯(cuò)誤，還能給出好的編碼風(fēng)格的建議，能夠大大減少開發(fā)時(shí)的風(fēng)險(xiǎn)。此外，在代碼提交前，一定要多次檢查代碼，尤其是那些復(fù)制粘貼過來的文件，經(jīng)常會(huì)出現(xiàn)遺漏的修改。提交代碼后，也可以找有經(jīng)驗(yàn)的同事幫忙閱讀和檢查下代碼（代碼審查），進(jìn)一步保證沒有語法和邏輯錯(cuò)誤。

編輯器語法檢查和提示

2. 異常處理

程序的運(yùn)行風(fēng)云變幻，同一段代碼在不同情況下也可能會(huì)產(chǎn)生不同的結(jié)果，甚至是異常。因此很多主流的編程語言中都有異常處理機(jī)制，比如在 Java 中，先用 try 捕獲異常、再用 catch 處理異常、最后用 finally 釋放資源和善后。

在編程時(shí)，要合理利用異常處理機(jī)制，來防御代碼中可能出現(xiàn)的種種問題。通常在異常處理中，我們會(huì)記錄錯(cuò)誤日志、執(zhí)行錯(cuò)誤上報(bào)和告警、重試等。

比如不信任數(shù)據(jù)庫，那就在查詢和操作數(shù)據(jù)時(shí)添加異常處理，一旦數(shù)據(jù)庫抽風(fēng)導(dǎo)致操作失敗，就在日志中記錄失敗信息，并通過郵件、短信等告警方式通知到開發(fā)者，就能第一時(shí)間發(fā)現(xiàn)問題并排查。必要時(shí)還可以實(shí)現(xiàn)自動(dòng)重試，省去一部分人工操作。

異常啦

3. 請(qǐng)求校驗(yàn)

所有的請(qǐng)求都是不可信的，哪怕是在公司內(nèi)網(wǎng)，也有可能因?yàn)橐恍┦д`，導(dǎo)致發(fā)出了錯(cuò)誤的請(qǐng)求。

因此我們編寫的每個(gè)接口，在實(shí)現(xiàn)具體的業(yè)務(wù)邏輯前，一定要先對(duì)請(qǐng)求參數(shù)加上校驗(yàn)，下面列舉幾種常見的校驗(yàn)方式：

參數(shù)類型校驗(yàn)：比如請(qǐng)求參數(shù)應(yīng)該是 Integer 整型而不是 Long 長整數(shù)類型。

值合法性校驗(yàn)：比如整數(shù)的范圍大于等于 0、字符串長度大于 5，或者滿足某種特定格式，比如手機(jī)號(hào)、身份證等。

用戶權(quán)限校驗(yàn)：很多接口需要登錄用戶或者管理員才能調(diào)用，因此必須通過請(qǐng)求參數(shù)（請(qǐng)求頭）來判斷當(dāng)前用戶的身份，被一個(gè)普通用戶下載了 VIP 付費(fèi)電影肯定是不合理的！

4. 流量控制

上面提到，所有的請(qǐng)求都是不可信的，不僅僅是請(qǐng)求的值，還有請(qǐng)求的量和頻率。對(duì)于所有接口，都要限制它的調(diào)用頻率，防止接口被大量瞬時(shí)的請(qǐng)求刷爆。對(duì)于付費(fèi)接口，還要防止用戶對(duì)接口的請(qǐng)求數(shù)超過原購買數(shù)。

此外，還有一種容易被忽視的情況，假如你的接口 A 中又調(diào)用了其他人的接口 B，也許你的接口 A 自身的邏輯能夠承受每秒 1000 個(gè)請(qǐng)求，但是你確定接口 B 可以承受么？

因此，需要進(jìn)行流量控制，不僅僅是預(yù)防接口被刷爆，還可以保護(hù)內(nèi)部的服務(wù)和調(diào)用。

什么，你說你的接口很牛逼，每秒能抗 100 萬個(gè)請(qǐng)求，也沒有調(diào)用其他的服務(wù)，那我就找 100 萬 + 1 個(gè)人同時(shí)請(qǐng)求你的接口，看你怕不怕！

DDOS 分布式拒絕服務(wù)攻擊

常用的流量控制按照不同的粒度可分為：

用戶流控：限制每個(gè)用戶在一定時(shí)間內(nèi)對(duì)某個(gè)接口的調(diào)用數(shù)。

接口流控：限制一定時(shí)間內(nèi)某個(gè)接口的總調(diào)用數(shù)。

單機(jī)流控：限制一定時(shí)間內(nèi)單臺(tái)服務(wù)器上的項(xiàng)目所有接口的總調(diào)用數(shù)。

分布式流控：限制一定時(shí)間內(nèi)項(xiàng)目所有服務(wù)器的總請(qǐng)求數(shù)。

當(dāng)然，除了上面提到的幾種方式外，流控可以非常靈活，也有很多優(yōu)秀的限流工具。比如 Java 語言 Guava 庫的 RateLimiter 令牌桶單機(jī)限流、阿里的 Sentinel 分布式限流框架等。

Sentinel 流控面板

5. 回滾

有時(shí)，我們對(duì)項(xiàng)目的操作可能是錯(cuò)誤的，可能是人工操作，也可能是機(jī)器操作，從而導(dǎo)致了一些線上故障。這時(shí)，可以選擇回滾。

回滾是指撤銷某個(gè)操作，將項(xiàng)目還原到之前的狀態(tài)，這里介紹幾種常見的回滾操作。

數(shù)據(jù)回滾

有時(shí)，我們想要批量插入數(shù)據(jù)，但是數(shù)據(jù)插入到一半時(shí)，程序突然出現(xiàn)異常，這個(gè)時(shí)候我們就需要把之前插入成功的數(shù)據(jù)進(jìn)行回滾，就好像什么都沒發(fā)生過一樣。否則可能存在數(shù)據(jù)不一致的風(fēng)險(xiǎn)。

最常見的方式就是使用事務(wù)來處理數(shù)據(jù)庫的批量操作，當(dāng)出現(xiàn)異常時(shí)，執(zhí)行數(shù)據(jù)庫客戶端的回滾方法即可。

配置回滾

如果將項(xiàng)目的配置信息，比如數(shù)據(jù)庫鏈接地址，寫死到代碼中，一旦配置錯(cuò)了或者地址發(fā)生變更，就要重新修改代碼，非常麻煩。

比較好的方式是將配置發(fā)布到配置中心進(jìn)行管理，讓項(xiàng)目去動(dòng)態(tài)讀取配置中心的配置。如果不小心發(fā)布了錯(cuò)誤的配置，可以直接在配置中心進(jìn)行回滾，將配置還原。

發(fā)布回滾

沒有人能保證自己的代碼正確無誤，很多時(shí)候，項(xiàng)目在測試環(huán)境驗(yàn)證時(shí)沒有發(fā)現(xiàn)任何問題，但是一上線，就漏洞百出。這就說明我們最新發(fā)布的代碼是存在問題的。

這時(shí)，最簡單的做法就是進(jìn)行版本回滾，將之前能夠正常運(yùn)行的代碼重新打包發(fā)布。大公司一般都有自己的項(xiàng)目發(fā)布平臺(tái)，能夠使用界面一鍵回滾，自動(dòng)發(fā)布以前版本的項(xiàng)目包。

6. 多級(jí)緩存

上面提到，緩存對(duì)項(xiàng)目是非常重要的，不僅是提升性能的利器，也是數(shù)據(jù)庫的保護(hù)傘。

但如果緩存掛掉怎么辦呢？

有兩種方案，第一種是為緩存搭建集群，從而保證緩存的高可用。

Redis 集群

但是一切都不可信，集群也有可能掛掉！

那么可以用第二種方案，一級(jí)緩存掛掉，我們就再搞一個(gè)二級(jí)緩存頂上！

通常，在高并發(fā)項(xiàng)目中，我們會(huì)設(shè)計(jì)多級(jí)緩存，即分布式緩存 + 本地緩存。當(dāng)請(qǐng)求需要獲取數(shù)據(jù)時(shí)，先從分布式緩存（比如 Redis） 中查詢，如果分布式緩存集體宕機(jī)，那就從本地緩存中獲取數(shù)據(jù)。這樣，即使緩存掛掉，也能夠幫助系統(tǒng)支撐一段時(shí)間。

這里可能和一些多級(jí)緩存的設(shè)計(jì)不同，有時(shí)，我們會(huì)把本地緩存作為一級(jí)緩存，緩存一些熱點(diǎn)數(shù)據(jù)，本地緩存找不到值時(shí)，才去訪問分布式緩存。這種設(shè)計(jì)主要解決的問題是，減少對(duì)分布式緩存的請(qǐng)求量，并進(jìn)一步提升性能，和上面的設(shè)計(jì)目的不同。

多級(jí)緩存設(shè)計(jì)

7. 服務(wù)熔斷和降級(jí)

每年的雙十一，我們會(huì)準(zhǔn)時(shí)守著屏幕上的搶購頁面，只為等待那一個(gè) “請(qǐng)稍后再試！”

我們的項(xiàng)目其實(shí)遠(yuǎn)比想象的要脆弱，很多服務(wù)經(jīng)常因?yàn)楦鞣N原因出現(xiàn)問題。比如搞活動(dòng)時(shí)，大量用戶同時(shí)訪問會(huì)導(dǎo)致對(duì)項(xiàng)目服務(wù)的請(qǐng)求增多，如果項(xiàng)目頂不住壓力，就會(huì)掛掉。

為了防止這種風(fēng)險(xiǎn)，我們可以采用服務(wù)降級(jí)策略，如果系統(tǒng)實(shí)在無法為所有用戶提供服務(wù)，那就退而求其次，給用戶直接返回一個(gè) “友好的” 提示或界面，而不是強(qiáng)行讓項(xiàng)目頂著壓力過勞死。

配合服務(wù)熔斷技術(shù)，可以根據(jù)系統(tǒng)的負(fù)載等指標(biāo)來動(dòng)態(tài)開啟或關(guān)閉降級(jí)。比如機(jī)器的 CPU 被占用爆滿時(shí)，就開啟降級(jí)，直接返回錯(cuò)誤；當(dāng)機(jī)器 CPU 恢復(fù)正常時(shí)，再正常返回?cái)?shù)據(jù)、執(zhí)行操作。

Hystrix 就是比較有名的微服務(wù)熔斷降級(jí)框架。

Hystrix

8. 主動(dòng)檢測

上面提到，即使是大公司的同步服務(wù)，也可能會(huì)出現(xiàn)同步不及時(shí)甚至是數(shù)據(jù)丟失的情況。因此，為了進(jìn)一步保證同步成功、數(shù)據(jù)的準(zhǔn)確，我們可以主動(dòng)檢測。

比如編寫一個(gè)定時(shí)腳本或者任務(wù)，每隔一段時(shí)間去檢查原地址和目標(biāo)地址的數(shù)據(jù)是否一致，或者通過一些邏輯來檢查數(shù)據(jù)是否正確。當(dāng)然也可以在每次數(shù)據(jù)同步結(jié)束后都立即去檢測，更加保險(xiǎn)。

主動(dòng)檢測

9. 數(shù)據(jù)補(bǔ)償

當(dāng)檢測出數(shù)據(jù)不一致后，我們就要進(jìn)行數(shù)據(jù)補(bǔ)償，比如將沒有同步的數(shù)據(jù)再次進(jìn)行同步、將不一致的數(shù)據(jù)進(jìn)行更新等。

除了用來解決主動(dòng)檢測出的數(shù)據(jù)不一致，數(shù)據(jù)補(bǔ)償也被廣泛用于業(yè)務(wù)設(shè)計(jì)和架構(gòu)設(shè)計(jì)中。

比如調(diào)用某個(gè)接口查詢數(shù)據(jù)失敗后，停頓一段時(shí)間，然后自動(dòng)重試，或者從其他地方獲取數(shù)據(jù)。又如消息隊(duì)列的生產(chǎn)者發(fā)送消息失敗時(shí)，應(yīng)該自動(dòng)進(jìn)行補(bǔ)發(fā)和記錄，而不是直接把這條消息作廢。

數(shù)據(jù)補(bǔ)償?shù)乃枷氡举|(zhì)上是保證數(shù)據(jù)的最終一致性，數(shù)據(jù)出錯(cuò)不可怕，知錯(cuò)能改就是好孩子。這種思想也被廣泛應(yīng)用于分布式事務(wù)等場景中。

10. 數(shù)據(jù)備份

數(shù)據(jù)是企業(yè)的生命，因此我們必須盡可能地保證數(shù)據(jù)的安全和完整。

很多同學(xué)會(huì)把自己重要的文件存放在多個(gè)地方，比如自己的電腦、網(wǎng)盤上等等。同樣，在軟件開發(fā)中，我們也應(yīng)該把重要的數(shù)據(jù)復(fù)制多份，作為副本存放在不同的地方。這樣，即使一臺(tái)服務(wù)器掛了，也可以從其他的服務(wù)器上獲取到數(shù)據(jù)，減少了風(fēng)險(xiǎn)。

數(shù)據(jù)備份

11. 心跳機(jī)制

接口可是個(gè)復(fù)雜多變的家伙，如果我們的項(xiàng)目依賴其他的接口來完成功能，那么最好保證該接口一直活著，否則可能會(huì)影響項(xiàng)目的運(yùn)行。

舉個(gè)例子，我們在使用銀行卡支付時(shí)，肯定需要調(diào)用銀行提供的接口來獲取銀行卡的余額信息，如果這個(gè)接口掛了，獲取不到余額，用戶也就無法支付，也就損失了一筆收入！

因此，我們需要時(shí)刻和重要的接口保持聯(lián)系，防止他們不小心死了。可以采用心跳機(jī)制，定時(shí)調(diào)用該接口或者發(fā)送一個(gè)心跳包，來判斷該接口是否仍然存活。一旦調(diào)用超時(shí)或者失敗，可以立刻進(jìn)行排查和處理，從而大大減少了事故的影響時(shí)長。

心跳檢測

12. 冗余設(shè)計(jì)

在系統(tǒng)資源和容量評(píng)估時(shí)，我們要做一些冗余設(shè)計(jì)，比如數(shù)據(jù)庫目前的總數(shù)據(jù)量有 1G，那么如果要將數(shù)據(jù)庫的數(shù)據(jù)同步到其他存儲(chǔ)（比如 Elasticsearch）時(shí)，至少要多預(yù)留一倍的存儲(chǔ)空間，即 2G，來應(yīng)對(duì)后面可能的數(shù)據(jù)增長。業(yè)務(wù)的發(fā)展?jié)摿υ酱?#xff0c;冗余的倍數(shù)也可以越多，但也要注意不要過分冗余，畢竟資源也是很貴的啊！

其實(shí)，冗余設(shè)計(jì)是一種重要的設(shè)計(jì)思想。當(dāng)我們設(shè)計(jì)業(yè)務(wù)或者系統(tǒng)架構(gòu)時(shí)，不能只局限于當(dāng)前的條件，而是要考慮到以后的發(fā)展，選擇一種相對(duì)便于擴(kuò)展的模式。否則之后項(xiàng)目越做越大，每一次對(duì)項(xiàng)目的改動(dòng)都步履維艱。

13. 彈性擴(kuò)縮容

夢想還是要有的，說不定突然，我們原先只有 100 人使用的小項(xiàng)目突然就火了，有幾十萬新用戶要來使用。

但是，由于我們的項(xiàng)目只部署在一臺(tái)服務(wù)器上，根本無法支撐那么多人，直接掛掉，導(dǎo)致這些用戶非常掃興，再也不想用我們的項(xiàng)目了。

夢想破碎了

這也是常見的風(fēng)險(xiǎn)，我們可以使用彈性擴(kuò)縮容技術(shù)，系統(tǒng)會(huì)根據(jù)當(dāng)前項(xiàng)目的使用和資源占用情況自動(dòng)擴(kuò)充或縮減資源。

比如當(dāng)系統(tǒng)壓力較大時(shí)，多分配幾臺(tái)機(jī)器（容器），當(dāng)系統(tǒng)壓力較小時(shí)，減少幾臺(tái)機(jī)器。這樣不僅能夠有效應(yīng)對(duì)突發(fā)的流量增長，還能夠在平時(shí)節(jié)約成本，并省去了人工分配調(diào)整機(jī)器的麻煩。

14. 異地多活

前面提到，服務(wù)器是不可信的，別說一個(gè)服務(wù)器掛掉，由于一些天災(zāi)人禍，整個(gè)機(jī)房都有可能集體掛掉！

和備份不同，異地多活是指在不同城市建立獨(dú)立的數(shù)據(jù)中心，正常情況下，用戶無論訪問哪一個(gè)地點(diǎn)的業(yè)務(wù)系統(tǒng)，都能夠得到正確的服務(wù)，即同時(shí)有多個(gè) “活” 的服務(wù)。

而某個(gè)地方業(yè)務(wù)異常的時(shí)候，用戶能夠訪問其他地方正常的業(yè)務(wù)系統(tǒng)，從而獲得正確的服務(wù)。

如此一來，即使廣州的機(jī)房跨了，咱還有上海的，上海的跨了，咱還有北京的。

同時(shí)活著的服務(wù)越多，系統(tǒng)就越可靠，但同時(shí)成本也越高、越復(fù)雜，因此幾乎都是大公司才做異地多活。千萬不要讓正常情況下的投入大于故障發(fā)生的損失！

餓了么異地多活技術(shù)實(shí)現(xiàn)（一）總體介紹

15. 監(jiān)控告警

項(xiàng)目的運(yùn)行不可能一直正常，但是我們不可能 24 小時(shí)盯著電腦屏幕來監(jiān)視項(xiàng)目的運(yùn)行情況吧？又不能完全不管項(xiàng)目，出了 bug 等著用戶來投訴。

因此，最好的方式是給業(yè)務(wù)添加監(jiān)控告警，當(dāng)程序出現(xiàn)異常時(shí)，信息會(huì)上報(bào)到監(jiān)控平臺(tái)，并第一時(shí)間給開發(fā)者發(fā)送通知。還可以通過監(jiān)控平臺(tái)實(shí)時(shí)查看項(xiàng)目的運(yùn)行情況，出了問題也能更快地定位。

Grafana 監(jiān)控平臺(tái)

16. 線上診斷和熱修復(fù)

既然程序世界一切都不可信，危險(xiǎn)無處不在，那么干脆就做最壞的打算，假設(shè)線上程序一定會(huì)出 bug。

既然防不勝防，那就嚴(yán)陣以待，在 bug 出現(xiàn)時(shí)用最快的速度修復(fù)它，來減少影響。

通常，我們要改 bug，也需要經(jīng)歷改動(dòng)代碼、提交代碼、合并代碼、打包構(gòu)建、發(fā)布上線等一系列流程。等流程走完了，可能系統(tǒng)都透心涼了。

為提高效率，我們可以使用線上診斷和熱修復(fù)技術(shù)。在出現(xiàn) bug 時(shí)，先用線上診斷工具輕松獲取項(xiàng)目的各運(yùn)行狀態(tài)和代碼執(zhí)行信息，提升排查效率。發(fā)現(xiàn)問題后，使用熱修復(fù)技術(shù)直接修改運(yùn)行時(shí)的代碼，無需重新構(gòu)建和重啟項(xiàng)目！

在 Java 中，我們可以使用阿里開源的診斷工具 Arthas，同時(shí)支持線上熱修復(fù)功能。也可以自己編寫腳本來實(shí)現(xiàn)，但是相對(duì)復(fù)雜一些。

Arthas Logo

---

看到這里，肯定有同學(xué)會(huì)吐槽，怎么寫個(gè)程序要考慮那么多和功能無關(guān)的問題。本來五分鐘就能寫完的代碼，現(xiàn)在可能一個(gè)小時(shí)都寫不完！

超兇

其實(shí)，并不是所有的項(xiàng)目都要做到絕對(duì)的安全（當(dāng)然我們也做不到），而是我們應(yīng)該時(shí)刻保持居安思危的思想，把防御性編程當(dāng)做自己的習(xí)慣。

實(shí)際情況下，要根據(jù)項(xiàng)目的量級(jí)、受眾、架構(gòu)、緊急程度等因素來綜合評(píng)估將項(xiàng)目做到何種程度的安全，而不是過度設(shè)計(jì)、杞人憂天。

讓我們把時(shí)間慢下來，在開發(fā)前先冷靜思考，預(yù)見并規(guī)避風(fēng)險(xiǎn)，不要讓達(dá)摩克利斯之劍落下。

點(diǎn)小花花，讓他們知道你?“在看”?我

總結(jié)

以上是生活随笔為你收集整理的揭秘软件开发的达摩克利斯之剑的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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