????軟件工程領(lǐng)域存在一個(gè)共識(shí)：維護(hù)代碼所花費(fèi)的時(shí)間要遠(yuǎn)多于寫代碼。而整個(gè)代碼維護(hù)過(guò)程中，最驚心動(dòng)魄與扣人心弦的部分，莫過(guò)于問(wèn)題排查(Trouble-shooting)了。特別是那些需要 7x24 小時(shí)不間斷維護(hù)在線業(yè)務(wù)的一線服務(wù)端程序員們，大大小小的問(wèn)題排查線上救火早已成為家常便飯，一不小心可能就吃成了自助餐 —— 豎著進(jìn)躺著出，吃不了也兜不住。本文分享作者在服務(wù)端問(wèn)題排查方面的一些經(jīng)驗(yàn)，包括常見問(wèn)題、排查流程、排查工具，結(jié)合實(shí)際項(xiàng)目中發(fā)生過(guò)的慘痛案例進(jìn)行現(xiàn)身說(shuō)法。

創(chuàng)新互聯(lián)公司主營(yíng)即墨網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司,主營(yíng)網(wǎng)站建設(shè)方案,成都app軟件開發(fā),即墨h5微信平臺(tái)小程序開發(fā)搭建,即墨網(wǎng)站營(yíng)銷推廣歡迎即墨等地區(qū)企業(yè)咨詢

一 問(wèn)題排查

1 常見問(wèn)題

Know Your Enemy：知己知彼，百戰(zhàn)不殆。

日常遇到的大部分問(wèn)題，大致可以歸到如下幾類：

• 邏輯缺陷：e.g. NPE、死循環(huán)、邊界情況未覆蓋。
• 性能瓶頸：e.g. 接口 RT 陡增、吞吐率上不去。
• 內(nèi)存異常：e.g. GC 卡頓、頻繁 FGC、內(nèi)存泄露、OOM
• 并發(fā)/分布式：e.g. 存在競(jìng)爭(zhēng)條件、時(shí)鐘不同步。
• 數(shù)據(jù)問(wèn)題：e.g. 出現(xiàn)臟數(shù)據(jù)、序列化失敗。
• 安全問(wèn)題：e.g. DDoS 攻擊、數(shù)據(jù)泄露。
• 環(huán)境故障：e.g. 宿主機(jī)宕機(jī)、網(wǎng)絡(luò)不通、丟包。
• 操作失誤：e.g. 配置推錯(cuò)、刪庫(kù)跑路(危險(xiǎn)動(dòng)作，請(qǐng)勿嘗試..)。

上述分類可能不太完備和嚴(yán)謹(jǐn)，想傳達(dá)的點(diǎn)是：你也可以積累一個(gè)這樣的 checklist，當(dāng)遇到問(wèn)題百思不得其解時(shí)，耐心過(guò)一遍，也許很快就能對(duì)號(hào)入座。

2 排查流程

醫(yī)生：小王你看，這個(gè)傷口的形狀，像不像一朵漂浮的白云?

病人：...再不給我包扎止血，就要變成火燒云了。

??

??

快速止血

問(wèn)題排查的第一步，一定是先把血止住，及時(shí)止損。如何快速止血?常見方式包括：

• 發(fā)布期間開始報(bào)錯(cuò)，且發(fā)布前一切正常?啥也別管，先回滾再說(shuō)，恢復(fù)正常后再慢慢排查。
• 應(yīng)用已經(jīng)穩(wěn)定運(yùn)行很長(zhǎng)一段時(shí)間，突然開始出現(xiàn)進(jìn)程退出現(xiàn)象?很可能是內(nèi)存泄露，默默上重啟大法吧。
• 只有少數(shù)固定機(jī)器報(bào)錯(cuò)?試試隔離這部分機(jī)器(關(guān)閉流量入口)。
• 單用戶流量突增導(dǎo)致服務(wù)不穩(wěn)定?如果不是惹不起的金主爸爸，請(qǐng)勇敢推送限流規(guī)則。
• 下游依賴掛了導(dǎo)致服務(wù)雪崩?還想什么呢，降級(jí)預(yù)案走起。

保留現(xiàn)場(chǎng)

血止住了?那么恭喜你，至少故障影響不會(huì)再擴(kuò)大了。卸下鍋，先喘口氣再說(shuō)。下一步，就是要根據(jù)線索找出問(wèn)題元兇了。作為一名排查老手，你需要有盡量保留現(xiàn)場(chǎng)的意識(shí)，例如：

