1. 先把三個原則的靶心認(rèn)清楚前年接手一個訂單模塊一個文件兩千三百多行里面有下單、算價、發(fā)券、調(diào)支付、寫對賬、發(fā)通知還有一段誰也不敢刪的歷史兼容邏輯注釋寫著“勿動動了會出事”。有次改一個優(yōu)惠券疊加規(guī)則上線第二天退款流程全掛了查了大半天才發(fā)現(xiàn)退款復(fù)用了算價里的一段私有方法而那段方法被我在改優(yōu)惠券時順手改了返回值結(jié)構(gòu)。這件事之后我把“原則性”這三個字重新理解了一遍——它不是面試時背的概念而是給代碼和系統(tǒng)劃的那幾條不能越的線單一職責(zé)原則管的是“邊界在哪”第一性原則管的是“從哪開始想”ACID原則管的是“什么狀態(tài)不能破”。三條線合起來最終落到三個很實(shí)在的地方安全、學(xué)習(xí)、節(jié)約——系統(tǒng)更不容易出事故自己成長路徑更清晰長期的人力和機(jī)器成本更低。這篇內(nèi)容適合誰看如果你寫業(yè)務(wù)代碼一兩年感覺項(xiàng)目越寫越亂、改一處崩三處如果你開始做一點(diǎn)模塊設(shè)計(jì)或者帶一兩個新人需要一套能講清楚、能落地的判斷標(biāo)準(zhǔn)如果你是做技術(shù)方案評審的經(jīng)常被“別人都這么做”這種理由堵回來。下面的東西不玩概念全是能直接抄的做法、能直接套的算例以及我踩過的坑。2. 三個原則各自盯住的是什么問題很多人把這三個原則當(dāng)成三個孤立的知識點(diǎn)考完就忘。真正有用的是把它們看成一套成本控制工具單一職責(zé)控制的是“變更成本”第一性原則控制的是“認(rèn)知成本”ACID控制的是“故障成本”。三樣?xùn)|西壓下去項(xiàng)目才可能長期活著。2.1 單一職責(zé)原則判斷標(biāo)準(zhǔn)是“變更的理由”不是“代碼行數(shù)”先糾正一個特別常見的誤解。SRPSingle Responsibility Principle里的“單一職責(zé)”不是“一個類只干一件事”也不是“一個方法只寫十行”。它的原始表述是“一個模塊應(yīng)該有且只有一個變更的理由”。關(guān)鍵詞是理由——理由來自人來自需求方。換句話說如果兩個需求來自不同的角色、不同的業(yè)務(wù)方向、不同的上線節(jié)奏卻都要改同一個文件那這個文件就違反了SRP。舉個具體的一個OrderService里同時放著“下單”“退款”“對賬出報(bào)表”三塊邏輯。下單的變更來自產(chǎn)品經(jīng)理退款的變更來自客服和財(cái)務(wù)對賬的變更來自財(cái)務(wù)結(jié)算周期。三個來源三種節(jié)奏三種驗(yàn)收方式卻擠在一個類里——這就是典型的職責(zé)過載。反過來一個PriceCalculator里有一百五十行算價邏輯包含了階梯價、會員價、區(qū)域價看著很長但它們?nèi)贾灰驗(yàn)椤岸▋r策略變化”這一個理由而改那它反而是合規(guī)的。所以行數(shù)不是判據(jù)變更源的個數(shù)才是。我習(xí)慣用一個很土的自測問題這個模塊如果要在周會上匯報(bào)我能不能用一句話說清它負(fù)責(zé)什么并且這句話里不出現(xiàn)“和”“以及”“順便”如果說不清基本就該拆了。2.2 第一性原則把“結(jié)論”還原成“事實(shí)”再從事實(shí)重新組裝第一性原則First Principles說白了就一句話別從別人給的結(jié)論出發(fā)從不可再分的事實(shí)出發(fā)。它的對立面是“類比推理”——因?yàn)閯e人這么做所以我也這么做因?yàn)樯洗芜@么做成了所以這次還這么做。類比推理省事但它會把別人的歷史包袱一起繼承過來。做過飯的人有體會照著菜譜一步步抄能做出一盤能吃的菜但只有搞明白“為什么先炒后燉”“為什么這個要大火快炒那個要小火慢煨”你才能在缺一味調(diào)料、換一口鍋的時候照樣做出來。寫系統(tǒng)也一樣。上來就問“我們要不要上消息隊(duì)列”“緩存用哪個”這是從結(jié)論出發(fā)先問“這個鏈路的讀寫比例是多少”“數(shù)據(jù)能容忍丟嗎”“延遲預(yù)算是多少毫秒”這是從事實(shí)出發(fā)。我見過最典型的一次爭論是某團(tuán)隊(duì)要做一個配置下發(fā)功能會上直接開吵“用推還是用拉”。吵了四十分鐘沒結(jié)果。后來有人把問題拉回事實(shí)配置一共多少條不到兩千條、多久變一次平均一天兩次、客戶端多少臺三千臺左右、能容忍多長延遲一分鐘內(nèi)都行。四個數(shù)字?jǐn)[出來答案自己就出來了——三千臺客戶端一天拉兩次QPS 不到 0.1隨便搞個定時輪詢就完事根本不需要長連接推送。算一遍比吵一小時管用。2.3 ACID原則它不是數(shù)據(jù)庫的專屬品是“狀態(tài)變更”的底線ACID 四個字母——原子性、一致性、隔離性、持久性——很多人只在學(xué)數(shù)據(jù)庫時背過工作后覺得那是 DBA 的事。但只要你的系統(tǒng)里存在“一次操作要改多處狀態(tài)”ACID 就是繞不開的底線。用轉(zhuǎn)賬這個老例子說清楚四件事。原子性指的是“扣錢和加錢要么都成要么都不成”不能出現(xiàn)扣了沒加一致性指的是“轉(zhuǎn)賬前后總金額不變”這是業(yè)務(wù)規(guī)則層面的約束隔離性指的是“兩個人同時轉(zhuǎn)不會互相看到中間狀態(tài)導(dǎo)致算錯”持久性指的是“銀行說轉(zhuǎn)成功了哪怕下一秒機(jī)房斷電這筆記錄也不能消失”。關(guān)鍵在于這四個性質(zhì)在業(yè)務(wù)層同樣成立。一次下單要扣庫存、生成訂單、發(fā)券、記流水這四步如果只成了兩步就是原子性被破壞兩個用戶搶最后一件庫存都顯示成功就是隔離性沒做好接口返回成功但消息沒發(fā)出去用戶看不到訂單就是持久性在業(yè)務(wù)語義上失守。把 ACID 當(dāng)成思維模型而不是數(shù)據(jù)庫參數(shù)你對“這次操作到底該放在一個事務(wù)里還是該拆開補(bǔ)償”的判斷會清晰很多。2.4 三條線合起來看它們都在給“不確定性”上鎖單獨(dú)看SRP 是模塊級的約束第一性是思考方法ACID 是數(shù)據(jù)層的約束好像不搭。但放到一個真實(shí)項(xiàng)目里它們其實(shí)是在給三種不同的不確定性上鎖需求會變所以要用 SRP 把變化圈在一個小范圍里別讓一次改動擴(kuò)散出去、信息不完整所以要用第一性把已知事實(shí)擺清楚別在假設(shè)上蓋樓、系統(tǒng)會出故障所以要用 ACID 保證出錯的時候狀態(tài)是可解釋、可恢復(fù)的。這三件事有一個共同特征它們都是“事前”的工作做完之后看不見摸不著但省下的是“事后”的巨額成本。改一處崩三處的項(xiàng)目排查一次線上資損事故的成本折算成人力往往夠重寫半個模塊了。3. 單一職責(zé)怎么落地從“上帝類”到能改得動的模塊道理都懂難的是手上這個兩千行的類怎么動手。我這幾年拆過七八個類似的模塊有幾個做法是可以直接復(fù)用的。3.1 先識別職責(zé)過載的四個信號別憑感覺判斷看信號。我總結(jié)下來有四個命中兩個以上基本就該動手了。第一個信號是測試成本異常。你想給某個方法寫個單元測試結(jié)果要 mock 掉五個依賴、準(zhǔn)備三份測試數(shù)據(jù)寫完發(fā)現(xiàn)測試代碼比被測代碼還長。這說明這個方法牽連的東西太多職責(zé)邊界早就糊了。第二個信號是命名里出現(xiàn)連接詞。OrderManager、DataUtil、CommonHelper、XxxAndYyyService這些名字本身就是投降聲明——作者已經(jīng)說不清它到底負(fù)責(zé)什么了。名字里帶“Manager”“Util”“Common”的類十個里有八個是垃圾桶。第三個信號是不同角色在改同一個文件。去看提交記錄如果同一個文件最近的提交者里有做訂單的、做財(cái)務(wù)的、做營銷的而且改的是不同區(qū)塊那這就是職責(zé)過載的鐵證。代碼的變更歷史比代碼本身更能說明問題。第四個信號是改一個需求要動多個不相關(guān)的地方。比如“會員折扣規(guī)則調(diào)整”這么一個需求你要改算價、改下單校驗(yàn)、改退款重算、改報(bào)表口徑四個地方分散在三個文件里改完還得祈禱沒漏。這種情況說明“定價”這個職責(zé)被切碎撒到各處了跟職責(zé)過載是一體兩面。3.2 按“變更來源”切不按“技術(shù)分層”切拆的時候最容易犯的錯是按技術(shù)分層拆把數(shù)據(jù)庫操作抽到 Repository把校驗(yàn)抽到 Validator把組裝抽到 Converter。拆完之后文件是變小了但一次業(yè)務(wù)變更仍然要橫跨五個文件改一遍因?yàn)檫@些層都是同一條業(yè)務(wù)鏈路的切片它們共享同一個變更理由。正確的切法是按變更來源切。還是拿訂單舉例我先畫一張表把這個模塊所有邏輯列出來標(biāo)上“誰會來改它”邏輯塊變更來源變更頻率是否獨(dú)立上線下單校驗(yàn)、創(chuàng)建訂單交易產(chǎn)品高是算價、優(yōu)惠疊加營銷產(chǎn)品很高是支付回調(diào)處理支付渠道對接中是退款、售后客服與財(cái)務(wù)中是對賬、報(bào)表口徑財(cái)務(wù)結(jié)算低但影響大是表格一拉出來答案就明擺著了這五塊是五個獨(dú)立的變更源應(yīng)該拆成五個模塊各自有獨(dú)立的接口、獨(dú)立的數(shù)據(jù)訪問、獨(dú)立的上線節(jié)奏。拆完之后算價規(guī)則再變也碰不到退款那段代碼我開頭遇到的那種事故從結(jié)構(gòu)上就被排除了。3.3 一段拆分前后的對照拆之前大概長這樣一個方法包辦到底class OrderService: def create_order(self, user_id, items, coupon_id): # 1. 校驗(yàn) if not items: raise ValueError(empty) user db.query_user(user_id) if user.status ! active: raise ValueError(inactive) # 2. 算價含會員價、券、階梯價200 行 total 0 for it in items: price db.query_price(it.sku) if user.level vip: price price * 0.95 total price * it.qty if coupon_id: coupon db.query_coupon(coupon_id) total total - coupon.amount # 3. 扣庫存 落單 發(fā)券 發(fā)通知 db.deduct_stock(items) order_id db.insert_order(user_id, items, total) db.mark_coupon_used(coupon_id) mq.send(order_created, order_id) return order_id拆之后每個類只對一個變更源負(fù)責(zé)class OrderValidator: 只因?yàn)椤合聠螠?zhǔn)入規(guī)則變化』而修改 def check(self, user, items): if not items: raise DomainError(EMPTY_ITEMS) if user.status ! active: raise DomainError(USER_INACTIVE) class PriceCalculator: 只因?yàn)椤憾▋r與優(yōu)惠策略變化』而修改 def calc(self, user, items, coupon): ... class OrderRepository: 只因?yàn)椤捍鎯Y(jié)構(gòu)或訪問方式變化』而修改 def save(self, order): ... def deduct_stock(self, items): ... class OrderCreatedNotifier: 只因?yàn)椤和ㄖ阑蛭陌缸兓欢薷?def notify(self, order_id): ... class CreateOrderUseCase: 編排只因?yàn)椤合聠瘟鞒滩襟E變化』而修改 def __init__(self, validator, pricer, repo, notifier): self.validator, self.pricer validator, pricer self.repo, self.notifier repo, notifier def execute(self, user, items, coupon): self.validator.check(user, items) amount self.pricer.calc(user, items, coupon) order_id self.repo.save_with_stock(user, items, amount) self.notifier.notify(order_id) return order_id注意CreateOrderUseCase這一層是必要的它負(fù)責(zé)“流程編排”。很多人拆完之后把編排邏輯也拆沒了結(jié)果調(diào)用方要自己按順序調(diào)五個對象漏一步就出錯——那是拆過頭了。3.4 拆過頭的三個坑我全踩過第一個坑是鏈路斷裂。拆得太碎一個新同事想搞懂“下單到底發(fā)生了什么”要跳八個文件每個文件都只看到局部。我的應(yīng)對是保留一個薄薄的編排層并且在編排層寫上完整的流程注釋讓人從入口一眼看到全貌想深入再看細(xì)節(jié)。第二個坑是為了單一而造轉(zhuǎn)發(fā)層。曾經(jīng)有個項(xiàng)目里出現(xiàn)了OrderService調(diào)OrderManager調(diào)OrderHandler調(diào)OrderProcessor四層全是透傳沒一行有實(shí)際邏輯。這種拆法只增加了導(dǎo)航成本。判斷標(biāo)準(zhǔn)很簡單一個類的方法如果全部只有一行轉(zhuǎn)發(fā)那它就不該存在。第三個坑是按技術(shù)拆而不是按業(yè)務(wù)拆。我前面說過這里再強(qiáng)調(diào)一次因?yàn)樗Ｒ娏恕０研ｒ?yàn)拆成Validator、把計(jì)算拆成Calculator看起來很像 SRP但如果校驗(yàn)規(guī)則和計(jì)算規(guī)則永遠(yuǎn)同增同減、同一個產(chǎn)品經(jīng)理提需求那它們其實(shí)共享同一個變更理由拆開反而制造了耦合。注意事項(xiàng)拆分粒度用一句話衡量——一個熟悉業(yè)務(wù)的人能不能在半小時內(nèi)把這個模塊的職責(zé)、輸入、輸出、依賴講清楚。能就夠細(xì)了不能繼續(xù)拆拆完發(fā)現(xiàn)要講半小時才能串起一條鏈路說明拆錯了方向。4. 第一性原則怎么用把拍腦袋換成算一遍第一性原則聽著玄其實(shí)是個很機(jī)械的流程。我把它拆成五步每次做方案評審都按這個走能擋掉大部分“過度設(shè)計(jì)”和“跟風(fēng)選型”。4.1 五步倒推目標(biāo)、約束、假設(shè)、推導(dǎo)、驗(yàn)證第一步寫清目標(biāo)。注意是目標(biāo)不是手段?！白屜到y(tǒng)支持十萬用戶”是目標(biāo)嗎不是太模糊?！霸诜逯得棵雰砂俅握埱笙伦x接口 P99 延遲低于 200 毫秒”這才是目標(biāo)。第二步列出硬約束。硬約束是那些你改不了的事實(shí)預(yù)算上限、團(tuán)隊(duì)現(xiàn)有技術(shù)棧、上線時間點(diǎn)、數(shù)據(jù)合規(guī)要求、現(xiàn)有數(shù)據(jù)庫的能力邊界。硬約束越早擺出來越好因?yàn)榉桨缚臻g是被約束框出來的。第三步剔除假設(shè)。這一步最費(fèi)勁也最值錢。你要逼自己把“我們一直是這么做的”“行業(yè)里一般都用這個”這類句子劃掉只留下能被驗(yàn)證的事實(shí)。我常用一個提問法這句話如果被證明是錯的我們的方案會變嗎會變那它就是假設(shè)需要驗(yàn)證不會變那它無關(guān)緊要可以忽略。第四步從約束推導(dǎo)。有了目標(biāo)和事實(shí)方案通常只剩一兩個合理選項(xiàng)。這一步不需要靈感只需要算術(shù)。第五步驗(yàn)證最小可行。別一次上全套。先用最小的成本驗(yàn)證核心假設(shè)跑通了再加。這一步能救很多命——我見過太多方案在第四步推得頭頭是道第五步一壓測全崩。4.2 一個真實(shí)的容量估算比任何爭論都有說服力回到前面那個配置下發(fā)的例子我把算術(shù)過程寫完整你能看到第一性是怎么工作的。已知事實(shí)配置總量約兩千條每條平均 2KB總共約 4MB平均每天變更兩次客戶端三千臺業(yè)務(wù)能接受的配置生效延遲是 1 分鐘。推導(dǎo)三千臺客戶端每分鐘拉一次就是每分鐘三千次請求折合50 QPS。每次返回 4MB 的話總帶寬是 50 × 4MB 200MB/s這個就有點(diǎn)嚇人了。但注意配置大部分時間不變所以可以用版本號做條件請求——客戶端帶上本地版本號服務(wù)端發(fā)現(xiàn)沒變就返回 304實(shí)際響應(yīng)體接近零。這樣帶寬壓力基本消失50 QPS 對一個普通服務(wù)來說毫無壓力。最后方案單實(shí)例 本地文件 版本號條件請求配一個定時任務(wù)做變更推送的喚醒。整個實(shí)現(xiàn)不到兩百行沒有引入任何中間件。如果當(dāng)初按“配置中心都該用長連接推送”這個結(jié)論出發(fā)那就要維護(hù)連接數(shù)、心跳、斷線重連、灰度發(fā)布工作量翻十倍不止。4.3 成本也要算而且要算全生命周期選型時只看開發(fā)工作量是新手最容易掉的坑。我在做第一性推導(dǎo)時會強(qiáng)制加一張全周期成本表把三年內(nèi)的賬一起算成本項(xiàng)方案A自研簡單版方案B引入成熟中間件初期開發(fā)約 5 人日約 15 人日含部署調(diào)試學(xué)習(xí)曲線無純業(yè)務(wù)代碼團(tuán)隊(duì) 3 人各約 3 天運(yùn)維負(fù)擔(dān)復(fù)用現(xiàn)有服務(wù)幾乎為零新增集群、監(jiān)控、備份、升級故障排查自己寫的日志齊全需要理解內(nèi)部機(jī)制擴(kuò)展上限十萬級 QPS 以內(nèi)夠用更高但短期用不上三年總成本估算約 8 人日約 30 人日 持續(xù)運(yùn)維這張表不是為了證明“自研一定更好”而是讓決策顯性化。如果業(yè)務(wù)確實(shí)需要百萬級吞吐那方案 B 的額外成本就是必要投入如果只需要 50 QPS方案 B 的那二十多人日就是純浪費(fèi)。4.4 什么情況下別用第一性原則這點(diǎn)必須說清楚因?yàn)楹芏嗳藢W(xué)了第一性之后什么事都想從零推一遍效率反而低了。成熟標(biāo)準(zhǔn)方案直接抄。比如排序、哈希、基礎(chǔ)的 HTTP 服務(wù)框架、常見的鑒權(quán)流程這些是被無數(shù)人驗(yàn)證過的最優(yōu)解你從第一性推一遍大概率推不出更好的還容易推出 bug。強(qiáng)合規(guī)、強(qiáng)安全的領(lǐng)域別自作聰明。涉及資金結(jié)算、隱私數(shù)據(jù)處理的部分行業(yè)里有一套經(jīng)過審計(jì)的規(guī)范流程照著做就行。這時候“我重新想了一遍”不是優(yōu)點(diǎn)是風(fēng)險。時間成本高的時候先求有再求好。周一要上線周五你還在推第一性那是自找麻煩。第一性原則適合用在“這個決策會影響三年”的地方不適合用在“這個決策下周就可能改”的地方。判斷標(biāo)準(zhǔn)是這個選擇錯了返工成本有多高高值得推低先跑起來。5. ACID怎么延伸到業(yè)務(wù)層事務(wù)邊界是設(shè)計(jì)出來的數(shù)據(jù)層的事務(wù)數(shù)據(jù)庫幫你兜底業(yè)務(wù)層的事務(wù)得自己設(shè)計(jì)。這一塊做不好出的都是資損級別的事故。5.1 四個字母在業(yè)務(wù)代碼里的具體樣子原子性在業(yè)務(wù)里對應(yīng)的是“一組操作要么全做要么全不做”。下單場景扣庫存、建訂單、核銷優(yōu)惠券、記流水。這四步如果在同一個數(shù)據(jù)庫里一個本地事務(wù)就解決了如果庫存和訂單在不同服務(wù)里就得靠補(bǔ)償或者本地消息表。一致性是業(yè)務(wù)規(guī)則層面的不變量。比如“任何時刻所有賬戶余額之和加上在途資金等于總發(fā)行量”這是一條永遠(yuǎn)要成立的規(guī)則。它不靠數(shù)據(jù)庫的約束來保證靠的是你把所有會改余額的路徑都收攏到同一個入口并且在那里做校驗(yàn)。這就是 SRP 和 ACID 的交匯點(diǎn)——如果改余額的邏輯散落在五個地方一致性根本無從保證。隔離性在業(yè)務(wù)里是“并發(fā)操作不能互相污染”。最典型的兩個人同時下單最后一件庫存。數(shù)據(jù)庫層面靠行鎖或者樂觀鎖版本號解決業(yè)務(wù)層面還要考慮“用戶點(diǎn)了兩次提交”這種重復(fù)請求那是冪等問題不是隔離問題得分開處理。持久性在業(yè)務(wù)里是“承諾了就要兌現(xiàn)”。接口返回成功意味著后續(xù)所有異步流程發(fā)消息、發(fā)券、發(fā)通知都必須最終完成。這里最容易出事主流程提交成功消息發(fā)送失敗用戶看不到訂單。解決辦法是把“發(fā)消息”這個動作也納入事務(wù)——本地消息表就是干這個的消息先寫進(jìn)同一個庫的表中跟業(yè)務(wù)數(shù)據(jù)一個事務(wù)提交再由后臺任務(wù)掃表投遞。5.2 隔離級別的取舍別只記結(jié)論這一塊面試?？嫉嬲绊懢€上表現(xiàn)的是這四種隔離級別帶來的鎖行為和并發(fā)度差異隔離級別臟讀不可重復(fù)讀幻讀并發(fā)度適用場景讀未提交可能可能可能最高幾乎不用僅用于極端統(tǒng)計(jì)場景讀已提交不會可能可能高大多數(shù)業(yè)務(wù)查詢的默認(rèn)選擇可重復(fù)讀不會不會視實(shí)現(xiàn)而定中同一事務(wù)內(nèi)需要多次讀同一批數(shù)據(jù)串行化不會不會不會最低強(qiáng)一致要求的結(jié)算類操作選的時候不要背“默認(rèn)用可重復(fù)讀”這種結(jié)論問自己兩個問題這個事務(wù)里會不會多次讀同一行數(shù)據(jù)并依賴結(jié)果一致會就要可重復(fù)讀以上。這個事務(wù)的并發(fā)量有多大、持鎖時間有多長并發(fā)高、持鎖長就往低級別靠用應(yīng)用層的樂觀鎖替代數(shù)據(jù)庫鎖。5.3 長事務(wù)是性能殺手也是故障源我遇到過的數(shù)據(jù)庫告警一半以上跟長事務(wù)有關(guān)。長事務(wù)的危害是雙份的一是長時間持有鎖把其他請求堵在門外二是回滾段膨脹拖慢整個實(shí)例。常見的長事務(wù)來源有這么幾個。把外部調(diào)用放進(jìn)事務(wù)里——事務(wù)里調(diào)了一個第三方接口對方超時三十秒鎖就持有三十秒。把批量操作放進(jìn)一個事務(wù)——一次性更新一萬行看著優(yōu)雅實(shí)際把鎖的范圍拉得極大。事務(wù)里做了重計(jì)算——循環(huán)里算價格、算積分算了兩秒才提交。我的處理原則很直接事務(wù)里只放數(shù)據(jù)庫操作而且只放必須原子的那幾個。外部調(diào)用、消息發(fā)送、文件寫入全都挪到事務(wù)外面用補(bǔ)償或者消息表保證最終一致。批量操作拆成小批每批五百到一千條分批提交。# 反例事務(wù)里做外部調(diào)用 def pay_bad(order_id): with db.transaction(): order db.lock_order(order_id) resp http.post(https://payment.example/charge, {...}) # 可能超時 30s order.status paid db.save(order) # 正例外部調(diào)用挪出去用狀態(tài)機(jī) 冪等鍵保證一致 def pay_good(order_id, idempotency_key): order db.get_order(order_id) if order.status paid: return order # 冪等重復(fù)請求直接返回 if not db.try_mark_paying(order_id, idempotency_key): return db.get_order(order_id) # 已被其他請求搶占 resp http.post(https://payment.example/charge, {...}) if resp.ok: db.mark_paid(order_id, resp.txn_id) else: db.mark_pay_failed(order_id, resp.code)5.4 冪等做不好前面全白搭只要你的接口可能被重試——不管是用戶手抖點(diǎn)兩次、客戶端超時重發(fā)、還是消息隊(duì)列重復(fù)投遞——就必須做冪等。三種做法我都用過各有適用面。唯一鍵約束最省事也最可靠。給業(yè)務(wù)表加一個冪等鍵字段比如“訂單號 操作類型”加唯一索引重復(fù)插入直接報(bào)沖突捕獲了當(dāng)成成功返回。缺點(diǎn)是冪等鍵的生成規(guī)則要提前設(shè)計(jì)好事后加字段很痛苦。狀態(tài)機(jī)前置判斷適合有明確生命周期的東西。支付單的狀態(tài)是“待支付→支付中→已支付”任何一步都先查狀態(tài)不符合前置條件就拒絕。注意這里必須用UPDATE ... WHERE status 待支付這種帶條件的更新讓數(shù)據(jù)庫來保證原子性別用“先查后改”的兩步走法那在并發(fā)下必然出錯。去重表適合沒有天然唯一鍵的場景比如消息消費(fèi)。建一張表記錄已處理的消息 ID處理前先插插失敗就說明處理過了。這張表要定期清理不然會無限增長。注意事項(xiàng)冪等的有效期要跟業(yè)務(wù)對齊。支付類操作可能需要永久冪等而“查詢類”操作壓根不需要冪等。別一刀切給所有接口都加去重表那是給自己找麻煩。6. 三個原則落到安全、學(xué)習(xí)、節(jié)約上是什么樣前面講的是“怎么做”這一節(jié)講“為什么值得做”。這三個維度是我評估一個技術(shù)決策值不值的時候最常用的三個尺子。6.1 安全原則是炸不穿的那層殼安全這個詞在這里有兩層意思。一層是狹義的信息安全權(quán)限校驗(yàn)、數(shù)據(jù)脫敏、越權(quán)防護(hù)。另一層是廣義的系統(tǒng)安全故障不會擴(kuò)散一次失誤不會拖垮全局。單一職責(zé)在狹義安全上的價值特別直接。假如權(quán)限校驗(yàn)的邏輯散落在二十個接口里你幾乎不可能保證每一處都寫對了只要漏一處就是越權(quán)漏洞。正確的做法是把校驗(yàn)收攏到一個入口網(wǎng)關(guān)或者統(tǒng)一攔截器讓“校驗(yàn)”成為一個只有單一職責(zé)的組件所有請求必須經(jīng)過它。這樣你要審計(jì)的只有一個地方。這就是為什么安全規(guī)范里總強(qiáng)調(diào)“統(tǒng)一入口”——不是官僚主義是把攻擊面收窄。ACID 在資金類業(yè)務(wù)里就是安全本身。原子性保證不會出現(xiàn)“扣了錢沒加錢”持久性保證“說成功了就一定成功”。這類系統(tǒng)里為了性能犧牲這些性質(zhì)的方案我一般直接否掉因?yàn)橐淮问鹿实拇鷥r遠(yuǎn)超性能收益。第一性原則在安全上的用法稍微繞一點(diǎn)但很有用它能幫你識別“看起來有必要其實(shí)沒必要”的安全措施。比如有人提議給所有接口加簽名校驗(yàn)理由是“更安全”。用第一性拆一下這個接口是內(nèi)網(wǎng)調(diào)用還是公網(wǎng)暴露調(diào)用方是不是只有固定的兩個服務(wù)如果只在內(nèi)網(wǎng)、調(diào)用方固定那簽名帶來的收益很小反而增加密鑰輪轉(zhuǎn)的運(yùn)維負(fù)擔(dān)。真正的風(fēng)險點(diǎn)可能在別處——比如這個接口有沒有做入?yún)㈤L度限制、會不會被用來做資源耗盡。6.2 學(xué)習(xí)用第一性原則搭骨架用單一職責(zé)管節(jié)奏學(xué)技術(shù)最容易陷入的狀態(tài)是“收藏了一堆文章一個都用不上”。原因是從結(jié)論入手——學(xué)了某個框架的用法但不知道它解決什么問題。我的做法是先問“這個東西沒出現(xiàn)之前人們怎么解決的痛點(diǎn)在哪”。比如學(xué)消息隊(duì)列先搞清楚沒有它的時候服務(wù)之間靠什么通信、會遇到什么問題同步調(diào)用鏈太長、高峰期扛不住、一個服務(wù)掛了拖垮上游。把痛點(diǎn)想透了再看消息隊(duì)列提供了什么異步解耦、削峰填谷、廣播。這時候它那些概念Topic、分區(qū)、消費(fèi)組、offset就不是名詞背誦而是“為了解決某個具體問題引入的機(jī)制”記起來毫不費(fèi)力。單一職責(zé)在學(xué)習(xí)節(jié)奏上的用法是一次只攻一個方向。我見過太多人同時學(xué)三門語言、兩個框架、一套云原生結(jié)果每樣都停在“會寫 Hello World”。按 SRP 的思路你某個階段的學(xué)習(xí)目標(biāo)應(yīng)該只有一個變更理由——“我要能獨(dú)立寫一個帶鑒權(quán)的增刪改查服務(wù)”這個目標(biāo)達(dá)成就停下來復(fù)盤再進(jìn)下一個。學(xué)習(xí)計(jì)劃里出現(xiàn)“同時學(xué)習(xí) A 和 B”這種表述基本都會失敗。ACID 對學(xué)習(xí)也有一層很妙的類比尤其是持久性。學(xué)的東西如果不落盤——不寫成筆記、不寫成代碼、不寫成可復(fù)現(xiàn)的 demo——它就像沒提交的事務(wù)隨時會丟。我的習(xí)慣是每學(xué)一個新東西強(qiáng)制產(chǎn)出一個最小可運(yùn)行的樣例放在自己的代碼庫里標(biāo)注“解決什么問題、關(guān)鍵配置是什么、踩了什么坑”。這玩意兒攢兩年就是自己的知識庫比任何收藏夾都值錢。6.3 節(jié)約省的是人力、算力、還有注意力節(jié)約這個詞容易被理解成“摳門”其實(shí)它指的是不浪費(fèi)。三個原則各自省的是不同的東西。單一職責(zé)省的是變更成本。這個收益是復(fù)利的一個邊界清晰的模塊改一次的成本是一一個邊界模糊的模塊改一次要通讀兩千行、要跑全量回歸、要擔(dān)心副作用成本是十。一年改二十次差距是多少不用算。而且這里還有個隱性收益——新人上手成本。邊界清晰的模塊新人兩天能改不清晰的兩周都不敢動。第一性原則省的是過度設(shè)計(jì)。前面那個配置下發(fā)的例子算一遍省掉二十多個人日。這類節(jié)省在很多項(xiàng)目里都存在只是沒人算過。我建議每個方案評審都強(qiáng)制帶一段“容量與成本估算”哪怕只有三行數(shù)字。養(yǎng)成這個習(xí)慣之后團(tuán)隊(duì)里“上來就要集群、就要中間件”的聲音會自然消失因?yàn)橐凰憔吐娥W了。ACID省的是故障處理成本。這個最容易被低估。一次數(shù)據(jù)不一致的事故處理成本包括定位幾小時到幾天、修數(shù)要寫腳本、要雙人校驗(yàn)、要留審計(jì)、用戶補(bǔ)償、后續(xù)的信任修復(fù)。相比之下把事務(wù)邊界設(shè)計(jì)對的成本可能只是多寫二十行代碼。這個投入產(chǎn)出比在任何項(xiàng)目里都是最高的。6.4 三者沖突的時候怎么排優(yōu)先級現(xiàn)實(shí)里一定會有沖突。為了節(jié)約成本少做校驗(yàn)安全就打折為了學(xué)習(xí)新技術(shù)引入復(fù)雜方案就違背節(jié)約為了趕進(jìn)度跳過拆分就把變更成本推給未來。我的排序是安全 節(jié)約 學(xué)習(xí)但這個排序有前提——這里的“安全”指的是不可逆的損失比如資金錯誤、數(shù)據(jù)泄露、用戶權(quán)益受損。這類事情發(fā)生了沒法回滾所以優(yōu)先級最高。節(jié)約排第二是因?yàn)樗绊懙氖强沙掷m(xù)性。一個長期虧錢的系統(tǒng)技術(shù)再優(yōu)雅也活不下來。學(xué)習(xí)排最后不是說學(xué)習(xí)不重要而是學(xué)習(xí)成本不該由生產(chǎn)系統(tǒng)承擔(dān)。想試新技術(shù)可以在旁路項(xiàng)目、內(nèi)部工具、灰度環(huán)境里試別拿核心鏈路當(dāng)試驗(yàn)田。我見過拿主站練手的出了事故之后再也沒人敢提“技術(shù)升級”這四個字反而把整個團(tuán)隊(duì)的技術(shù)迭代能力凍住了。7. 常見問題與排查技巧實(shí)錄下面這些是我和身邊同行真遇到過的問題按癥狀整理成速查表遇到類似情況可以直接對照。癥狀大概率原因排查動作處理方式改 A 功能導(dǎo)致 B 功能崩職責(zé)耦合共用私有方法看 B 的調(diào)用鏈?zhǔn)欠翊┻^ A抽出共用部分明確接口邊界一個類改一次要跑全量回歸變更影響面不可控用提交記錄看該文件的修改者分布按變更來源拆分模塊事務(wù)超時、連接池被打滿長事務(wù)持有鎖查慢事務(wù)日志看事務(wù)內(nèi)是否有外部調(diào)用外部調(diào)用挪出事務(wù)批量拆小用戶被重復(fù)扣款接口缺冪等查請求日志是否有重復(fù)入?yún)⒓游ㄒ绘I或狀態(tài)機(jī)前置判斷并發(fā)下庫存超賣隔離性不足看扣減語句是否帶條件更新改條件更新或加樂觀鎖版本號接口返回成功但用戶看不到數(shù)據(jù)主流程與異步流程不一致查消息是否投遞成功本地消息表 定時補(bǔ)償方案越做越復(fù)雜工期一再延沒做容量估算按結(jié)論選型補(bǔ)一份目標(biāo)與約束清單用最小可行方案先跑通拆完模塊反而更難維護(hù)按技術(shù)分層拆而非按變更源拆數(shù)一條業(yè)務(wù)鏈路要跨幾個文件按變更源重新劃分新人一周都不敢改代碼缺乏清晰的模塊職責(zé)說明看模塊是否有單一入口收斂入口補(bǔ)流程注釋7.1 三個不寫在文檔里的排查心得第一個先看提交歷史再看代碼。代碼只告訴你“現(xiàn)在是什么”提交歷史告訴你“為什么會變成這樣”。一個文件如果被五個人反復(fù)改而且每次改動都很小很碎那它的問題一定不是代碼質(zhì)量問題是職責(zé)劃分問題。改代碼解決不了得改結(jié)構(gòu)。第二個用“畫一條鏈路”的辦法定位耦合。拿一張紙從請求入口開始把經(jīng)過的每個方法畫出來。如果這條線穿過五個以上的類、跨越三個業(yè)務(wù)概念那就是耦合過重。這個動作我做過很多次畫到一半就能看出來問題在哪。第三個修復(fù)數(shù)據(jù)事故之前先想清楚怎么防止它再發(fā)生。線上數(shù)據(jù)錯了第一反應(yīng)是寫腳本修數(shù)這沒錯但修完就完事的話下周還會再來一次。修數(shù)腳本和防重腳本應(yīng)該同時寫。7.2 我自己的月度自查清單每個月我會花半小時過一遍手上的模塊問自己五個問題這個月改得最多的那個文件它的變更來源是幾個如果超過兩個下個月排期拆。有沒有哪個接口的響應(yīng)時間在悄悄變長如果有是有慢查詢還是有外部依賴。有沒有哪個流程的事務(wù)邊界是“順手加的”而不是設(shè)計(jì)出來的有沒有哪個方案是“因?yàn)閯e人都這么做”而選定的如果有補(bǔ)一份估算。有沒有哪個模塊我已經(jīng)不敢在沒測試的情況下改了最后一問最靈。當(dāng)你對某個模塊產(chǎn)生“不敢動”的恐懼時那地方一定有問題而且問題通常不是技術(shù)難度是結(jié)構(gòu)混亂。注意事項(xiàng)以上所有做法都有一個共同前提——你得先承認(rèn)自己的代碼會爛。抱著“我這套設(shè)計(jì)能撐十年”的心態(tài)什么原則都救不了。原則的作用是讓系統(tǒng)爛得慢一點(diǎn)讓修補(bǔ)的成本低一點(diǎn)僅此而已。最后分享一個我自己一直在用的笨辦法每次做完一個模塊我會在文件頂部寫三行注釋——這個模塊負(fù)責(zé)什么、它在什么情況下會被修改、它依賴誰。三行寫不出來說明這個模塊我自己都沒想清楚那就別急著提交先想明白。這個習(xí)慣堅(jiān)持了幾年最大的收獲不是代碼變好看了而是每次需求來的時候我能在一分鐘內(nèi)判斷出這次改動會波及哪里、要不要提前拆。這種“心里有數(shù)”的感覺比任何設(shè)計(jì)模式都值錢。