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