原创文章 如有侵权联系删除

本来不是一个大问题，由于陷入逻辑悖论，想到了以下的问题，重新分析并调试，重新得出理解

时间仓促 整篇文章格式未调，

问题1：直接访问浏览器->访问网关服务18084->访问到provider会不会经过consumer?

如果走consumer 整个访问路径是怎样的？如果经过consumer需要解决问题1 问题2
如果不走consumer 就不会有熔断策略因为只有服务consumer写了熔断策略。必须通过consumer处理，有异常超时才会响应熔断机制。明明通过浏览器client访问网关访问 怎么经过了consumer 这个是怎么理解的。 浏览器是客户端 consumer是客户端，但是他们两个是不同的两个客户端。 之前我们是浏览器访问-consumer才访问到provider ，但是现在是直接浏览器-》网关-》provider

问题2如果走consumer，那么路径是不是1.浏览器->consumer1808->访问网关18084->provider ，能解决熔断问题，但是访问浏览器指定的是网关18084访问的

如果不是

问题3如果走consumer，那么路径是不是1.浏览器->访问网关18084->consumer1801->provider ，能解决熔断问题，能想通浏览器直接访问网关 ，但是如何是网关的负载均衡落到provider而不是consumer

答案整理在最后总结

先看一下工程目录结构
看一下网关路由配置

看一下消费者描述，他的端口是18082

消费者负载均衡策略-轮询

消费者提供三个控制器匹配用户请求，由user- consumer这个服务调用user-provider

此时形成的访问路径为

通过网关访问，并不经过user-consumer处理

user-consumer下的三个controller对应的控制器都下断点看是否会经过user-consumer处理

在两个提供者user-provider和user-provider-demo01实例对应的控制器断下，最终通过网关的负载均衡一定会选择到一台provider

轮询方式的负载均衡并不会确保每次一定都会按顺序落在对应的服务上。

通过网关18084访问http://localhost:18084/user/find/1 程序并不会断在user-consumer里面的三个controller里面的任何一个控制器，但是可以断在user-provider 中(这是一定)

通过网关18084访问http://localhost:18084/default/consumer/1

也会报如下错

网关路由配置

其中uri: lb://user-provider
路由并且负载均衡的是user-provider服务的集群

结论：所以整个从浏览器发起请求直接访问网关的调用都不会经过user-consumer服务

# 注释版本
server:
  port: 18084
spring:
  application:
    # 应用名
    name: api-gateway
  cloud:
    gateway:
      routes:
        # 用户所有以/user开始的请求，都给http://localhost:18081服务处理
        #id唯一标识，可自定义 , 随便写，可以写小红，小花都行
        - id: user-service-route
          #路由的服务地址
          uri: lb://user-provider
          # 路由拦截的地址配置（断言）
          # /user/**所有以/user开始的请求都将被路由到uri指定的服务地址，
          # 将该请求交给uri指定的服务处理，比如请求：http://localhost:18084/user/find/2会把请求交给http://localhost:18081/user/find/2处理
          predicates:
            - Path=/user/**
# Eureka服务中心配置
eureka:
  client:
    service-url:
      # 注册Eureka Server集群
      defaultZone: http://127.0.0.1:7001/eureka

总结

其实就是consumer和provider概念混淆了，作为用户通过浏览器访问就是consumer消费者而不是项目中的user-consumer
这个项目调用过程是浏览器-user-consuemr到user-provider
加了网关之后就由网关直接路由到了user-provider
关键核心是uri: lb://user-provider user-provider在这里是一个集群
加了网关后项目调用过程是直接通过浏览器-网关-user-provider

消费者 提供者 客户端 服务端概念都是相对而言的
由于这个的demo简单
provider仅仅是被调用没有依赖任何一个服务的调用，所以没有对应的兜底策略 (熔断策略)