• 隔離一兩臺(tái)機(jī)器：將這部分機(jī)器入口流量關(guān)閉，讓它們靜靜等待你的檢閱。
• Dump 應(yīng)用快照：常用的快照類型一般就是線程堆棧和堆內(nèi)存映射。
• 所有機(jī)器都回滾了，咋辦?別慌，如果你的應(yīng)用監(jiān)控運(yùn)維體系足夠健全，那么你還有多維度的歷史數(shù)據(jù)可以回溯：應(yīng)用日志、中間件日志、GC 日志、內(nèi)核日志、Metrics 指標(biāo)等。

定位原因

OK，排查線索也有了，接下來(lái)該怎么定位具體原因?這個(gè)環(huán)節(jié)會(huì)綜合考驗(yàn)?zāi)愕募夹g(shù)深度、業(yè)務(wù)熟悉度和實(shí)操經(jīng)驗(yàn)，因?yàn)樵蛲记姘俟郑枰?case by case 的追蹤與分析。這里給出幾個(gè)排查方向上的建議：

• 關(guān)聯(lián)近期變更：90% 以上的線上問(wèn)題都是由變更引發(fā)，這也是為什么集團(tuán)安全生產(chǎn)的重點(diǎn)一直是在管控“變更”。所以，先不要急著否認(rèn)(“肯定不是我剛加的那行代碼問(wèn)題!”)，相信統(tǒng)計(jì)學(xué)概率，好好 review 下近期的變更歷史(從近至遠(yuǎn))。
• 全鏈路追蹤分析：微服務(wù)和中臺(tái)化盛行的當(dāng)下，一次業(yè)務(wù)請(qǐng)求不經(jīng)過(guò)十個(gè)八個(gè)應(yīng)用處理一遍，都不好意思說(shuō)自己是寫 Java 的。所以，不要只盯著自己的應(yīng)用不放，你需要把排查 scope 放大到全鏈路。
• 還原事件時(shí)間線：請(qǐng)把自己想象成福爾摩斯(柯南也行)，擺在你面前的就是一個(gè)案發(fā)現(xiàn)場(chǎng)，你需要做的是把不同時(shí)間點(diǎn)的所有事件線索都串起來(lái)，重建和還原整個(gè)案發(fā)過(guò)程。要相信，時(shí)間戳是不會(huì)騙人的。
• 找到 Root Cause：排查問(wèn)題多了你會(huì)發(fā)現(xiàn)，很多疑似原因往往只是另一個(gè)更深層次原因的表象結(jié)果之一。作為福爾摩斯，你最需要找到的是幕后兇手，而不是雇傭的殺人犯 —— 否則 TA 還會(huì)雇人再來(lái)一次。
• 嘗試復(fù)現(xiàn)問(wèn)題：千辛萬(wàn)苦推導(dǎo)出了根因，也不要就急著開始修 bug 了。如果可以，最好能把問(wèn)題穩(wěn)定復(fù)現(xiàn)出來(lái)，這樣才更有說(shuō)服力。這里提醒一點(diǎn)：可千萬(wàn)別在生產(chǎn)環(huán)境干這事(除非你真的 know what you're doing)，否則搞不好就是二次傷害(你：哈哈哈，你看，這把刀當(dāng)時(shí)就是從這個(gè)角度捅進(jìn)去的，軌跡完全一樣。用戶：...)。

解決問(wèn)題

最后，問(wèn)題根因已經(jīng)找到，如何完美解決收尾?幾個(gè)基本原則：

• 修復(fù)也是一種變更，需要經(jīng)過(guò)完整的回歸測(cè)試、灰度發(fā)布;切忌火急火燎上線了 bugfix，結(jié)果引發(fā)更多的 bugs to fix。
• 修復(fù)發(fā)布后，一定要做線上驗(yàn)證，并且保持觀察一段時(shí)間，確保是真的真的修復(fù)了。
• 最后，如果問(wèn)題已經(jīng)上升到了故障這個(gè)程度，那就拉上大伙好好做個(gè)故障復(fù)盤吧。整個(gè)處理過(guò)程一定還有提升空間，你的經(jīng)驗(yàn)教訓(xùn)對(duì)其他同學(xué)來(lái)說(shuō)也是一次很好的輸入和自查機(jī)會(huì)：幸福總是相似的，故障也是。

3 排查工具

手里只有錘子，那看什么都像釘子。作為工程師，你需要的是一整套工具箱。

??

??

??

??

問(wèn)題排查其實(shí)就是一次持續(xù)觀測(cè)應(yīng)用行為的過(guò)程。為了確保不遺漏關(guān)鍵細(xì)節(jié)，你需要讓自己的應(yīng)用變得更“可觀測(cè)(Observable)。

提升應(yīng)用可觀測(cè)性有三大利器：日志(Logging)、監(jiān)控(Metrics)、追蹤(Tracing)。在我之前所做的項(xiàng)目中，這三塊能力分別是由 SLS、Alimonitor / AliMetrics / Tsar、EagleEye 提供的，這里就不再展開描述了。

另外也很推薦 Arthas 這個(gè)工具，非常實(shí)用和順手，相信很多同學(xué)都已經(jīng)用過(guò)。

二 系統(tǒng)優(yōu)化

只學(xué)會(huì)了問(wèn)題排查還遠(yuǎn)遠(yuǎn)不夠(當(dāng)然技能必須點(diǎn)滿，shit always happen)，再熟練也只是治標(biāo)不治本。如果想從根源上規(guī)避問(wèn)題，必須從系統(tǒng)本身出發(fā)：按照性能、穩(wěn)定性和可維護(hù)性三個(gè)方向，持續(xù)優(yōu)化你的系統(tǒng)實(shí)現(xiàn)，扼殺問(wèn)題于搖籃之中，讓自己每天都能睡個(gè)安穩(wěn)覺。

老板：既要快，又要穩(wěn)，還要好。哦，工資的事你別擔(dān)心，下個(gè)月一定能發(fā)出來(lái)。

??

??

系統(tǒng)優(yōu)化的三個(gè)基本方向：性能(Performance)、穩(wěn)定性(Stability)、可維護(hù)性(Maintainability)。三者之間并不是完全獨(dú)立的，而是存在著復(fù)雜的相互作用關(guān)系，有時(shí)甚至?xí)讼碎L(zhǎng)。

