前两年我们团队做了一个决定：把运行了三年的单体应用拆成微服务。当时觉得拆完就万事大吉，结果那天晚上，光是把注册中心、网关、配置中心、六个业务服务在本地拉起来，就花了四个小时。后面还有各种联调问题等着——服务间超时、配置不一致、消息重复消费。所以当有人问"微服务概览"到底要了解什么时，我的答案从来不是那几张架构图，而是：先搞清楚微服务解决什么问题、拆分的边界在哪、服务之间怎么通信、技术栈怎么选、项目怎么启动和联调。这篇文章就按这个顺序聊一遍，全是过来人的视角，适合准备从单体转微服务、或者刚开始接触 Spring Cloud / Go 微服务的同学。
1. 微服务解决了什么问题，又带来了什么问题
1.1 单体系统的四个痛点
我在做那个单体项目的时候，最痛苦的事情不是写代码，是发布。项目跑了两三年，代码十几万行，每次上线要挑凌晨，因为重启一次要三五分钟，白天根本不敢动。这是单体系统的第一个痛点：发布耦合。任何一个小功能改动，都要把整个应用重新打包、重启，所有功能一起承担风险。哪怕你只改了一个按钮的颜色，也要把订单、支付、用户这些模块全部重新部署一遍。
第二个痛点是故障放大。内存泄漏、慢 SQL、某个第三方接口超时，只要发生在任何一个模块里，整个应用都可能被拖垮。一个统计报表的定时任务把 CPU 打满，线上所有接口一起超时，这种事故我经历过不止一次。
第三个痛点是扩展粒度太粗。用户量上来之后，你只能把整个应用水平复制一份。但瓶颈往往只在某几个模块，比如商品详情页的查询压力大，而订单写入其实没那么忙。单体应用没法只给商品模块加机器，只能整体扩容，成本很高。
第四个痛点是技术栈捆绑。整个团队被绑在同一个语言、同一个框架、同一个数据库上。想给某个模块上 Go、换一个更适合的存储，几乎不可能。这些问题叠加起来，才是拆微服务的真正动机，而不是因为"微服务听起来高级"。
1.2 微服务的定义和被包装的现实
微服务的定义其实很朴素：把一个大的应用，拆成一组小的服务，每个服务对应一个独立的业务能力，可以单独开发、单独部署、单独扩展，服务之间通过网络通信。
但这里有个被包装得很严重的地方。很多文章把微服务说得像搭积木一样优雅，实际拆完之后，你面对的是分布式系统的全部复杂性。原来一次方法调用现在变成一次网络请求，原来的本地事务变成分布式事务，原来的单库查询变成跨库聚合。我之前在团队里说过一句话：微服务把单体时代的"难写"换成了"难查"。代码写起来确实清爽了，但排查一个问题要从网关到注册中心到多个服务的日志里反复跳转。
所以真正理解微服务，要先接受它不是一个"优化"方案，而是一个"取舍"方案。它换来的是每个服务的独立性和弹性，代价是网络、数据、运维的整体复杂度上升。
1.3 什么时候不该上微服务
这句话可能不太中听，但我还是要说：如果你的团队只有三五个人，业务还没验证清楚，用户量也没到瓶颈，单体应用往往比微服务更合适。我自己见过太多团队，为了简历上多一行微服务经历，硬把一个几千行代码的项目拆成十几个服务，结果就是接口调用链越拉越长，问题定位越来越慢，发布一次要协调好几个服务的前后顺序，效率反而下降。
微服务适合的场景有几个特征：多团队并行开发、模块间边界清晰、存在独立的性能瓶颈、需要独立部署和弹性伸缩。如果这些一个都不占，那就不要动。这个判断，比学会任何框架都值钱。
2. 微服务拆分：边界、粒度、数据
2.1 按业务域拆，而不是按技术层拆
真正开始拆的时候，第一个分歧往往出现在"按什么拆"。我看过一些失败的案例，是团队按技术层拆的，把控制层拆成一个服务、业务层拆成一个服务、数据访问层拆成一个服务。这种拆法看起来"分层清晰"，实际上每个请求都要在三个服务之间跳来跳去，一次普通的查询变成三次网络调用，性能和排查难度都是灾难。
我个人的经验是按业务域拆，也就是围绕"用户、商品、订单、支付、库存"这种业务边界来拆。判断标准很简单：如果一个功能的数据被两个以上的服务频繁修改，那这个边界就有问题。微服务拆分本质上是在画数据边界，不是画代码分层。
具体操作上，我会走这么几个步骤：第一步梳理核心业务流程，把全链路画出来；第二步圈出高内聚的业务域，看哪些数据是同一个域里高度耦合的；第三步明确域与域之间的依赖方向，尽量避免循环依赖；第四步才去设计接口。顺序不能反，先有业务边界，再有服务接口，最后才是框架选型。
2.2 拆分粒度怎么定
很多新人最喜欢问的问题就是：一个微服务到底该多大、多少行代码才算合适？说实话，没有标准答案。但有两个经验值可以参考：一是单服务最好能由"一个两到八人的小团队"在两周内完成一次迭代；二是如果某个服务内部的模块之间还需要频繁同步沟通才能发版，那说明它太大了，应该继续拆；反过来，如果两个服务之间每次改动都要一起发布，那说明它们本不该分开。
还有一个更实际的判断：看发布频率。健康的微服务之间，发布频率应该是相互独立的。你发布订单服务不需要通知用户服务团队，这才说明拆分到位了。如果每次改一个字段要同时改三个服务、还要掐着时间一起上线，那不是微服务，那是把单体打碎了之后又用胶水粘回去。
我记得有一次拆用户服务，本来觉得拆完就完了，结果发现用户服务还要依赖商品服务的收藏数据，商品服务又要查用户服务的画像数据，两个服务互相调用，最后只能在中间加了一层聚合服务。这个教训告诉我们：拆的时候要提前把"数据归属权"想清楚，谁的字段谁维护，别人要数据只能走接口。
2.3 数据拆分和分布式事务
服务拆完，数据库通常也要拆。原来一张大库里什么表都放，现在每个服务有自己的库，这就带来两个绕不开的问题。
第一个是跨服务查询消失了。以前一条 SQL 可以 join 三张表，现在这些表散落在不同服务、不同库，你只能在代码里做聚合：先查订单，再查用户，再查商品，然后拼装结果。性能不一定差很多，但代码复杂度上来了。这也是为什么很多团队在微服务架构里引入"数据同步 + 读模型"：把其他服务的只读数据通过消息同步到本地库，用空间换查询效率。
第二个是分布式事务。最经典的场景是下单：扣库存、扣余额、生成订单，原本是一个本地事务，拆成三个服务后，任何一个失败都可能造成数据不一致。常用的方案有几种：两阶段提交（2PC）用得越来越少，因为性能和可用性都差；Seata 这种 AT/TCC 方案在很多 Java 微服务项目里比较常见；但更主流的思路是"最终一致性"，也就是用本地消息表加消息队列来异步保障。具体到业务上，宁可让用户看到"支付处理中"，也不要让库存扣了但订单没生成这种脏数据长期存在。
关于数据这块，我强烈建议团队在拆库之前先统计一下：哪些表被多个服务读写？这些表就是拆库时最大的难点。你无法通过接口封装来解决所有共享表的问题，有时候不得不使用"共享数据库 + 按表归属"这种过渡方案，但要想清楚它只是个过渡，别让它变成长期债。
3. 微服务之间的调用方式：从同步到异步
3.1 同步调用：REST、Feign、gRPC 和 Dubbo
微服务之间怎么通信，是面试问得最多、也是实际设计中最重要的问题。同步调用最直观，A 服务的请求直接发给 B 服务，等 B 返回结果再继续往下走。Java 生态里最常用的是 HTTP + JSON，Spring Cloud 里用 OpenFeign 封装；追求性能时会用 gRPC，它的通信协议基于 HTTP/2，传输是序列化的二进制，接口定义用 proto 文件，跨语言支持也很好；还有 Dubbo，在国内很多传统 Java 项目里依然有大量存量，它自带服务治理能力。
选哪种同步方式，我的判断标准是：如果是内部服务之间、流量不算特别大、团队以 Java 为主，HTTP + Feign 就够了，简单、好排查、谁都能接。如果服务间调用很频繁、对延迟敏感，或者有跨语言需求（比如 Java 服务要调 Go 服务），gRPC 会更合适。有一点要提醒，gRPC 的调试成本比 HTTP 高，没有浏览器那种直观的请求页面，需要 grpcurl 这类工具，团队要提前习惯。
同步调用看起来简单，但它是很多线上故障的源头。我最常跟年轻同事强调的三个词：超时、重试、熔断。任何一个同步调用都必须设置超时时间，不能无限等；重试要有限制，而且最好只在幂等接口上重试；熔断是防止一个慢服务把整个系统拖垮的关键。这些不是可选项，是同步调用的标配。
3.2 异步调用：消息队列解决的是什么问题
同步调用解决不了的问题，通常要上消息队列。最典型的几个场景：一是削峰填谷，比如秒杀场景瞬间流量巨大，直接用同步接口打数据库肯定扛不住，把请求先丢进 MQ，后端按自己的能力慢慢消费；二是解耦，下单之后要通知积分服务加积分、通知短信服务发通知、通知推荐服务更新数据，如果都用同步调用，任何一个下游出问题都会影响下单主链路，改成消息之后，下单服务只管发消息，下游自己消费；三是数据最终一致性，前面说的分布式事务很多就是靠消息实现的。
主流产品里，Kafka 吞吐量高但功能相对简单，适合大数据量、日志、实时计算场景；RocketMQ 和 RabbitMQ 在业务消息、事务消息、延迟消息方面更友好。选择标准大致是：业务消息为主、需要事务消息和延迟队列，优先 RocketMQ；团队 Java 底子好也可以用 RabbitMQ；大数据生态则绕不开 Kafka。
上 MQ 有个绕不开的坑：消息丢失、消息重复。丢失可以通过生产端确认加消费端手动提交 offset 来降低概率；重复则只能靠消费幂等兜底，比如消费前先查本地去重表，或者用唯一键约束。记住一个理念：消息队列保证的是"至少一次"送达，不是"恰好一次"，所以消费端必须设计成幂等的。
3.3 注册中心、配置中心和网关：看不见的基础设施
很多初学微服务的人把注意力全放在业务代码上，忽略了真正的复杂点其实是基础设施。注册中心是第一个要了解的，服务启动时把自己注册进去，调用方从注册中心发现服务地址，而不是在配置文件里写死 IP。没有注册中心就没有动态扩缩容，加了新节点还要改配置，那就失去微服务的意义了。Java 生态里 Nacos 目前很主流，还有 Consul、Eureka，Go 生态里则是 etcd 用得比较多。
配置中心解决的是"改了配置不用重启服务"的问题。微服务数量一多，挨个改配置文件再重启是不可想象的。配置中心的基本思路是：项目代码里的占位符在运行时从配置中心拉取真实配置，配置变更通过推或拉机制通知服务动态刷新。
网关则是所有外部请求的统一入口。客户端不需要知道订单服务部署在哪里，它只请求网关，网关做路由转发、统一鉴权、限流、跨域处理。我之前在一个项目里见过反面教材：网关没上，所有服务暴露给外部，然后每个服务都写了一遍鉴权逻辑，改一次权限策略要发六七个服务。这事儿其实用一个网关就能解决。常见的网关有 Spring Cloud Gateway、Kong、APISIX 等。
3.4 调用链上的"可用性三件套"
服务一多，任何一个节点的抖动都可能放大成全站故障。所以微服务领域有一整套约定俗称的可用性手段，面试也爱考。
超时控制：每个调用的超时时间都要单独设计。连接超时代表建立连接的最长等待，通常几百毫秒到一两秒；读取超时代表等待对端返回数据的时间，要看接口的真实耗时。我见过有人把所有超时都设成三秒，结果一个聚合接口要调四个下游、每个下游偶尔都要两秒，一次请求最快也要八秒，用户体验自然很差。所以超时设置要在"防卡死"和"不误杀"之间找平衡，而且要对慢调用有监控，而不是简单调大超时。
重试：重试这件事要非常克制。很多人一看到请求失败，条件反射就是重试三次，但重试可能会放大故障：下游服务本来已经过载，你重试只会让它更慢。我自己的原则是：只在连接异常、瞬时超时这类"可能是偶发"的情况下重试，业务性错误绝不重试；重试次数不超过两次；重试前最好加一点随机退避；最关键的是，只有幂等接口才允许重试，否则用户可能收到两条一模一样的短信。
熔断与降级：熔断是给下游服务一个"休息时间"。比如订单服务调用积分服务，连续失败比例超过阈值，熔断器就直接打开，后面的请求不再真实调用积分服务，而是快速走降级逻辑：给用户返回一个"稍后到账"的提示，或者直接返回兜底数据。等过一段时间，熔断器半开，放少量请求试探，如果恢复了就关掉。这套机制能防止单个故障服务拖垮整个调用链。Java 生态里 Hystrix 已经有点过时了，Sentinel 更主流。
限流：限流保护的是系统自身的处理能力。不管下游能扛多少流量，你自己服务能处理的请求数是有上限的，超过上限就该拒绝一部分，而不是让所有请求都堆在队列里等超时。常用的限流手段是令牌桶，控制平均速率和突发流量；实现上可以用 Redis + Lua 做分布式计数，也可以用网关层做集中限流，双管齐下最稳。
链路追踪：服务少的时候靠肉眼翻日志还能忍，服务一多，一个请求横跨五六个服务，每台机器日志各记各的，你根本拼不出完整的调用链。链路追踪系统会给每个请求分配一个全局 traceId，日志里带上这个 ID，查询时按 traceId 拉出所有相关日志，就能还原整个调用路径和时间消耗。SkyWalking 对 Java 比较友好，接入成本低；Jaeger 在 Go 生态更常见。
4. 技术栈选型：Java 的 Spring Cloud 和 Go 微服务
4.1 Spring Cloud：成熟生态里的主流选择
Java 微服务绕不开 Spring Boot + Spring Cloud。Spring Boot 负责把一个服务跑起来，Spring Cloud 提供微服务所需的各种套件。很多人分不清这两个东西：Spring Boot 是一个快速构建独立应用的框架，它解决的是"单个服务怎么写"；Spring Cloud 是分布式系统的工具箱，它解决的是"多个服务怎么协作"。我经常用一句话概括：Spring Boot 是一辆性能不错的车，Spring Cloud 是配套的高速路、加油站和交通管制。
当前主流组件大概这么分工：Nacos 注册中心 + 配置中心；OpenFeign 做服务间声明式 HTTP 调用；Spring Cloud Gateway 做网关；Sentinel 做熔断限流；Seata 做分布式事务；SkyWalking 做链路追踪。这套组合在 Java 领域非常成熟，资料多、招人容易、踩坑方案现成。如果团队以 Java 为主，直接抄这套组合基本不会错。
但也有它的槽点：重。哪怕只是引入几个组件，本地启动时内存就吃紧，我一个 16G 内存的笔记本同时跑注册中心、网关、配置中心和四五个服务，风扇就开始狂转。所以 Java 微服务在本地开发时一定要学会"部分启动"，只启动你负责的服务和它依赖的服务，其他服务用远程环境或者 mock 掉。
4.2 Go 微服务：轻量、高性能，但不是零成本
Go 这几年在微服务领域越来越常见，尤其适合高并发网关、中间件、边缘服务这类场景。Go 微服务的优势很直接：编译成单一二进制，部署就是 copy 一个文件，资源占用比 Java 小很多，起服务秒级完成，非常适合容器化。如果同一个系统里 Java 写业务、Go 写网关和流量入口，是很常见的组合。
Go 微服务的框架选择，现在比较主流的几个：go-zero，国产开源，集成度很高，自带了 API 定义、rpc、日志、限流等能力，属于"开箱即用"型；Kratos，是 bilibili 开源的微服务框架，设计上更强调接口规范和插件化，很多公司会在内部二开；go-micro 曾经很流行，但近两年维护节奏和社区争议比较大，新项目我会谨慎一点。服务间通信大多数用 gRPC，注册中心常用 etcd 或 Nacos。
要注意的是，Go 微服务的"框架"边界没有 Java 那么统一。Java 里 Spring Cloud 几乎是一站式标准，Go 这边更多是"框架 + 组件"自己拼，比如 go-zero 自己带注册发现和配置管理，但不一定自带分布式事务方案。所以选 Go 微服务，团队里至少要有一个能把整套链路串起来的人，不然很容易变成"每个服务各自为政"。
4.3 中间件怎么选：Redis 几乎绕不开，MQ 和数据库按需上
聊到中间件，几乎每个 Java 微服务项目都会用到 Redis。大家在网上一搜就能看到类似的问题是"java微服务 spring boot spring cloud 中间件选择 redis"，这说明 Redis 已经是微服务的基础设施了。Redis 在微服务里的用途至少有四个：缓存热点数据，比如商品详情、用户会话，这是最基本的；实现分布式锁，在多个服务实例之间互斥地执行某个任务，常见方案是 setnx 加过期时间，复杂场景用 Redisson；做限流计数器，配合 Lua 脚本在 Redis 里完成令牌桶或滑动窗口的判断；另外 Redis 还常用于排行榜、短信验证码这类临时数据存储。
选中间件时最重要的是克制。我见过不少项目，微服务才五六个，中间件先引入了 Redis、MySQL、Kafka、Elasticsearch、MongoDB、xxl-job 六七个，听起来高大上，实际上运维成本和故障面成倍增加。每个中间件都是一个独立系统，需要监控、备份、参数调优、异常处理。中间件的选择原则应该是：能少则少，除非有明确的业务收益。缓存先上 Redis，消息先上一种 MQ，搜索确实有需求再上 ES，不要一开始就把全家桶堆上去。
下面我整理了一个参考表格，按典型场景给选型建议：
| 需求 | 推荐方案 | 备注 |
|---|---|---|
| 服务注册与配置 | Nacos / etcd | Java 生态首选 Nacos，Go 生态常用 etcd |
| 服务间同步调用 | OpenFeign / gRPC | Java 内部用 Feign，跨语言或高频用 gRPC |
| 异步消息 | RocketMQ / Kafka / RabbitMQ | 业务消息用 RocketMQ/RabbitMQ，大数据用 Kafka |
| 缓存与分布式锁 | Redis | 基本属于必选 |
| 熔断限流 | Sentinel | Java 生态为主，Go 可用框架自带或自研 |
| 链路追踪 | SkyWalking / Jaeger | 建议起步就接 |
| 分布式事务 | Seata / 本地消息表 | 事务高频再上 Seata，低频用消息最终一致性 |
4.4 一个参考的技术选型组合
如果从零起步，我推荐的最小可用组合是这样的：Nacos（注册 + 配置）+ Spring Cloud Gateway + OpenFeign + Sentinel + Redis + 一种 MQ。团队小可以先不碰 Seata，分布式事务先靠消息和人工对账；链路追踪可以用 SkyWalking 简单接一下。这个组合足够支撑从单体拆到十几个服务的规模，也是大多数中小团队比较稳妥的路径。再往后，服务多了再考虑 Service Mesh、多机房、云原生这些更重的方案，但那是另一个话题了，不是微服务概览的范畴。
5. 从启动到联调：一次真实的微服务拉起过程
5.1 启动顺序为什么这么重要
我第一次带团队做微服务项目联调时，最崩溃的就是"服务启动顺序"。微服务之间互相依赖，启动顺序不对就会报"找不到服务提供者"。合理的顺序是：先启动基础设施，再启动业务服务。具体说，注册中心和配置中心必须先起来，因为后续所有服务起来后要注册自己、拉取配置；然后是网关，它本身要订阅路由配置；最后才是各个业务服务。如果某个业务服务依赖数据库初始化，还要先做好数据库迁移。
以 Spring Cloud 项目举例，我会按这个顺序操作：
- 先启动 Nacos，确认 8848 端口和 9848 端口都能访问；
- 启动配置中心相关的基础配置，确保 Nacos 里的公共配置和数据源配置都导入，否则业务服务起不来；
- 启动网关服务，验证它能正常启动并成功连接 Nacos；
- 按依赖顺序启动基础服务（用户、权限这类被依赖多的先起），再启动上层业务服务（订单、支付等）；
- 每个服务启动后看一眼 Nacos 控制台，确认服务已经注册成功，再看一下日志有没有报连不上数据库、拉取配置失败之类的错。
还有个容易被忽略的点：本地端口规划。十几个服务如果不提前约定端口，很容易冲突。我们团队会维护一个端口分配表，比如用户服务 8081、订单服务 8082、支付服务 8083，每个人本地启动时按这个表来，避免你起 8081 他起 8082 结果发现代码里写死了别的端口。
5.2 Go 微服务怎么启动和联调
Go 微服务和 Java 的启动流程本质是一样的，都要注册中心先起、业务服务后起，但实际操作上有些差异。Go 服务编译成二进制后，启动命令很简单，比如go run cmd/server.go -c config.yaml，或者先go build再直接运行二进制文件。很多 go-zero 或 Kratos 项目支持通过配置文件指定注册中心地址，比如 etcd 的地址、服务名、监听端口。联调的时候，两个 Go 服务之间用 gRPC 通信，你不仅要把服务启动起来，还要保证 proto 生成的客户端代码和服务端实现版本一致，否则接口会报"未实现的方法"或者字段匹配错误。
Go 微服务的本地联调有一个特别常见的坑：跨语言调用。比如一个 Java 的订单服务要调 Go 的用户服务，两边定义的接口要完全一致。如果是 gRPC，proto 文件就是唯一的契约，改字段要同步改两边；如果用的是 HTTP，字段命名规范（下划线还是驼峰）和日期格式都可能成为联调暗坑。我建议团队把接口契约文档或 proto 文件作为评审对象，任何改动都要先过契约，再写代码。
5.3 联调必查的几个地方
联调阶段常见的问题，我列几个踩过无数次的。
配置不一致：这个词简直是联调时的噩梦。同一个服务在本地连的数据库是 A 库，在测试环境连的是 B 库，结果本地调得好好的，一上测试环境就报表不存在。每个环境的配置一定要由配置中心统一管理，环境切换只需要改一个 profile 或 namespace。我在项目里还见过更隐蔽的：配置中心里有一份配置，代码仓库里也有一份，改漏了某一个，两个环境的行就就对不上。所以从第一天起就约定"配置只以配置中心为准"，仓库里的 application 文件只留占位符。
服务发现失败：服务起了但注册中心看不到，先查服务名是否一致，再查注册地址是不是配成了 127.0.0.1，导致别的机器访问不到。多实例本地调试时，有时候需要临时指定局域网 IP 注册。另外 Nacos 这种注册中心有服务健康检查机制，如果注册上了但心跳异常，服务会被剔除，控制台看到的状态是"不健康"，这时候要查服务节点的网卡、防火墙和心跳上报间隔。
网络超时：本地两个服务之间调用，如果对方没起或者响应慢，默认超时时间可能几秒钟就断。调联调环境的时候，超时配置要放宽一点；但生产环境的超时一定要严格，这是两套参数，千万别图省事用同一份配置。我吃过一次亏：用联调环境的宽松超时配置直接上了生产，结果一个下游慢接口把线程池拖满，整个应用全部卡死。
消息重复：联调时最容易发现消息重复消费的问题。比如下单服务发了消息，支付服务消费时因为超时重发了一次，结果积分加了两遍。所以消费端幂等从第一天就要做，最朴素的做法就是消费前查一下业务流水表，这个流水号已经处理过就直接跳过。不要觉得量小不需要，重复消费是消息系统的常态，越早做越省心。
还有一个心得：强烈建议在联调阶段就把链路追踪日志的 traceId 打通。看问题的时候，只看单个服务的日志很难定位，有了 traceId 才能把一个请求在用户服务、订单服务、支付服务里的日志串在一起。这一步晚做不如早做，等项目跑起来再补，日志格式改动要动的地方更多。
6. 微服务面试，绕不开的几类题
6.1 为什么面试爱问微服务
我总觉得这里有两层原因。第一层是技术层面，微服务牵扯的东西太多，注册发现、配置管理、网关、熔断限流、链路追踪、分布式事务、数据一致性，随便挑一个都能往深里问，面试官很容易通过一个微服务问题判断出候选人的技术广度。第二层是工程层面，微服务改变了团队协作方式，拆不拆、怎么拆、代码归谁管、发布怎么协调，这些都是真实项目里每天都在发生的问题。面试官问微服务，其实是在掂量你有没有处理分布式系统复杂度的实战能力。所以准备微服务面试别只背概念，多想想"我在真实项目里遇到过什么、怎么解决的"，这比流利的定义更有说服力。
6.2 几个高频问题和我自己的答题思路
我挑几个最常被问到的题，讲一下思路。
第一，"微服务拆分的原则是什么"。不要只回答"按业务域拆"，要加一句：拆分后在数据上要相互独立，调用上要依赖清晰，发布上要互不影响。最好能举一个自己的例子，比如按用户、订单、支付拆，然后说明为什么支付不能和订单放一起，因为支付涉及资金安全、有独立的合规要求和变更频率，这是业务边界决定的。
第二，"服务间调用失败了怎么办"。这个题考察的是容错思维。我的答题结构是：先设超时，再限制重试，再上熔断降级，最后是链路追踪和告警。把这几个动作按顺序说出来，基本就能过关。如果面试官追问分布式事务，就讲"最终一致性 + 本地消息表 + 定时对账"的组合，而不是一上来就说 Seata，因为对账兜底才是生产环境真正的保险。
第三，"CAP 和微服务有什么关系"。这个问题容易答成纯背诵，我会尽量把它落到具体选型上。CAP 说分布式系统在分区发生时，只能保证一致性和可用性中的一个。注册中心就是典型的取舍场景：Eureka 优先保证可用性，网络分区时各个节点还能继续服务，但可能读到旧数据；Nacos 支持 AP 和 CP 两种模式切换，配置中心往往用 CP，注册发现用 AP。微服务业务系统的常态其实是"最终一致性"，账户余额可以短暂不是最新值，但不能永远不一致。能结合注册中心选型和数据一致性方案来讲 CAP，会比干巴巴背定理有说服力得多。
第四，"一个接口为什么会超时，你怎么排查"。这种题特别实际，面试官默认你是真的排过障。我的思路是分层排查：第一层看入口，网关有没有限流、有没有规则拦截，是不是请求根本没转发下去；第二层看服务自身，接口内部是慢查询、第三方调用、还是 GC 停顿，这一步通常要借助链路追踪看耗时分布；第三层看依赖，你调的下游服务是不是变慢了，最怕的是下游慢还拖着你的线程不放。排查工具方面，先看 traceId 把整个调用链拉出来，再看数据库慢查询日志和中间件监控面板，基本就能定位到具体环节。能够把排查思路说得有条理，比最后说出"就是慢 SQL 导致的"这个结论更能证明你的工程能力。
6.3 若依微服务 Plus 这类脚手架能帮你什么
现在网上经常能看到若依微服务 Plus 这类基于 Spring Cloud 的开源后台脚手架，确实是个好东西，注册中心、网关、认证、代码生成都给你配好了，能让你在很短时间内把一套微服务跑起来。我的建议是：可以用它来学习、搭演示系统，甚至作为公司项目的起点，但一定要把里面的组件分工搞清楚，别只是"能跑就行"。面试的时候，如果你只说"我用了若依微服务 Plus"，其实反映不出多少技术含量；但如果你能说清楚里面的用户认证是怎么做的、网关为什么这样配置、服务间调用的链路是啥，那才说明你真理解了。脚手架帮你省掉的是机械劳动，不是理解成本。
6.4 准备微服务相关面试的一个建议
如果时间有限，不要死记硬背，可以自己动手把一个最小微服务系统跑起来：一个注册中心、两个服务、一个网关、一个 Redis。自己真实地启动、调用、停掉一个服务看系统怎么容错，比背二十道面试题有用得多。我之前带过的几个同事，都是靠这种最小系统把微服务的骨架串起来的，面试时反而能聊得很深。
最后再多说一句，算是我这几年最深的体会。微服务不是一个"上了就高级"的技术，它更像一种组织协同方式。你真正要先问自己的不是"我用不用 Spring Cloud"或者"我会不会写 Go 微服务"，而是"我这个业务的边界画清楚了吗、数据归谁管、团队怎么协同"。想清楚这些，框架和中间件都是水到渠成的事。反过来，边界没想清楚就硬拆，再好的技术栈也救不回来。
