Spring 面经系列 · 第 8 篇：微服务架构、注册/配置/网关、限流熔断降级与 Seata 分布式事务

Spring 面经系列 · 第 8 篇微服务架构、注册/配置/网关、限流熔断降级与 Seata 分布式事务简历上写了「微服务」面试就会收到一串连环问为什么要拆拆了之后不是问题更多一个服务挂掉为什么整条链路都死跨服务下单钱扣了货没发出事务怎么办线上报错你怎么知道是哪个服务出的这些问题看着是七道题其实是一条因果链——拆分换来了效率效率带来了依赖依赖带来了雪崩风险风险带来了防护组件防护和一致性又带来了注册中心、配置中心、网关、熔断、分布式事务、链路追踪这一整套技术栈。本文把 13 个分 PP65P77按这条因果链串起来。素材是语音转写同音错字密集Nacos写成「NEO」、Seata写成「theta」、Sentinel写成「森林nail」、IRule写成「ERROLL」、undo_log写成「安 do log」我按术语还原。这套题数字特别多——Nacos 心跳阈值、Ribbon 默认策略、Seata 的默认处置——视频全是口述凡我没对照到官方原文的都标了未核实别当背书材料当提问预警用。1. 单体、分布式、SOA、微服务先把四个词放对位置P66 这道题很多同学是糊的视频作者给的归位方式很直接分布式是上位概念——把一个应用拆成多块、部署在不同服务器上组成一个应用就叫分布式SOA 和微服务都满足这个特性所以两者都属于分布式架构。拆到不同服务器后分布式缓存、分布式事务、分布式 ID 与跨节点一致性问题随之而来这是分布式这一层的共同代价。两者的区别作者给了一个适合面试直接用的记忆法概念视频作者的口径拆分程度治理组件分布式架构应用拆成多块部署在不同服务器——SOA面向服务服务注册在「总线」上调用时从总线查找可理解成「微服务的不完整形态」说白了就是只有一个注册中心的微服务架构较粗基本只有服务注册微服务各功能抽成更小、更彻底的服务细注册中心、配置中心、网关、远程调用、容错熔断一整套打个补丁「SOA 只有一个注册中心的微服务」是作者的私人简化SOA 常配的 ESB 服务总线他一句带过——够用但别当学术定义。P65 问「你们为什么要用微服务」作者先纠正前提微服务基本都是从单体演变来的——单体为省成本而生业务量涨上来、代码难动了才拆一上来就上微服务的极少业务没成型就拆基本是自找麻烦。回答要按这个叙事走结合自己项目讲每点两三条就够别背概念清单。维度单体下的痛视频描述拆分换来什么开发效率几十人一个代码库、启动极慢作者说迭代三四年的项目启动一次「够出去抽根烟」次日都不敢关机服务小起得快发布敏捷性提前上线一个模块会被别人未完成的改动卡住只能开分支最后合并每个服务独立发布迭代分工与成长新人必须把全应用技术栈本地搭一遍改一处牵全身23 人一个服务专人专攻并发或存储容易成领域专家技术多样性一个应用基本一套栈业务收缩时非主力语言作者举 PHP、.NET的程序员容易流失各服务可用不同语言框架存储统一传输协议REST 或 RPC即可扩容与资源并发上来只能整体集群低并发模块白耗资源也难压出单模块水位只给高并发服务扩容单服务压测出准确水位维护与责任老系统人员换几茬老代码没人敢动出错追责追不准按业务模块拆责任边界随服务缩小容错一次内存溢出OOM整个应用不可用弱依赖如积分挂了直接熔断隔离下单主流程照常后期补偿扩展技术升级基本没机会嫌哪个服务技术老旧再拆一个出来用新技术重写付出什么P65 后半微服务本质是分布式系统分布式问题全家桶抬高开发者门槛事务很难保证最终一致性只能尽量运维复杂度飙升——作者经验值单体 10、微服务 100、上了容器化降到 50仍远高于单体接口有依赖改格式可能牵连一片作者认为靠约定可避免各服务独立导致公共类重复劳动。最大的两个坑是开发门槛和运维难度。一句话理解微服务是用「系统级复杂度」换「小块独立变更的自由」换得值不值看业务量和团队配套。2. 微服务怎么拆原则、时机、演进节奏P67 拆成「怎么拆」和「什么时候拆」两问。怎么拆作者给三点原则原则展开高内聚、低耦合、职责单一职责隔离尽量减少强依赖与循环依赖——是「尽量」零依赖不可能粒度适中一个接口一个服务太细一个表一个服务能做但初期别这样。初期以业务模型切入、按功能模块产品、用户、订单垂直拆分渐进式演进从几个、十几个到几十上百个慢慢来团队、工具、监控、治理配套要跟着节奏走配套跟不上拆得越细越是一场灾难拆的过程躲不开一串工程问题注册发现编排、数据库拆分、分布式技术落地、链路压测、追踪、统一日志、配置中心、熔断降级、MQ 设计、前后端分离——只能演进着补齐不可能学一套框架就全塞进来。演进阶段他画了一条线阶段引入什么作者说的现状0.5单体刚拆成几个、十来个服务过渡期1.0只上注册发现拆分初期建议到这就够1.5往服务治理过渡转型中的传统企业领头羊多在这2.0熔断、降级、治理 完整链路追踪与监控大部分互联网企业处于这个阶段3.0Service Mesh 服务网格一线互联网公司在尝试什么时候拆四条预估业务飞速增长、快到瓶颈就提前拆撞上瓶颈再拆就晚了架构设计需要大量异构技术栈起初就判断业务复杂、流量大、基础设施成熟可以一起手微服务 1.0先只上注册发现最大前提是成本——人力硬件时间投入都大没成本别拆。我的补充四条里最容易被追问「数据库怎么拆」视频只点了题简历写了拆分的话得自己备好表归属、跨库查询、跨库事务三小问。3. 八个常用组件与一次请求的完整路径P68 只要真学过都能说几个作者的贡献是把「每个组件堵哪个窟窿」讲清了组件堵的窟窿作者点名的产品与推荐注册中心手工维护提供者地址机器一迁移就全废按服务名拉列表下线与扩容动态感知。定位最核心没有它基本微服务都撑不起来Eureka作者称「已闭园」不推荐见事实说明、Nacos客户端负载均衡器拉回来的是集群如订单 3 实例调用得分发消费者自己就是客户端所以在客户端做Ribbon作者先说它仍活跃可用又说 Spring Cloud LoadBalancer 更强大、最终推荐后者原话绕按现状整理服务调用手写 RestTemplate 调 REST 不够优雅要像调本地方法一样调远程FeignNetflix不推荐、OpenFeign、Dubbo RPC配置中心成百上千个服务各有各的配置没法各自维护Spring Cloud Config、Nacos 自带用它家注册就顺手用它家配置熔断降级单个服务挂掉不拖垮应用激增流量不打垮系统Hystrix作者称已退役、Sentinel推荐但他称「完整版要用阿里付费的那个」存疑分布式事务拆分后本地事务管不了跨服务一致性Seata服务网关统一入口把鉴权、日志、限流、路由、跨域等与业务无关的公共逻辑收口Zuul作者称「一和二」、Spring Cloud Gateway推荐、Envoy转写作「link id」、Kong链路追踪快速定位出问题的服务、实时看健康状况、协助快速恢复本 P 只讲作用工具在 P75 展开作者给网关的比喻是小区门卫限流是统一通知门卫请求日志是登记鉴权是决定今天见谁跨域整个小区统一做。一次下单请求穿过这些组件的路径我按视频内容重画成横版调用主路径 客户端 ──HTTP──► 服务网关 ──► 商品服务 ──Ribbon按服务名──► 订单服务 ──► 库存服务 鉴权/限流/日志/ (防护组件包住 (XID 沿链路传播, 跨域/路由转发 下游弱依赖) 分支注册全局锁) │ └──► 积分服务弱依赖熔断隔离失败走降级事后补偿 旁路支撑每个服务实例都要发生 服务实例 ──①注册/心跳/主动注销──► 注册中心(Nacos Server) 服务实例 ◄─②定时拉取健康列表──── 注册中心 服务实例 ◄─③长轮询拉取配置────── 配置中心(Nacos) 各微服务 ──④分支注册/上报──────► Seata TC全局决议提交或回滚 整条链路 ──⑤埋点上报──────────► 链路追踪SkyWalking一句话理解这八件套注册中心管「找得到」负载均衡管「分得匀」远程调用管「调得优雅」配置中心管「改得快」网关管「进得来」熔断限流管「死不了」分布式事务管「账得平」链路追踪管「查得着」——每个组件都在给拆分挖的窟窿打补丁。4. 注册中心、配置中心、网关三个基础设施分别怎么答4.1 注册中心的核心功能P69作者开场先提醒答这题前先确认你说的是哪个注册中心各家实现有差异Eureka 自我保护、Consul 本 P 都没提但核心一致他以 Nacos 为例。功能清单功能机制视频口径他给的默认值服务注册服务启动时通过 REST 接口向 Nacos Server 注册例一个订单 两个库存实例—心跳保活Nacos 客户端维持定时心跳证明「我可用」防止被剔除每 5 秒一次不健康标记服务端超 15 秒没收到心跳把健康状态置 false拉取时跳过它但实例还在15 秒剔除客户端超 30 秒没发心跳服务端直接剔除实例30 秒服务发现客户端有定时任务持续去服务端拉取健康实例列表—主动注销服务停止时客户端主动发 REST 注销请求摘掉自己—Q1为什么 15 秒只标记不健康30 秒才真剔除转写没讲原因。按机制推断笔者判断这 1530 秒缓冲是留给「网络抖一下、GC 停一下」的余量一次心跳丢失就删实例调用链会被误杀抖动。版本边界必须交代这组「5 / 15 / 30 秒」是口述值与社区文章对 Nacos 1.x HTTP 心跳的描述一致但本次未核到官方文档原文且 2.x 起临时实例据称改走 gRPC 长连接、不再套这组参数——均未核实。稳妥答法是先讲「注册、心跳、发现、注销」四个功能参数说「以 1.x 默认值为例细节以版本文档为准」。4.2 谈谈配置中心P70「谈谈 XX」这种开放题作者要求应用、优点、原理三层都备着答完应用会被追原理。配置中心解决什么三个痛点全对着「本地配置文件」开火维护性差——所有服务连同一台 Redis它一迁移涉及的服务都得挨个改配置实时性差——改完要重启重启这一台的工夫别的还没重启存在不一致窗口只能靠「改完瞬间全部感知」来尽量保一致安全性差——账号密码躺在本地配置里人人可见作者的「删库跑路」表述。典型内容数据库连接地址迁移时只改一处、实例实时拉取、缓存连接地址与账号密码等敏感信息、动态参数——客户端超时、限流规则、降级开关、按地区或时段的功能开关双 11 前切高配 Redis、打开限流过了再关。集中配置改一处即实时生效传统文件做不到这个响应速度。原理层作者把所有配置中心的取数方式归成两类——服务端推和客户端拉——然后说 Nacos 用拉客户端配了监听器监听器结合定时任务内部是个长轮询的缓存池拿本地缓存配置的 MD5与服务端比对不一致就说明配置变了拉回新配置存入本地缓存、重算 MD5、触发监听器回调刷新服务配置。Q2推不是更实时吗为什么用拉作者的账100 个服务接配置中心用推则配置一变服务端要挨个通知 100 个客户端压力全在中心侧还得靠心跳维持每条连接有效用拉把压力摊到每个客户端各发各的 HTTP 定时请求服务端轻得多。补一个术语坑Nacos 配置中心的官方机制通常被描述为长轮询——客户端请求挂起在服务端有变化立刻返回语义介于推和拉之间作者口述成「定时拉取 MD5 对比」不完全等价未核对原文未核实。简历写 Spring Cloud Config 或 Apollo 的各自同步机制自己再备一份。4.3 服务网关可以做什么P71这题比上一道友好但作者给的答法仍是先分类再列举——把网关分成流量网关和业务网关这一下就和背清单的拉开差距分类职责边界功能清单作者口径流量网关与业务系统、内部服务完全无关全局性流控、日志统计、安全策略、统一跨域业务网关与业务、内部服务有关联部署在业务服务前面、流量网关后面服务级流控、降级与熔断、内部路由、负载均衡、服务过滤与聚合、权限验证/鉴权、业务规则、参数校验网关可以不止一道大型系统会把流量网关和业务网关分成好几道系统不大就合进一个做——第 3 章门卫比喻里的限流、登记、鉴权、跨域正对进这两类。5. 雪崩、限流、熔断、降级一条因果链四个词外加 RibbonP72、P73、P76 本质是同一条链先有被拖死的机制雪崩才有三种自救手段限流、熔断、降级调用往哪个实例去则由负载均衡决定。雪崩过程作者的电商场景秒杀并发激增 → 积分服务被打挂 → 商品服务调它迟迟无响应、线程池打满被拖垮 → 订单服务同样堆积被拖垮 → 共享服务把不可用逐级扩散 → 整个应用不可用。定义因服务提供者的不可用导致服务调用者的不可用并且逐渐放大。作者称它是「导致服务不可用的最大元凶」。解法两个方向一是熔断降级把挂掉的服务熔断隔离、请求走降级兜底二是用线程池或 MQ 消息队列异步承接超时快速失败不再因下游过慢而阻塞整条链。限流则对并发大的服务限制请求数量超水位直接失败或匀速排队防激增流量打垮系统秒杀、大促必备。熔断和降级这对概念作者用警匪片一秒讲清交易正酣A 方接到电话「有内鬼终止交易执行 B 计划」——终止交易是熔断B 计划是降级。熔断是防雪崩的措施A 调 B 发现 B 不可用A 为保自己及时切断与 B 的通讯但切断后不能干等——不能直接给用户抛「下单失败」降级是提前备好的兜底比如下单时积分服务挂了先返回「积分添加正常」、往数据库记一条日志后续任务调度扫这张表把积分补偿回来等 B 恢复再走正常通讯。词触发条件谁出手动作目标限流入口流量超过可承受水位入口/网关或服务自身直接失败或匀速排队激增流量不压垮系统熔断下游调用失败/超时达到阈值调用方防护组件自动机制暂时切断对下游调用并隔离自己不陪葬阻断雪崩降级弱依赖不可用或资源吃紧要弃车保帅业务代码提前写好的预案返回兜底结果默认值/记账后补偿牺牲非核心保主流程雪崩以上都没做—后果线程池逐级打满、链路整体不可用三个词共同防范的对象容易搞混的一点熔断是机制、降级是预案真实系统里常连着用——熔断器打开落到调用方的降级方法上。Ribbon 的策略P76作者说所有策略都实现了IRule接口转写作「ERROLL」点了六个策略行为作者口径RandomRandomRule随机RoundRobinRoundRobinRule轮询RetryRetryRule轮询基础上加重试WeightedWeightedResponseTimeRule按权重响应时间分配BestBestAvailableRule过滤掉失效实例挑并发请求最小的作者又补了句「并且它还是轮询的」原话含糊此点未核实默认的分区感知规则ZoneAvoidanceRule服务部署在不同区域机房他举上海、重庆先选离自己区域最近的再轮询版本口径Spring Cloud Netflix2.2.9.RELEASE官方文档里默认 IRule 就是 ZoneAvoidanceRule核过原文Ribbon 原生默认策略、Spring Cloud 切换/移除 Ribbon 的版本边界未核实——面试说「Spring Cloud 体系Netflix 时代默认 ZoneAvoidanceRule」比报版本号安全。6. 分布式事务与 Seata AT 模式原理P74Seata 有 AT、TCC、SAGA、XA 四种模式作者建议只讲最常见的 AT——面试官想听的是你对分布式事务统一解法的理解。先立框架分布式事务不像本地事务一个阶段能完成所以走二阶段提交——第一阶段准备通知各参与者微服务第二阶段提交或回滚。这里必须纠一句转写说「四种模式都采用二阶段提交」XA 确是数据库协议层标准 2PC、AT 也是二阶段流程但 TCC 是 try/confirm/cancel 三个业务动作、SAGA 是正向操作加补偿链严格说不算经典 2PC——作者这句压缩过头了笔者判断其余模式细节转写未展开未核实。三个角色是全模式骨架角色全称住在哪干什么TC事务协调者Seata Server 那个独立服务协调每组全局事务、按 XID 隔离、管理分支事务决定何时提交/回滚像事务总管TM事务管理器发起者微服务里Seata 客户端侧开始时向 TC 申请开启全局事务本地事务完成或出问题时上报通知 TC 提交或回滚RM资源管理器微服务里Seata 客户端侧管理分支资源向 TC 注册分支事务、申请全局锁、执行分支提交/回滚AT 模式完整执行链按作者叙述整理两个关键追问见后面的 Q阶段一一边执行一边留好后悔药 TM ──begin──► TC 创建全局事务生成全局唯一 XID沿整条调用链传播兼作事务组隔离 ▼ 分支执行 UPDATE代理拦下这条 SQL RM①解析 SQL 拿类型(update)/表(product)/条件 ②按表条件拼 SELECT 查「前镜像」 ③执行 UPDATE ④再查一遍拿「后镜像」 ⑤前镜像后镜像写 undo_log带分支 ID ⑥向 TC 注册分支事务 ⑦为这一行申请【全局锁】——其他 Seata 管理的全局事务不能再碰它防脏读脏写 ⑧本地 commit业务数据和 undo_log 一起入库 阶段二TC 汇总分支上报后二选一 全部成功 ──► TC 把提交请求丢进异步队列、立刻返回成功异步按分支 ID 删掉 undo_log完事 有分支失败 ─► 开本地事务按 XID分支ID 找 undo_log 后镜像 vs 当前数据比对 ──一致──► 前镜像逆向生成 UPDATE 回滚 → 删 undo_log → 提交 → 回报 TC └不一致─► 被全局事务之外的动作改过脏写无法感知成因默认打日志异常通知、人工介入Q3阶段一就本地提交了不怕这期间别的事务改这行吗作者的应对就是第⑦步全局锁在 TC 层面锁住这行其他走 Seata 的分布式事务不能操作不受 Seata 管理的外部写入拦不住靠第二阶段的后镜像比对事后发现——「事前拦事后验」的归纳是我顺着他的描述整理的转写没这么细。Q4回滚直接拿前镜像恢复就行为什么先比对后镜像这是作者专门自问自答的一步比对是判断当前数据是不是被本全局事务之外的动作改过。改过了就是脏写此时回滚等于把别人的修改一起抹掉所以 Seata 只打日志、触发异常通知、人工介入——作者强调「这是默认策略具体看策略配置」。这个默认行为我未对照官方文档逐字核实回答时垫一句「按作者的工程经验」更安全。至于 AT 为什么这么设计我的补白阶段一就提交、数据立即可见、行锁早已释放是 AT 换吞吐的代价验脏就是给它兜底。一句话理解 AT各分支照常走本地事务先落库把「前镜像 后镜像」记进 undo_log 当后悔药把「该不该反悔」的决议权交给 TC——没反悔就删药反悔就照药方逆向回滚。社区通说是 AT 用得最广但「AT 是某版本默认模式」未核实问到就答「我们项目用 AT其他按场景选」。7. 落地项目里限流降级怎么配出了异常怎么查7.1 真实场景与阈值来源P77这是全套 77 个分 P 的最后一问作者的面试方法论反而最值钱简历技能栏写什么就是替面试官出题。他自述做过面试官拿到简历先看技能栏、再结合项目问「你既然会项目里怎么用的」只停在理论的人一问就懵。建议写上去的每项技能提前落到一个项目场景真没做过就设想一个作者原话是否妥当自己斟酌——我的看法是设想场景必须技术上自洽、经得起三层追问否则是挖坑。限流场景不必是电商作者举的非互联网例子——上万人的公司OA 打卡集中在 8:008:30这也是洪峰可以匀速排队。降级的正确姿势是提前做依赖梳理哪些服务不重要不紧急、可延迟或暂停使用积分是典型弱依赖哪些必须誓死保护——丢车保帅的名单要在出事前列好。他给了个参考日志级别的预案分层级别情形作者口径触发方式一般偶发网络抖动或发布上线导致的超时自动降级警告一段时间成功率有波动原话表述混乱未核实自动或人工错误可用率低于 90%转写作「错误率达到 90%」显系口误自动降级严重特殊原因导致数据错误紧急人工降级所以降级分自动与人工两路秒杀高峰前把「猜你喜欢」「热卖商品」查询人工关掉、过了再开就是最朴素的人工降级。触发维度无非 QPS/并发、响应时间他说超 25 秒可降、错误率他说 5%10% 可自动降——这些区间全是口述经验值不是产品默认参数未核实。被追问「QPS 阈值怎么定的」三层答案一、万金油——「测试团队给的」大厂会由测试提前压出单台服务器在几种集群形态下的最高水位限流值 单机水位 × 集群台数二、自己估——二八法则80% 的访问量集中在 20% 的时间如日 PV 一千万峰值 QPS ≈ 10000000 × 0.8 ÷ (86400 × 0.2) ≈ 463作者说这公式基本不会被真考三、看自家压测报告。作者的收尾传统项目一样有高并发场景把话变成自己的。7.2 微服务架构排错P75作者先来一句绕口令「想服务不雪崩高可用防护组件少不了想微服务架构定位快监控平台少不了。」思路转变是他反复强调的单体排错只要日志微服务里「一出错就查日志」是单体思维正确顺序是先定位哪个服务、哪个节点出问题再进那个服务看日志。工具管哪一段作者口径Spring Boot Actuator Spring Boot Admin监控指标 可视化面板展示所有实例异常变色黄告警、红异常点进去看异常信息日志查看与过滤、动态调日志级别平时高、排查时低不影响线上还能看上下线与访问记录Zipkin / SkyWalking链路追踪定位整条链路里哪个服务出问题性能剖析定位慢请求、慢响应SkyWalking 带告警钉钉/企业微信直接通知开发人员。作者推荐 SkyWalking防护组件日志熔断触发要把被熔断的服务、类、方法记下来数据库异常要记具体信息——日志质量决定你定位到服务后能否定位到原因垫一句笔者判断Spring Boot Admin 是社区项目codecentric别说成 Spring 官方出品临时调低日志级别要配恢复动作忘调回来本身就是容量事故。答这题的最后一步真在线上解决过问题把真实案例塞进模板比模板更有说服力。最后总结按我的判断这 13 个分 P 考的是同一件事你想没想清楚「拆分换来什么、付出什么、怎么补」。P65/P66 是概念与代价的记账P67 是拆的节奏P68 是补丁总账P69P71 是三大基础设施的答法P72/P73/P76 是流量与容错因果链P74 是最硬的原理题——全局锁、undo_log、后镜像验脏这三件套能把 Q4 讲明白的人不多P77/P75 回到面试桌本身技能要落到场景数字要说清来源排错要先定位再查日志。我倾向于把这套题答成因果链而不是清单拆分引入寻址、配置、容错、一致性、排障五个新问题每个组件恰好认领一个——无论往哪支追问你都站在主线上。本文覆盖分 P分 P视频原始标题本文对应小节P65微服务架构的优缺点1P66SOA、分布式、微服务之间有什么关系和区别1P67微服务怎么拆2P68常用微服务组件及作用3P69介绍注册中心的核心功能4.1P70谈谈配置中心4.2P71说说服务网关可以做什么4.3P72什么是服务雪崩什么是服务限流5P73什么是熔断什么是降级5P74说说Seata的实现原理6P75微服务架构排错7.2P76说说Ribbon有哪些负载均衡策略5P77你项目哪些场景用到了限流、降级怎么配的7.1事实说明视频里给的事实仅代表转写表述SOA 与微服务均属分布式SOA 可理解成「只有一个注册中心的微服务」微服务基本由单体演变优缺点清单运维复杂度 10→100→容器化 50 为经验值拆分三原则、0.53.0 阶段论、拆分时机与成本前提八组件定位注册中心最核心、网关门卫Nacos 注册四功能 心跳 5s/15s/30s 主动注销配置中心三痛点、推/拉二分、MD5 对比 监听回调网关分流量/业务两类雪崩定义与两条解法、限流两模式、「终止交易是熔断、B 计划是降级」、积分记账补偿Ribbon 策略皆实现 IRule、点名六种Seata 四模式、TC/TM/RM 三角色、AT 两阶段全流程XID、前后镜像、undo_log、全局锁、本地提交、异步删日志、后镜像验脏、默认转人工四级降级预案、限流阈值三来源测试提供/二八法则/压测排错「先定位再查日志」、ActuatorAdmin、Zipkin/SkyWalking、告警到钉钉/企业微信。官方文档 / 公开事实本次亲自核实Spring Cloud Netflix 2.2.9.RELEASE 文档中默认 IRule 为ZoneAvoidanceRule并示例BestAvailableRule、WeightedResponseTimeRuleSeata 官网 AT 模式页 确认 AT 经代理数据源「插入回滚日志 undo_log、检查全局锁」、角色为 TM/RM/TC、一阶段随本地事务提交、二阶段回滚比对后镜像检测脏写GitHub API 查询2026-10显示 Netflix/ribbon、Netflix/eureka、Netflix/Hystrix 仓库均未归档——作者「已闭园/已退役」的说法与仓库状态不完全等同。笔者判断 / 未核实Nacos 心跳 5s/15s/30s 未对官方文档原文与社区对 1.x 的描述一致2.x 改长连接的说法亦未核实配置中心「长轮询」与作者「定时拉取」的术语差异未核对「Sentinel 完整版需付费」存疑开源 Sentinel 免费疑指云上商业版「四种模式都是二阶段提交」为作者压缩表述TCC/SAGA 分类纠偏属我的判断Seata「AT 为默认/最常用」「脏写默认转人工」「全局锁行级粒度」未逐条核实Ribbon 原生默认策略及 Spring Cloud 切换/移除 Ribbon 的版本边界未核实运维复杂度 10/100/50、降级各百分比区间均为经验值非产品参数「SOA≈只有注册中心的微服务」未计 ESB 要素Q1 缓冲期解释、「事前拦事后验」、Admin 为社区项目属笔者补白流程图按口述重绘。参考资料 致谢[1] Spring面经-哔哩哔哩素材来源共 77 个分 P本文取自 P65P77文中一律称「视频作者」[2] Nacos 官网注册中心与配置中心[3] Netflix Eureka 仓库[4] Netflix Ribbon 仓库[5] Spring Cloud 项目页 与 Spring Cloud Netflix 2.2.9.RELEASE 参考文档默认 IRule 核实处[6] OpenFeign 项目页 与 Feign 仓库[7] Apache Dubbo 官网[8] Spring Cloud Config 项目页 与 Apache Apollo 仓库[9] Apache Seata 官网与 AT 模式文档本文第 6 章[10] Alibaba SentinelApache 孵化官网[11] Netflix Hystrix 仓库[12] Netflix Zuul 仓库 与 Spring Cloud Gateway 项目页[13] Envoy 官网 与 Kong 官网[14] Apache SkyWalking 官网 与 Zipkin 官网第 7 章排错工具链[15] Spring Boot 项目页Actuator与 codecentric Spring Boot Admin 仓库[16] Redis 官网配置中心举例的迁移对象[17] Istio 官网Service Mesh 阶段的代表项目感谢视频作者把微服务这条线拆成「概念归位 → 怎么拆 → 组件地图 → 三大基础设施 → 容错因果链 → Seata → 场景落地 → 排错方法论」的完整序列尤其「终止交易是熔断、B 计划是降级」「回滚前先比后镜像」「限流阈值的万金油答案是测试给的」这几处是把概念题答成工程题的关键也照例提醒口述里的版本号、默认参数、退役时间线开口前都要再做一次官方对照。