最優(yōu)秀的軟件系統(tǒng)，并非要把這三個(gè)方向都做到極致，而是會(huì)根據(jù)自己實(shí)際的業(yè)務(wù)需求和場(chǎng)景合理取舍，在這三者之間達(dá)到一個(gè)綜合最優(yōu)的動(dòng)態(tài)平衡狀態(tài)，讓各方面都能做到足夠好即可。

所以，優(yōu)化不只是一門科學(xué)，也是一門藝術(shù)。

1 性能優(yōu)化

問(wèn)：要跑出最快的圈速，是車手重要，還是賽車重要?答：全都重要。

沒有哪個(gè)男人會(huì)不喜歡高性能跑車，也沒有哪個(gè)女人會(huì)希望在看李佳琦直播時(shí)突然卡頓。

性能，是各行各業(yè)工程師們共同追求的終極浪漫。

性能指標(biāo)

指標(biāo)(Indicators)是衡量一件事物好壞的科學(xué)量化手段。對(duì)于性能而言，一般會(huì)使用如下指標(biāo)評(píng)估：

• 吞吐率(Throughput)：系統(tǒng)單位時(shí)間內(nèi)能處理的工作負(fù)載，例如：在線 Web 系統(tǒng) - QPS/TPS，離線數(shù)據(jù)分析系統(tǒng) - 每秒處理的數(shù)據(jù)量。
• 響應(yīng)時(shí)間(Response Time)：以 Web 請(qǐng)求處理為例，響應(yīng)時(shí)間(RT)即請(qǐng)求從發(fā)出到收到的往返時(shí)間，一般會(huì)由網(wǎng)絡(luò)傳輸延遲、排隊(duì)延遲和實(shí)際處理耗時(shí)幾個(gè)部分共同組成。
• 可伸縮性(Scalability)：系統(tǒng)通過(guò)增加機(jī)器資源(垂直/水平)來(lái)承載更多工作負(fù)載的能力;投入產(chǎn)出比越高(理想情況是線性伸縮)，則說(shuō)明系統(tǒng)的可伸縮性越好。

此外，同一個(gè)系統(tǒng)的吞吐率與響應(yīng)時(shí)間，一般還會(huì)存在如下關(guān)聯(lián)關(guān)系：吞吐率小于某個(gè)臨界值時(shí)，響應(yīng)時(shí)間幾乎不變;一旦超出這個(gè)臨界值，系統(tǒng)將進(jìn)入超載狀態(tài)(overloaded)，響應(yīng)時(shí)間開始線性增長(zhǎng)。對(duì)于一個(gè)有穩(wěn)定性要求的系統(tǒng)，需要在做性能壓測(cè)和容量規(guī)劃時(shí)充分考慮這個(gè)臨界值的大小。

