前两年我们团队做了一个决定把运行了三年的单体应用拆成微服务。当时觉得拆完就万事大吉结果那天晚上光是把注册中心、网关、配置中心、六个业务服务在本地拉起来就花了四个小时。后面还有各种联调问题等着——服务间超时、配置不一致、消息重复消费。所以当有人问微服务概览到底要了解什么时我的答案从来不是那几张架构图而是先搞清楚微服务解决什么问题、拆分的边界在哪、服务之间怎么通信、技术栈怎么选、项目怎么启动和联调。这篇文章就按这个顺序聊一遍全是过来人的视角适合准备从单体转微服务、或者刚开始接触 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 JSONSpring 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、EurekaGo 生态里则是 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 / etcdJava 生态首选 NacosGo 生态常用 etcd服务间同步调用OpenFeign / gRPCJava 内部用 Feign跨语言或高频用 gRPC异步消息RocketMQ / Kafka / RabbitMQ业务消息用 RocketMQ/RabbitMQ大数据用 Kafka缓存与分布式锁Redis基本属于必选熔断限流SentinelJava 生态为主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 的用户服务两边定义的接口要完全一致。如果是 gRPCproto 文件就是唯一的契约改字段要同步改两边如果用的是 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 微服务而是我这个业务的边界画清楚了吗、数据归谁管、团队怎么协同。想清楚这些框架和中间件都是水到渠成的事。反过来边界没想清楚就硬拆再好的技术栈也救不回来。