前言在前七篇文章中我们拆解了Spring的IoC、AOP、SpringMVC、自动配置、事务管理、设计模式和扩展点。这些是单机Spring的核心能力。但如果你的系统需要支撑千万用户、需要7×24小时高可用、需要快速迭代发布——单机架构很快就会触到天花板。这就是微服务要解决的问题。面试中微服务是高级话题的入口面试官会追着问“微服务和单体架构各自的优缺点是什么什么时候该拆”“Nacos的注册中心和配置中心分别解决什么问题”“Sentinel的限流、熔断、降级有什么区别”“服务间怎么通信Feign和RestTemplate有什么区别”本文从单体到微服务的演进出发拆解你的秒杀系统项目中的微服务架构以及Nacos、Sentinel、Gateway等核心组件各自解决什么问题。本文核心问题单体架构和微服务架构各自的优缺点是什么什么时候该拆Nacos的注册中心和配置中心分别解决什么问题Sentinel的限流、熔断、降级有什么区别各自适合什么场景Gateway网关在微服务中扮演什么角色服务间怎么通信OpenFeign和RestTemplate有什么区别你的秒杀系统用了什么样的微服务架构各服务之间如何协作读完本文你将对微服务架构拥有从原理到实践的完整理解并能清晰地解释简历上秒杀项目的架构设计。一、单体 vs 微服务——什么时候该拆疑问单体架构能跑得好好的为什么要拆成微服务回答单体架构在项目初期简单高效——所有代码在一个项目里开发、测试、部署都方便。但当系统变大后每次修改都要全量部署、各模块之间耦合严重、不同的功能模块之间资源争抢——拆分的理由变得不可忽视。1.1 单体架构的困境单体架构 ┌──────────────────────────────────────┐ │ 单体应用 │ │ │ │ ┌────────┐ ┌────────┐ ┌────────┐ │ │ │用户模块 │ │订单模块 │ │课程模块 │ │ │ └────┬───┘ └───┬────┘ └───┬────┘ │ │ │ │ │ │ │ ┌────┴─────────┴─────────┴────┐ │ │ │ 共享数据库 │ │ │ └──────────────────────────────┘ │ └──────────────────────────────────────┘ 问题 1. 一个模块的Bug可能导致整个系统崩溃——故障半径大 2. 修改一行代码需要全量部署——发布周期长、风险高 3. 所有模块共享同一个数据库——表结构耦合严重、资源争抢 4. 不同模块对硬件需求不同——无法对单个模块做针对性弹性伸缩1.2 微服务的拆分微服务架构 ┌──────────┐ ┌──────────┐ ┌──────────┐ │ 用户服务 │ │ 订单服务 │ │ 课程服务 │ ← 独立部署、独立扩展 └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ ┌────┴─────┐ ┌────┴─────┐ ┌────┴─────┐ │ 用户DB │ │ 订单DB │ │ 课程DB │ ← 各自独立的数据库 └──────────┘ └──────────┘ └──────────┘ 优势 1. 故障隔离订单服务挂了用户仍可登录和浏览课程 2. 独立部署课程服务发布不影响订单服务 3. 独立扩容秒杀时只扩容订单服务其他服务不受影响1.3 但微服务不是银弹维度单体微服务开发效率初期高效初期需搭建基础设施部署复杂度简单多个服务需要编排故障隔离差好运维成本低高监控、链路追踪、日志聚合数据一致性天然支持事务分布式事务复杂适用规模小团队、初期项目中大型系统、多团队协作建议项目初期用单体快速验证业务——用SpringBoot快速搭建、快速迭代。当团队人数增多、模块边界清晰、有独立的部署和扩容需求时再逐步拆分为微服务。从单体到微服务是一个渐进的演进过程不是一个非此即彼的架构抉择。二、Nacos——注册中心与配置中心疑问Nacos是什么它在微服务中同时扮演两个角色回答Nacos是阿里巴巴开源的微服务基础设施同时提供注册中心和配置中心两项能力。前者负责服务的发现和健康检查后者负责配置的集中管理和动态刷新。2.1 注册中心——服务发现没有注册中心时服务A调用服务B需要硬编码B的IP地址。B扩容或缩容后A的配置需要手动更新。B宕机时A无从感知继续发请求到宕机的节点。有了注册中心后服务B启动时将自己的IP和端口注册到Nacos服务A从Nacos查询服务B的地址列表Nacos通过定时心跳检测服务B的健康状态并自动摘除失效节点。注册中心的核心能力 1. 服务注册服务启动时向Nacos注册自己的IP和端口 2. 服务发现服务调用方从Nacos获取目标服务的地址列表 3. 健康检查Nacos定时向服务发心跳检测是否存活自动摘除失效节点2.2 配置中心——集中管理配置没有配置中心时每个服务都有自己的application.yml分散在各自的项目中。修改一个共享配置需要改多个服务、重新打包部署重启。配置变更的链路长、风险大、易遗漏。有了配置中心后所有配置在Nacos中集中管理一个配置项的所有服务共用。修改配置后Nacos实时推送变更通知各服务收到通知后自动刷新无须重启。配置中心的核心能力 1. 集中管理所有服务的配置存储在Nacos中统一可见 2. 动态刷新修改配置后无需重启服务即生效 3. 环境隔离通过namespace区分dev/prod环境2.3 为什么选择Nacos对比维度NacosEurekaConsul注册配置能力✅ 两者合二为一❌ 只做注册✅ 两者合二为一健康检查自适应支持多种健康检查方式需手动配置支持多种协议对SpringCloud整合⭐ 原生支持度高功能单一整合不如Nacos常用度高逐渐减少中Nacos同时做注册中心和配置中心不需要部署两套组件运维简单。对Spring Cloud Alibaba的原生支持高整合顺畅。三、Sentinel——限流、熔断、降级疑问Sentinel的限流、熔断、降级有什么区别各自适合什么场景回答限流是主动防御熔断是被动反应降级是善后兜底。三者协同保证了系统在最差情况下仍能对外提供基本的服务能力而不是被某个故障拖垮整个链路。3.1 限流——主动防御限流是把超出系统承载能力的请求挡在门外保护系统不被突发流量冲垮。秒杀开始时预估单节点QPS上限为2000。Sentinel配置限流规则当QPS超过2000时多余请求被直接拒绝返回系统繁忙而不是排队等待、占满整个连接池和线程池、最终拖垮整个服务。这是用牺牲部分请求换取所有请求的稳定处理时间。3.2 熔断——被动反应熔断是调用下游服务失败率过高时暂时停止调用给下游恢复的时间窗口。订单服务调用库存服务的失败率达到50%。继续调用只会让库存服务的压力层层传导至订单服务——线程等待库存响应、连接池被占满、新请求被拒。Sentinel触发熔断后订单服务直接返回库存服务暂不可用不再继续等待。半分钟后尝试放行一个请求探测库存服务是否恢复——恢复了恢复调用没恢复继续熔断。3.3 降级——善后兜底降级是当限流或熔断触发后给出一个兜底方案而不是直接抛异常给用户。RestControllerRequestMapping(/api/course)publicclassCourseController{GetMapping(/detail)SentinelResource(valuecourseDetail,fallbackgetCourseDetailFallback,// 降级方法blockHandlergetCourseDetailBlocked// 限流/熔断处理)publicResultCoursegetDetail(RequestParamLongcourseId){returnResult.success(courseService.getDetail(courseId));}// 降级方法返回缓存中的基础信息publicResultCoursegetCourseDetailFallback(LongcourseId,Throwablee){log.error(课程详情查询降级: courseId{},courseId,e);CoursecachedcacheService.getFromLocal(courseId);if(cached!null){returnResult.success(cached,数据来自缓存可能不是最新);}returnResult.fail(服务繁忙请稍后再试);}// 限流/熔断处理publicResultCoursegetCourseDetailBlocked(LongcourseId,BlockExceptione){returnResult.fail(当前访问人数过多请稍后再试);}}3.4 三者的关系限流是主动防御——在请求进来之前就做出判断拒绝超出能力的请求。熔断是被动反应——调用下游已经失败了才触发此时上游不再重试直到下游恢复。降级是善后兜底——无论限流还是熔断触发最终都由降级方法给出一个友好的返回而不是把系统异常暴露给用户。这三个机制协同构成了微服务的容错防线——限流保护自己不被打垮熔断保护下游不被波及降级保护用户体验不被摧毁。四、Gateway——微服务的统一入口疑问Gateway在微服务中扮演什么角色为什么需要网关回答Gateway是所有外部请求的统一入口。客户端不需要分别对接用户服务、订单服务、课程服务的地址——只需连接GatewayGateway根据请求路径动态转发到对应的微服务。没有网关时每个服务都暴露自己的外网地址。前端需要维护多个地址开发调试和部署的复杂度随服务数量线性增长。每个服务都要自己做鉴权、限流、日志代码重复且可能不一致。有了网关后前端只连接Gateway一个地址。鉴权、限流、日志、跨域处理这些横切关注点都在网关层统一完成各个微服务专注自己的业务逻辑不再需要每个服务都重复实现这些基础功能。Gateway的工作原理客户端请求GET /api/course/detail?id1001 ↓ Gateway网关统一入口 ↓ 断言Predicate匹配 /api/course/** → 路由到课程服务 ↓ 过滤器Filter添加认证头、日志记录、限流检查 ↓ 转发到课程服务 → 处理请求 → 返回响应Gateway的核心三要素路由定义转发规则Predicate匹配请求是否满足转发条件Filter在请求转发前后插入处理逻辑。Predicate和Filter可以组合实现对哪些请求、做什么处理、转发到哪的灵活路由规则。五、服务间通信——Feign vs RestTemplate疑问微服务之间怎么互相调用Feign和RestTemplate有什么区别回答RestTemplate是Spring提供的HTTP客户端需要手动拼接URL和参数。OpenFeign是声明式的HTTP客户端定义接口即可自动生成代理对象完成HTTP调用。// RestTemplate方式手动拼接URL关注点混杂Stringurlhttp://course-service/api/course/courseId;CoursecourserestTemplate.getForObject(url,Course.class);// OpenFeign方式声明式调用关注点聚焦于业务语义FeignClient(namecourse-service)// 自动从Nacos获取course-service的地址列表publicinterfaceCourseClient{GetMapping(/api/course/{id})ResultCoursegetCourse(PathVariableLongid);}// 调用时就像调用本地方法AutowiredprivateCourseClientcourseClient;publicvoiddoSomething(LongcourseId){CoursecoursecourseClient.getCourse(courseId);// 本地方法语义HTTP调用在背后完成}维度RestTemplateOpenFeign调用方式手动拼接URL声明接口注解服务发现需手动解析自动对接Nacos负载均衡需手动配合Ribbon自动负载均衡代码可读性关注点在HTTP协议层面关注点在业务语义层面维护成本高低秒杀项目中使用的是OpenFeign——订单服务调用课程服务、用户服务调用订单服务都通过Feign声明式接口完成。代码简洁、自动对接Nacos做服务发现和负载均衡不需要手动拼接URL。六、秒杀系统的微服务架构疑问你的秒杀系统用了什么样的微服务架构各服务之间如何协作回答秒杀系统采用Spring Cloud Alibaba微服务架构分为五个核心服务NacosSentinelGateway。6.1 整体架构图客户端 ↓ Gateway 网关统一入口 ↓ ┌────────────────┼────────────────┐ ↓ ↓ ↓ 用户服务 订单服务 课程服务 认证鉴权 秒杀核心 课程信息 ↓ ↓ ↓ 用户DB 订单DB 课程DB ↓ RocketMQ ↓ 订单消费者 → 异步创建订单 ↓ Redis 库存扣减 缓存6.2 各服务职责服务职责核心能力Gateway网关统一入口、路由转发鉴权、限流、跨域处理用户服务认证与鉴权JWT双Token、RBAC权限课程服务课程信息管理课程详情、多级缓存订单服务秒杀核心Redis扣减库存、RocketMQ异步削峰Nacos注册配置服务发现、动态配置Sentinel容错保障限流、熔断、降级6.3 一次秒杀请求的完整链路1. 客户端发送秒杀请求 → Gateway 2. Gateway鉴权 → 通过 → 转发到订单服务 3. 订单服务Redis Lua原子扣减库存 → 扣减成功 4. 订单服务发送RocketMQ事务消息 → 立即返回排队中 5. RocketMQ推送给订单消费者 → 异步创建订单 6. 订单消费者落库MySQL → 更新库存流水状态 7. 前端轮询订单状态 → 订单创建完成 → 显示抢购成功 容错保障 - 订单服务过载 → Sentinel限流 → 返回系统繁忙 - 课程服务异常 → Sentinel熔断 → 调用降级方法返回本地缓存数据 - Redis宕机 → 多级缓存兜底 → 从MySQL恢复库存数据每一层都有对应的容错机制——限流保护订单服务不被打垮熔断保护课程服务异常不波及其他服务降级保证用户体验不被摧毁多级缓存和异步补偿保证数据最终一致。这五道防线共同构成了秒杀系统的高可用能力。七、面试中这样回答面试官“你们的微服务架构是什么样的”回答框架“我们使用Spring Cloud Alibaba微服务架构。Gateway作为统一入口做鉴权和路由转发。Nacos同时做注册中心和配置中心——服务列表动态发现、配置集中管理。订单服务是秒杀核心通过Redis Lua原子扣减库存RocketMQ异步削峰创建订单。用户服务负责JWT双Token认证和RBAC权限。课程服务负责课程信息和多级缓存。Sentinel作为容错保障——秒杀接口过载时限流保护订单服务课程服务异常时熔断并降级返回本地缓存数据。”总结单体 → 微服务是渐进演进初期用SpringBoot快速验证业务团队扩大、模块独立后逐步拆分Nacos 注册中心 配置中心服务发现让调用方自动获取最新服务列表配置集中管理让变更免重启。比Eureka多了配置能力Sentinel三层防护限流主动防御过载熔断被动停止对故障服务的调用降级给友好兜底。三者协同保护系统不被流量或故障冲垮Gateway作为统一入口路由、鉴权、限流、日志在网关层统一完成微服务专注自己的业务Feign声明式调用 RestTemplate自动服务发现、自动负载均衡、代码可读性高秒杀系统五道防线Gateway鉴权→订单服务限流→库存原子扣减→MQ异步削峰→多级缓存定时对账。每道防线守护一个层面的可用性组合起来形成完整的容错体系专栏完结本文是Spring原理专栏的第八篇也是最后一篇。从IoC容器到AOP切面从SpringMVC到自动配置从事务管理到设计模式从扩展点到微服务——八篇文章覆盖了Spring核心知识体系。配合Java基础、JVM、并发编程、MySQL、Redis五个专栏Java后端面试的核心知识模块已全部覆盖。