注：其實(shí)按更嚴(yán)謹(jǐn)?shù)恼f(shuō)法，性能就是單指一個(gè)系統(tǒng)有多“快”;上述部分指標(biāo)并不純粹只代表系統(tǒng)快慢，但也都與快慢息息相關(guān)。

性能分析

古人有句老話，If you can't measure it, you can't improve It.

要優(yōu)化一個(gè)系統(tǒng)的性能(例如Web請(qǐng)求響應(yīng)時(shí)間)，你必須首先準(zhǔn)確地測(cè)量和分析出，當(dāng)前系統(tǒng)的性能究竟差在哪：是請(qǐng)求解析不夠快，還是查詢 DB 太慢?如果是后者，那又是掃描數(shù)據(jù)條目階段太慢，還是返回結(jié)果集太慢?或者會(huì)不會(huì)只是應(yīng)用與 DB 之間的網(wǎng)絡(luò)延遲太大?

任何復(fù)雜請(qǐng)求的處理過(guò)程，最終都可以拆解出一系列并行/串行的原子操作。如果只是逮住哪個(gè)就去優(yōu)化哪個(gè)，顯然效率不會(huì)太高(除非你運(yùn)氣爆棚)。更合理的做法，應(yīng)該是堅(jiān)持 2/8 原則：優(yōu)先分析和優(yōu)化系統(tǒng)瓶頸，即當(dāng)前對(duì)系統(tǒng)性能影響最大的原子操作;他們很可能就是 ROI 最高的優(yōu)化點(diǎn)。

具體該如何去量化分析性能?這里列出了一些工具參考：

• 系統(tǒng)層面：tsar、top、iostat、vmstat
• 網(wǎng)絡(luò)層面：iftop、tcpdump、wireshark
• 數(shù)據(jù)庫(kù)層面：SQL explain、CloudDBA
• 應(yīng)用代碼層面：JProfiler、Arthas、jstack

其中很多工具也是問(wèn)題排查時(shí)常用的診斷工具;畢竟，無(wú)論是性能分析還是診斷分析，目的都是去理解一個(gè)系統(tǒng)和他所處的環(huán)境，所需要做的事情都是相似的。

優(yōu)化原則

你應(yīng)該做的：上面已經(jīng)提了很多，這里再補(bǔ)充一點(diǎn)：性能優(yōu)化與做功能需求一樣，都是為業(yè)務(wù)服務(wù)的，因此優(yōu)化時(shí)千萬(wàn)不要忙著自嗨，一定要結(jié)合目標(biāo)需求和應(yīng)用場(chǎng)景 —— 也許這塊你想做的優(yōu)化，壓根線上就碰不到;也許那塊很難做的優(yōu)化，可以根據(jù)流量特征做非通用的定制優(yōu)化。

你不應(yīng)該做的：即老生常談的提前優(yōu)化(Premature-optimization)與過(guò)度優(yōu)化(Over-optimization) —— 通常而言(并不絕對(duì))，性能優(yōu)化都不是免費(fèi)的午餐，優(yōu)化做的越多，往往可維護(hù)性也會(huì)越差。

優(yōu)化手段

常用的性能優(yōu)化手段有哪些?我這里總結(jié)了 8 個(gè)套路(最后 1 個(gè)是小霸王多合一匯總套路)。

1)簡(jiǎn)化

有些事，你可以選擇不做。

• 業(yè)務(wù)層面：e.g. 流程精簡(jiǎn)、需求簡(jiǎn)化。
• 編碼層面：e.g. 循環(huán)內(nèi)減少高開銷操作。
• 架構(gòu)層面：e.g. 減少?zèng)]必要的抽象/分層。
• 數(shù)據(jù)層面：e.g. 數(shù)據(jù)清洗、提取、聚合。

2)并行

有些事，你可以找人一起做。

方式：?jiǎn)螜C(jī)并行(多線程)、多機(jī)并行(分布式)。

優(yōu)點(diǎn)：充分利用機(jī)器資源(多核、集群)。

缺點(diǎn)：同步開銷、線程開銷、數(shù)據(jù)傾斜。

• 同步優(yōu)化：樂觀鎖、細(xì)粒度鎖、無(wú)鎖。
• 線程替代(如協(xié)程：Java WISP、Go routines、Kotlin coroutines)。
• 數(shù)據(jù)傾斜：負(fù)載均衡(Hash / RR / 動(dòng)態(tài))。

