简介一套基于Spring Cloud与Spring Cloud Alibaba的微服务商城系统源码面向中高级Java开发者用于理解微服务拆分、服务治理与分布式场景下的落地实现。包内共515个文件以346个Java源码为核心辅以59个XML和41个YML配置另有9个SQL脚本、55张PNG/JPG示意图片等压缩包仅5.14MB结构紧凑。项目整合Eureka/Nacos服务注册发现、Gateway/Zuul网关、Feign调用、Seata分布式事务、Sentinel限流熔断及OAuth2认证授权覆盖用户、商品、订单、商户、支付等典型商城模块并包含验证码服务等工具类代码。已有225人学习适合想通过完整源码快速掌握Spring Cloud Alibaba组件组合用法、理清微服务权限链路与订单支付流程的开发者参考。1. 拿到微服务商城系统源码第一步不是启动而是拆包看结构很多人在拿到“基于SpringCloud, SpringCloud alibaba的微服务商城系统源码.zip”之后第一反应是解压、配数据库、直接mvn spring-boot:run然后被一连串报错劝退。原因倒不复杂SpringCloud Alibaba 生态的组件版本关联极强Nacos、Gateway、Sentinel、Seata 各自依赖不同启动顺序又有讲究这套源码里十来个微服务模块只要有一个连不上注册中心整条链路就全断。这篇博文不沿着“某某项目的业务功能”去复述而是面向你已经拿到了这份源码、想把它跑起来并改成自己用的场景。我会把这条路上绕不开的组件选型、配置项、启动顺序、分布式事务取舍、网关路由与鉴权方案一次讲透。涉及 SpringCloud、SpringCloud Alibaba、微服务拆分、Nacos 注册配置中心、Sentinel 流量治理这些热搜词背后的工程做法都会落到可复现的命令和代码上。整套架构里有个反直觉的点商城这类业务听起来是典型的“高并发抢购”但源码里真正难调的往往不是并发本身而是服务间调用的链路追踪和分布式事务。订单、库存、支付这三个服务只要不在同一个数据库里怎么保证数据一致才是日常开发里消耗时间最多的地方。下面就从这份源码最核心的技术底座开始把每个模块为什么存在、改哪些参数能跑通讲清楚。2. 微服务商城系统的工程结构模块划分与 SpringCloud Alibaba 组件选型2.1 先看懂十个服务模块和三个基础设施组件标准的 SpringCloud Alibaba 商城源码通常按业务域拆成 mall-gateway网关、mall-auth认证中心、mall-user用户服务、mall-product商品服务、mall-order订单服务、mall-cart购物车服务、mall-payment支付服务、mall-stock库存服务、mall-seckill秒杀服务、mall-search搜索服务。如果代码里带有后台管理界面还会有 mall-admin 服务营销引擎独立的话再拆一个 mall-promotion。拆模块容易真正的难点在基础设施。这份源码背后必然挂着三件事Nacos 做注册中心和配置中心、Sentinel 做流量治理和熔断限流、Seata 做分布式事务管理。有些改版会把 SkyWalking 或 Zipkin 也带上用于链路追踪。你打开源码里的 pom.xml 看依赖如果看到spring-cloud-alibaba-dependencies这个 BOM基本就能确认它的组件版本是统一的不会出现 sentinel 和 nacos client 各自锁版本的问题。dependencyManagement dependencies dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-alibaba-dependencies/artifactId version2021.1/version typepom/type scopeimport/scope /dependency /dependencies /dependencyManagement这里先注意一件事2021.1这个版本号是 SpringCloud Alibaba 的版本不是 SpringBoot 的版本。它对应的是 SpringBoot 2.4.x 和 SpringCloud 2020.0.x。如果你在源码里看到 SpringBoot 版本是 2.3.x那 Alibaba 版本要降到2021.1以下才能兼容。版本不匹配是拿到源码后最常见的启动失败原因比代码本身出错的比例高得多。2.2 注册中心 Nacos为什么商城服务必须全部挂到它上面微服务架构图里画得再漂亮服务之间不通过 HTTP 地址硬编码互调就必须有一个注册中心。Nacos 在这个位置承担两个职责服务注册发现和配置管理。每个微服务启动时向 Nacos 注册自己的 IP 和端口调用方通过服务名去发现对方地址而不是把localhost:8083写死在配置里。商城系统的服务实例数量是动态的订单服务可能部署 3 个副本商品服务可能部署 2 个只有通过注册中心才能做到负载均衡。spring: application: name: mall-order cloud: nacos: discovery: server-addr: 127.0.0.1:8848 namespace: mall-dev group: MALL_GROUP config: server-addr: 127.0.0.1:8848 namespace: mall-dev group: MALL_GROUP file-extension: yaml这段配置写进bootstrap.yaml才能优先加载。server-addr指向 Nacos 的地址namespace区分环境——同一个 Nacos 上可以挂 dev、test、prod 多套环境服务之间通过命名空间隔离不会互相看到。group做逻辑分组商城业务可以统一放MALL_GROUP和公司里的其他业务线区分开。file-extension指定配置文件的格式。有个经常踩的坑Nacos 客户端从 2.x 开始服务端必须也用 2.x且默认会占用 9848 端口做 gRPC 通信。如果你只开了 8848 的防火墙服务会反复报连接超时。源码里如果 Nacos server 是 1.x客户端 spring-cloud-alibaba 版本不需要太高避免因 gRPC 逻辑引入而连不上。2.3 配置中心不只为存参数更重要的是动态刷新商城系统的配置项很多数据库连接串、Redis 地址、MQ 的 topic、支付回调地址、限流阈值、降级开关这堆东西如果在每个服务里各自维护一份改一个参数要重新发版。Nacos 配置中心解决的就是这个问题。服务启动时先连配置中心拉取配置本地application.yaml只保留最低限度的启动信息。在 Nacos 控制台里新建配置Data ID 的命名规则通常是${spring.application.name}-${spring.profiles.active}.${file-extension}。举例mall-order-dev.yaml。配置内容可以是数据源的全套内容也可以只是某个开关项。关键点在于配置中心里能放一项RefreshScope支持的配置它会在 Nacos 端配置变更时自动推给客户端并刷新 Bean。RefreshScope RestController public class OrderSwitchController { Value(${order.timeout:5000}) private Integer orderTimeout; }这里的逻辑是RefreshScope标记的 Bean 在收到 Nacos 配置变更事件后会重新创建实例所以Value注入的值会跟着变。注意只有标记了RefreshScope的类才会被刷新普通 Service 里用Value注入的字段不会自动更新。常见做法是单独写一个配置属性类让其他组件通过调用这个类的方法取值避免在业务代码里到处散落Value。2.3.1 Nacos 配置项缺失时的启动保护源码没有配好的情况经常是 jar 包能启动但连不上数据库。原因多半是 Nacos 里缺失mall-order-dev.yaml这个配置。服务启动时会尝试拉取拉不到就用本地的application.yaml。如果本地配置里的密码是占位符就会导致后续初始化数据源失败。稳妥的处理是先不依赖配置中心把一份完整的配置放在本地确认服务能启动再逐步搬进 Nacos。3. 微服务网关 SpringCloud Gateway路由、鉴权与跨域3.1 网关在商城系统里的位置一切外部流量的统一入口商城系统的外部流量先打到 SpringCloud Gateway再分发到各个微服务。网关不能只做反向代理它的核心职责按优先级排序是路由转发、鉴权校验、限流熔断、跨域处理。源码里网关模块的 pom.xml 会同时引入spring-cloud-starter-gateway、spring-cloud-starter-alibaba-nacos-discovery、spring-cloud-starter-alibaba-sentinel这三样Sentinel 在网关侧做的是sentinel-spring-cloud-gateway-adapter适配。spring: cloud: gateway: routes: - id: mall-product uri: lb://mall-product predicates: - Path/api/product/** filters: - StripPrefix2 - id: mall-order uri: lb://mall-order predicates: - Path/api/order/** filters: - StripPrefix2lb://mall-order表示走负载均衡去 Nacos 发现服务实例Path/api/order/**是路由规则StripPrefix2表示去掉路径中的前两段比如/api/order/create转发到订单服务时变成/create。这套机制下前端对接的路径永远是网关地址微服务内部的地址对客户端完全不可见。3.2 网关层鉴权JWT 校验放在网关而不是每个服务里商城系统的用户认证状态通过 Token 在各服务间传递。常见方案是 gateway 统一做 JWT 校验校验通过后把用户信息放进 Header 再转发给下游服务。这样订单服务、商品服务本身不需要关心 Token 怎么解析只需要信任网关传过来的 Header。Configuration public class GatewayAuthFilter { Bean public RouteLocator customRouteLocator(RouteLocatorBuilder builder) { return builder.routes() .route(mall-auth, r - r.path(/api/auth/**) .filters(f - f.stripPrefix(2)) .uri(lb://mall-auth)) .route(mall-order, r - r.path(/api/order/**) .filters(f - f.stripPrefix(2) .filter(new JwtAuthFilter())) .uri(lb://mall-order)) .build(); } }这里把需要放行的路径登录、注册、验证码绕过 JWT 校验其他业务路径统一经过JwtAuthFilter。校验逻辑里只做解析和验签不查数据库。用户角色权限这类信息也放进 Token 的 claims 里下游服务从 Header 取。网关改过之后需要重点验证的一点是放行路径是否和自己控制的鉴权白名单一致。比如支付回调接口不允许被网关拦截否则第三方支付平台的回调请求会被 401 拒掉。常见的做法是把回调路径单独再开一个网关路由并且不用走 JWT 校验或者在网关转发时手动加上内部密钥 Header。4. 分布式事务与流量治理Seata 的取舍和 Sentinel 的参数调节4.1 下单扣库存这种跨服务事务为什么不能直接用本地事务商城最典型的高频操作是用户下单订单服务插入订单记录库存服务扣减库存购物车服务清空购物车支付成功后还要通知物流系统。如果不做分布式事务管理下单成功但库存扣减失败就会出现超卖库存扣了但订单状态更新失败用户多付了钱。Seata 在这个位置上有 AT 模式和 TCC 模式两种选择。源码里多数情况集成的是 AT 模式它的特点是业务代码零侵入框架自动解析 SQL、生成 undo 日志、事务提交时做全局提交或回滚。AT 模式要求所有参与事务的数据库都支持 JDBC 标准接口并且每条数据表都要有主键。seata: enabled: true application-id: mall-order tx-service-group: mall_tx_group registry: type: nacos nacos: server-addr: 127.0.0.1:8848 service: vgroup-mapping: mall_tx_group: default这里tx-service-group是这个事务分组所有参与分布式事务的服务必须用同一个分组名才能共用一个 Seata Server。vgroup-mapping把逻辑分组映射到 Seata Server 的集群名。注意 Seata Server 也要注册到 Nacos如果 Nacos 里没有它的注册记录业务服务启动会报can not get cluster name。AT 模式的代价在于数据源必须被 Seata 代理。DataSource 的 Bean 要加GlobalTransactionScanner或者在配置里指定代理数据源。如果源码里没有做这一步Seata 的全局事务是不生效的只是代码不报错数据照常提交。4.2 Sentinel 在商城场景的 3 个必调参数QPS、线程数、熔断比例Sentinel 是 SpringCloud Alibaba 生态里负责流量治理的组件。商城系统里最常见的三种场景秒杀接口瞬时流量极高需要限流支付回调接口偶尔超时需要熔断商品详情接口依赖商品服务和营销服务其中一个挂了另一个不能拖垮。以秒杀下单接口为例单机 QPS 限制设置为 200超过的直接返回“系统繁忙”。在 Sentinel 控制台配置的规则本质上是下发到每个服务实例的本地内存里的。控制台本身不拦截流量它只负责推送规则。PostMapping(/seckill/{skuId}) SentinelResource(value seckillOrder, blockHandler seckillBlockHandler) public R seckill(PathVariable Long skuId) { return seckillService.doSeckill(skuId); } public R seckillBlockHandler(Long skuId, BlockException e) { return R.error(当前抢购人数过多请稍后再试); }SentinelResource切的是资源维度blockHandler指定被限流后的返回逻辑。QPS 这项最好压测后确定不要拍脑袋填。线程数这项针对的是慢调用场景比如支付服务响应越来越慢活跃线程数超过阈值后直接拒绝新请求。熔断比例这项针对的是下游接口的错误率错误率超过 50% 时打开熔断之后的请求快速失败不再真正打到下游服务。4.2.1 规则持久化的必要性直接用控制台配置规则服务重启后规则会丢。生产环境常见做法是把规则推到 Nacos 配置中心Sentinel 客户端监听 Nacos 配置变更实现规则持久化。源码里如果只是演示版本一般不带这个能力。你接手之后要做的是把sentinel-dashboard和 Nacos 打通控制台只负责展示规则统一配置在 Nacos。5. 微服务整合 knife4j 做接口文档聚合与联调验证5.1 为什么要聚合接口文档而不是每个服务各开一个 Swagger 页面十几个微服务每个都有独立的 Swagger UI前端开发要记十几个端口来调试这在开发联调阶段根本没法用。微服务整合 knife4j 的价值就在这里它把每个微服务的 OpenAPI 文档聚合到网关一个入口统一展示。knife4j 是对 Swagger 的增强UI 更友好、支持离线文档导出、支持全局参数比如 Token。网关的聚合方案上常见的做法是使用 knife4j 官方提供的网关聚合依赖在网关服务里配置各个服务对应的 Swagger 资源路径。具体来说每个业务服务暴露自己的/v3/api-docs网关把这些路径聚合到/doc.html下前端只需要访问网关地址即可看到所有服务的接口列表。springdoc: api-docs: enabled: true swagger-ui: enabled: true knife4j: enable: true setting: language: zh_cn业务服务配置这一项是基础关键点在于网关服务里做资源聚合。聚合配置要告诉网关每个服务叫什么名字、去哪里拿文档 JSON 数据并且转发时要把上游服务的 context-path 处理对。配置不当时点击某个接口会报 404多半是StripPrefix的层数不对文档拿不到接口的真实路径。5.2 联调时的统一鉴权传参聚合文档调试接口时最麻烦的是每个接口都要填 Token。knife4j 支持配置全局参数一次性填写 Token 后所有调试请求自动带上 Authorization Header。knife4j: enable: true setting: language: zh_cn global-operations: - authorizations: - name: Authorization in: header type: apiKey这种方案下网关侧的 JWT 过滤器不用改动。由于请求带上了 Header网关放行后传给下游业务服务照常处理。联调效率提升得最明显不用每个服务切换页面去填参数。需要注意的是这个全局参数配置在网关聚合的配置里才有效单独写在业务服务上意义不大因为入口统一了。6. 几个能直接提升开发效率的 Sidebar 配置拿到这套源码后做一些小的参数调整就能改善日常开发体验。下面几个配置点可以作为通用模板直接套用跟具体的商城业务无关但每个都能减少调试时间。1. Nacos 本地启动时的初始配置。单机模式启动 Nacos 用startup.cmd -m standalone不要开集群模式。Windows 服务器上如果端口被占用直接改application.properties里的server.port即可不需要重装。2. 配置文件里的数据库连接建议加autoReconnecttrue。MySQL 默认连接超时时间为 8 小时数据库空闲一段时间后微服务懒连接会失效第一次请求时报连接异常。加上这个参数后能自动重连。spring: datasource: url: jdbc:mysql://localhost:3306/mall?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/ShanghaiautoReconnecttrue3. 用spring-boot-maven-plugin做多模块打包。商城系统是多模块工程直接在根目录执行mvn clean package -DskipTests即可不用每个模块单独打包。-DskipTests会跳过测试用例编译的额外耗时但在交付前还是手动跑一遍关键测试类。4. 服务启动顺序。先启动 Nacos再启动 Seata Server然后启动网关和业务服务。业务服务里不配置对 Nacos 强依赖的可以先启动但网关依赖所有服务的注册信息最好等其他服务都注册完成后再启动网关避免首次调用时路由找不到服务实例。5. 幂等性验证。分布式事务最容易出现的坑是接口被重复调用后产生多条订单。可以在订单服务里加一张去重表以 userId 加 orderNo 作唯一索引插入时捕获 DuplicateKeyException 直接返回上一次的订单结果。本文还有配套的精品资源点击获取
微服务商城系统源码实践：SpringCloud Alibaba组件配置与运行指南
简介一套基于Spring Cloud与Spring Cloud Alibaba的微服务商城系统源码面向中高级Java开发者用于理解微服务拆分、服务治理与分布式场景下的落地实现。包内共515个文件以346个Java源码为核心辅以59个XML和41个YML配置另有9个SQL脚本、55张PNG/JPG示意图片等压缩包仅5.14MB结构紧凑。项目整合Eureka/Nacos服务注册发现、Gateway/Zuul网关、Feign调用、Seata分布式事务、Sentinel限流熔断及OAuth2认证授权覆盖用户、商品、订单、商户、支付等典型商城模块并包含验证码服务等工具类代码。已有225人学习适合想通过完整源码快速掌握Spring Cloud Alibaba组件组合用法、理清微服务权限链路与订单支付流程的开发者参考。1. 拿到微服务商城系统源码第一步不是启动而是拆包看结构很多人在拿到“基于SpringCloud, SpringCloud alibaba的微服务商城系统源码.zip”之后第一反应是解压、配数据库、直接mvn spring-boot:run然后被一连串报错劝退。原因倒不复杂SpringCloud Alibaba 生态的组件版本关联极强Nacos、Gateway、Sentinel、Seata 各自依赖不同启动顺序又有讲究这套源码里十来个微服务模块只要有一个连不上注册中心整条链路就全断。这篇博文不沿着“某某项目的业务功能”去复述而是面向你已经拿到了这份源码、想把它跑起来并改成自己用的场景。我会把这条路上绕不开的组件选型、配置项、启动顺序、分布式事务取舍、网关路由与鉴权方案一次讲透。涉及 SpringCloud、SpringCloud Alibaba、微服务拆分、Nacos 注册配置中心、Sentinel 流量治理这些热搜词背后的工程做法都会落到可复现的命令和代码上。整套架构里有个反直觉的点商城这类业务听起来是典型的“高并发抢购”但源码里真正难调的往往不是并发本身而是服务间调用的链路追踪和分布式事务。订单、库存、支付这三个服务只要不在同一个数据库里怎么保证数据一致才是日常开发里消耗时间最多的地方。下面就从这份源码最核心的技术底座开始把每个模块为什么存在、改哪些参数能跑通讲清楚。2. 微服务商城系统的工程结构模块划分与 SpringCloud Alibaba 组件选型2.1 先看懂十个服务模块和三个基础设施组件标准的 SpringCloud Alibaba 商城源码通常按业务域拆成 mall-gateway网关、mall-auth认证中心、mall-user用户服务、mall-product商品服务、mall-order订单服务、mall-cart购物车服务、mall-payment支付服务、mall-stock库存服务、mall-seckill秒杀服务、mall-search搜索服务。如果代码里带有后台管理界面还会有 mall-admin 服务营销引擎独立的话再拆一个 mall-promotion。拆模块容易真正的难点在基础设施。这份源码背后必然挂着三件事Nacos 做注册中心和配置中心、Sentinel 做流量治理和熔断限流、Seata 做分布式事务管理。有些改版会把 SkyWalking 或 Zipkin 也带上用于链路追踪。你打开源码里的 pom.xml 看依赖如果看到spring-cloud-alibaba-dependencies这个 BOM基本就能确认它的组件版本是统一的不会出现 sentinel 和 nacos client 各自锁版本的问题。dependencyManagement dependencies dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-alibaba-dependencies/artifactId version2021.1/version typepom/type scopeimport/scope /dependency /dependencies /dependencyManagement这里先注意一件事2021.1这个版本号是 SpringCloud Alibaba 的版本不是 SpringBoot 的版本。它对应的是 SpringBoot 2.4.x 和 SpringCloud 2020.0.x。如果你在源码里看到 SpringBoot 版本是 2.3.x那 Alibaba 版本要降到2021.1以下才能兼容。版本不匹配是拿到源码后最常见的启动失败原因比代码本身出错的比例高得多。2.2 注册中心 Nacos为什么商城服务必须全部挂到它上面微服务架构图里画得再漂亮服务之间不通过 HTTP 地址硬编码互调就必须有一个注册中心。Nacos 在这个位置承担两个职责服务注册发现和配置管理。每个微服务启动时向 Nacos 注册自己的 IP 和端口调用方通过服务名去发现对方地址而不是把localhost:8083写死在配置里。商城系统的服务实例数量是动态的订单服务可能部署 3 个副本商品服务可能部署 2 个只有通过注册中心才能做到负载均衡。spring: application: name: mall-order cloud: nacos: discovery: server-addr: 127.0.0.1:8848 namespace: mall-dev group: MALL_GROUP config: server-addr: 127.0.0.1:8848 namespace: mall-dev group: MALL_GROUP file-extension: yaml这段配置写进bootstrap.yaml才能优先加载。server-addr指向 Nacos 的地址namespace区分环境——同一个 Nacos 上可以挂 dev、test、prod 多套环境服务之间通过命名空间隔离不会互相看到。group做逻辑分组商城业务可以统一放MALL_GROUP和公司里的其他业务线区分开。file-extension指定配置文件的格式。有个经常踩的坑Nacos 客户端从 2.x 开始服务端必须也用 2.x且默认会占用 9848 端口做 gRPC 通信。如果你只开了 8848 的防火墙服务会反复报连接超时。源码里如果 Nacos server 是 1.x客户端 spring-cloud-alibaba 版本不需要太高避免因 gRPC 逻辑引入而连不上。2.3 配置中心不只为存参数更重要的是动态刷新商城系统的配置项很多数据库连接串、Redis 地址、MQ 的 topic、支付回调地址、限流阈值、降级开关这堆东西如果在每个服务里各自维护一份改一个参数要重新发版。Nacos 配置中心解决的就是这个问题。服务启动时先连配置中心拉取配置本地application.yaml只保留最低限度的启动信息。在 Nacos 控制台里新建配置Data ID 的命名规则通常是${spring.application.name}-${spring.profiles.active}.${file-extension}。举例mall-order-dev.yaml。配置内容可以是数据源的全套内容也可以只是某个开关项。关键点在于配置中心里能放一项RefreshScope支持的配置它会在 Nacos 端配置变更时自动推给客户端并刷新 Bean。RefreshScope RestController public class OrderSwitchController { Value(${order.timeout:5000}) private Integer orderTimeout; }这里的逻辑是RefreshScope标记的 Bean 在收到 Nacos 配置变更事件后会重新创建实例所以Value注入的值会跟着变。注意只有标记了RefreshScope的类才会被刷新普通 Service 里用Value注入的字段不会自动更新。常见做法是单独写一个配置属性类让其他组件通过调用这个类的方法取值避免在业务代码里到处散落Value。2.3.1 Nacos 配置项缺失时的启动保护源码没有配好的情况经常是 jar 包能启动但连不上数据库。原因多半是 Nacos 里缺失mall-order-dev.yaml这个配置。服务启动时会尝试拉取拉不到就用本地的application.yaml。如果本地配置里的密码是占位符就会导致后续初始化数据源失败。稳妥的处理是先不依赖配置中心把一份完整的配置放在本地确认服务能启动再逐步搬进 Nacos。3. 微服务网关 SpringCloud Gateway路由、鉴权与跨域3.1 网关在商城系统里的位置一切外部流量的统一入口商城系统的外部流量先打到 SpringCloud Gateway再分发到各个微服务。网关不能只做反向代理它的核心职责按优先级排序是路由转发、鉴权校验、限流熔断、跨域处理。源码里网关模块的 pom.xml 会同时引入spring-cloud-starter-gateway、spring-cloud-starter-alibaba-nacos-discovery、spring-cloud-starter-alibaba-sentinel这三样Sentinel 在网关侧做的是sentinel-spring-cloud-gateway-adapter适配。spring: cloud: gateway: routes: - id: mall-product uri: lb://mall-product predicates: - Path/api/product/** filters: - StripPrefix2 - id: mall-order uri: lb://mall-order predicates: - Path/api/order/** filters: - StripPrefix2lb://mall-order表示走负载均衡去 Nacos 发现服务实例Path/api/order/**是路由规则StripPrefix2表示去掉路径中的前两段比如/api/order/create转发到订单服务时变成/create。这套机制下前端对接的路径永远是网关地址微服务内部的地址对客户端完全不可见。3.2 网关层鉴权JWT 校验放在网关而不是每个服务里商城系统的用户认证状态通过 Token 在各服务间传递。常见方案是 gateway 统一做 JWT 校验校验通过后把用户信息放进 Header 再转发给下游服务。这样订单服务、商品服务本身不需要关心 Token 怎么解析只需要信任网关传过来的 Header。Configuration public class GatewayAuthFilter { Bean public RouteLocator customRouteLocator(RouteLocatorBuilder builder) { return builder.routes() .route(mall-auth, r - r.path(/api/auth/**) .filters(f - f.stripPrefix(2)) .uri(lb://mall-auth)) .route(mall-order, r - r.path(/api/order/**) .filters(f - f.stripPrefix(2) .filter(new JwtAuthFilter())) .uri(lb://mall-order)) .build(); } }这里把需要放行的路径登录、注册、验证码绕过 JWT 校验其他业务路径统一经过JwtAuthFilter。校验逻辑里只做解析和验签不查数据库。用户角色权限这类信息也放进 Token 的 claims 里下游服务从 Header 取。网关改过之后需要重点验证的一点是放行路径是否和自己控制的鉴权白名单一致。比如支付回调接口不允许被网关拦截否则第三方支付平台的回调请求会被 401 拒掉。常见的做法是把回调路径单独再开一个网关路由并且不用走 JWT 校验或者在网关转发时手动加上内部密钥 Header。4. 分布式事务与流量治理Seata 的取舍和 Sentinel 的参数调节4.1 下单扣库存这种跨服务事务为什么不能直接用本地事务商城最典型的高频操作是用户下单订单服务插入订单记录库存服务扣减库存购物车服务清空购物车支付成功后还要通知物流系统。如果不做分布式事务管理下单成功但库存扣减失败就会出现超卖库存扣了但订单状态更新失败用户多付了钱。Seata 在这个位置上有 AT 模式和 TCC 模式两种选择。源码里多数情况集成的是 AT 模式它的特点是业务代码零侵入框架自动解析 SQL、生成 undo 日志、事务提交时做全局提交或回滚。AT 模式要求所有参与事务的数据库都支持 JDBC 标准接口并且每条数据表都要有主键。seata: enabled: true application-id: mall-order tx-service-group: mall_tx_group registry: type: nacos nacos: server-addr: 127.0.0.1:8848 service: vgroup-mapping: mall_tx_group: default这里tx-service-group是这个事务分组所有参与分布式事务的服务必须用同一个分组名才能共用一个 Seata Server。vgroup-mapping把逻辑分组映射到 Seata Server 的集群名。注意 Seata Server 也要注册到 Nacos如果 Nacos 里没有它的注册记录业务服务启动会报can not get cluster name。AT 模式的代价在于数据源必须被 Seata 代理。DataSource 的 Bean 要加GlobalTransactionScanner或者在配置里指定代理数据源。如果源码里没有做这一步Seata 的全局事务是不生效的只是代码不报错数据照常提交。4.2 Sentinel 在商城场景的 3 个必调参数QPS、线程数、熔断比例Sentinel 是 SpringCloud Alibaba 生态里负责流量治理的组件。商城系统里最常见的三种场景秒杀接口瞬时流量极高需要限流支付回调接口偶尔超时需要熔断商品详情接口依赖商品服务和营销服务其中一个挂了另一个不能拖垮。以秒杀下单接口为例单机 QPS 限制设置为 200超过的直接返回“系统繁忙”。在 Sentinel 控制台配置的规则本质上是下发到每个服务实例的本地内存里的。控制台本身不拦截流量它只负责推送规则。PostMapping(/seckill/{skuId}) SentinelResource(value seckillOrder, blockHandler seckillBlockHandler) public R seckill(PathVariable Long skuId) { return seckillService.doSeckill(skuId); } public R seckillBlockHandler(Long skuId, BlockException e) { return R.error(当前抢购人数过多请稍后再试); }SentinelResource切的是资源维度blockHandler指定被限流后的返回逻辑。QPS 这项最好压测后确定不要拍脑袋填。线程数这项针对的是慢调用场景比如支付服务响应越来越慢活跃线程数超过阈值后直接拒绝新请求。熔断比例这项针对的是下游接口的错误率错误率超过 50% 时打开熔断之后的请求快速失败不再真正打到下游服务。4.2.1 规则持久化的必要性直接用控制台配置规则服务重启后规则会丢。生产环境常见做法是把规则推到 Nacos 配置中心Sentinel 客户端监听 Nacos 配置变更实现规则持久化。源码里如果只是演示版本一般不带这个能力。你接手之后要做的是把sentinel-dashboard和 Nacos 打通控制台只负责展示规则统一配置在 Nacos。5. 微服务整合 knife4j 做接口文档聚合与联调验证5.1 为什么要聚合接口文档而不是每个服务各开一个 Swagger 页面十几个微服务每个都有独立的 Swagger UI前端开发要记十几个端口来调试这在开发联调阶段根本没法用。微服务整合 knife4j 的价值就在这里它把每个微服务的 OpenAPI 文档聚合到网关一个入口统一展示。knife4j 是对 Swagger 的增强UI 更友好、支持离线文档导出、支持全局参数比如 Token。网关的聚合方案上常见的做法是使用 knife4j 官方提供的网关聚合依赖在网关服务里配置各个服务对应的 Swagger 资源路径。具体来说每个业务服务暴露自己的/v3/api-docs网关把这些路径聚合到/doc.html下前端只需要访问网关地址即可看到所有服务的接口列表。springdoc: api-docs: enabled: true swagger-ui: enabled: true knife4j: enable: true setting: language: zh_cn业务服务配置这一项是基础关键点在于网关服务里做资源聚合。聚合配置要告诉网关每个服务叫什么名字、去哪里拿文档 JSON 数据并且转发时要把上游服务的 context-path 处理对。配置不当时点击某个接口会报 404多半是StripPrefix的层数不对文档拿不到接口的真实路径。5.2 联调时的统一鉴权传参聚合文档调试接口时最麻烦的是每个接口都要填 Token。knife4j 支持配置全局参数一次性填写 Token 后所有调试请求自动带上 Authorization Header。knife4j: enable: true setting: language: zh_cn global-operations: - authorizations: - name: Authorization in: header type: apiKey这种方案下网关侧的 JWT 过滤器不用改动。由于请求带上了 Header网关放行后传给下游业务服务照常处理。联调效率提升得最明显不用每个服务切换页面去填参数。需要注意的是这个全局参数配置在网关聚合的配置里才有效单独写在业务服务上意义不大因为入口统一了。6. 几个能直接提升开发效率的 Sidebar 配置拿到这套源码后做一些小的参数调整就能改善日常开发体验。下面几个配置点可以作为通用模板直接套用跟具体的商城业务无关但每个都能减少调试时间。1. Nacos 本地启动时的初始配置。单机模式启动 Nacos 用startup.cmd -m standalone不要开集群模式。Windows 服务器上如果端口被占用直接改application.properties里的server.port即可不需要重装。2. 配置文件里的数据库连接建议加autoReconnecttrue。MySQL 默认连接超时时间为 8 小时数据库空闲一段时间后微服务懒连接会失效第一次请求时报连接异常。加上这个参数后能自动重连。spring: datasource: url: jdbc:mysql://localhost:3306/mall?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/ShanghaiautoReconnecttrue3. 用spring-boot-maven-plugin做多模块打包。商城系统是多模块工程直接在根目录执行mvn clean package -DskipTests即可不用每个模块单独打包。-DskipTests会跳过测试用例编译的额外耗时但在交付前还是手动跑一遍关键测试类。4. 服务启动顺序。先启动 Nacos再启动 Seata Server然后启动网关和业务服务。业务服务里不配置对 Nacos 强依赖的可以先启动但网关依赖所有服务的注册信息最好等其他服务都注册完成后再启动网关避免首次调用时路由找不到服务实例。5. 幂等性验证。分布式事务最容易出现的坑是接口被重复调用后产生多条订单。可以在订单服务里加一张去重表以 userId 加 orderNo 作唯一索引插入时捕获 DuplicateKeyException 直接返回上一次的订单结果。本文还有配套的精品资源点击获取
