1. 微服务与分布式到底在聊什么先把面试的底层逻辑搞清楚1.1 面试官问微服务他真正想听到的并不是“答得全”“微服务”“分布式”这两个词在Java后端面试里几乎场场出现。但说实话很多人背了半个月的八股一开口还是被面试官一句话问住“你这个服务拆了之后数据一致性怎么办”然后就没有然后了。我个人的看法是面试官问微服务真正想考察的不是你会不会背“微服务就是把大系统拆成小服务”这个定义而是你有没有踩过分布式环境下的坑有没有理解拆服务之后带来的连锁代价。微服务带来的好处——独立部署、独立扩展、故障隔离、团队自治——这些大家都知道。真正的分水岭在于当你拆完之后原来单体应用里简单的事情变得不再简单了服务之间怎么找到对方一个请求挂了怎么处理分布式事务怎么保证并发调用下怎么防重复、防超卖。所以这篇内容我不打算给你写一个平铺直叙的知识点汇总而是按照“面试官喜欢问什么、你该怎么答、为什么这么答”的线索来整理。你把这套逻辑顺明白了比背一百个名词解释管用。1.2 分布式架构的核心挑战是同一个网络不可靠在聊任何具体技术之前我建议你先想明白一个底层逻辑分布式的本质就是把原本在一个进程里完成的调用变成了跨网络、跨进程的调用。网络是不稳定的延迟是不确定的节点可能宕机消息可能丢也可能重复。这就引出了分布式系统最核心的矛盾在不可靠的网络之上如何提供可靠的服务能力。这也是为什么你会发现所有分布式相关的技术点最后都能归结到几个共性问题上可用性、一致性、性能、幂等。注册中心解决的是服务怎么被发现分布式锁解决的是多个节点不能同时干同一件事分布式事务解决的是多个节点的数据要么都对、要么都别改分布式ID解决的是多个节点生成的编号不能重复。你想清楚每一个技术点到底在解决哪个共性问题面试的时候就不会被问乱了。2. Spring Cloud Alibaba 生态注册、配置、网关、限流一次讲透2.1 Nacos 同时承担注册中心和配置中心为什么它能成为主流现在的微服务面试Nacos几乎是绕不开的。它的定位是“服务注册中心 配置中心”二合一。服务注册中心的作用通俗点说就是让服务之间能互相找到服务提供方启动时把自己的IP和端口注册到Nacos服务消费方去Nacos拉取服务列表然后发起调用。配置中心则把散落在各个服务里的配置统一管理起来改了配置不用重启服务就能生效。面试里常问的一个细节是Nacos的AP和CP模式切换。Nacos基于临时实例做服务注册时走的是AP模式优先保证可用性就算集群里有节点失联剩下的节点依然能响应注册和查询如果使用持久化实例则支持CP模式优先保证数据一致性。这个设计跟Eureka和ZooKeeper的区别逻辑一致Eureka天生就是APZooKeeper天生就是CP而Nacos把两种模式都做了。这里你最好能答出“为什么注册中心一般选AP而不是CP”因为注册中心最重要的能力是让服务间还能调用就算注册信息短暂不一致也比注册中心宕机导致整个系统瘫痪要好。另一个高频追问是“服务下线了怎么感知”。心跳机制是基础答案服务实例会定时向Nacos发送心跳超过15秒没收到就标记为不健康30秒没收到就剔除。但面试官通常还会追问“如果Nacos本身挂了呢”这是一个非常典型的挖坑问题完整答案我在第6部分给你拆解。2.2 Spring Cloud Gateway路由、过滤器、跨域和限流API网关是微服务架构里的流量入口。Spring Cloud Gateway的核心模型就三个东西路由Route、断言Predicate、过滤器Filter。路由定义了“什么请求转发到哪个服务”断言是路由的匹配条件比如按路径、按Header、按参数匹配过滤器则是请求在转发前后经过的处理逻辑。面试里关于网关问得最多的是“网关做了哪些事”。我建议你这样分层回答第一层是基础路由转发把客户端的请求分发给下游服务第二层是横切关注点包括统一鉴权、统一日志、跨域处理、灰度发布第三层是流量治理包括限流、熔断、超时控制。这个分层回答的好处是能体现出你的架构思维而不是零散地背几个名词。限流是网关的高频考点核心算法有令牌桶和漏桶两种。令牌桶允许一定的突发流量因为桶里可以累积令牌漏桶则是匀速流出适合保护下游系统。Spring Cloud Gateway自带的RequestRateLimiter基于Redis实现使用了令牌桶算法。真到了生产环境我建议把限流阈值、熔断阈值这些参数配置到Nacos里这样压测完或者活动大促时调阈值不用发版重启。2.3 用 IDEA 从零搭一个微服务骨架多模块和多实例启动是基本功这个部分我给一个可以直接照做的最小骨架方案。用IDEA新建一个Maven父工程然后创建这几个子模块gateway模块端口8000、user-service模块端口8001、order-service模块端口8002、common模块放公共工具类。父工程POM里管理Spring Boot和Spring Cloud Alibaba的版本注意Spring Boot 2.7.x对应Spring Cloud 2021.x、Spring Cloud Alibaba 2021.0.5.0这套版本组合我实际用过比较稳定。每个服务模块引入spring-cloud-starter-alibaba-nacos-discovery在application.yml里配置Nacos地址和服务名。这里有个新手很容易卡住的地方Nacos要先本地启动。去Nacos官网下载Server包解压后运行startup.cmdWindows或者startup.shLinux默认跑在8848端口然后打开控制台就能看到注册上来的服务。“一个模块起多个实例”这个热搜词背后是微服务本地联调的常见需求。IDEA里不需要复制多份代码只需要给同一个服务配置多个启动器在Run/Debug Configurations里复制一个启动配置然后在VM options里加-Dserver.port8003再启动一次这个服务就以另外一个端口注册到Nacos了。我经常用这个方式在本地模拟同一个服务的多个实例测试负载均衡和故障转移。看到Nacos控制台里出现两个IP:Port的实例说明这个技能点你入门了。2.4 一个典型的微服务架构图到底画什么很多人在简历上画微服务架构图画了满满一页面试官一看就皱眉头。架构图不是越复杂越好而是要让面试官在30秒内看懂你系统的分层和数据流向。我个人建议一张合格的架构图至少包含四层入口层Nginx或SLB、网关层Spring Cloud Gateway、业务服务层user-service、order-service等、基础设施层Nacos、Sentinel、Seata、Redis、MQ、MySQL。用箭头把调用关系画清楚旁边标上每个组件的用途比如“Nacos注册与配置”“Sentinel限流与熔断”“Seata分布式事务”。如果你不想从零画可以参考若依微服务plus这种开源脚手架的模块划分思路。它把系统拆成了网关、认证、系统、文件、日志等标准模块非常适合学习微服务模块边界怎么定。但注意学习脚手架的目的不是照搬而是理解它为什么切这么细。真正的项目里模块不是越细越好拆得太细会导致调用链加长、事务问题变多、运维复杂我见过最夸张的项目把十几个人的小团队硬拆了三十多个微服务最后天天在处理链路问题。3. 分布式锁Redis和ZooKeeper两套方案面试必问3.1 为什么JVM的锁不够用跨进程并发是本质原因分布式锁出现的根本原因是单机上的synchronized和Lock只能锁住当前JVM进程内的线程。微服务部署了多个实例后同一个服务可能有两三个进程同时在跑“库存扣减”这种操作如果只在方法上加synchronized每个实例都只能锁住自己三个实例同时拿到的库存都是10各自扣完再写回库存就变成9而不是7。分布式锁就是在多个进程都能访问到的公共组件上做互斥。传统方案依赖数据库唯一约束或悲观锁但性能和可用性都不理想现在的主流方案集中在Redis和ZooKeeper上。判断一个分布式锁靠不靠谱可以从四个维度看互斥性同一时刻只有一个客户端能拿到锁、安全性锁只能被持有者释放不能误删别人的锁、可用性不会因为某个节点挂掉导致所有客户端拿不到锁、可重入性同一客户端可以重复获取同一把锁而不死锁。3.2 Redis分布式锁的完整链路从SET NX到RedissonRedis实现分布式锁核心命令是SET key value NX EX。NX表示只有当key不存在时才设置成功EX设置过期时间两个参数必须同时出现在一条命令里这是面试官最爱挖的坑之一。如果你用setnx和expire两条命令分开执行中间一旦进程崩溃锁没有设置过期时间就会变成死锁其他线程永远拿不到锁。这属于回答了“考点”但暴露了“没实践”的典型错误。拿到锁之后的第二个坑是释放锁。如果释放时只执行del key有可能删掉了别人刚获取的锁。正确做法是value存一个唯一标识比如UUID释放时先比较value是否一致一致才删除。这个“比较删除”的过程必须是原子的实现方式是Lua脚本if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end这只是最基础的实现。生产环境里更推荐直接使用Redisson框架它提供了一个“看门狗”机制如果业务还没执行完分布式锁的过期时间会被自动续期默认每10秒检查一次如果锁还在持有中就续到30秒避免业务超时后锁自动释放另一个线程进来造成并发问题。Redisson对可重入也做了支持同一个线程可以多次加锁。如果要自己实现一个简化版可重入锁可以用ThreadLocal记录当前线程和重入次数加锁时判断当前线程是否已经持有锁是则加计数不重复执行Redis命令。3.3 ZooKeeper分布式锁临时顺序节点加Watch机制ZooKeeper实现分布式锁的思路和Redis完全不同。它基于临时顺序节点客户端在指定锁路径下创建临时顺序节点然后获取当前路径下所有子节点列表判断自己创建的节点是不是序号最小的那个如果是就拿到锁不是就监听序号排在自己前一位的那个节点。一旦前一个节点被删除释放锁或持有者宕机ZooKeeper会通知监听它的下一个节点去检查自己是否轮到了这就是Watch机制。临时节点的好处是即使客户端进程挂了ZooKeeper也会自动删除它的临时节点锁自然释放不需要额外设置过期时间。Redis的锁面临“客户端崩溃导致锁等到超时才能释放”的问题在ZooKeeper方案里基本不存在。两种方案的选择我给一个相对客观的对比维度Redis分布式锁ZooKeeper分布式锁性能高基于内存操作中等节点创建和监听有开销实现复杂度低但要注意过期时间、续期等细节中等需要理解临时顺序节点和Watch可靠性主从切换可能丢失锁临时节点机制更稳适用场景高并发、可接受极小概率锁丢失对锁可靠性要求很高的场景客户端生态Redisson成熟开箱即用Curator封装较好3.4 面试追问锁超时、锁续期、重入、脑裂怎么答面试官通常会顺着“Redis分布式锁”连环追问四个问题。第一个是“如果业务执行时间超过锁的过期时间怎么办”答案是Redisson的看门狗自动续期如果没有看门狗就要自己开一个守护线程定时续期业务结束后取消续期并释放锁。第二个是“锁的可重入怎么实现”答案是ThreadLocal记录线程标识和重入次数。第三个是“主从复制场景下锁丢失了怎么办”Redis主节点刚写入锁还没同步到从节点主节点挂了从节点顶上后锁就丢了这是单机Redis锁的固有问题RedLock试图解决但没有被广泛认可因为它在客户端和多个独立节点之间做多数派确认复杂度很高且仍有争议面试里能说出“RedLock理论可行但工程上用得少大家更愿意用ZooKeeper或者接受这个极小概率风险”就算过关。第四个是“GC停顿导致的锁失效问题”JVM发生长时间的Full GC时业务线程被暂停锁已经过期自动释放了其他线程进来执行恢复后原线程继续执行就出现并发这种情况只能尽量缩短GC停顿或者使用更可靠的锁方案面试时重点说清原因即可。4. 分布式事务CAP、BASE、2PC、TCC、Seata一次理清4.1 CAP与BASE分布式事务的理论底座分布式事务的所有方案本质上都是在CAP之间做取舍。CAP的三项是一致性Consistency、可用性Availability、分区容错性Partition tolerance。注意一个常见误区不是“三选二”而是网络分区在后端系统里一定会发生所以P是必须选的你真正要在C和A之间做选择。如果你选了CP比如ZooKeeper和etcd那么当节点间无法通信时为保证数据一致系统会拒绝写入请求以保证多数派节点状态一致代价是短时间不可用。如果你选了AP比如Eureka和Redis集群系统会继续提供服务但可能出现某些节点数据暂时不一致的情况后续再慢慢同步达到最终一致。BASE理论是对AP的落地解读基本可用Basically Available、软状态Soft state、最终一致Eventually consistent。你在回答分布式事务时如果能把每个方案对应到“它牺牲了什么、换来了什么”面试官基本就能确定你是真的理解而不是背概念。4.2 2PC和3PC的演进逻辑为什么两阶段提交很难用两阶段提交2PC是分布式事务的经典协议。第一阶段“准备”事务协调者询问所有参与节点能不能提交参与节点执行本地事务但不提交然后把结果告诉协调者。第二阶段“提交/回滚”如果所有参与节点都准备好了协调者通知所有人提交只要有一个人没准备好通知所有人回滚。2PC看起来逻辑很简单但实际用起来很痛苦。第一个痛点是阻塞第一阶段锁住资源期间所有参与者都在等待协调者的最终指令这个等待是同步阻塞的资源占用严重。第二个痛点是协调者单点如果协调者在第二阶段挂了参与者就卡在“准备好了但不知道提交还是回滚”的状态只能一直等下去。第三个痛点是数据不一致第二阶段如果网络故障部分参与者收到提交指令部分没有数据就不一致了2PC没有机制去修复这种状态。3PC引入了超时机制把第一阶段拆成CanCommit和PreCommit两步参与者在等待超时后可以自行决定提交解决了一部分阻塞问题但也带来了新的不一致风险所以实际使用的系统很少。面试答到这里可以顺势说一句“所以业界真正落地时更倾向于用TCC、Saga这类柔性事务方案”就自然衔接到了下一个考点。4.3 TCC、Saga、本地消息表、最大努力通知柔性事务的四个方向2PC这类刚性事务方案在微服务里不好用是因为微服务跨进程跨数据库锁资源太久会拖垮接口性能。于是业界转向了柔性事务核心思路是“牺牲强一致换取最终一致”常见路径有四条。第一条是TCCTry-Confirm-Cancel把一笔业务拆成三步Try阶段尝试执行检查资源并预留比如冻结库存10件Confirm阶段确认执行真正扣减预留资源把冻结库存变成已扣减Cancel阶段取消执行释放预留资源回滚冻结的库存。TCC对业务侵入性强每个操作都要写三个方法但控制力强适合金融支付这类场景。第二条是Saga把一个长事务拆成一串本地事务每个本地事务都有对应的补偿事务后面失败了就逆序执行补偿操作。Saga没有Try阶段没有资源预留实现相对简洁但做不到隔离性适合订单流程这类容忍中间状态的场景。第三条是本地消息表将业务操作和消息记录放在同一个本地事务里业务成功则消息表必然多一条待发送记录然后通过后台任务把消息发给MQ或直接投递给下游下游消费成功后删除或标记这条消息。第四条是最大努力通知主要面向支付回调这类场景发送方不保证一次成功而是按固定间隔重试N次直到接收方成功确认这种方式虽然成功率很高但接收方必须做好幂等。我整理了一个对比表方便你记忆方案一致性强度业务侵入度实现复杂度典型场景2PC/3PC强一致低高协议重、易阻塞少数需要严格一致的核心场景TCC最终一致高每个操作三个方法高支付、资金类需要资源预留Saga最终一致中中订单创建、长流程业务本地消息表最终一致中引入消息表中低跨服务状态同步最大努力通知最终一致低低支付结果通知、回调4.4 Seata的原理TC、TM、RM和AT模式的执行链路Seata是Java生态里最主流的分布式事务框架面试必问它的角色划分和AT模式原理。Seata有三个角色TC事务协调器是独立的Server负责全局事务的提交和回滚TM事务管理器在发起方业务代码里负责开启全局事务和提交/回滚全局事务RM资源管理器在每个参与事务的服务里负责管理分支事务的资源向TC注册分支并汇报状态。AT模式是Seata的招牌它的核心是“无侵入”。第一阶段RM执行本地事务比如执行一条UPDATE语句Seata会拿着UNDO_LOG反向生成回滚日志然后把修改前和修改后的镜像一起写入UNDO_LOG表跟业务数据在同一个本地事务里提交。第二阶段如果全局提交RM只需异步删除UNDO_LOG如果全局回滚RM读取UNDO_LOG用反向SQL把数据恢复成修改前的样子。AT模式看起来神奇但有一个重要限制就是它需要数据库层面的支持且有全局锁的代价性能会比直接本地事务下降不少。所以面试常问“Seata AT和TCC怎么选”答案是如果对业务代码侵入少、性能要求没那么极端、数据库是关系型且SQL可解析优先AT如果业务必须高度定制、或者底层是NoSQL只能TCC。4.5 下单扣库存的经典场景实际项目怎么落地订单和库存的分布式事务是面试里最常考的场景题。一个典型的下单流程创建订单、扣减库存、生成支付单。这三个操作在微服务里通常属于订单服务和库存服务跨了两个服务两个库不能用本地事务。如果面试官问你会怎么做我建议你分阶梯回答第一步接受最终一致性方案明确“下单成功后给用户返回成功但内部可以异步对账”第二步采用本地消息表或事务消息订单服务在创建订单的同一个本地事务里写入一条“扣库存消息”然后异步发送给库存服务第三步库存服务消费消息扣减库存如果扣减成功回执确认如果失败重试第四步引入定时任务巡检把超时未完成的订单状态从“处理中”改成“已失败”释放库存。这套链路能覆盖绝大多数业务场景而且每一步都有现成技术栈支撑是面试里比“我要用Seata”更有说服力的回答因为它体现了对异步、重试、幂等、对账这些手段的理解。5. 分布式领域的高频考点ID、任务、缓存、会话、幂等5.1 分布式ID的选型为什么不能只用数据库自增单体架构用数据库自增主键完全没问题但拆了多个服务、多个库之后每个库各自自增就会出现ID冲突所以需要全局唯一的分布式ID。分布式ID常见的方案有四类UUID、数据库号段模式、叶子服务Leaf、雪花算法。UUID最简单本地生成性能高但结果是字符串作为数据库主键索引效率低且太长。数据库号段模式是每次从数据库取一段ID比如1000个缓存在本地内存用完了再取一段性能和可靠性都不错Leaf的号段模式就是这么实现的缺点是依赖数据库数据库挂了发号能力就没了。雪花算法Snowflake是实际项目里用得最多的方案它生成的ID是一个64位的Long第1位固定041位毫秒时间戳10位机器ID12位同毫秒内的序列号单机一毫秒能生成4096个不重复ID。雪花算法有个著名的坑是时钟回拨如果服务器时间往回跳了生成的ID可能跟之前重复。解决办法通常有三种短时间回拨就等待时间追平超过阈值就告警并停止发号或把最后一位时间戳改用其他策略。面试能答出这个坑并给出“等待告警”的处理方案一般就能让面试官满意。5.2 分布式任务调度多实例下的定时任务不能各自为战先想一个场景订单超时关单的定时任务服务部署了三个实例如果你在每个实例上都跑同一个Spring定时任务那每天凌晨三点三个实例同时扫一遍超时订单同一笔订单可能被处理三次。想要避免重复执行可以做MySQL行锁或Redis分布式锁但更专业的解法是用分布式任务调度平台。目前国内用得最多的是XXL-JOB。它的核心模型是调度中心和执行器调度中心负责触发任务执行器部署在业务服务里负责实际执行调度中心通过HTTP回调把任务分配给某个执行器实例。它的关键能力有几个路由策略轮询、随机、故障转移、分片广播把一个任务拆成多片每台机器处理一部分数据适合大数据量的批处理、失败重试、动态调整执行时间。如果你在面试中说“我们用了XXL-JOB”面试官很可能会追问“分片广播怎么做”。答案是在任务方法里获取当前执行器的分片参数shardingIndex和shardingTotal然后按ID取模路由数据比如总共有10个执行器每台机器只处理ID取模等于自己编号的那部分数据这样既能横向扩展也不会重复处理。5.3 分布式缓存穿透、击穿、雪崩与一致性Redis在分布式场景下几乎必然出现面试也几乎必然会问缓存三大问题。缓存穿透是查询一个不存在的key请求直接打到数据库要解决可以在缓存里存空值或者用布隆过滤器拦截不存在的ID。缓存击穿是某个热点key突然过期大量并发请求同时打到数据库解决方案是热点key永不过期或者在更新时用互斥锁控制单个请求去查库。缓存雪崩是大批量key在同一时间过期或者Redis集群整体宕机请求全量打到数据库解决方法是过期时间加随机值打散或者做多级缓存降低Redis故障时对数据库的冲击。还有一个容易被追问的难点是缓存和数据库的一致性。常用的Cache Aside模式是读时先查缓存缓存没有就读数据库再回填写时先更新数据库再删除缓存。但“先更库再删缓存”在极端情况下还是可能删失败导致脏数据。工程上的常见做法是延迟双删更新数据库后先删除一次缓存过几百毫秒再删除一次把中间并发写入的旧值清掉更可靠的做法是订阅数据库Binlog比如用Canal异步去删除或更新缓存这样即使删失败了也能通过重试来兜底。5.4 分布式会话与统一鉴权JWT、单点登录、第三方登录微服务拆开之后用户登录状态怎么办传统的Session存在单个应用内存里请求打到另一个服务实例上就找不到Session了。解决方案通常有三个方向Session复制、Redis集中存储Session、JWT无状态令牌。Session复制只适合小规模集群Redis存储Session是目前比较通用的做法而JWT是现在接口鉴权的主流。JWT最大的特点是服务端无状态用户登录成功认证服务签发一个包含用户ID和过期时间的签名令牌业务服务只需要校验签名不需要查数据库就能确认用户身份。它的缺点是令牌一旦签发无法主动失效除非引入黑名单机制所以敏感操作还得依赖短过期时间加刷新令牌。在微服务架构里网关会统一校验Token通过之后把用户信息透传到下游服务这就是统一鉴权。如果你在项目里做过微信服务号登录可以把它作为第三方OAuth登录的一个典型案例来回答前端跳转微信授权页微信回调携带code后端拿code向微信服务端换取用户openid和access_token再用这部分信息找到或创建本地用户最终签发自己的JWT。这套流程里JWT就是微服务内部会话的统一载体网关层负责校验业务服务拿到用户ID即可。5.5 幂等性设计高并发接口最容易被忽视的一环幂等性在分布式场景里非常重要因为网络重试、MQ重复投递、用户双击提交都会导致同一个请求被处理多次。一个典型的例子用户下单时网络超时前端自动重试如果后端没有幂等处理就会生成两笔订单。常见的幂等实现方式有三种第一种是数据库唯一索引用业务单号或请求ID做唯一约束第二次插入直接报冲突用异常来识别重复第二种是Token机制前端提交前先向后端申请一个一次性Token后端处理完立即删除Token第二次提交就校验失败第三种是状态机订单状态从“待支付”到“已支付”再到“已发货”只有合法的状态迁移才允许执行重复的“支付”操作会因为状态不匹配而拒绝。面试回答时最好结合场景说比如“我们在支付回调接口用了Token状态机双重幂等收到的回调先校验Token再判断订单状态只有待支付状态才能更新为已支付”这样比单纯背方案更有说服力。6. 面试答题的组织方法别背八股要讲架构决策6.1 一个高分的微服务回答是怎么组织起来的技术面试到后来面试官其实听不太进去一个一个孤立的知识点他更想听你分析问题和做技术取舍的方式。我建议你用“先结论、再场景、后方案、最后代价”的结构答题。举一个例子如果面试官问“为什么你们要用微服务”不要劈头就答“微服务有独立部署、独立扩展等优点”而是先说结论“我认为微服务适合业务复杂度和团队规模都比较大的场景”然后说场景“当时单体应用的代码库快撑不住了发布要协调很多人”再说方案“我们按业务域把系统拆成订单、用户、支付等几个服务”最后说代价“拆了之后麻烦事变多了分布式事务、分布式锁、链路排查都要重新搞所以不是万能的”。这个结构体现的是技术决策能力而不是背诵能力。6.2 面试官最爱的连环追问把坑提前填好我整理了几个几乎百发百中的连环追问套路。第一个是分布式锁场景从“用过Redis分布式锁吗”一路追到“为什么不能用setnx加expire”、“业务超时了怎么办”、“主从切换会丢锁吗”、“GC停顿导致锁失效怎么解决”。这一套要是能顺畅答完说明你真的研究过。第二个是Nacos场景从“Nacos是做什么的”追到“AP和CP区别”“服务下线怎么感知”“Nacos挂了怎么办”。第三个是Seata场景从“分布式事务怎么解决”追到“AT模式一阶段做了什么”、“全局锁是什么”、“为什么不建议所有场景都用Seata”。每个追问我前面的章节都给了要点答题时注意“先答是什么再答为什么最后给替代方案”。6.3 版本、工具、调试避坑细节决定成败最后这部分是我自己踩坑总结的经验不一定在八股里但面试和工作中都很实用。版本兼容性是最容易出问题的。如果你用JDK 8Spring Boot 2.7.x搭配Spring Cloud 2021.x和Spring Cloud Alibaba 2021.0.5.0是我实测最稳的组合。JDK 17以上就要用Spring Boot 3.x和Spring Cloud 2022.xSpring Cloud Alibaba也要升级到2022.0.0.0否则启动报错会让你怀疑人生。Nacos 2.x和1.x的客户端通信协议不同本地调试时最好统一Nacos Server和客户端依赖的版本。本地多实例调试IDEA的用法我在2.3已经说了这里再补一个细节不同实例除了端口不同最好在启动参数里加上不同的-Dspring.application.instance_id标识否则Nacos控制台里会出现两个同名的实例容易混淆。分布式相关工具也可以帮你拓宽知识点jmeter可以做分布式压测Controller节点负责调度Agent节点负责实际发压适合模拟多机器并发请求Hadoop伪分布式模式是用一台机器模拟分布式环境用来理解大数据分布式存储和计算的最小成本方案分布式爬虫可以用Scrapy加Redis去重来实现URL调度和去重Git本身就是分布式版本控制系统的典型代表每个开发者的本地仓库都是完整历史仓库。这些虽然不全属于Java微服务的范畴但聊到“分布式”这个话题时能讲出来会显得你知识面很宽。7. 写在最后八股之外动手搭一次比背十遍都管用说实话微服务和分布式这块内容光靠看文章很难真正消化。我自己带的很多新人刚开始背Redis分布式锁背得很熟一让写Redisson配置就卡住了一让排查Nacos服务掉线就懵了。所以我最后的建议是花两三个晚上用2.3那套骨架把项目搭出来注册两个服务用网关把请求转发过去再尝试用Redisson写一个分布式锁扣库存用Seata把下单和扣库存串起来。踩过启动报错、版本冲突、配置缺失这些坑之后你对这套体系的记忆是看十篇八股都换不来的。面试的时候我的体会是面试官并不指望你什么都会他更看重你在遇到不懂的问题时能不能给出合理的分析路径。比如被问到不熟悉的技术你可以说“这个组件我没在生产环境用过但我从原理上判断它大概是这样工作的如果是我的话我会先用一个最小demo验证一下”。这种回答方式比支支吾吾或者硬编一个答案要加分得多。把上面这些知识点理解透再配合一两次真实的动手实践微服务和分布式这块你基本就能过关了。
微服务与分布式面试核心：从Nacos到Redis分布式锁与Seata实战
1. 微服务与分布式到底在聊什么先把面试的底层逻辑搞清楚1.1 面试官问微服务他真正想听到的并不是“答得全”“微服务”“分布式”这两个词在Java后端面试里几乎场场出现。但说实话很多人背了半个月的八股一开口还是被面试官一句话问住“你这个服务拆了之后数据一致性怎么办”然后就没有然后了。我个人的看法是面试官问微服务真正想考察的不是你会不会背“微服务就是把大系统拆成小服务”这个定义而是你有没有踩过分布式环境下的坑有没有理解拆服务之后带来的连锁代价。微服务带来的好处——独立部署、独立扩展、故障隔离、团队自治——这些大家都知道。真正的分水岭在于当你拆完之后原来单体应用里简单的事情变得不再简单了服务之间怎么找到对方一个请求挂了怎么处理分布式事务怎么保证并发调用下怎么防重复、防超卖。所以这篇内容我不打算给你写一个平铺直叙的知识点汇总而是按照“面试官喜欢问什么、你该怎么答、为什么这么答”的线索来整理。你把这套逻辑顺明白了比背一百个名词解释管用。1.2 分布式架构的核心挑战是同一个网络不可靠在聊任何具体技术之前我建议你先想明白一个底层逻辑分布式的本质就是把原本在一个进程里完成的调用变成了跨网络、跨进程的调用。网络是不稳定的延迟是不确定的节点可能宕机消息可能丢也可能重复。这就引出了分布式系统最核心的矛盾在不可靠的网络之上如何提供可靠的服务能力。这也是为什么你会发现所有分布式相关的技术点最后都能归结到几个共性问题上可用性、一致性、性能、幂等。注册中心解决的是服务怎么被发现分布式锁解决的是多个节点不能同时干同一件事分布式事务解决的是多个节点的数据要么都对、要么都别改分布式ID解决的是多个节点生成的编号不能重复。你想清楚每一个技术点到底在解决哪个共性问题面试的时候就不会被问乱了。2. Spring Cloud Alibaba 生态注册、配置、网关、限流一次讲透2.1 Nacos 同时承担注册中心和配置中心为什么它能成为主流现在的微服务面试Nacos几乎是绕不开的。它的定位是“服务注册中心 配置中心”二合一。服务注册中心的作用通俗点说就是让服务之间能互相找到服务提供方启动时把自己的IP和端口注册到Nacos服务消费方去Nacos拉取服务列表然后发起调用。配置中心则把散落在各个服务里的配置统一管理起来改了配置不用重启服务就能生效。面试里常问的一个细节是Nacos的AP和CP模式切换。Nacos基于临时实例做服务注册时走的是AP模式优先保证可用性就算集群里有节点失联剩下的节点依然能响应注册和查询如果使用持久化实例则支持CP模式优先保证数据一致性。这个设计跟Eureka和ZooKeeper的区别逻辑一致Eureka天生就是APZooKeeper天生就是CP而Nacos把两种模式都做了。这里你最好能答出“为什么注册中心一般选AP而不是CP”因为注册中心最重要的能力是让服务间还能调用就算注册信息短暂不一致也比注册中心宕机导致整个系统瘫痪要好。另一个高频追问是“服务下线了怎么感知”。心跳机制是基础答案服务实例会定时向Nacos发送心跳超过15秒没收到就标记为不健康30秒没收到就剔除。但面试官通常还会追问“如果Nacos本身挂了呢”这是一个非常典型的挖坑问题完整答案我在第6部分给你拆解。2.2 Spring Cloud Gateway路由、过滤器、跨域和限流API网关是微服务架构里的流量入口。Spring Cloud Gateway的核心模型就三个东西路由Route、断言Predicate、过滤器Filter。路由定义了“什么请求转发到哪个服务”断言是路由的匹配条件比如按路径、按Header、按参数匹配过滤器则是请求在转发前后经过的处理逻辑。面试里关于网关问得最多的是“网关做了哪些事”。我建议你这样分层回答第一层是基础路由转发把客户端的请求分发给下游服务第二层是横切关注点包括统一鉴权、统一日志、跨域处理、灰度发布第三层是流量治理包括限流、熔断、超时控制。这个分层回答的好处是能体现出你的架构思维而不是零散地背几个名词。限流是网关的高频考点核心算法有令牌桶和漏桶两种。令牌桶允许一定的突发流量因为桶里可以累积令牌漏桶则是匀速流出适合保护下游系统。Spring Cloud Gateway自带的RequestRateLimiter基于Redis实现使用了令牌桶算法。真到了生产环境我建议把限流阈值、熔断阈值这些参数配置到Nacos里这样压测完或者活动大促时调阈值不用发版重启。2.3 用 IDEA 从零搭一个微服务骨架多模块和多实例启动是基本功这个部分我给一个可以直接照做的最小骨架方案。用IDEA新建一个Maven父工程然后创建这几个子模块gateway模块端口8000、user-service模块端口8001、order-service模块端口8002、common模块放公共工具类。父工程POM里管理Spring Boot和Spring Cloud Alibaba的版本注意Spring Boot 2.7.x对应Spring Cloud 2021.x、Spring Cloud Alibaba 2021.0.5.0这套版本组合我实际用过比较稳定。每个服务模块引入spring-cloud-starter-alibaba-nacos-discovery在application.yml里配置Nacos地址和服务名。这里有个新手很容易卡住的地方Nacos要先本地启动。去Nacos官网下载Server包解压后运行startup.cmdWindows或者startup.shLinux默认跑在8848端口然后打开控制台就能看到注册上来的服务。“一个模块起多个实例”这个热搜词背后是微服务本地联调的常见需求。IDEA里不需要复制多份代码只需要给同一个服务配置多个启动器在Run/Debug Configurations里复制一个启动配置然后在VM options里加-Dserver.port8003再启动一次这个服务就以另外一个端口注册到Nacos了。我经常用这个方式在本地模拟同一个服务的多个实例测试负载均衡和故障转移。看到Nacos控制台里出现两个IP:Port的实例说明这个技能点你入门了。2.4 一个典型的微服务架构图到底画什么很多人在简历上画微服务架构图画了满满一页面试官一看就皱眉头。架构图不是越复杂越好而是要让面试官在30秒内看懂你系统的分层和数据流向。我个人建议一张合格的架构图至少包含四层入口层Nginx或SLB、网关层Spring Cloud Gateway、业务服务层user-service、order-service等、基础设施层Nacos、Sentinel、Seata、Redis、MQ、MySQL。用箭头把调用关系画清楚旁边标上每个组件的用途比如“Nacos注册与配置”“Sentinel限流与熔断”“Seata分布式事务”。如果你不想从零画可以参考若依微服务plus这种开源脚手架的模块划分思路。它把系统拆成了网关、认证、系统、文件、日志等标准模块非常适合学习微服务模块边界怎么定。但注意学习脚手架的目的不是照搬而是理解它为什么切这么细。真正的项目里模块不是越细越好拆得太细会导致调用链加长、事务问题变多、运维复杂我见过最夸张的项目把十几个人的小团队硬拆了三十多个微服务最后天天在处理链路问题。3. 分布式锁Redis和ZooKeeper两套方案面试必问3.1 为什么JVM的锁不够用跨进程并发是本质原因分布式锁出现的根本原因是单机上的synchronized和Lock只能锁住当前JVM进程内的线程。微服务部署了多个实例后同一个服务可能有两三个进程同时在跑“库存扣减”这种操作如果只在方法上加synchronized每个实例都只能锁住自己三个实例同时拿到的库存都是10各自扣完再写回库存就变成9而不是7。分布式锁就是在多个进程都能访问到的公共组件上做互斥。传统方案依赖数据库唯一约束或悲观锁但性能和可用性都不理想现在的主流方案集中在Redis和ZooKeeper上。判断一个分布式锁靠不靠谱可以从四个维度看互斥性同一时刻只有一个客户端能拿到锁、安全性锁只能被持有者释放不能误删别人的锁、可用性不会因为某个节点挂掉导致所有客户端拿不到锁、可重入性同一客户端可以重复获取同一把锁而不死锁。3.2 Redis分布式锁的完整链路从SET NX到RedissonRedis实现分布式锁核心命令是SET key value NX EX。NX表示只有当key不存在时才设置成功EX设置过期时间两个参数必须同时出现在一条命令里这是面试官最爱挖的坑之一。如果你用setnx和expire两条命令分开执行中间一旦进程崩溃锁没有设置过期时间就会变成死锁其他线程永远拿不到锁。这属于回答了“考点”但暴露了“没实践”的典型错误。拿到锁之后的第二个坑是释放锁。如果释放时只执行del key有可能删掉了别人刚获取的锁。正确做法是value存一个唯一标识比如UUID释放时先比较value是否一致一致才删除。这个“比较删除”的过程必须是原子的实现方式是Lua脚本if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end这只是最基础的实现。生产环境里更推荐直接使用Redisson框架它提供了一个“看门狗”机制如果业务还没执行完分布式锁的过期时间会被自动续期默认每10秒检查一次如果锁还在持有中就续到30秒避免业务超时后锁自动释放另一个线程进来造成并发问题。Redisson对可重入也做了支持同一个线程可以多次加锁。如果要自己实现一个简化版可重入锁可以用ThreadLocal记录当前线程和重入次数加锁时判断当前线程是否已经持有锁是则加计数不重复执行Redis命令。3.3 ZooKeeper分布式锁临时顺序节点加Watch机制ZooKeeper实现分布式锁的思路和Redis完全不同。它基于临时顺序节点客户端在指定锁路径下创建临时顺序节点然后获取当前路径下所有子节点列表判断自己创建的节点是不是序号最小的那个如果是就拿到锁不是就监听序号排在自己前一位的那个节点。一旦前一个节点被删除释放锁或持有者宕机ZooKeeper会通知监听它的下一个节点去检查自己是否轮到了这就是Watch机制。临时节点的好处是即使客户端进程挂了ZooKeeper也会自动删除它的临时节点锁自然释放不需要额外设置过期时间。Redis的锁面临“客户端崩溃导致锁等到超时才能释放”的问题在ZooKeeper方案里基本不存在。两种方案的选择我给一个相对客观的对比维度Redis分布式锁ZooKeeper分布式锁性能高基于内存操作中等节点创建和监听有开销实现复杂度低但要注意过期时间、续期等细节中等需要理解临时顺序节点和Watch可靠性主从切换可能丢失锁临时节点机制更稳适用场景高并发、可接受极小概率锁丢失对锁可靠性要求很高的场景客户端生态Redisson成熟开箱即用Curator封装较好3.4 面试追问锁超时、锁续期、重入、脑裂怎么答面试官通常会顺着“Redis分布式锁”连环追问四个问题。第一个是“如果业务执行时间超过锁的过期时间怎么办”答案是Redisson的看门狗自动续期如果没有看门狗就要自己开一个守护线程定时续期业务结束后取消续期并释放锁。第二个是“锁的可重入怎么实现”答案是ThreadLocal记录线程标识和重入次数。第三个是“主从复制场景下锁丢失了怎么办”Redis主节点刚写入锁还没同步到从节点主节点挂了从节点顶上后锁就丢了这是单机Redis锁的固有问题RedLock试图解决但没有被广泛认可因为它在客户端和多个独立节点之间做多数派确认复杂度很高且仍有争议面试里能说出“RedLock理论可行但工程上用得少大家更愿意用ZooKeeper或者接受这个极小概率风险”就算过关。第四个是“GC停顿导致的锁失效问题”JVM发生长时间的Full GC时业务线程被暂停锁已经过期自动释放了其他线程进来执行恢复后原线程继续执行就出现并发这种情况只能尽量缩短GC停顿或者使用更可靠的锁方案面试时重点说清原因即可。4. 分布式事务CAP、BASE、2PC、TCC、Seata一次理清4.1 CAP与BASE分布式事务的理论底座分布式事务的所有方案本质上都是在CAP之间做取舍。CAP的三项是一致性Consistency、可用性Availability、分区容错性Partition tolerance。注意一个常见误区不是“三选二”而是网络分区在后端系统里一定会发生所以P是必须选的你真正要在C和A之间做选择。如果你选了CP比如ZooKeeper和etcd那么当节点间无法通信时为保证数据一致系统会拒绝写入请求以保证多数派节点状态一致代价是短时间不可用。如果你选了AP比如Eureka和Redis集群系统会继续提供服务但可能出现某些节点数据暂时不一致的情况后续再慢慢同步达到最终一致。BASE理论是对AP的落地解读基本可用Basically Available、软状态Soft state、最终一致Eventually consistent。你在回答分布式事务时如果能把每个方案对应到“它牺牲了什么、换来了什么”面试官基本就能确定你是真的理解而不是背概念。4.2 2PC和3PC的演进逻辑为什么两阶段提交很难用两阶段提交2PC是分布式事务的经典协议。第一阶段“准备”事务协调者询问所有参与节点能不能提交参与节点执行本地事务但不提交然后把结果告诉协调者。第二阶段“提交/回滚”如果所有参与节点都准备好了协调者通知所有人提交只要有一个人没准备好通知所有人回滚。2PC看起来逻辑很简单但实际用起来很痛苦。第一个痛点是阻塞第一阶段锁住资源期间所有参与者都在等待协调者的最终指令这个等待是同步阻塞的资源占用严重。第二个痛点是协调者单点如果协调者在第二阶段挂了参与者就卡在“准备好了但不知道提交还是回滚”的状态只能一直等下去。第三个痛点是数据不一致第二阶段如果网络故障部分参与者收到提交指令部分没有数据就不一致了2PC没有机制去修复这种状态。3PC引入了超时机制把第一阶段拆成CanCommit和PreCommit两步参与者在等待超时后可以自行决定提交解决了一部分阻塞问题但也带来了新的不一致风险所以实际使用的系统很少。面试答到这里可以顺势说一句“所以业界真正落地时更倾向于用TCC、Saga这类柔性事务方案”就自然衔接到了下一个考点。4.3 TCC、Saga、本地消息表、最大努力通知柔性事务的四个方向2PC这类刚性事务方案在微服务里不好用是因为微服务跨进程跨数据库锁资源太久会拖垮接口性能。于是业界转向了柔性事务核心思路是“牺牲强一致换取最终一致”常见路径有四条。第一条是TCCTry-Confirm-Cancel把一笔业务拆成三步Try阶段尝试执行检查资源并预留比如冻结库存10件Confirm阶段确认执行真正扣减预留资源把冻结库存变成已扣减Cancel阶段取消执行释放预留资源回滚冻结的库存。TCC对业务侵入性强每个操作都要写三个方法但控制力强适合金融支付这类场景。第二条是Saga把一个长事务拆成一串本地事务每个本地事务都有对应的补偿事务后面失败了就逆序执行补偿操作。Saga没有Try阶段没有资源预留实现相对简洁但做不到隔离性适合订单流程这类容忍中间状态的场景。第三条是本地消息表将业务操作和消息记录放在同一个本地事务里业务成功则消息表必然多一条待发送记录然后通过后台任务把消息发给MQ或直接投递给下游下游消费成功后删除或标记这条消息。第四条是最大努力通知主要面向支付回调这类场景发送方不保证一次成功而是按固定间隔重试N次直到接收方成功确认这种方式虽然成功率很高但接收方必须做好幂等。我整理了一个对比表方便你记忆方案一致性强度业务侵入度实现复杂度典型场景2PC/3PC强一致低高协议重、易阻塞少数需要严格一致的核心场景TCC最终一致高每个操作三个方法高支付、资金类需要资源预留Saga最终一致中中订单创建、长流程业务本地消息表最终一致中引入消息表中低跨服务状态同步最大努力通知最终一致低低支付结果通知、回调4.4 Seata的原理TC、TM、RM和AT模式的执行链路Seata是Java生态里最主流的分布式事务框架面试必问它的角色划分和AT模式原理。Seata有三个角色TC事务协调器是独立的Server负责全局事务的提交和回滚TM事务管理器在发起方业务代码里负责开启全局事务和提交/回滚全局事务RM资源管理器在每个参与事务的服务里负责管理分支事务的资源向TC注册分支并汇报状态。AT模式是Seata的招牌它的核心是“无侵入”。第一阶段RM执行本地事务比如执行一条UPDATE语句Seata会拿着UNDO_LOG反向生成回滚日志然后把修改前和修改后的镜像一起写入UNDO_LOG表跟业务数据在同一个本地事务里提交。第二阶段如果全局提交RM只需异步删除UNDO_LOG如果全局回滚RM读取UNDO_LOG用反向SQL把数据恢复成修改前的样子。AT模式看起来神奇但有一个重要限制就是它需要数据库层面的支持且有全局锁的代价性能会比直接本地事务下降不少。所以面试常问“Seata AT和TCC怎么选”答案是如果对业务代码侵入少、性能要求没那么极端、数据库是关系型且SQL可解析优先AT如果业务必须高度定制、或者底层是NoSQL只能TCC。4.5 下单扣库存的经典场景实际项目怎么落地订单和库存的分布式事务是面试里最常考的场景题。一个典型的下单流程创建订单、扣减库存、生成支付单。这三个操作在微服务里通常属于订单服务和库存服务跨了两个服务两个库不能用本地事务。如果面试官问你会怎么做我建议你分阶梯回答第一步接受最终一致性方案明确“下单成功后给用户返回成功但内部可以异步对账”第二步采用本地消息表或事务消息订单服务在创建订单的同一个本地事务里写入一条“扣库存消息”然后异步发送给库存服务第三步库存服务消费消息扣减库存如果扣减成功回执确认如果失败重试第四步引入定时任务巡检把超时未完成的订单状态从“处理中”改成“已失败”释放库存。这套链路能覆盖绝大多数业务场景而且每一步都有现成技术栈支撑是面试里比“我要用Seata”更有说服力的回答因为它体现了对异步、重试、幂等、对账这些手段的理解。5. 分布式领域的高频考点ID、任务、缓存、会话、幂等5.1 分布式ID的选型为什么不能只用数据库自增单体架构用数据库自增主键完全没问题但拆了多个服务、多个库之后每个库各自自增就会出现ID冲突所以需要全局唯一的分布式ID。分布式ID常见的方案有四类UUID、数据库号段模式、叶子服务Leaf、雪花算法。UUID最简单本地生成性能高但结果是字符串作为数据库主键索引效率低且太长。数据库号段模式是每次从数据库取一段ID比如1000个缓存在本地内存用完了再取一段性能和可靠性都不错Leaf的号段模式就是这么实现的缺点是依赖数据库数据库挂了发号能力就没了。雪花算法Snowflake是实际项目里用得最多的方案它生成的ID是一个64位的Long第1位固定041位毫秒时间戳10位机器ID12位同毫秒内的序列号单机一毫秒能生成4096个不重复ID。雪花算法有个著名的坑是时钟回拨如果服务器时间往回跳了生成的ID可能跟之前重复。解决办法通常有三种短时间回拨就等待时间追平超过阈值就告警并停止发号或把最后一位时间戳改用其他策略。面试能答出这个坑并给出“等待告警”的处理方案一般就能让面试官满意。5.2 分布式任务调度多实例下的定时任务不能各自为战先想一个场景订单超时关单的定时任务服务部署了三个实例如果你在每个实例上都跑同一个Spring定时任务那每天凌晨三点三个实例同时扫一遍超时订单同一笔订单可能被处理三次。想要避免重复执行可以做MySQL行锁或Redis分布式锁但更专业的解法是用分布式任务调度平台。目前国内用得最多的是XXL-JOB。它的核心模型是调度中心和执行器调度中心负责触发任务执行器部署在业务服务里负责实际执行调度中心通过HTTP回调把任务分配给某个执行器实例。它的关键能力有几个路由策略轮询、随机、故障转移、分片广播把一个任务拆成多片每台机器处理一部分数据适合大数据量的批处理、失败重试、动态调整执行时间。如果你在面试中说“我们用了XXL-JOB”面试官很可能会追问“分片广播怎么做”。答案是在任务方法里获取当前执行器的分片参数shardingIndex和shardingTotal然后按ID取模路由数据比如总共有10个执行器每台机器只处理ID取模等于自己编号的那部分数据这样既能横向扩展也不会重复处理。5.3 分布式缓存穿透、击穿、雪崩与一致性Redis在分布式场景下几乎必然出现面试也几乎必然会问缓存三大问题。缓存穿透是查询一个不存在的key请求直接打到数据库要解决可以在缓存里存空值或者用布隆过滤器拦截不存在的ID。缓存击穿是某个热点key突然过期大量并发请求同时打到数据库解决方案是热点key永不过期或者在更新时用互斥锁控制单个请求去查库。缓存雪崩是大批量key在同一时间过期或者Redis集群整体宕机请求全量打到数据库解决方法是过期时间加随机值打散或者做多级缓存降低Redis故障时对数据库的冲击。还有一个容易被追问的难点是缓存和数据库的一致性。常用的Cache Aside模式是读时先查缓存缓存没有就读数据库再回填写时先更新数据库再删除缓存。但“先更库再删缓存”在极端情况下还是可能删失败导致脏数据。工程上的常见做法是延迟双删更新数据库后先删除一次缓存过几百毫秒再删除一次把中间并发写入的旧值清掉更可靠的做法是订阅数据库Binlog比如用Canal异步去删除或更新缓存这样即使删失败了也能通过重试来兜底。5.4 分布式会话与统一鉴权JWT、单点登录、第三方登录微服务拆开之后用户登录状态怎么办传统的Session存在单个应用内存里请求打到另一个服务实例上就找不到Session了。解决方案通常有三个方向Session复制、Redis集中存储Session、JWT无状态令牌。Session复制只适合小规模集群Redis存储Session是目前比较通用的做法而JWT是现在接口鉴权的主流。JWT最大的特点是服务端无状态用户登录成功认证服务签发一个包含用户ID和过期时间的签名令牌业务服务只需要校验签名不需要查数据库就能确认用户身份。它的缺点是令牌一旦签发无法主动失效除非引入黑名单机制所以敏感操作还得依赖短过期时间加刷新令牌。在微服务架构里网关会统一校验Token通过之后把用户信息透传到下游服务这就是统一鉴权。如果你在项目里做过微信服务号登录可以把它作为第三方OAuth登录的一个典型案例来回答前端跳转微信授权页微信回调携带code后端拿code向微信服务端换取用户openid和access_token再用这部分信息找到或创建本地用户最终签发自己的JWT。这套流程里JWT就是微服务内部会话的统一载体网关层负责校验业务服务拿到用户ID即可。5.5 幂等性设计高并发接口最容易被忽视的一环幂等性在分布式场景里非常重要因为网络重试、MQ重复投递、用户双击提交都会导致同一个请求被处理多次。一个典型的例子用户下单时网络超时前端自动重试如果后端没有幂等处理就会生成两笔订单。常见的幂等实现方式有三种第一种是数据库唯一索引用业务单号或请求ID做唯一约束第二次插入直接报冲突用异常来识别重复第二种是Token机制前端提交前先向后端申请一个一次性Token后端处理完立即删除Token第二次提交就校验失败第三种是状态机订单状态从“待支付”到“已支付”再到“已发货”只有合法的状态迁移才允许执行重复的“支付”操作会因为状态不匹配而拒绝。面试回答时最好结合场景说比如“我们在支付回调接口用了Token状态机双重幂等收到的回调先校验Token再判断订单状态只有待支付状态才能更新为已支付”这样比单纯背方案更有说服力。6. 面试答题的组织方法别背八股要讲架构决策6.1 一个高分的微服务回答是怎么组织起来的技术面试到后来面试官其实听不太进去一个一个孤立的知识点他更想听你分析问题和做技术取舍的方式。我建议你用“先结论、再场景、后方案、最后代价”的结构答题。举一个例子如果面试官问“为什么你们要用微服务”不要劈头就答“微服务有独立部署、独立扩展等优点”而是先说结论“我认为微服务适合业务复杂度和团队规模都比较大的场景”然后说场景“当时单体应用的代码库快撑不住了发布要协调很多人”再说方案“我们按业务域把系统拆成订单、用户、支付等几个服务”最后说代价“拆了之后麻烦事变多了分布式事务、分布式锁、链路排查都要重新搞所以不是万能的”。这个结构体现的是技术决策能力而不是背诵能力。6.2 面试官最爱的连环追问把坑提前填好我整理了几个几乎百发百中的连环追问套路。第一个是分布式锁场景从“用过Redis分布式锁吗”一路追到“为什么不能用setnx加expire”、“业务超时了怎么办”、“主从切换会丢锁吗”、“GC停顿导致锁失效怎么解决”。这一套要是能顺畅答完说明你真的研究过。第二个是Nacos场景从“Nacos是做什么的”追到“AP和CP区别”“服务下线怎么感知”“Nacos挂了怎么办”。第三个是Seata场景从“分布式事务怎么解决”追到“AT模式一阶段做了什么”、“全局锁是什么”、“为什么不建议所有场景都用Seata”。每个追问我前面的章节都给了要点答题时注意“先答是什么再答为什么最后给替代方案”。6.3 版本、工具、调试避坑细节决定成败最后这部分是我自己踩坑总结的经验不一定在八股里但面试和工作中都很实用。版本兼容性是最容易出问题的。如果你用JDK 8Spring Boot 2.7.x搭配Spring Cloud 2021.x和Spring Cloud Alibaba 2021.0.5.0是我实测最稳的组合。JDK 17以上就要用Spring Boot 3.x和Spring Cloud 2022.xSpring Cloud Alibaba也要升级到2022.0.0.0否则启动报错会让你怀疑人生。Nacos 2.x和1.x的客户端通信协议不同本地调试时最好统一Nacos Server和客户端依赖的版本。本地多实例调试IDEA的用法我在2.3已经说了这里再补一个细节不同实例除了端口不同最好在启动参数里加上不同的-Dspring.application.instance_id标识否则Nacos控制台里会出现两个同名的实例容易混淆。分布式相关工具也可以帮你拓宽知识点jmeter可以做分布式压测Controller节点负责调度Agent节点负责实际发压适合模拟多机器并发请求Hadoop伪分布式模式是用一台机器模拟分布式环境用来理解大数据分布式存储和计算的最小成本方案分布式爬虫可以用Scrapy加Redis去重来实现URL调度和去重Git本身就是分布式版本控制系统的典型代表每个开发者的本地仓库都是完整历史仓库。这些虽然不全属于Java微服务的范畴但聊到“分布式”这个话题时能讲出来会显得你知识面很宽。7. 写在最后八股之外动手搭一次比背十遍都管用说实话微服务和分布式这块内容光靠看文章很难真正消化。我自己带的很多新人刚开始背Redis分布式锁背得很熟一让写Redisson配置就卡住了一让排查Nacos服务掉线就懵了。所以我最后的建议是花两三个晚上用2.3那套骨架把项目搭出来注册两个服务用网关把请求转发过去再尝试用Redisson写一个分布式锁扣库存用Seata把下单和扣库存串起来。踩过启动报错、版本冲突、配置缺失这些坑之后你对这套体系的记忆是看十篇八股都换不来的。面试的时候我的体会是面试官并不指望你什么都会他更看重你在遇到不懂的问题时能不能给出合理的分析路径。比如被问到不熟悉的技术你可以说“这个组件我没在生产环境用过但我从原理上判断它大概是这样工作的如果是我的话我会先用一个最小demo验证一下”。这种回答方式比支支吾吾或者硬编一个答案要加分得多。把上面这些知识点理解透再配合一两次真实的动手实践微服务和分布式这块你基本就能过关了。
![[光学原理与应用-521]：对光的错误理解与纠偏](http://pic.xiahunao.cn/yaotu/[光学原理与应用-521]：对光的错误理解与纠偏)