3)異步

有些事，你可以放手，不用死等。

方式：消息隊(duì)列 + 任務(wù)線程 + 通知機(jī)制。

優(yōu)點(diǎn)：提升吞吐率、組件解耦、削峰填谷。

缺點(diǎn)：排隊(duì)延遲(隊(duì)列積壓)。

• 避免過(guò)度積壓：Back-pressure(Reactive思想)。

4)批量

有些事，你可以合起來(lái)一起做。

方式：多次單一操作 → 合并為單次批量操作。

案例：TCP Nagel 算法;DB 的批量讀寫接口。

優(yōu)點(diǎn)：避免單次操作的固有開銷，均攤后總開銷更低。

缺點(diǎn)：等待延遲 + 聚合延遲。

• 減少等待延遲：Timeout 觸發(fā)提交，控制延遲上限。

5)時(shí)間空間互換

游戲的本質(zhì)：要么有閑，要么有錢。

空間換時(shí)間：避免重復(fù)計(jì)算、拉近傳輸距離、分流減少壓力。

• 案例：緩存、CDN、索引、只讀副本(replication)。

時(shí)間換空間：有時(shí)候也能達(dá)到“更快”的效果(數(shù)據(jù)量減少 → 傳輸時(shí)間減少)。

• 案例：數(shù)據(jù)壓縮(HTTP/2 頭部壓縮、Bitmap)。

6)數(shù)據(jù)結(jié)構(gòu)與算法優(yōu)化

程序 = 數(shù)據(jù)結(jié)構(gòu) + 算法

• 多了解一些“冷門”的數(shù)據(jù)結(jié)構(gòu) ：Skip list、Bloom filter、Time Wheel 等。
• 一些“簡(jiǎn)單”的算法思想：遞歸、分治、貪心、動(dòng)態(tài)規(guī)劃。

7)池化 & 局部化

共享經(jīng)濟(jì) & 小區(qū)超市

池化(Pooling)：減少資源創(chuàng)建和銷毀開銷。

• 案例：線程池、內(nèi)存池、DB 連接池、Socket 連接池。

局部化(Localization)：避免共享資源競(jìng)爭(zhēng)開銷。

• 案例：TLB(ThreadLocalBuffer)、多級(jí)緩存(本地局部緩存 -> 共享全局緩存)。

8)更多優(yōu)化手段

• 升級(jí)紅利：內(nèi)核、JRE、依賴庫(kù)、協(xié)議。
• 調(diào)參大師：配置、JVM、內(nèi)核、網(wǎng)卡。
• SQL 優(yōu)化：索引、SELECT *、LIMIT 1。
• 業(yè)務(wù)特征定制優(yōu)化：e.g. 凌晨業(yè)務(wù)低峰期做日志輪轉(zhuǎn)。
• Hybrid 思想(優(yōu)點(diǎn)結(jié)合)：JDK sort() 實(shí)現(xiàn)、Weex/RN。

2 穩(wěn)定性優(yōu)化

穩(wěn)住，我們能贏?！?by [0 殺 10 死] 正在等待復(fù)活的魯班七號(hào)

維持穩(wěn)定性是我們程序員每天都要思考和討論的大事。

什么樣的系統(tǒng)才算穩(wěn)定?我自己寫了個(gè)小工具，本地跑跑從來(lái)沒出過(guò)問(wèn)題，算穩(wěn)定嗎?淘寶網(wǎng)站幾千人維護(hù)，但雙十一零點(diǎn)還是經(jīng)常下單失敗，所以它不穩(wěn)定嘍?

穩(wěn)定是相對(duì)的，業(yè)務(wù)規(guī)模越大、場(chǎng)景越復(fù)雜，系統(tǒng)越容易出現(xiàn)不穩(wěn)定，且?guī)?lái)的影響也越嚴(yán)重。

??

??

衡量指標(biāo)

不同業(yè)務(wù)所提供的服務(wù)類型千差萬(wàn)別，如何用一致的指標(biāo)去衡量系統(tǒng)穩(wěn)定性?標(biāo)準(zhǔn)做法是定義服務(wù)的可用性(Availability)：只要對(duì)用戶而言服務(wù)“可用”，那就認(rèn)為系統(tǒng)當(dāng)前是穩(wěn)定的;否則就是不穩(wěn)定。用這樣的方式，采集和匯總后就能得到服務(wù)總的可用/不可用比例(服務(wù)時(shí)長(zhǎng) or 服務(wù)次數(shù))，以此來(lái)監(jiān)測(cè)和量化一個(gè)系統(tǒng)的穩(wěn)定性。

