Spring 面經(jīng)系列 · 第 8 篇微服務(wù)架構(gòu)、注冊/配置/網(wǎng)關(guān)、限流熔斷降級與 Seata 分布式事務(wù)簡歷上寫了「微服務(wù)」面試就會收到一串連環(huán)問為什么要拆拆了之后不是問題更多一個服務(wù)掛掉為什么整條鏈路都死跨服務(wù)下單錢扣了貨沒發(fā)出事務(wù)怎么辦線上報錯你怎么知道是哪個服務(wù)出的這些問題看著是七道題其實是一條因果鏈——拆分換來了效率效率帶來了依賴依賴帶來了雪崩風(fēng)險風(fēng)險帶來了防護組件防護和一致性又帶來了注冊中心、配置中心、網(wǎng)關(guān)、熔斷、分布式事務(wù)、鏈路追蹤這一整套技術(shù)棧。本文把 13 個分 PP65P77按這條因果鏈串起來。素材是語音轉(zhuǎn)寫同音錯字密集Nacos寫成「NEO」、Seata寫成「theta」、Sentinel寫成「森林nail」、IRule寫成「ERROLL」、undo_log寫成「安 do log」我按術(shù)語還原。這套題數(shù)字特別多——Nacos 心跳閾值、Ribbon 默認(rèn)策略、Seata 的默認(rèn)處置——視頻全是口述凡我沒對照到官方原文的都標(biāo)了未核實別當(dāng)背書材料當(dāng)提問預(yù)警用。1. 單體、分布式、SOA、微服務(wù)先把四個詞放對位置P66 這道題很多同學(xué)是糊的視頻作者給的歸位方式很直接分布式是上位概念——把一個應(yīng)用拆成多塊、部署在不同服務(wù)器上組成一個應(yīng)用就叫分布式SOA 和微服務(wù)都滿足這個特性所以兩者都屬于分布式架構(gòu)。拆到不同服務(wù)器后分布式緩存、分布式事務(wù)、分布式 ID 與跨節(jié)點一致性問題隨之而來這是分布式這一層的共同代價。兩者的區(qū)別作者給了一個適合面試直接用的記憶法概念視頻作者的口徑拆分程度治理組件分布式架構(gòu)應(yīng)用拆成多塊部署在不同服務(wù)器——SOA面向服務(wù)服務(wù)注冊在「總線」上調(diào)用時從總線查找可理解成「微服務(wù)的不完整形態(tài)」說白了就是只有一個注冊中心的微服務(wù)架構(gòu)較粗基本只有服務(wù)注冊微服務(wù)各功能抽成更小、更徹底的服務(wù)細(xì)注冊中心、配置中心、網(wǎng)關(guān)、遠(yuǎn)程調(diào)用、容錯熔斷一整套打個補丁「SOA 只有一個注冊中心的微服務(wù)」是作者的私人簡化SOA 常配的 ESB 服務(wù)總線他一句帶過——夠用但別當(dāng)學(xué)術(shù)定義。P65 問「你們?yōu)槭裁匆梦⒎?wù)」作者先糾正前提微服務(wù)基本都是從單體演變來的——單體為省成本而生業(yè)務(wù)量漲上來、代碼難動了才拆一上來就上微服務(wù)的極少業(yè)務(wù)沒成型就拆基本是自找麻煩?；卮鹨催@個敘事走結(jié)合自己項目講每點兩三條就夠別背概念清單。維度單體下的痛視頻描述拆分換來什么開發(fā)效率幾十人一個代碼庫、啟動極慢作者說迭代三四年的項目啟動一次「夠出去抽根煙」次日都不敢關(guān)機服務(wù)小起得快發(fā)布敏捷性提前上線一個模塊會被別人未完成的改動卡住只能開分支最后合并每個服務(wù)獨立發(fā)布迭代分工與成長新人必須把全應(yīng)用技術(shù)棧本地搭一遍改一處牽全身23 人一個服務(wù)專人專攻并發(fā)或存儲容易成領(lǐng)域?qū)＜壹夹g(shù)多樣性一個應(yīng)用基本一套棧業(yè)務(wù)收縮時非主力語言作者舉 PHP、.NET的程序員容易流失各服務(wù)可用不同語言框架存儲統(tǒng)一傳輸協(xié)議REST 或 RPC即可擴容與資源并發(fā)上來只能整體集群低并發(fā)模塊白耗資源也難壓出單模塊水位只給高并發(fā)服務(wù)擴容單服務(wù)壓測出準(zhǔn)確水位維護與責(zé)任老系統(tǒng)人員換幾茬老代碼沒人敢動出錯追責(zé)追不準(zhǔn)按業(yè)務(wù)模塊拆責(zé)任邊界隨服務(wù)縮小容錯一次內(nèi)存溢出OOM整個應(yīng)用不可用弱依賴如積分掛了直接熔斷隔離下單主流程照常后期補償擴展技術(shù)升級基本沒機會嫌哪個服務(wù)技術(shù)老舊再拆一個出來用新技術(shù)重寫付出什么P65 后半微服務(wù)本質(zhì)是分布式系統(tǒng)分布式問題全家桶抬高開發(fā)者門檻事務(wù)很難保證最終一致性只能盡量運維復(fù)雜度飆升——作者經(jīng)驗值單體 10、微服務(wù) 100、上了容器化降到 50仍遠(yuǎn)高于單體接口有依賴改格式可能牽連一片作者認(rèn)為靠約定可避免各服務(wù)獨立導(dǎo)致公共類重復(fù)勞動。最大的兩個坑是開發(fā)門檻和運維難度。一句話理解微服務(wù)是用「系統(tǒng)級復(fù)雜度」換「小塊獨立變更的自由」換得值不值看業(yè)務(wù)量和團隊配套。2. 微服務(wù)怎么拆原則、時機、演進節(jié)奏P67 拆成「怎么拆」和「什么時候拆」兩問。怎么拆作者給三點原則原則展開高內(nèi)聚、低耦合、職責(zé)單一職責(zé)隔離盡量減少強依賴與循環(huán)依賴——是「盡量」零依賴不可能粒度適中一個接口一個服務(wù)太細(xì)一個表一個服務(wù)能做但初期別這樣。初期以業(yè)務(wù)模型切入、按功能模塊產(chǎn)品、用戶、訂單垂直拆分漸進式演進從幾個、十幾個到幾十上百個慢慢來團隊、工具、監(jiān)控、治理配套要跟著節(jié)奏走配套跟不上拆得越細(xì)越是一場災(zāi)難拆的過程躲不開一串工程問題注冊發(fā)現(xiàn)編排、數(shù)據(jù)庫拆分、分布式技術(shù)落地、鏈路壓測、追蹤、統(tǒng)一日志、配置中心、熔斷降級、MQ 設(shè)計、前后端分離——只能演進著補齊不可能學(xué)一套框架就全塞進來。演進階段他畫了一條線階段引入什么作者說的現(xiàn)狀0.5單體剛拆成幾個、十來個服務(wù)過渡期1.0只上注冊發(fā)現(xiàn)拆分初期建議到這就夠1.5往服務(wù)治理過渡轉(zhuǎn)型中的傳統(tǒng)企業(yè)領(lǐng)頭羊多在這2.0熔斷、降級、治理 完整鏈路追蹤與監(jiān)控大部分互聯(lián)網(wǎng)企業(yè)處于這個階段3.0Service Mesh 服務(wù)網(wǎng)格一線互聯(lián)網(wǎng)公司在嘗試什么時候拆四條預(yù)估業(yè)務(wù)飛速增長、快到瓶頸就提前拆撞上瓶頸再拆就晚了架構(gòu)設(shè)計需要大量異構(gòu)技術(shù)棧起初就判斷業(yè)務(wù)復(fù)雜、流量大、基礎(chǔ)設(shè)施成熟可以一起手微服務(wù) 1.0先只上注冊發(fā)現(xiàn)最大前提是成本——人力硬件時間投入都大沒成本別拆。我的補充四條里最容易被追問「數(shù)據(jù)庫怎么拆」視頻只點了題簡歷寫了拆分的話得自己備好表歸屬、跨庫查詢、跨庫事務(wù)三小問。3. 八個常用組件與一次請求的完整路徑P68 只要真學(xué)過都能說幾個作者的貢獻是把「每個組件堵哪個窟窿」講清了組件堵的窟窿作者點名的產(chǎn)品與推薦注冊中心手工維護提供者地址機器一遷移就全廢按服務(wù)名拉列表下線與擴容動態(tài)感知。定位最核心沒有它基本微服務(wù)都撐不起來Eureka作者稱「已閉園」不推薦見事實說明、Nacos客戶端負(fù)載均衡器拉回來的是集群如訂單 3 實例調(diào)用得分發(fā)消費者自己就是客戶端所以在客戶端做Ribbon作者先說它仍活躍可用又說 Spring Cloud LoadBalancer 更強大、最終推薦后者原話繞按現(xiàn)狀整理服務(wù)調(diào)用手寫 RestTemplate 調(diào) REST 不夠優(yōu)雅要像調(diào)本地方法一樣調(diào)遠(yuǎn)程FeignNetflix不推薦、OpenFeign、Dubbo RPC配置中心成百上千個服務(wù)各有各的配置沒法各自維護Spring Cloud Config、Nacos 自帶用它家注冊就順手用它家配置熔斷降級單個服務(wù)掛掉不拖垮應(yīng)用激增流量不打垮系統(tǒng)Hystrix作者稱已退役、Sentinel推薦但他稱「完整版要用阿里付費的那個」存疑分布式事務(wù)拆分后本地事務(wù)管不了跨服務(wù)一致性Seata服務(wù)網(wǎng)關(guān)統(tǒng)一入口把鑒權(quán)、日志、限流、路由、跨域等與業(yè)務(wù)無關(guān)的公共邏輯收口Zuul作者稱「一和二」、Spring Cloud Gateway推薦、Envoy轉(zhuǎn)寫作「link id」、Kong鏈路追蹤快速定位出問題的服務(wù)、實時看健康狀況、協(xié)助快速恢復(fù)本 P 只講作用工具在 P75 展開作者給網(wǎng)關(guān)的比喻是小區(qū)門衛(wèi)限流是統(tǒng)一通知門衛(wèi)請求日志是登記鑒權(quán)是決定今天見誰跨域整個小區(qū)統(tǒng)一做。一次下單請求穿過這些組件的路徑我按視頻內(nèi)容重畫成橫版調(diào)用主路徑 客戶端 ──HTTP──? 服務(wù)網(wǎng)關(guān) ──? 商品服務(wù) ──Ribbon按服務(wù)名──? 訂單服務(wù) ──? 庫存服務(wù) 鑒權(quán)/限流/日志/ (防護組件包住 (XID 沿鏈路傳播, 跨域/路由轉(zhuǎn)發(fā) 下游弱依賴) 分支注冊全局鎖) │ └──? 積分服務(wù)弱依賴熔斷隔離失敗走降級事后補償 旁路支撐每個服務(wù)實例都要發(fā)生 服務(wù)實例 ──①注冊/心跳/主動注銷──? 注冊中心(Nacos Server) 服務(wù)實例 ?─②定時拉取健康列表──── 注冊中心 服務(wù)實例 ?─③長輪詢拉取配置────── 配置中心(Nacos) 各微服務(wù) ──④分支注冊/上報──────? Seata TC全局決議提交或回滾 整條鏈路 ──⑤埋點上報──────────? 鏈路追蹤SkyWalking一句話理解這八件套注冊中心管「找得到」負(fù)載均衡管「分得勻」遠(yuǎn)程調(diào)用管「調(diào)得優(yōu)雅」配置中心管「改得快」網(wǎng)關(guān)管「進得來」熔斷限流管「死不了」分布式事務(wù)管「賬得平」鏈路追蹤管「查得著」——每個組件都在給拆分挖的窟窿打補丁。4. 注冊中心、配置中心、網(wǎng)關(guān)三個基礎(chǔ)設(shè)施分別怎么答4.1 注冊中心的核心功能P69作者開場先提醒答這題前先確認(rèn)你說的是哪個注冊中心各家實現(xiàn)有差異Eureka 自我保護、Consul 本 P 都沒提但核心一致他以 Nacos 為例。功能清單功能機制視頻口徑他給的默認(rèn)值服務(wù)注冊服務(wù)啟動時通過 REST 接口向 Nacos Server 注冊例一個訂單 兩個庫存實例—心跳保活Nacos 客戶端維持定時心跳證明「我可用」防止被剔除每 5 秒一次不健康標(biāo)記服務(wù)端超 15 秒沒收到心跳把健康狀態(tài)置 false拉取時跳過它但實例還在15 秒剔除客戶端超 30 秒沒發(fā)心跳服務(wù)端直接剔除實例30 秒服務(wù)發(fā)現(xiàn)客戶端有定時任務(wù)持續(xù)去服務(wù)端拉取健康實例列表—主動注銷服務(wù)停止時客戶端主動發(fā) REST 注銷請求摘掉自己—Q1為什么 15 秒只標(biāo)記不健康30 秒才真剔除轉(zhuǎn)寫沒講原因。按機制推斷筆者判斷這 1530 秒緩沖是留給「網(wǎng)絡(luò)抖一下、GC 停一下」的余量一次心跳丟失就刪實例調(diào)用鏈會被誤殺抖動。版本邊界必須交代這組「5 / 15 / 30 秒」是口述值與社區(qū)文章對 Nacos 1.x HTTP 心跳的描述一致但本次未核到官方文檔原文且 2.x 起臨時實例據(jù)稱改走 gRPC 長連接、不再套這組參數(shù)——均未核實。穩(wěn)妥答法是先講「注冊、心跳、發(fā)現(xiàn)、注銷」四個功能參數(shù)說「以 1.x 默認(rèn)值為例細(xì)節(jié)以版本文檔為準(zhǔn)」。4.2 談?wù)勁渲弥行腜70「談?wù)?XX」這種開放題作者要求應(yīng)用、優(yōu)點、原理三層都備著答完應(yīng)用會被追原理。配置中心解決什么三個痛點全對著「本地配置文件」開火維護性差——所有服務(wù)連同一臺 Redis它一遷移涉及的服務(wù)都得挨個改配置實時性差——改完要重啟重啟這一臺的工夫別的還沒重啟存在不一致窗口只能靠「改完瞬間全部感知」來盡量保一致安全性差——賬號密碼躺在本地配置里人人可見作者的「刪庫跑路」表述。典型內(nèi)容數(shù)據(jù)庫連接地址遷移時只改一處、實例實時拉取、緩存連接地址與賬號密碼等敏感信息、動態(tài)參數(shù)——客戶端超時、限流規(guī)則、降級開關(guān)、按地區(qū)或時段的功能開關(guān)雙 11 前切高配 Redis、打開限流過了再關(guān)。集中配置改一處即實時生效傳統(tǒng)文件做不到這個響應(yīng)速度。原理層作者把所有配置中心的取數(shù)方式歸成兩類——服務(wù)端推和客戶端拉——然后說 Nacos 用拉客戶端配了監(jiān)聽器監(jiān)聽器結(jié)合定時任務(wù)內(nèi)部是個長輪詢的緩存池拿本地緩存配置的 MD5與服務(wù)端比對不一致就說明配置變了拉回新配置存入本地緩存、重算 MD5、觸發(fā)監(jiān)聽器回調(diào)刷新服務(wù)配置。Q2推不是更實時嗎為什么用拉作者的賬100 個服務(wù)接配置中心用推則配置一變服務(wù)端要挨個通知 100 個客戶端壓力全在中心側(cè)還得靠心跳維持每條連接有效用拉把壓力攤到每個客戶端各發(fā)各的 HTTP 定時請求服務(wù)端輕得多。補一個術(shù)語坑Nacos 配置中心的官方機制通常被描述為長輪詢——客戶端請求掛起在服務(wù)端有變化立刻返回語義介于推和拉之間作者口述成「定時拉取 MD5 對比」不完全等價未核對原文未核實。簡歷寫 Spring Cloud Config 或 Apollo 的各自同步機制自己再備一份。4.3 服務(wù)網(wǎng)關(guān)可以做什么P71這題比上一道友好但作者給的答法仍是先分類再列舉——把網(wǎng)關(guān)分成流量網(wǎng)關(guān)和業(yè)務(wù)網(wǎng)關(guān)這一下就和背清單的拉開差距分類職責(zé)邊界功能清單作者口徑流量網(wǎng)關(guān)與業(yè)務(wù)系統(tǒng)、內(nèi)部服務(wù)完全無關(guān)全局性流控、日志統(tǒng)計、安全策略、統(tǒng)一跨域業(yè)務(wù)網(wǎng)關(guān)與業(yè)務(wù)、內(nèi)部服務(wù)有關(guān)聯(lián)部署在業(yè)務(wù)服務(wù)前面、流量網(wǎng)關(guān)后面服務(wù)級流控、降級與熔斷、內(nèi)部路由、負(fù)載均衡、服務(wù)過濾與聚合、權(quán)限驗證/鑒權(quán)、業(yè)務(wù)規(guī)則、參數(shù)校驗網(wǎng)關(guān)可以不止一道大型系統(tǒng)會把流量網(wǎng)關(guān)和業(yè)務(wù)網(wǎng)關(guān)分成好幾道系統(tǒng)不大就合進一個做——第 3 章門衛(wèi)比喻里的限流、登記、鑒權(quán)、跨域正對進這兩類。5. 雪崩、限流、熔斷、降級一條因果鏈四個詞外加 RibbonP72、P73、P76 本質(zhì)是同一條鏈先有被拖死的機制雪崩才有三種自救手段限流、熔斷、降級調(diào)用往哪個實例去則由負(fù)載均衡決定。雪崩過程作者的電商場景秒殺并發(fā)激增 → 積分服務(wù)被打掛 → 商品服務(wù)調(diào)它遲遲無響應(yīng)、線程池打滿被拖垮 → 訂單服務(wù)同樣堆積被拖垮 → 共享服務(wù)把不可用逐級擴散 → 整個應(yīng)用不可用。定義因服務(wù)提供者的不可用導(dǎo)致服務(wù)調(diào)用者的不可用并且逐漸放大。作者稱它是「導(dǎo)致服務(wù)不可用的最大元兇」。解法兩個方向一是熔斷降級把掛掉的服務(wù)熔斷隔離、請求走降級兜底二是用線程池或 MQ 消息隊列異步承接超時快速失敗不再因下游過慢而阻塞整條鏈。限流則對并發(fā)大的服務(wù)限制請求數(shù)量超水位直接失敗或勻速排隊防激增流量打垮系統(tǒng)秒殺、大促必備。熔斷和降級這對概念作者用警匪片一秒講清交易正酣A 方接到電話「有內(nèi)鬼終止交易執(zhí)行 B 計劃」——終止交易是熔斷B 計劃是降級。熔斷是防雪崩的措施A 調(diào) B 發(fā)現(xiàn) B 不可用A 為保自己及時切斷與 B 的通訊但切斷后不能干等——不能直接給用戶拋「下單失敗」降級是提前備好的兜底比如下單時積分服務(wù)掛了先返回「積分添加正?！?、往數(shù)據(jù)庫記一條日志后續(xù)任務(wù)調(diào)度掃這張表把積分補償回來等 B 恢復(fù)再走正常通訊。詞觸發(fā)條件誰出手動作目標(biāo)限流入口流量超過可承受水位入口/網(wǎng)關(guān)或服務(wù)自身直接失敗或勻速排隊激增流量不壓垮系統(tǒng)熔斷下游調(diào)用失敗/超時達(dá)到閾值調(diào)用方防護組件自動機制暫時切斷對下游調(diào)用并隔離自己不陪葬阻斷雪崩降級弱依賴不可用或資源吃緊要棄車保帥業(yè)務(wù)代碼提前寫好的預(yù)案返回兜底結(jié)果默認(rèn)值/記賬后補償犧牲非核心保主流程雪崩以上都沒做—后果線程池逐級打滿、鏈路整體不可用三個詞共同防范的對象容易搞混的一點熔斷是機制、降級是預(yù)案真實系統(tǒng)里常連著用——熔斷器打開落到調(diào)用方的降級方法上。Ribbon 的策略P76作者說所有策略都實現(xiàn)了IRule接口轉(zhuǎn)寫作「ERROLL」點了六個策略行為作者口徑RandomRandomRule隨機RoundRobinRoundRobinRule輪詢RetryRetryRule輪詢基礎(chǔ)上加重試WeightedWeightedResponseTimeRule按權(quán)重響應(yīng)時間分配BestBestAvailableRule過濾掉失效實例挑并發(fā)請求最小的作者又補了句「并且它還是輪詢的」原話含糊此點未核實默認(rèn)的分區(qū)感知規(guī)則ZoneAvoidanceRule服務(wù)部署在不同區(qū)域機房他舉上海、重慶先選離自己區(qū)域最近的再輪詢版本口徑Spring Cloud Netflix2.2.9.RELEASE官方文檔里默認(rèn) IRule 就是 ZoneAvoidanceRule核過原文Ribbon 原生默認(rèn)策略、Spring Cloud 切換/移除 Ribbon 的版本邊界未核實——面試說「Spring Cloud 體系Netflix 時代默認(rèn) ZoneAvoidanceRule」比報版本號安全。6. 分布式事務(wù)與 Seata AT 模式原理P74Seata 有 AT、TCC、SAGA、XA 四種模式作者建議只講最常見的 AT——面試官想聽的是你對分布式事務(wù)統(tǒng)一解法的理解。先立框架分布式事務(wù)不像本地事務(wù)一個階段能完成所以走二階段提交——第一階段準(zhǔn)備通知各參與者微服務(wù)第二階段提交或回滾。這里必須糾一句轉(zhuǎn)寫說「四種模式都采用二階段提交」XA 確是數(shù)據(jù)庫協(xié)議層標(biāo)準(zhǔn) 2PC、AT 也是二階段流程但 TCC 是 try/confirm/cancel 三個業(yè)務(wù)動作、SAGA 是正向操作加補償鏈嚴(yán)格說不算經(jīng)典 2PC——作者這句壓縮過頭了筆者判斷其余模式細(xì)節(jié)轉(zhuǎn)寫未展開未核實。三個角色是全模式骨架角色全稱住在哪干什么TC事務(wù)協(xié)調(diào)者Seata Server 那個獨立服務(wù)協(xié)調(diào)每組全局事務(wù)、按 XID 隔離、管理分支事務(wù)決定何時提交/回滾像事務(wù)總管TM事務(wù)管理器發(fā)起者微服務(wù)里Seata 客戶端側(cè)開始時向 TC 申請開啟全局事務(wù)本地事務(wù)完成或出問題時上報通知 TC 提交或回滾RM資源管理器微服務(wù)里Seata 客戶端側(cè)管理分支資源向 TC 注冊分支事務(wù)、申請全局鎖、執(zhí)行分支提交/回滾AT 模式完整執(zhí)行鏈按作者敘述整理兩個關(guān)鍵追問見后面的 Q階段一一邊執(zhí)行一邊留好后悔藥 TM ──begin──? TC 創(chuàng)建全局事務(wù)生成全局唯一 XID沿整條調(diào)用鏈傳播兼作事務(wù)組隔離 ▼ 分支執(zhí)行 UPDATE代理攔下這條 SQL RM①解析 SQL 拿類型(update)/表(product)/條件 ②按表條件拼 SELECT 查「前鏡像」 ③執(zhí)行 UPDATE ④再查一遍拿「后鏡像」 ⑤前鏡像后鏡像寫 undo_log帶分支 ID ⑥向 TC 注冊分支事務(wù) ⑦為這一行申請【全局鎖】——其他 Seata 管理的全局事務(wù)不能再碰它防臟讀臟寫 ⑧本地 commit業(yè)務(wù)數(shù)據(jù)和 undo_log 一起入庫 階段二TC 匯總分支上報后二選一 全部成功 ──? TC 把提交請求丟進異步隊列、立刻返回成功異步按分支 ID 刪掉 undo_log完事 有分支失敗 ─? 開本地事務(wù)按 XID分支ID 找 undo_log 后鏡像 vs 當(dāng)前數(shù)據(jù)比對 ──一致──? 前鏡像逆向生成 UPDATE 回滾 → 刪 undo_log → 提交 → 回報 TC └不一致─? 被全局事務(wù)之外的動作改過臟寫無法感知成因默認(rèn)打日志異常通知、人工介入Q3階段一就本地提交了不怕這期間別的事務(wù)改這行嗎作者的應(yīng)對就是第⑦步全局鎖在 TC 層面鎖住這行其他走 Seata 的分布式事務(wù)不能操作不受 Seata 管理的外部寫入攔不住靠第二階段的后鏡像比對事后發(fā)現(xiàn)——「事前攔事后驗」的歸納是我順著他的描述整理的轉(zhuǎn)寫沒這么細(xì)。Q4回滾直接拿前鏡像恢復(fù)就行為什么先比對后鏡像這是作者專門自問自答的一步比對是判斷當(dāng)前數(shù)據(jù)是不是被本全局事務(wù)之外的動作改過。改過了就是臟寫此時回滾等于把別人的修改一起抹掉所以 Seata 只打日志、觸發(fā)異常通知、人工介入——作者強調(diào)「這是默認(rèn)策略具體看策略配置」。這個默認(rèn)行為我未對照官方文檔逐字核實回答時墊一句「按作者的工程經(jīng)驗」更安全。至于 AT 為什么這么設(shè)計我的補白階段一就提交、數(shù)據(jù)立即可見、行鎖早已釋放是 AT 換吞吐的代價驗臟就是給它兜底。一句話理解 AT各分支照常走本地事務(wù)先落庫把「前鏡像 后鏡像」記進 undo_log 當(dāng)后悔藥把「該不該反悔」的決議權(quán)交給 TC——沒反悔就刪藥反悔就照藥方逆向回滾。社區(qū)通說是 AT 用得最廣但「AT 是某版本默認(rèn)模式」未核實問到就答「我們項目用 AT其他按場景選」。7. 落地項目里限流降級怎么配出了異常怎么查7.1 真實場景與閾值來源P77這是全套 77 個分 P 的最后一問作者的面試方法論反而最值錢簡歷技能欄寫什么就是替面試官出題。他自述做過面試官拿到簡歷先看技能欄、再結(jié)合項目問「你既然會項目里怎么用的」只停在理論的人一問就懵。建議寫上去的每項技能提前落到一個項目場景真沒做過就設(shè)想一個作者原話是否妥當(dāng)自己斟酌——我的看法是設(shè)想場景必須技術(shù)上自洽、經(jīng)得起三層追問否則是挖坑。限流場景不必是電商作者舉的非互聯(lián)網(wǎng)例子——上萬人的公司OA 打卡集中在 8:008:30這也是洪峰可以勻速排隊。降級的正確姿勢是提前做依賴梳理哪些服務(wù)不重要不緊急、可延遲或暫停使用積分是典型弱依賴哪些必須誓死保護——丟車保帥的名單要在出事前列好。他給了個參考日志級別的預(yù)案分層級別情形作者口徑觸發(fā)方式一般偶發(fā)網(wǎng)絡(luò)抖動或發(fā)布上線導(dǎo)致的超時自動降級警告一段時間成功率有波動原話表述混亂未核實自動或人工錯誤可用率低于 90%轉(zhuǎn)寫作「錯誤率達(dá)到 90%」顯系口誤自動降級嚴(yán)重特殊原因?qū)е聰?shù)據(jù)錯誤緊急人工降級所以降級分自動與人工兩路秒殺高峰前把「猜你喜歡」「熱賣商品」查詢?nèi)斯りP(guān)掉、過了再開就是最樸素的人工降級。觸發(fā)維度無非 QPS/并發(fā)、響應(yīng)時間他說超 25 秒可降、錯誤率他說 5%10% 可自動降——這些區(qū)間全是口述經(jīng)驗值不是產(chǎn)品默認(rèn)參數(shù)未核實。被追問「QPS 閾值怎么定的」三層答案一、萬金油——「測試團隊給的」大廠會由測試提前壓出單臺服務(wù)器在幾種集群形態(tài)下的最高水位限流值 單機水位 × 集群臺數(shù)二、自己估——二八法則80% 的訪問量集中在 20% 的時間如日 PV 一千萬峰值 QPS ≈ 10000000 × 0.8 ÷ (86400 × 0.2) ≈ 463作者說這公式基本不會被真考三、看自家壓測報告。作者的收尾傳統(tǒng)項目一樣有高并發(fā)場景把話變成自己的。7.2 微服務(wù)架構(gòu)排錯P75作者先來一句繞口令「想服務(wù)不雪崩高可用防護組件少不了想微服務(wù)架構(gòu)定位快監(jiān)控平臺少不了。」思路轉(zhuǎn)變是他反復(fù)強調(diào)的單體排錯只要日志微服務(wù)里「一出錯就查日志」是單體思維正確順序是先定位哪個服務(wù)、哪個節(jié)點出問題再進那個服務(wù)看日志。工具管哪一段作者口徑Spring Boot Actuator Spring Boot Admin監(jiān)控指標(biāo) 可視化面板展示所有實例異常變色黃告警、紅異常點進去看異常信息日志查看與過濾、動態(tài)調(diào)日志級別平時高、排查時低不影響線上還能看上下線與訪問記錄Zipkin / SkyWalking鏈路追蹤定位整條鏈路里哪個服務(wù)出問題性能剖析定位慢請求、慢響應(yīng)SkyWalking 帶告警釘釘/企業(yè)微信直接通知開發(fā)人員。作者推薦 SkyWalking防護組件日志熔斷觸發(fā)要把被熔斷的服務(wù)、類、方法記下來數(shù)據(jù)庫異常要記具體信息——日志質(zhì)量決定你定位到服務(wù)后能否定位到原因墊一句筆者判斷Spring Boot Admin 是社區(qū)項目codecentric別說成 Spring 官方出品臨時調(diào)低日志級別要配恢復(fù)動作忘調(diào)回來本身就是容量事故。答這題的最后一步真在線上解決過問題把真實案例塞進模板比模板更有說服力。最后總結(jié)按我的判斷這 13 個分 P 考的是同一件事你想沒想清楚「拆分換來什么、付出什么、怎么補」。P65/P66 是概念與代價的記賬P67 是拆的節(jié)奏P68 是補丁總賬P69P71 是三大基礎(chǔ)設(shè)施的答法P72/P73/P76 是流量與容錯因果鏈P74 是最硬的原理題——全局鎖、undo_log、后鏡像驗臟這三件套能把 Q4 講明白的人不多P77/P75 回到面試桌本身技能要落到場景數(shù)字要說清來源排錯要先定位再查日志。我傾向于把這套題答成因果鏈而不是清單拆分引入尋址、配置、容錯、一致性、排障五個新問題每個組件恰好認(rèn)領(lǐng)一個——無論往哪支追問你都站在主線上。本文覆蓋分 P分 P視頻原始標(biāo)題本文對應(yīng)小節(jié)P65微服務(wù)架構(gòu)的優(yōu)缺點1P66SOA、分布式、微服務(wù)之間有什么關(guān)系和區(qū)別1P67微服務(wù)怎么拆2P68常用微服務(wù)組件及作用3P69介紹注冊中心的核心功能4.1P70談?wù)勁渲弥行?.2P71說說服務(wù)網(wǎng)關(guān)可以做什么4.3P72什么是服務(wù)雪崩什么是服務(wù)限流5P73什么是熔斷什么是降級5P74說說Seata的實現(xiàn)原理6P75微服務(wù)架構(gòu)排錯7.2P76說說Ribbon有哪些負(fù)載均衡策略5P77你項目哪些場景用到了限流、降級怎么配的7.1事實說明視頻里給的事實僅代表轉(zhuǎn)寫表述SOA 與微服務(wù)均屬分布式SOA 可理解成「只有一個注冊中心的微服務(wù)」微服務(wù)基本由單體演變優(yōu)缺點清單運維復(fù)雜度 10→100→容器化 50 為經(jīng)驗值拆分三原則、0.53.0 階段論、拆分時機與成本前提八組件定位注冊中心最核心、網(wǎng)關(guān)門衛(wèi)Nacos 注冊四功能 心跳 5s/15s/30s 主動注銷配置中心三痛點、推/拉二分、MD5 對比 監(jiān)聽回調(diào)網(wǎng)關(guān)分流量/業(yè)務(wù)兩類雪崩定義與兩條解法、限流兩模式、「終止交易是熔斷、B 計劃是降級」、積分記賬補償Ribbon 策略皆實現(xiàn) IRule、點名六種Seata 四模式、TC/TM/RM 三角色、AT 兩階段全流程XID、前后鏡像、undo_log、全局鎖、本地提交、異步刪日志、后鏡像驗臟、默認(rèn)轉(zhuǎn)人工四級降級預(yù)案、限流閾值三來源測試提供/二八法則/壓測排錯「先定位再查日志」、ActuatorAdmin、Zipkin/SkyWalking、告警到釘釘/企業(yè)微信。官方文檔 / 公開事實本次親自核實Spring Cloud Netflix 2.2.9.RELEASE 文檔中默認(rèn) IRule 為ZoneAvoidanceRule并示例BestAvailableRule、WeightedResponseTimeRuleSeata 官網(wǎng) AT 模式頁 確認(rèn) AT 經(jīng)代理數(shù)據(jù)源「插入回滾日志 undo_log、檢查全局鎖」、角色為 TM/RM/TC、一階段隨本地事務(wù)提交、二階段回滾比對后鏡像檢測臟寫GitHub API 查詢2026-10顯示 Netflix/ribbon、Netflix/eureka、Netflix/Hystrix 倉庫均未歸檔——作者「已閉園/已退役」的說法與倉庫狀態(tài)不完全等同。筆者判斷 / 未核實Nacos 心跳 5s/15s/30s 未對官方文檔原文與社區(qū)對 1.x 的描述一致2.x 改長連接的說法亦未核實配置中心「長輪詢」與作者「定時拉取」的術(shù)語差異未核對「Sentinel 完整版需付費」存疑開源 Sentinel 免費疑指云上商業(yè)版「四種模式都是二階段提交」為作者壓縮表述TCC/SAGA 分類糾偏屬我的判斷Seata「AT 為默認(rèn)/最常用」「臟寫默認(rèn)轉(zhuǎn)人工」「全局鎖行級粒度」未逐條核實Ribbon 原生默認(rèn)策略及 Spring Cloud 切換/移除 Ribbon 的版本邊界未核實運維復(fù)雜度 10/100/50、降級各百分比區(qū)間均為經(jīng)驗值非產(chǎn)品參數(shù)「SOA≈只有注冊中心的微服務(wù)」未計 ESB 要素Q1 緩沖期解釋、「事前攔事后驗」、Admin 為社區(qū)項目屬筆者補白流程圖按口述重繪。參考資料 致謝[1] Spring面經(jīng)-嗶哩嗶哩素材來源共 77 個分 P本文取自 P65P77文中一律稱「視頻作者」[2] Nacos 官網(wǎng)注冊中心與配置中心[3] Netflix Eureka 倉庫[4] Netflix Ribbon 倉庫[5] Spring Cloud 項目頁 與 Spring Cloud Netflix 2.2.9.RELEASE 參考文檔默認(rèn) IRule 核實處[6] OpenFeign 項目頁 與 Feign 倉庫[7] Apache Dubbo 官網(wǎng)[8] Spring Cloud Config 項目頁 與 Apache Apollo 倉庫[9] Apache Seata 官網(wǎng)與 AT 模式文檔本文第 6 章[10] Alibaba SentinelApache 孵化官網(wǎng)[11] Netflix Hystrix 倉庫[12] Netflix Zuul 倉庫 與 Spring Cloud Gateway 項目頁[13] Envoy 官網(wǎng) 與 Kong 官網(wǎng)[14] Apache SkyWalking 官網(wǎng) 與 Zipkin 官網(wǎng)第 7 章排錯工具鏈[15] Spring Boot 項目頁Actuator與 codecentric Spring Boot Admin 倉庫[16] Redis 官網(wǎng)配置中心舉例的遷移對象[17] Istio 官網(wǎng)Service Mesh 階段的代表項目感謝視頻作者把微服務(wù)這條線拆成「概念歸位 → 怎么拆 → 組件地圖 → 三大基礎(chǔ)設(shè)施 → 容錯因果鏈 → Seata → 場景落地 → 排錯方法論」的完整序列尤其「終止交易是熔斷、B 計劃是降級」「回滾前先比后鏡像」「限流閾值的萬金油答案是測試給的」這幾處是把概念題答成工程題的關(guān)鍵也照例提醒口述里的版本號、默認(rèn)參數(shù)、退役時間線開口前都要再做一次官方對照。