简介面向毕业设计场景的基于Spring Cloud微服务架构的商城项目整合了服务注册与发现、配置管理、分布式事务、远程调用、熔断保护、链路追踪、统一网关、后台监控、日志收集等微服务核心能力覆盖后台管理、商户端、用户端及定时任务等业务模块适合计算机相关专业毕业生或希望深入理解微服务落地的开发人员参考。压缩包内共计一千八百七十三个文件包括二百四十个Java源文件、一百五十四个依赖包、七十九个XML与五十一个YML配置文件、十二个SQL数据库脚本另有大量JPG和PNG图片资源整体体积约一百四十三兆目录按网关层、调用层和业务模块划分便于按需查阅。项目中实现了网关Token鉴权、商户与用户权限控制、商品与订单管理、微信支付回调、超时订单自动处理等关键逻辑并附带详细说明文档既可直接作为毕业设计源码参考也有助于理解微服务架构中服务治理、分布式事务和链路监控等方案的实际落地方式。目前已有三十人学习下载。1. 一次订单支付背后微服务商城如何做鉴权与事务兜底从用户下单、支付回调到订单超时关闭一次看似普通的流程会横跨网关、用户调用服务、商品服务、订单服务和微信支付服务。整个流程在单体架构里由一个事务就能完成拆成微服务后每个服务独立数据库就出现了两个必须解决的问题一是所有服务接口不能裸奔必须统一经过网关校验二是订单创建时如果库存扣了但订单没生成要靠分布式事务回滚。这个毕业设计正好把这两条线串了起来适合两类人一类是课程设计需要完整可运行源码和数据库脚本的在校生另一类是打算从单体跳到微服务开发、想在一套代码里看清Gateway、Feign、Hystrix、Seata、Zipkin、ELK之间如何配合的后端开发。下面按一次请求的调用顺序逐层拆解。2. 网关层与Nacos配置中心gatewayToken的生成、下发与校验2.1 为什么选择Redis保存gatewayToken项目说明里的网关层方案非常明确TokenFilter生成gatewayToken并保存至Redis访问服务时在请求头加上这个字符串每个服务被访问时都验证请求头中的字符串匹配才允许访问否则返回“非法访问”提示。在微服务架构里网关是唯一对外入口常见做法是网关做OAuth2或者JWT解析。这个项目采用了更直观的方式TokenFilter每次请求生成一个UUID作为gatewayToken写入Redis并设置过期时间同时把该值放入请求头向下游透传。下游每个微服务都写一个拦截器从请求头取出gatewayToken再查Redis能查到就放行。它解决的问题很实际即使某个微服务的非网关端口被误暴露没有合法gatewayToken的请求也会被拦截。相比引入全套Spring Security OAuth2这套方案对学习微服务路由和过滤器的人来说更容易看懂。Component public class TokenFilter implements GlobalFilter, Ordered { private final StringRedisTemplate redisTemplate; public TokenFilter(StringRedisTemplate redisTemplate) { this.redisTemplate redisTemplate; } Override public MonoVoid filter(ServerWebExchange exchange, GatewayFilterChain chain) { String token UUID.randomUUID().toString().replace(-, ); redisTemplate.opsForValue().set(gateway:token: token, 1, 600, TimeUnit.SECONDS); ServerHttpRequest request exchange.getRequest().mutate() .header(gatewayToken, token) .build(); return chain.filter(exchange.mutate().request(request).build()); } Override public int getOrder() { return -100; } }逻辑说明UUID.randomUUID()生成全局唯一的32位字符串replace(-, )去掉横线以缩短长度。写入Redis的key加了gateway:token:前缀避免与其他业务key冲突600秒过期时间作为网关校验的默认有效期。这里要特别注意上述代码是每个请求生成新token并覆盖Redis中同名key旧token自然过期后会被Redis清理。生产环境更推荐的做法是登录成功时生成token并保存到Redis网关从Redis读取后放入请求头而不是每个请求重新生成这样下游服务才能根据token追踪用户会话。参数说明getOrder()返回-100表示这个全局过滤器优先级最高尽量在路由转发之前执行redisTemplate.opsForValue().set的第四个参数是过期时间单位这里使用TimeUnit.SECONDS意味着600秒后token自动失效。如果你希望微服务之间自动传递身份信息还可以在过滤器里继续put其它请求头比如X-User-Id。2.2 Nacos注册中心与配置中心的衔接网关和所有微服务启动后都要注册到Nacos否则lb://开头的路由没法做负载均衡。在bootstrap.yml中配置spring: application: name: gateway-service cloud: nacos: discovery: server-addr: 127.0.0.1:8848 namespace: mall config: server-addr: 127.0.0.1:8848 namespace: mall group: DEFAULT_GROUP file-extension: yaml逻辑说明namespace用于环境隔离例如dev、test、prod各建一个命名空间。file-extension: yaml决定了Nacos配置管理里读取的Data ID格式默认拼接为gateway-service.yaml。网关启动时会拉取这个配置文件如果拉取失败启动不会立刻报错但路由信息会缺失。网关注册到Nacos后还需要把路由信息配好。课程设计里放在本地配置也没问题但生产环境更推荐放到Nacos上这样修改路由不用重启网关。路由配置如下spring: cloud: gateway: routes: - id: user-service-route uri: lb://user-service predicates: - Path/api/user/** filters: - StripPrefix1lb://user-service表示从Nacos找到名为user-service的服务StripPrefix1表示去掉第一段路径/api/user后再转发。实际部署时只要网关和微服务都指向同一个Nacos就能完成自动发现与负载均衡。下面是Nacos关键配置项的说明配置项作用生产环境建议server-addrNacos服务端地址使用域名或Nginx代理避免写死IPnamespace环境隔离与多租户每个环境一个namespacegroup同一环境内分组默认DEFAULT_GROUP即可file-extension配置文件扩展名统一使用yaml2.3 服务端拦截器如何校验gatewayToken下游服务要验证网关下发的Token最合适的落点是Spring拦截器在WebMvcConfigurer里注册让它拦截除了登录接口和静态资源之外的所有路径。public class GatewayTokenInterceptor implements HandlerInterceptor { private final StringRedisTemplate redisTemplate; public GatewayTokenInterceptor(StringRedisTemplate redisTemplate) { this.redisTemplate redisTemplate; } Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { String token request.getHeader(gatewayToken); if (token null || Boolean.FALSE.equals(redisTemplate.hasKey(gateway:token: token))) { response.setStatus(403); response.setCharacterEncoding(UTF-8); try { response.getWriter().write(非法访问); } catch (IOException ignored) { } return false; } return true; } }逻辑说明先判断请求头gatewayToken是否存在然后查Redis key是否存在。hasKey返回布尔值这里用Boolean.FALSE.equals(...)是为了避免Redis返回null时出现NPE。返回false表示拦截请求不再执行后续业务返回true则放行。校验失败时设置403状态码并写出“非法访问”提示文本与项目说明中的提示一致。参数说明403比401更严谨这里表示服务器理解了请求但拒绝执行如果使用401则语义是未认证。实际项目中可以考虑同时设置Cache-Control: no-store防止代理缓存错误页面。拦截器注册时排除登录、注册和静态资源路径例如excludePathPatterns(/login, /register, /static/**)否则登录接口自己也会在校验Token时被拦截。2.4 配置动态刷新与版本兼容Nacos配置中心的一个价值是修改配置后无需重启服务。在需要动态刷新的类上加RefreshScope即可。RefreshScope RestController public class TokenConfigController { Value(${mall.gateway.expire:600}) private Long expireSeconds; }修改Nacos上的mall.gateway.expire后调用POST /actuator/refreshexpireSeconds会被重新绑定。这里的${mall.gateway.expire:600}表示如果没有配置则默认600秒。要注意Spring Cloud Alibaba版本必须和Spring Boot版本匹配老版本引入RefreshScope后配置更新偶尔不生效处理办法是在配置类中加一个ConfigurationProperties(prefix mall.gateway)这样刷新更可靠。3. 服务间调用链Feign接口设计、Hystrix熔断与Seata分布式事务3.1 Feign声明式远程调用替代RestTemplate项目正文里明确写了“远程调用服务feign”。调用层四个模块与业务服务之间的调用使用Feign最合适。相比RestTemplateFeign把HTTP API封装成Java接口调用方不需要拼URL代码简洁且容易做链路线程上下文传递。FeignClient(name order-service, path /order, fallback OrderClientFallback.class) public interface OrderClient { PostMapping(/create) Result createOrder(RequestBody OrderCreateDTO dto); GetMapping(/get) Result getOrderById(RequestParam(orderId) Long orderId); }逻辑说明name order-service指定下游服务在Nacos中的注册名Feign会从Nacos拿到该服务实例列表。path /order表示接口统一前缀fallback指定降级处理类。记住RequestBody只能有一个DTO必须实现Serializable否则Feign底层序列化时容易报类型转换异常。参数说明RequestParam(orderId)必须显式写出参数名。如果编译时不加-parameters参数Feign无法从反射中拿到参数名请求会变成orderIdnull。在pom.xml中配置maven-compiler-plugin的parameters为true能解决这个问题。3.2 Hystrix超时与熔断参数调用层引入Hystrix后必须设置合理的超时时间。订单支付或微信支付回调这类接口往往超过默认1秒因此要单独调大超时阈值。hystrix: command: default: execution: isolation: thread: timeoutInMilliseconds: 8000 circuitBreaker: requestVolumeThreshold: 10 errorThresholdPercentage: 50 sleepWindowInMilliseconds: 5000 threadpool: default: coreSize: 20 maxQueueSize: 200逻辑说明timeoutInMilliseconds是线程超时时间超过这个时间会触发降级requestVolumeThreshold是10秒内请求数阈值只有请求数达到该值才会判断熔断errorThresholdPercentage是错误率阈值50%表示请求失败一半时打开熔断器sleepWindowInMilliseconds是熔断打开后的睡眠时间之后进入半开状态尝试放行少量请求。Hystrix核心参数表如下参数含义建议值timeoutInMilliseconds线程执行超时时间8000毫秒requestVolumeThreshold10秒内最小请求数10errorThresholdPercentage错误率熔断阈值50sleepWindowInMilliseconds熔断器打开后等待时间5000毫秒coreSize默认线程池核心线程数20maxQueueSize线程池任务队列容量200降级方法里不能只返回一个“失败”字符串。订单服务的降级需要区分网络异常和业务失败否则定时任务可能把正常订单误删。实际设计中可以返回Result对象其中错误码用503表示依赖不可用业务层可以针对该错误码做补偿。3.3 Seata AT模式管理分布式事务微服务拆分后一次下单会调用商品服务扣减库存再调用订单服务创建订单。如果订单创建失败库存已经被扣掉了必须通过Seata全局事务回滚。AT模式对业务代码侵入最小核心就是加一个GlobalTransactional注解。Service public class OrderFacadeService { GlobalTransactional(name create-order, timeoutMills 60000, rollbackFor Exception.class) public void createOrder(OrderCreateDTO dto) { productService.deductStock(dto.getProductId(), dto.getCount()); orderService.createOrder(dto); } }逻辑说明name create-order是全局事务ID在Seata控制台里用它来查找事务详情timeoutMills超过60秒会由协调器发起回滚rollbackFor指定哪些异常触发回滚这里使用Exception.class表示捕获一切异常。AT模式要求所有参与全局事务的业务库中都必须有undo_log表课程设计源码里的数据库文件应该已经包含该表和对应的SQL如果启动时提示找不到表优先检查Seata配置中数据库连接和业务数据库是否一致。参数说明productService.deductStock和orderService.createOrder都是通过Feign调用。Seata在发起方生成全局事务XID并通过Feign请求头透传给下游服务下游服务在事务分支注册后执行本地事务。如果下游服务提交后发生异常Seata会依据undo_log中记录的前后镜像生成反向SQL进行回滚。需要特别提醒Feign透传XID必须配置RequestInterceptor源码中这个类通常写好了但自己重写时容易漏掉导致全局事务失效只回滚当前服务。Component public class SeataRequestInterceptor implements RequestInterceptor { Override public void apply(RequestTemplate template) { String xid RootContext.getXID(); if (xid ! null) { template.header(RootContext.KEY_XID, xid); } } }这个拦截器的意义在于把Seata的XID放进Feign请求头下游服务拿到后才能加入同一个全局事务分支。漏配这个类即使加了GlobalTransactional也无法跨库回滚。4. 业务模块拆分的四种调用范式后台、商户、用户与定时任务4.1 登录拦截与RBAC权限校验的公共处理在项目说明的调用层中后台、商户、用户模块重点任务都是“登录拦截”。登录拦截要做两件事第一校验gatewayToken是否真实有效第二解析当前登录用户并做RBAC权限判断。实际项目中网关校验通过后会向请求头写入X-User-Id但下游不能盲目信任该字段因为该请求头可能被伪造。拦截器代码示例如下public class RbacInterceptor implements HandlerInterceptor { private final StringRedisTemplate redisTemplate; private final PermissionFeignClient permissionFeignClient; Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { String token request.getHeader(gatewayToken); String userId request.getHeader(X-User-Id); if (token null || userId null) { throw new BizException(非法访问); } Boolean valid redisTemplate.hasKey(gateway:token: token); if (Boolean.FALSE.equals(valid)) { throw new BizException(非法访问); } if (!permissionFeignClient.checkPermission(userId, request.getRequestURI())) { throw new BizException(无权限访问); } return true; } }这个拦截器里每个请求都会调用远程权限服务性能和稳定性都不理想。改进方式是引入本地缓存把用户ID与接口路径的权限关系缓存到Caffeine或Redis并设置10分钟过期时间。课程设计里可以用Cacheable简化实现但要注意权限变更后缓存的实时性。在后台模块里还承担RBAC权限管理功能需要维护用户表、角色表、菜单表和用户角色关联表。用户登录时后台主页服务查询角色并生成权限集合然后写入Redis后续拦截器从Redis读取该集合做路径匹配即可不必每次请求都查库。4.2 四大调用模块的功能矩阵四个调用模块不是简单的代码复制而是按业务边界拆分的聚合层。后台模块偏管理商户模块偏商品运营用户模块偏购物全流程定时任务负责系统兜底。调用模块核心功能依赖的下游服务后台模块登录注册、商户停用启用、费率修改、RBAC权限管理、群发消息、订单查看后台主页、商户主页、用户主页、订单服务商户模块商户海报和logo修改、用户信息查看、商品CRUD、上下架、订单查看商户主页、用户主页、商品服务、订单服务用户模块商城主页海报、商品图片、购物车、用户信息修改、商品评价、订单生成、微信支付图片服务、用户主页、订单服务、微信支付服务定时任务超时订单删除、商品库存恢复、微信支付回调后修改订单状态订单服务、商品服务、微信支付服务从表中能看到不同调用模块会重复依赖用户主页服务但各自关注的数据维度不同。后台关心启用停用商户关注logo和海报用户关心购物车和评论。为了避免调用层代码膨胀把公共的Feign接口抽成一个client-api模块四个调用层只在自己的业务应用中引用自己需要的部分。4.3 定时任务如何保证不重复执行定时任务部署到多实例环境时Scheduled会在每个实例上同时执行造成重复删单、库存多加。必须使用分布式锁保证只有一个实例在执行。Scheduled(cron 0 */5 * * * ?) public void closeTimeoutOrders() { String lockKey lock:close-order; Boolean locked redisTemplate.opsForValue().setIfAbsent(lockKey, 1, Duration.ofMinutes(2)); if (Boolean.TRUE.equals(locked)) { try { ListLong orderIds orderClient.listTimeoutOrders(); for (Long orderId : orderIds) { orderClient.closeOrder(orderId); productClient.restoreStock(orderId); } } finally { redisTemplate.delete(lockKey); } } }逻辑说明setIfAbsent(lockKey, 1, Duration.ofMinutes(2))是Redis的SET NX EX命令只有key不存在时才能写入成功从而保证只有一个实例拿到锁。2分钟过期时间防止持锁实例宕机后锁永久存在。拿到锁的实例先查询超时订单列表再逐个关闭订单并恢复库存。为了追求一致性推荐把“关闭订单”和“恢复库存”放到同一个Seata全局事务中避免恢复库存时通知服务失败导致库存少回。参数说明cron 0 */5 * * * ?表示每5分钟执行一次。如果订单允许15分钟内支付扫描条件可以设置为创建时间距今超过15分钟且状态为未支付、未关闭。任务开始时删除锁而不是任务执行完再删除这样可以防止任务执行时间超过锁过期时间时锁提前被别人拿走。更稳妥的方案是在finally块中先判断锁的值是否仍属于当前实例再删除避免误删别人的锁。4.4 微信支付回调的幂等处理微信支付成功后会以异步回调方式通知商户通知可能有多次延迟重试。用户模块中“订单的生成”“微信支付服务实现微信支付功能”都涉及回调处理。回调接口必须做到幂等处理方式是先按订单号查询状态状态为未支付时进行修改UPDATE t_order SET status PAID, pay_time NOW() WHERE order_no #{orderNo} AND status UNPAID参数说明status UNPAID这个条件保证一次回调只能把订单从未支付改成已支付。第二次回调时因为状态已变成PAID更新影响行数为0业务层据此返回“处理成功”给微信服务器避免重复发货或重复加积分。课程设计源码中还可以配合订单服务里的唯一索引来进一步保证幂等。5. Zipkin链路追踪与ELK日志收集的落地技巧5.1 Zipkin链路数据采样与请求拼接一个下单请求会经过网关、用户调用模块、订单模块、商品模块排查问题如果没有链路信息只能逐个服务翻日志。Zipkin配合Sleuth可以为每个请求生成全局唯一的TraceId并在服务间自动传递。spring: zipkin: base-url: http://127.0.0.1:9411 sender: type: web sleuth: sampler: probability: 1.0逻辑说明probability: 1.0表示全量采样适合课程设计演示能看到所有请求链路。生产环境建议设置0.1只采样10%避免链路数据量太大对存储造成压力。sender.type: web表示通过HTTP上报给Zipkin如果链路数据量大可以改成kafka上报减少对应用线程的阻塞。5.2 ELK日志收集的关键配置Zipkin能告诉我们请求经过了哪些服务但具体报错信息要看日志。ELK体系里应用日志通过Logstash发给Elasticsearch再用Kibana查询。要让日志与链路关联必须把TraceId写进日志pattern中。appender nameLOGSTASH classnet.logstash.logback.appender.LogstashTcpSocketAppender destination127.0.0.1:5000/destination encoder classnet.logstash.logback.encoder.LogstashEncoder customFields{service_name:user-call-service}/customFields /encoder /appender逻辑说明LogstashTcpSocketAppender通过TCP把日志发送到LogstashLogstashEncoder会把MDC中的traceId、spanId作为JSON字段序列化输出。service_name自定义字段用于区分是哪个服务产生的日志这样日志在Elasticsearch中可以通过service_name关键字过滤。如果项目不便引入额外依赖在logback-spring.xml里直接把%X{traceId}写入pattern也可以但Kibana解析会麻烦一些。无论在Zipkin还是日志中TraceId的格式都是一串16位十六进制随机数或64位数字匹配规则是同一个请求的所有服务日志包含相同的TraceId。5.3 Kibana验证链路是否真正打通在Kibana中先用service_name: user-call-service过滤找到一次具体请求的日志复制其traceId再使用该traceId搜索全部日志就能看到这次请求在网关、调用层、订单服务、商品服务里的全部记录。排查性能瓶颈的顺序是先在Zipkin查看这个请求的Span时间线找到耗时最大的服务进入Kibana用traceId搜索该服务的日志查看线程状态、SQL执行时间和异常信息。订单服务出现明显超时时还能在Zipkin里看到Feign客户端调用阶段的时间占比从而判断是网络问题还是下游数据库慢查询。这是一个实用技巧课程设计演示时不要一次性启动全部服务先启动Nacos、Redis、Seata Server、Zipkin和Elasticsearch再启动业务服务最后启动四个调用层模块和网关。启动过程中观察Nacos服务列表确认所有服务都注册成功后再进行下单测试这样能准确观察链路数据是否完整。若日志里出现大量zipkin.reporter断开连接错误排查Zipkin地址是否能从应用服务器访问其次检查spring.zipkin.base-url路径是否写错成/api/v2/spans这个是大多数链路追踪不生效的主要原因。本文还有配套的精品资源点击获取
简介面向毕业设计场景的基于Spring Cloud微服务架构的商城项目整合了服务注册与发现、配置管理、分布式事务、远程调用、熔断保护、链路追踪、统一网关、后台监控、日志收集等微服务核心能力覆盖后台管理、商户端、用户端及定时任务等业务模块适合计算机相关专业毕业生或希望深入理解微服务落地的开发人员参考。压缩包内共计一千八百七十三个文件包括二百四十个Java源文件、一百五十四个依赖包、七十九个XML与五十一个YML配置文件、十二个SQL数据库脚本另有大量JPG和PNG图片资源整体体积约一百四十三兆目录按网关层、调用层和业务模块划分便于按需查阅。项目中实现了网关Token鉴权、商户与用户权限控制、商品与订单管理、微信支付回调、超时订单自动处理等关键逻辑并附带详细说明文档既可直接作为毕业设计源码参考也有助于理解微服务架构中服务治理、分布式事务和链路监控等方案的实际落地方式。目前已有三十人学习下载。1. 一次订单支付背后微服务商城如何做鉴权与事务兜底从用户下单、支付回调到订单超时关闭一次看似普通的流程会横跨网关、用户调用服务、商品服务、订单服务和微信支付服务。整个流程在单体架构里由一个事务就能完成拆成微服务后每个服务独立数据库就出现了两个必须解决的问题一是所有服务接口不能裸奔必须统一经过网关校验二是订单创建时如果库存扣了但订单没生成要靠分布式事务回滚。这个毕业设计正好把这两条线串了起来适合两类人一类是课程设计需要完整可运行源码和数据库脚本的在校生另一类是打算从单体跳到微服务开发、想在一套代码里看清Gateway、Feign、Hystrix、Seata、Zipkin、ELK之间如何配合的后端开发。下面按一次请求的调用顺序逐层拆解。2. 网关层与Nacos配置中心gatewayToken的生成、下发与校验2.1 为什么选择Redis保存gatewayToken项目说明里的网关层方案非常明确TokenFilter生成gatewayToken并保存至Redis访问服务时在请求头加上这个字符串每个服务被访问时都验证请求头中的字符串匹配才允许访问否则返回“非法访问”提示。在微服务架构里网关是唯一对外入口常见做法是网关做OAuth2或者JWT解析。这个项目采用了更直观的方式TokenFilter每次请求生成一个UUID作为gatewayToken写入Redis并设置过期时间同时把该值放入请求头向下游透传。下游每个微服务都写一个拦截器从请求头取出gatewayToken再查Redis能查到就放行。它解决的问题很实际即使某个微服务的非网关端口被误暴露没有合法gatewayToken的请求也会被拦截。相比引入全套Spring Security OAuth2这套方案对学习微服务路由和过滤器的人来说更容易看懂。Component public class TokenFilter implements GlobalFilter, Ordered { private final StringRedisTemplate redisTemplate; public TokenFilter(StringRedisTemplate redisTemplate) { this.redisTemplate redisTemplate; } Override public MonoVoid filter(ServerWebExchange exchange, GatewayFilterChain chain) { String token UUID.randomUUID().toString().replace(-, ); redisTemplate.opsForValue().set(gateway:token: token, 1, 600, TimeUnit.SECONDS); ServerHttpRequest request exchange.getRequest().mutate() .header(gatewayToken, token) .build(); return chain.filter(exchange.mutate().request(request).build()); } Override public int getOrder() { return -100; } }逻辑说明UUID.randomUUID()生成全局唯一的32位字符串replace(-, )去掉横线以缩短长度。写入Redis的key加了gateway:token:前缀避免与其他业务key冲突600秒过期时间作为网关校验的默认有效期。这里要特别注意上述代码是每个请求生成新token并覆盖Redis中同名key旧token自然过期后会被Redis清理。生产环境更推荐的做法是登录成功时生成token并保存到Redis网关从Redis读取后放入请求头而不是每个请求重新生成这样下游服务才能根据token追踪用户会话。参数说明getOrder()返回-100表示这个全局过滤器优先级最高尽量在路由转发之前执行redisTemplate.opsForValue().set的第四个参数是过期时间单位这里使用TimeUnit.SECONDS意味着600秒后token自动失效。如果你希望微服务之间自动传递身份信息还可以在过滤器里继续put其它请求头比如X-User-Id。2.2 Nacos注册中心与配置中心的衔接网关和所有微服务启动后都要注册到Nacos否则lb://开头的路由没法做负载均衡。在bootstrap.yml中配置spring: application: name: gateway-service cloud: nacos: discovery: server-addr: 127.0.0.1:8848 namespace: mall config: server-addr: 127.0.0.1:8848 namespace: mall group: DEFAULT_GROUP file-extension: yaml逻辑说明namespace用于环境隔离例如dev、test、prod各建一个命名空间。file-extension: yaml决定了Nacos配置管理里读取的Data ID格式默认拼接为gateway-service.yaml。网关启动时会拉取这个配置文件如果拉取失败启动不会立刻报错但路由信息会缺失。网关注册到Nacos后还需要把路由信息配好。课程设计里放在本地配置也没问题但生产环境更推荐放到Nacos上这样修改路由不用重启网关。路由配置如下spring: cloud: gateway: routes: - id: user-service-route uri: lb://user-service predicates: - Path/api/user/** filters: - StripPrefix1lb://user-service表示从Nacos找到名为user-service的服务StripPrefix1表示去掉第一段路径/api/user后再转发。实际部署时只要网关和微服务都指向同一个Nacos就能完成自动发现与负载均衡。下面是Nacos关键配置项的说明配置项作用生产环境建议server-addrNacos服务端地址使用域名或Nginx代理避免写死IPnamespace环境隔离与多租户每个环境一个namespacegroup同一环境内分组默认DEFAULT_GROUP即可file-extension配置文件扩展名统一使用yaml2.3 服务端拦截器如何校验gatewayToken下游服务要验证网关下发的Token最合适的落点是Spring拦截器在WebMvcConfigurer里注册让它拦截除了登录接口和静态资源之外的所有路径。public class GatewayTokenInterceptor implements HandlerInterceptor { private final StringRedisTemplate redisTemplate; public GatewayTokenInterceptor(StringRedisTemplate redisTemplate) { this.redisTemplate redisTemplate; } Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { String token request.getHeader(gatewayToken); if (token null || Boolean.FALSE.equals(redisTemplate.hasKey(gateway:token: token))) { response.setStatus(403); response.setCharacterEncoding(UTF-8); try { response.getWriter().write(非法访问); } catch (IOException ignored) { } return false; } return true; } }逻辑说明先判断请求头gatewayToken是否存在然后查Redis key是否存在。hasKey返回布尔值这里用Boolean.FALSE.equals(...)是为了避免Redis返回null时出现NPE。返回false表示拦截请求不再执行后续业务返回true则放行。校验失败时设置403状态码并写出“非法访问”提示文本与项目说明中的提示一致。参数说明403比401更严谨这里表示服务器理解了请求但拒绝执行如果使用401则语义是未认证。实际项目中可以考虑同时设置Cache-Control: no-store防止代理缓存错误页面。拦截器注册时排除登录、注册和静态资源路径例如excludePathPatterns(/login, /register, /static/**)否则登录接口自己也会在校验Token时被拦截。2.4 配置动态刷新与版本兼容Nacos配置中心的一个价值是修改配置后无需重启服务。在需要动态刷新的类上加RefreshScope即可。RefreshScope RestController public class TokenConfigController { Value(${mall.gateway.expire:600}) private Long expireSeconds; }修改Nacos上的mall.gateway.expire后调用POST /actuator/refreshexpireSeconds会被重新绑定。这里的${mall.gateway.expire:600}表示如果没有配置则默认600秒。要注意Spring Cloud Alibaba版本必须和Spring Boot版本匹配老版本引入RefreshScope后配置更新偶尔不生效处理办法是在配置类中加一个ConfigurationProperties(prefix mall.gateway)这样刷新更可靠。3. 服务间调用链Feign接口设计、Hystrix熔断与Seata分布式事务3.1 Feign声明式远程调用替代RestTemplate项目正文里明确写了“远程调用服务feign”。调用层四个模块与业务服务之间的调用使用Feign最合适。相比RestTemplateFeign把HTTP API封装成Java接口调用方不需要拼URL代码简洁且容易做链路线程上下文传递。FeignClient(name order-service, path /order, fallback OrderClientFallback.class) public interface OrderClient { PostMapping(/create) Result createOrder(RequestBody OrderCreateDTO dto); GetMapping(/get) Result getOrderById(RequestParam(orderId) Long orderId); }逻辑说明name order-service指定下游服务在Nacos中的注册名Feign会从Nacos拿到该服务实例列表。path /order表示接口统一前缀fallback指定降级处理类。记住RequestBody只能有一个DTO必须实现Serializable否则Feign底层序列化时容易报类型转换异常。参数说明RequestParam(orderId)必须显式写出参数名。如果编译时不加-parameters参数Feign无法从反射中拿到参数名请求会变成orderIdnull。在pom.xml中配置maven-compiler-plugin的parameters为true能解决这个问题。3.2 Hystrix超时与熔断参数调用层引入Hystrix后必须设置合理的超时时间。订单支付或微信支付回调这类接口往往超过默认1秒因此要单独调大超时阈值。hystrix: command: default: execution: isolation: thread: timeoutInMilliseconds: 8000 circuitBreaker: requestVolumeThreshold: 10 errorThresholdPercentage: 50 sleepWindowInMilliseconds: 5000 threadpool: default: coreSize: 20 maxQueueSize: 200逻辑说明timeoutInMilliseconds是线程超时时间超过这个时间会触发降级requestVolumeThreshold是10秒内请求数阈值只有请求数达到该值才会判断熔断errorThresholdPercentage是错误率阈值50%表示请求失败一半时打开熔断器sleepWindowInMilliseconds是熔断打开后的睡眠时间之后进入半开状态尝试放行少量请求。Hystrix核心参数表如下参数含义建议值timeoutInMilliseconds线程执行超时时间8000毫秒requestVolumeThreshold10秒内最小请求数10errorThresholdPercentage错误率熔断阈值50sleepWindowInMilliseconds熔断器打开后等待时间5000毫秒coreSize默认线程池核心线程数20maxQueueSize线程池任务队列容量200降级方法里不能只返回一个“失败”字符串。订单服务的降级需要区分网络异常和业务失败否则定时任务可能把正常订单误删。实际设计中可以返回Result对象其中错误码用503表示依赖不可用业务层可以针对该错误码做补偿。3.3 Seata AT模式管理分布式事务微服务拆分后一次下单会调用商品服务扣减库存再调用订单服务创建订单。如果订单创建失败库存已经被扣掉了必须通过Seata全局事务回滚。AT模式对业务代码侵入最小核心就是加一个GlobalTransactional注解。Service public class OrderFacadeService { GlobalTransactional(name create-order, timeoutMills 60000, rollbackFor Exception.class) public void createOrder(OrderCreateDTO dto) { productService.deductStock(dto.getProductId(), dto.getCount()); orderService.createOrder(dto); } }逻辑说明name create-order是全局事务ID在Seata控制台里用它来查找事务详情timeoutMills超过60秒会由协调器发起回滚rollbackFor指定哪些异常触发回滚这里使用Exception.class表示捕获一切异常。AT模式要求所有参与全局事务的业务库中都必须有undo_log表课程设计源码里的数据库文件应该已经包含该表和对应的SQL如果启动时提示找不到表优先检查Seata配置中数据库连接和业务数据库是否一致。参数说明productService.deductStock和orderService.createOrder都是通过Feign调用。Seata在发起方生成全局事务XID并通过Feign请求头透传给下游服务下游服务在事务分支注册后执行本地事务。如果下游服务提交后发生异常Seata会依据undo_log中记录的前后镜像生成反向SQL进行回滚。需要特别提醒Feign透传XID必须配置RequestInterceptor源码中这个类通常写好了但自己重写时容易漏掉导致全局事务失效只回滚当前服务。Component public class SeataRequestInterceptor implements RequestInterceptor { Override public void apply(RequestTemplate template) { String xid RootContext.getXID(); if (xid ! null) { template.header(RootContext.KEY_XID, xid); } } }这个拦截器的意义在于把Seata的XID放进Feign请求头下游服务拿到后才能加入同一个全局事务分支。漏配这个类即使加了GlobalTransactional也无法跨库回滚。4. 业务模块拆分的四种调用范式后台、商户、用户与定时任务4.1 登录拦截与RBAC权限校验的公共处理在项目说明的调用层中后台、商户、用户模块重点任务都是“登录拦截”。登录拦截要做两件事第一校验gatewayToken是否真实有效第二解析当前登录用户并做RBAC权限判断。实际项目中网关校验通过后会向请求头写入X-User-Id但下游不能盲目信任该字段因为该请求头可能被伪造。拦截器代码示例如下public class RbacInterceptor implements HandlerInterceptor { private final StringRedisTemplate redisTemplate; private final PermissionFeignClient permissionFeignClient; Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { String token request.getHeader(gatewayToken); String userId request.getHeader(X-User-Id); if (token null || userId null) { throw new BizException(非法访问); } Boolean valid redisTemplate.hasKey(gateway:token: token); if (Boolean.FALSE.equals(valid)) { throw new BizException(非法访问); } if (!permissionFeignClient.checkPermission(userId, request.getRequestURI())) { throw new BizException(无权限访问); } return true; } }这个拦截器里每个请求都会调用远程权限服务性能和稳定性都不理想。改进方式是引入本地缓存把用户ID与接口路径的权限关系缓存到Caffeine或Redis并设置10分钟过期时间。课程设计里可以用Cacheable简化实现但要注意权限变更后缓存的实时性。在后台模块里还承担RBAC权限管理功能需要维护用户表、角色表、菜单表和用户角色关联表。用户登录时后台主页服务查询角色并生成权限集合然后写入Redis后续拦截器从Redis读取该集合做路径匹配即可不必每次请求都查库。4.2 四大调用模块的功能矩阵四个调用模块不是简单的代码复制而是按业务边界拆分的聚合层。后台模块偏管理商户模块偏商品运营用户模块偏购物全流程定时任务负责系统兜底。调用模块核心功能依赖的下游服务后台模块登录注册、商户停用启用、费率修改、RBAC权限管理、群发消息、订单查看后台主页、商户主页、用户主页、订单服务商户模块商户海报和logo修改、用户信息查看、商品CRUD、上下架、订单查看商户主页、用户主页、商品服务、订单服务用户模块商城主页海报、商品图片、购物车、用户信息修改、商品评价、订单生成、微信支付图片服务、用户主页、订单服务、微信支付服务定时任务超时订单删除、商品库存恢复、微信支付回调后修改订单状态订单服务、商品服务、微信支付服务从表中能看到不同调用模块会重复依赖用户主页服务但各自关注的数据维度不同。后台关心启用停用商户关注logo和海报用户关心购物车和评论。为了避免调用层代码膨胀把公共的Feign接口抽成一个client-api模块四个调用层只在自己的业务应用中引用自己需要的部分。4.3 定时任务如何保证不重复执行定时任务部署到多实例环境时Scheduled会在每个实例上同时执行造成重复删单、库存多加。必须使用分布式锁保证只有一个实例在执行。Scheduled(cron 0 */5 * * * ?) public void closeTimeoutOrders() { String lockKey lock:close-order; Boolean locked redisTemplate.opsForValue().setIfAbsent(lockKey, 1, Duration.ofMinutes(2)); if (Boolean.TRUE.equals(locked)) { try { ListLong orderIds orderClient.listTimeoutOrders(); for (Long orderId : orderIds) { orderClient.closeOrder(orderId); productClient.restoreStock(orderId); } } finally { redisTemplate.delete(lockKey); } } }逻辑说明setIfAbsent(lockKey, 1, Duration.ofMinutes(2))是Redis的SET NX EX命令只有key不存在时才能写入成功从而保证只有一个实例拿到锁。2分钟过期时间防止持锁实例宕机后锁永久存在。拿到锁的实例先查询超时订单列表再逐个关闭订单并恢复库存。为了追求一致性推荐把“关闭订单”和“恢复库存”放到同一个Seata全局事务中避免恢复库存时通知服务失败导致库存少回。参数说明cron 0 */5 * * * ?表示每5分钟执行一次。如果订单允许15分钟内支付扫描条件可以设置为创建时间距今超过15分钟且状态为未支付、未关闭。任务开始时删除锁而不是任务执行完再删除这样可以防止任务执行时间超过锁过期时间时锁提前被别人拿走。更稳妥的方案是在finally块中先判断锁的值是否仍属于当前实例再删除避免误删别人的锁。4.4 微信支付回调的幂等处理微信支付成功后会以异步回调方式通知商户通知可能有多次延迟重试。用户模块中“订单的生成”“微信支付服务实现微信支付功能”都涉及回调处理。回调接口必须做到幂等处理方式是先按订单号查询状态状态为未支付时进行修改UPDATE t_order SET status PAID, pay_time NOW() WHERE order_no #{orderNo} AND status UNPAID参数说明status UNPAID这个条件保证一次回调只能把订单从未支付改成已支付。第二次回调时因为状态已变成PAID更新影响行数为0业务层据此返回“处理成功”给微信服务器避免重复发货或重复加积分。课程设计源码中还可以配合订单服务里的唯一索引来进一步保证幂等。5. Zipkin链路追踪与ELK日志收集的落地技巧5.1 Zipkin链路数据采样与请求拼接一个下单请求会经过网关、用户调用模块、订单模块、商品模块排查问题如果没有链路信息只能逐个服务翻日志。Zipkin配合Sleuth可以为每个请求生成全局唯一的TraceId并在服务间自动传递。spring: zipkin: base-url: http://127.0.0.1:9411 sender: type: web sleuth: sampler: probability: 1.0逻辑说明probability: 1.0表示全量采样适合课程设计演示能看到所有请求链路。生产环境建议设置0.1只采样10%避免链路数据量太大对存储造成压力。sender.type: web表示通过HTTP上报给Zipkin如果链路数据量大可以改成kafka上报减少对应用线程的阻塞。5.2 ELK日志收集的关键配置Zipkin能告诉我们请求经过了哪些服务但具体报错信息要看日志。ELK体系里应用日志通过Logstash发给Elasticsearch再用Kibana查询。要让日志与链路关联必须把TraceId写进日志pattern中。appender nameLOGSTASH classnet.logstash.logback.appender.LogstashTcpSocketAppender destination127.0.0.1:5000/destination encoder classnet.logstash.logback.encoder.LogstashEncoder customFields{service_name:user-call-service}/customFields /encoder /appender逻辑说明LogstashTcpSocketAppender通过TCP把日志发送到LogstashLogstashEncoder会把MDC中的traceId、spanId作为JSON字段序列化输出。service_name自定义字段用于区分是哪个服务产生的日志这样日志在Elasticsearch中可以通过service_name关键字过滤。如果项目不便引入额外依赖在logback-spring.xml里直接把%X{traceId}写入pattern也可以但Kibana解析会麻烦一些。无论在Zipkin还是日志中TraceId的格式都是一串16位十六进制随机数或64位数字匹配规则是同一个请求的所有服务日志包含相同的TraceId。5.3 Kibana验证链路是否真正打通在Kibana中先用service_name: user-call-service过滤找到一次具体请求的日志复制其traceId再使用该traceId搜索全部日志就能看到这次请求在网关、调用层、订单服务、商品服务里的全部记录。排查性能瓶颈的顺序是先在Zipkin查看这个请求的Span时间线找到耗时最大的服务进入Kibana用traceId搜索该服务的日志查看线程状态、SQL执行时间和异常信息。订单服务出现明显超时时还能在Zipkin里看到Feign客户端调用阶段的时间占比从而判断是网络问题还是下游数据库慢查询。这是一个实用技巧课程设计演示时不要一次性启动全部服务先启动Nacos、Redis、Seata Server、Zipkin和Elasticsearch再启动业务服务最后启动四个调用层模块和网关。启动过程中观察Nacos服务列表确认所有服务都注册成功后再进行下单测试这样能准确观察链路数据是否完整。若日志里出现大量zipkin.reporter断开连接错误排查Zipkin地址是否能从应用服务器访问其次检查spring.zipkin.base-url路径是否写错成/api/v2/spans这个是大多数链路追踪不生效的主要原因。本文还有配套的精品资源点击获取