可是，通過(guò)什么來(lái)定義某個(gè)服務(wù)當(dāng)前是否可用呢?這一點(diǎn)確實(shí)跟業(yè)務(wù)相關(guān)，但大部分同類業(yè)務(wù)都可以用類似的方式去定義。例如，對(duì)于一般的 Web 網(wǎng)站，我們可以按如下方式去定義服務(wù)是否可用：API 請(qǐng)求都返回成功，且頁(yè)面總加載時(shí)間 < 3 秒。

對(duì)于阿里云對(duì)外提供的云產(chǎn)品而言，服務(wù)可用性是一個(gè)更加需要格外重視并持續(xù)提升的指標(biāo)：阿里云上的很多用戶會(huì)同時(shí)使用多款云產(chǎn)品，其中任何一款產(chǎn)品出現(xiàn)可用性問(wèn)題，都會(huì)直接被用戶的用戶感知和放大。所以，越是底層的基礎(chǔ)設(shè)施，可用性要求就越高。關(guān)于可用性的更多細(xì)節(jié)指標(biāo)和概念(SLI / SLO / SLA)，可進(jìn)一步參考云智能 SLA 了解。

可用性測(cè)量

有了上述可用性指標(biāo)定義后，接下來(lái)該如何去準(zhǔn)確測(cè)量系統(tǒng)的可用性表現(xiàn)?一般有如下兩種方式。

1)探針模擬

從客戶端側(cè)，模擬用戶的調(diào)用行為。

• 優(yōu)點(diǎn)：數(shù)據(jù)真實(shí)(客戶端角度)
• 缺點(diǎn)：數(shù)據(jù)不全面(單一客戶數(shù)據(jù))

2)服務(wù)端采集

從服務(wù)端側(cè)，直接分析日志和數(shù)據(jù)。

優(yōu)點(diǎn)：覆蓋所有調(diào)用數(shù)據(jù)。

缺點(diǎn)：缺失客戶端鏈路數(shù)據(jù)。

對(duì)可用性數(shù)據(jù)要求較高的系統(tǒng)，也可以同時(shí)運(yùn)用上述兩種方式，建議結(jié)合你的業(yè)務(wù)場(chǎng)景綜合評(píng)估選擇。

優(yōu)化原則

你應(yīng)該做的：關(guān)注 RT 的數(shù)據(jù)分布(如：p50/p99/p999 分位點(diǎn))，而不是平均值(mean) —— 平均值并沒有太大意義，更應(yīng)該去關(guān)注你那 1%、0.1% 用戶的準(zhǔn)確感受。

你不應(yīng)該做的：不要嘗試承諾和優(yōu)化可用性到 100% —— 一方面是無(wú)法實(shí)現(xiàn)，存在太多客觀不可控因素;另一方面也沒有意義，客戶幾乎關(guān)注不到 0.001% 的可用性差別。

優(yōu)化手段

常用的穩(wěn)定性優(yōu)化手段有哪些?這里也總結(jié)了 8 個(gè)套路：

1)避免單點(diǎn)

父母：一個(gè)人在外漂了這么多年，也該找個(gè)人穩(wěn)定下來(lái)了。

如何避免?

• 集群部署
• 數(shù)據(jù)副本
• 多機(jī)房容災(zāi)

只堆量不夠，還需要具備故障轉(zhuǎn)移能力(Failover)。

• 接入層：DNS、VipServer、SLB。
• 服務(wù)層：服務(wù)發(fā)現(xiàn) + 健康檢查 + 剔除機(jī)制。
• 應(yīng)用層：無(wú)狀態(tài)設(shè)計(jì)(Stateless)，便于隨時(shí)和快速切換。

2)流控/限流

計(jì)劃生育、上學(xué)調(diào)劑、車牌限號(hào)、景區(qū)限行... 人生處處被流控。

• 類型：QPS 流控、并發(fā)度流控。
• 工具：RateLimiter、信號(hào)量、Sentinel。
• 粒度：全局、用戶級(jí)、接口級(jí)。
• 熱點(diǎn)流控：避免意料之外的突增流量。

3)熔斷

上午買的股票熔斷，晚上家里保險(xiǎn)絲熔斷... 淡定，及時(shí)止損而已。

