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

一 問題排查

1 常見問題

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

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

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

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

2 排查流程

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

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

??

快速止血

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

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

保留現(xiàn)場

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

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

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

解決問題

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

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

3 排查工具

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

??

??

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

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

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

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

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

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

??

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

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

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

1 性能優(yōu)化

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

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

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

性能指標(biāo)

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

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

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

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

性能分析

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

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

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

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

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

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

優(yōu)化原則

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

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

優(yōu)化手段

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

1)簡化

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

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

2)并行

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

方式：單機(jī)并行(多線程)、多機(jī)并行(分布式)。

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

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

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

3)異步

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

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

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

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

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

4)批量

有些事，你可以合起來一起做。

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

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

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

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

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

5)時間空間互換

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

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

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

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

• 案例：數(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 等。
• 一些“簡單”的算法思想：遞歸、分治、貪心、動態(tài)規(guī)劃。

7)池化 & 局部化

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

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

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

局部化(Localization)：避免共享資源競爭開銷。

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

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

• 升級紅利：內(nèi)核、JRE、依賴庫、協(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ù)活的魯班七號

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

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

穩(wěn)定是相對的，業(yè)務(wù)規(guī)模越大、場景越復(fù)雜，系統(tǒng)越容易出現(xiàn)不穩(wěn)定，且?guī)淼挠绊懸苍絿?yán)重。

??

衡量指標(biāo)

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

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

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

可用性測量

有了上述可用性指標(biāo)定義后，接下來該如何去準(zhǔn)確測量系統(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ù)。

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

優(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% —— 一方面是無法實(shí)現(xiàn)，存在太多客觀不可控因素;另一方面也沒有意義，客戶幾乎關(guān)注不到 0.001% 的可用性差別。

優(yōu)化手段

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

1)避免單點(diǎn)

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

如何避免?

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

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

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

2)流控/限流

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

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

3)熔斷

上午買的股票熔斷，晚上家里保險絲熔斷... 淡定，及時止損而已。

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

4)降級

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

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

常見降級方式：

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

5)超時/重試

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

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

Timeout vs. Deadline：使用絕對時間會更好

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

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

6)資源設(shè)限

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

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

7)資源隔離

雙 12 女友還是要敗家?得嘞刷你自個的卡吧，別動我的。

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

8 )安全生產(chǎn)

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

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

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

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

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

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

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

前人栽樹，后人乘涼。

前人挖坑，后人涼涼。

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

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

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

衡量指標(biāo)

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

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

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

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

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

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

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

重要性

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

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

優(yōu)化原則

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

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

優(yōu)化手段

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

1)編碼規(guī)范

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

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

2)代碼重構(gòu)

別灰心，代碼還有救。

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

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

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

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

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

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

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

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

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

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

三 結(jié)語

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

對，就在這句話底下。

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