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