• 目的：防止連鎖故障(雪崩效應(yīng))。
• 工具：Hystrix、Failsafe、Resilience4j。
• 功能：自動(dòng)繞開異常服務(wù)并檢測(cè)恢復(fù)狀態(tài)。
• 流程：關(guān)閉 → 打開 → 半開。

4)降級(jí)

沒時(shí)間做飯了，今天就吃外賣吧... 對(duì)于健康問(wèn)題，還是得少一點(diǎn)降級(jí)。

觸發(fā)原因：流控、熔斷、負(fù)載過(guò)高。

常見降級(jí)方式：

• 關(guān)閉非核心功能：停止應(yīng)用日志打印
• 犧牲數(shù)據(jù)時(shí)效性：返回緩存中舊數(shù)據(jù)
• 犧牲數(shù)據(jù)精確性：降低數(shù)據(jù)采樣頻率

5)超時(shí)/重試

釘釘不回怎么辦?每 10 分鐘 ping 一次，超過(guò) 1 小時(shí)打電話。

• 超時(shí)：避免調(diào)用端陷入永久阻塞。
• 超時(shí)時(shí)間設(shè)置：全鏈路自上而下規(guī)劃

Timeout vs. Deadline：使用絕對(duì)時(shí)間會(huì)更好

重試：確?？芍卦嚥僮鞯膬绲刃?。

• 消息去重
• 異步重試
• 指數(shù)退避

6)資源設(shè)限

雙 11 如何避免女友敗家?提前把自己信用卡額度調(diào)低。

• 目的：防止資源被異常流量耗盡
• 資源類型：線程、隊(duì)列、DB 連接
• 設(shè)限方式：資源池化、有界隊(duì)列
• 超限處理：返回 ServiceUnavailable / QuotaExceeded

7)資源隔離

雙 12 女友還是要敗家?得嘞刷你自個(gè)的卡吧，別動(dòng)我的。

• 目的：防止資源被部分異常流量耗盡;為 VIP 客戶提供服務(wù)質(zhì)量保證(QoS)。
• 隔離方式：隊(duì)列劃分、獨(dú)立集群;注意處理優(yōu)先級(jí)和資源分配比例。

8 )安全生產(chǎn)

女友哭著說(shuō)再讓我最后剁一次手吧?安全第一，寧愿心疼也不要肉疼。

程序動(dòng)態(tài)性：開關(guān)、配置、熱升級(jí)。

• Switch：類型安全;侵入性小。

審核機(jī)制：代碼 Review、發(fā)布審批。

灰度發(fā)布;分批部署;回滾預(yù)案。

• DUCT：自動(dòng)/手動(dòng)調(diào)整 HSF 節(jié)點(diǎn)權(quán)重。

3 可維護(hù)性優(yōu)化

前人栽樹，后人乘涼。

前人挖坑，后人涼涼。

維護(hù)的英文是 maintain，也能翻譯成：維持、供給。所以軟件維護(hù)能有多重要?它就是軟件系統(tǒng)的呼吸機(jī)和食物管道，維持軟件生命的必要供給。

系統(tǒng)開發(fā)完成上線，不過(guò)只是把它“生”下來(lái)而已。軟件真正能發(fā)揮多大價(jià)值，看的是交付后持續(xù)的價(jià)值兌現(xiàn)過(guò)程 —— 是不斷茁壯成長(zhǎng)，為用戶發(fā)光發(fā)熱?還是慢慢墮落，逐漸被用戶所遺忘?這并不是取決于它當(dāng)下瞬時(shí)是否足夠優(yōu)秀(性能)和靠譜(穩(wěn)定)，而是取決于未來(lái) —— 能否在不斷變化的市場(chǎng)環(huán)境、客戶需求和人為因素中，始終保持足夠優(yōu)秀和靠譜，并且能越來(lái)越好。

相比性能和穩(wěn)定性而言，可維護(hù)性所體現(xiàn)的價(jià)值往往是最長(zhǎng)遠(yuǎn)、但也最難在短期內(nèi)可兌現(xiàn)的，因此很多軟件項(xiàng)目都選擇了在前期犧牲可維護(hù)性。這樣決策帶來(lái)的后果，就跟架構(gòu)設(shè)計(jì)一樣，是幾乎無(wú)法(或者需要非常高的成本)去彌補(bǔ)和挽回的。太多的軟件項(xiàng)目，就是因?yàn)樵絹?lái)越不可維護(hù)(代碼改不動(dòng)、bug 修不完、feature 加不上)，最后只能慢慢淪落為一個(gè)誰(shuí)都不想碰的遺留項(xiàng)目。

衡量指標(biāo)

相比性能和穩(wěn)定性而言，可維護(hù)性確實(shí)不太好量化(藝術(shù)成分 > 科學(xué)成分)。這里我選取了幾個(gè)偏定性分析的指標(biāo)：

1)復(fù)雜度(Complexity)：是否復(fù)雜度可控?

• 編碼：簡(jiǎn)潔度、命名一致性、代碼行數(shù)等。
• 架構(gòu)：組件耦合度、層次清晰度、職責(zé)單一性等。

2)可擴(kuò)展性(Extensibility)：是否易于變更?

• 需要變更代碼或配置時(shí)，是否簡(jiǎn)單優(yōu)雅、不易出錯(cuò)。

3)可運(yùn)維性(Operability)：是否方便運(yùn)維?

• 日志、監(jiān)控是否完善;部署、擴(kuò)容是否容易。

重要性

這里給了幾個(gè)觀點(diǎn)，進(jìn)一步強(qiáng)調(diào)可維護(hù)性的重要性。

• 軟件生命周期：維護(hù)周期 >> 開發(fā)周期。
• 破窗效應(yīng)、熵增定律：可維護(hù)性會(huì)趨向于越來(lái)越差。
• 遺留系統(tǒng)的危害：理解難度，修改成本，變更風(fēng)險(xiǎn);陷入不斷踩坑、填坑、又挖坑的循環(huán)。

優(yōu)化原則

你應(yīng)該做的：遵循 KISS 原則、DRY 原則、各種代碼可讀性和架構(gòu)設(shè)計(jì)原則等。

你不應(yīng)該做的：引入過(guò)多臨時(shí)性、Hack 代碼;功能 Work 就 OK，欠一堆技術(shù)債(出來(lái)混總是要還的)。

優(yōu)化手段

常用的可維護(hù)性優(yōu)化手段有哪些?這里我總結(jié)了 4 個(gè)套路：

1)編碼規(guī)范

無(wú)規(guī)矩，不成方圓。

• 編碼：推薦《Java 開發(fā)手冊(cè)》，另外也推薦 The Art of Readable Code 這本書。
• 日志：無(wú)盲點(diǎn)、無(wú)冗余、TraceID。
• 測(cè)試：代碼覆蓋度、自動(dòng)化回歸。

2)代碼重構(gòu)

別灰心，代碼還有救。

何時(shí)重構(gòu)：任何時(shí)候代碼中嗅到壞味道(bad smell)。

重構(gòu)節(jié)奏：小步迭代、回歸驗(yàn)證。

重構(gòu) vs. 重寫：需要綜合考慮成本、風(fēng)險(xiǎn)、并行版本維護(hù)等因素。

推薦閱讀：Refactoring: Improving the Design of Existing Code。

3)數(shù)據(jù)驅(qū)動(dòng)

相信數(shù)據(jù)的力量。

• 系統(tǒng)數(shù)據(jù)：監(jiān)控覆蓋、Metrics 采集等，對(duì)于理解系統(tǒng)、排查問(wèn)題至關(guān)重要。
• 業(yè)務(wù)數(shù)據(jù)：一致性校驗(yàn)、舊數(shù)據(jù)清理等;要相信，數(shù)據(jù)往往比代碼要活得更久。

4)技術(shù)演進(jìn)

技術(shù)是第一生產(chǎn)力。

• 死守陣地 or 緊跟潮流? 需要綜合評(píng)估風(fēng)險(xiǎn)、生產(chǎn)力、學(xué)習(xí)成本。
• 當(dāng)前方向：微服務(wù)化、容器化。

三 結(jié)語(yǔ)

Truth lies underneath the skin - 真理永遠(yuǎn)暗藏在表象底下。

對(duì)，就在這句話底下。

歡迎各位技術(shù)同路人加入阿里云云原生應(yīng)用研發(fā)平臺(tái) EMAS 團(tuán)隊(duì)，我們專注于廣泛的云原生技術(shù)(Backend as a Service、Serverless、DevOps、低代碼平臺(tái)等)，致力于為企業(yè)、開發(fā)者提供一站式的應(yīng)用研發(fā)管理服務(wù)，內(nèi)推直達(dá)：pengqun.pq # alibaba-inc.com，有信必回。

分享名稱：救火必備！問(wèn)題排查與系統(tǒng)優(yōu)化手冊(cè)
URL鏈接：http://uogjgqi.cn/article/djjesgj.html