Spring Cloud之网关-Gateway（二）

上周简单的学习了一下Gateway的基本概念和使用，因为上周时间仓促并没有来的及通过整体的项目来学习Gateway的使用，今天趁机通过一个简单的例子来了解Gateway是如何工作的。在这之前我提前创建好了一个简单的项目user-service，另外微服务注册中心和配置中心使用的是Nacos，如果对Nacos不是很了解的小伙伴可以通过我之前的文章Alibaba-Nacos入门学习一下，这里就不再多说了。

一、使用Nacos

在上次的gateway-service项目以及新建的user-service项目的pom文件中分别添加Nacos的相关依赖，如下：

        <!-- nacos start -->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
            <version>0.2.2.RELEASE</version>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
            <version>0.2.2.RELEASE</version>
        </dependency>
        <!-- nacos end -->

另外在各项目启动类上分别添加@EnableDiscoveryClient注解，当然如果你想使用其他的注册中心也是可以的，比如Eureka。
接着修改各服务的bootstrap.xml文件，添加Nacos的相关配置项，如下：

spring:
  cloud:
    nacos:
      config:
        server-addr: 127.0.0.1:8848
        file-extension: yaml
      discovery:
        server-addr: 127.0.0.1:8848

二、负载均衡

将创建好的user-service项目复制一份，在本地做一个伪服务集群，并修改其中一个端口号。我本地设置的端口号分别为9010、9020。另外为了区分这两个服务实例，简单的写一个接口，分别返回不同的内容以做区分，代码如下：

### 端口号9010的服务实例
@Slf4j
@RestController
@RequestMapping("/user")
public class UserController {

    @GetMapping("/hello")
    public String hello(HttpServletRequest httpServletRequest,@RequestParam("role") String role) {
        log.info(">>>> remote address={}, request param={}<<<<",httpServletRequest.getRemoteAddr(),role);
        return "hello from user-service-1,server port=9010";
    }

}

### 端口号9020的服务实例
@Slf4j
@RestController
@RequestMapping("/user")
public class UserController {

    @GetMapping("/hello")
    public String hello(HttpServletRequest httpServletRequest, @RequestParam("role") String role) {
        log.info(">>>> remote address={}, request param={}<<<<",httpServletRequest.getRemoteAddr(),role);
        return "hello from user-service-2,server port=9020";
    }

}

接着以单机模式启动本地的Nacos，然后分别启动gateway-service和user-service（两个实例），然后登录到Nacos服务列表页查看注入成功的服务，如下图所示：

图-1.png
根据上图可以看出我们的gateway-service和user-service都成功注册，且user-service的实例数是2个。
在gateway-service项目中添加相关路由配置项，因为目前我们只有一个user-service服务，只需要配置其路由即可，application.xml配置如下：

spring:
  cloud:
    gateway:
      routes:
        - id: user-service
          uri: http://localhost:9010
          predicates:
            - Path=/user/**
            - Query=role,admin

我们先通过user-service的ip和端口号进行测试，单个访问是没有问题的，但是如果将http://localhost:9010改成http://user-service就会报错。

2019-12-21 16:32:35.358 ERROR 15212 --- [or-http-epoll-3] a.w.r.e.AbstractErrorWebExceptionHandler : [13622f57]  500 Server Error for HTTP GET "/user/hello?role=admin"

java.net.UnknownHostException: user-service: 未知的名称或服务
    at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method) ~[na:1.8.0_171]
    Suppressed: reactor.core.publisher.FluxOnAssembly$OnAssemblyException: 
Error has been observed at the following site(s):
    |_ checkpoint ⇢ org.springframework.cloud.gateway.filter.WeightCalculatorWebFilter [DefaultWebFilterChain]
    |_ checkpoint ⇢ HTTP GET "/user/hello?role=admin" [ExceptionHandlingWebHandler]

所以如果想通过服务名称进行路由就只能将uri项改为lb://user-service，改好之后，重启gateway-service，然后再在通过网关服务调用user-service接口，多次调用就会发现响应结果不太一样，如下图：

图-2.png 图-3.png
其实多次调用就会发现9010和9020是交替出现的，也就是或在进行负载均衡的时候，Gateway默认的负载均衡算法采用的是轮询。

三、负载均衡实现

现在我们知道了Gateway在进行路由的时候选择的是轮询算法，那么其是如何实现的呢？？接下来我们就通过源码来一探究竟。
上周在学习Gateway的基本使用和概念的时候，讲到其内部有很多过滤器，其中有一个就是LoadBalancerClientFilter，根据名称就知道这是一个负载均衡的过滤器。LoadBalancerClientFilter会从其入参ServerWebExchange变量中根据属性名称gatewayRequestUrl中查找URI， 如果该URL是lb相关的，比如lb:// user-service，它将使用LoadBalancerClient将服务名称解析为具体的主机和端口，并在ServerWebExchange的同一属性中替换成新的URI。未经修改的原始URL会添加到gatewayOriginalRequestUrl属性中的列表中。
现在基本的流程我们清楚了，接下来我们就一步步的跟着源码进行分析，首先是LoadBalancerClientFilter的filter方法，代码如下：

    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        URI url = (URI)exchange.getAttribute(ServerWebExchangeUtils.GATEWAY_REQUEST_URL_ATTR);
        String schemePrefix = (String)exchange.getAttribute(ServerWebExchangeUtils.GATEWAY_SCHEME_PREFIX_ATTR);
          ## 判断是否是lb或者前缀是lb
        if (url != null && ("lb".equals(url.getScheme()) || "lb".equals(schemePrefix))) {
          ## 将原url添加到exchange的ServerWebExchangeUtils.GATEWAY_ORIGINAL_REQUEST_URL_ATTR属性
            ServerWebExchangeUtils.addOriginalRequestUrl(exchange, url);
            if (log.isTraceEnabled()) {
                log.trace("LoadBalancerClientFilter url before: " + url);
            }
            ## 获取具体的服务实例，这时候会就会知道集体服务的ip地址和端口号，核心方法
            ServiceInstance instance = this.choose(exchange);
            if (instance == null) {
                throw NotFoundException.create(this.properties.isUse404(), "Unable to find instance for " + url.getHost());
            } else {
                ## 获取请求URI，判断是http还是https请求
                URI uri = exchange.getRequest().getURI();
                String overrideScheme = instance.isSecure() ? "https" : "http";
                if (schemePrefix != null) {
                    overrideScheme = url.getScheme();
                }
                ## 重构url，这时候是具体服务的请求地址，比如127.0.0.1:9010/user/hello?role=admin
                URI requestUrl = this.loadBalancer.reconstructURI(new DelegatingServiceInstance(instance, overrideScheme), uri);
                if (log.isTraceEnabled()) {
                    log.trace("LoadBalancerClientFilter url chosen: " + requestUrl);
                }
                ## 讲具体的请求url方法添加到exchange的属性ServerWebExchangeUtils.GATEWAY_REQUEST_URL_ATTR中
                exchange.getAttributes().put(ServerWebExchangeUtils.GATEWAY_REQUEST_URL_ATTR, requestUrl);
                ## 将exchange传递到下游的过滤器
                return chain.filter(exchange);
            }
        } else {
            return chain.filter(exchange);
        }
    }

上面的代码中简单的分析了各部分代码的作用，基本上还是比较容易理解。上面代码中的核心其实是这段：

##获取具体请求的服务实例，也就是路由到哪个服务
ServiceInstance instance = this.choose(exchange);
##具体方法，其实调用的是LoadBalancerClient的choose
protected ServiceInstance choose(ServerWebExchange exchange) {
        return this.loadBalancer.choose(((URI)exchange.getAttribute(ServerWebExchangeUtils.GATEWAY_REQUEST_URL_ATTR)).getHost());
}

根据上面这部分代码我们知道实际上是由具体的LoadBalancerClient执行相关方法，其实现是RibbonLoadBalancerClient实例，我们继续看下相关代码：

public ServiceInstance choose(String serviceId) {
        return this.choose(serviceId, (Object)null);
 }

public ServiceInstance choose(String serviceId, Object hint) {
        ## 获取具体的服务信息
    Server server = getServer(getLoadBalancer(serviceId), hint);
    if (server == null) {
        return null;
    }
        ## 对上一步获取的服务信息包装成RibbonServer
    return new RibbonServer(serviceId, server, isSecure(server, serviceId), serverIntrospector(serviceId).getMetadata(server));
}

1、获取服务列表信息

我们着重分析下下面这行代码：

Server server = this.getServer(this.getLoadBalancer(serviceId), hint);

首先我们先从this.getLoadBalancer(serviceId)入手，，这个方法会根据变量serviceId（即服务名称）获取具体的ILoadBalancer实例，最终其调用的是SpringClientFactory的getInstance方法，代码如下：

public <C> C getInstance(String name, Class<C> type) {
        C instance = super.getInstance(name, type);
        if (instance != null) {
            return instance;
        } else {
            IClientConfig config = (IClientConfig)this.getInstance(name, IClientConfig.class);
            return instantiateWithConfig(this.getContext(name), type, config);
        }
}

###super.getInstance(name, type)
public <T> T getInstance(String name, Class<T> type) {
        AnnotationConfigApplicationContext context = this.getContext(name);
        return BeanFactoryUtils.beanNamesForTypeIncludingAncestors(context, type).length > 0 ? context.getBean(type) : null;
}

上述的代码会根据服务名称和其返回的类型获取到具体信息，因为这部分涉及的代码比较多，我没有深入往下研究，instance实例的具体类型是ZoneAwareLoadBalancer。具体信息，见下图：

图-4.png
根据上图可以看出，其包含了user-service服务的相关信息，比如服务名称、所有服务列表、启动的服务列表等。

2、负载均衡实现

我们继续分看我们分析的这行代码：

Server server = this.getServer(this.getLoadBalancer(serviceId), hint);
protected Server getServer(ILoadBalancer loadBalancer, Object hint) {
    if (loadBalancer == null) {
        return null;
    }
    ## 选择的是default
    return loadBalancer.chooseServer(hint != null ? hint : "default");
}

this.getServer(this.getLoadBalancer(serviceId), hint)方法是从服务列表中获取具体某一个服务实例，可以说真正的负载均衡是通过loadBalancer的chooseServer方法实现的，而loadBalancer是一个ZoneAwareLoadBalancer实例，这时候会执行chooseServer方法，但是最终执行的是其父类BaseLoadBalancer的chooseServer方法，我们大概看下相关的代码：

public Server chooseServer(Object key) {
        if (counter == null) {
            counter = createCounter();
        }
        counter.increment();
        if (rule == null) {
            return null;
        } else {
            try {
                ## 负载均衡算法选择具体的服务器
                return rule.choose(key);
            } catch (Exception e) {
                logger.warn("LoadBalancer [{}]:  Error choosing server for key {}", name, key, e);
                return null;
            }
        }
}

上面代码中执行的是this.rule.choose(key);即ZoneAvoidanceRule的choose方法，因为其继承了PredicateBasedRule，因此执行的是其父类的方法，代码如下：

public Server choose(Object key) {
        ILoadBalancer lb = this.getLoadBalancer();
        Optional<Server> server = this.getPredicate().chooseRoundRobinAfterFiltering(lb.getAllServers(), key);
        return server.isPresent() ? (Server)server.get() : null;
}

### AbstractServerPredicate的chooseRoundRobinAfterFiltering方法，选择具体的服务器
public Optional<Server> chooseRoundRobinAfterFiltering(List<Server> servers, Object loadBalancerKey) {
        List<Server> eligible = getEligibleServers(servers, loadBalancerKey);
        if (eligible.size() == 0) {
            return Optional.absent();
        }
        return Optional.of(eligible.get(incrementAndGetModulo(eligible.size())));
}
### 轮询算法
private int incrementAndGetModulo(int modulo) {
        for (;;) {
            int current = nextIndex.get();
            int next = (current + 1) % modulo;
            if (nextIndex.compareAndSet(current, next) && current < modulo)
                return current;
        }
}

上面代码中先获取到所有的服务列表，然后通过incrementAndGetModulo计算出具体的服务索引，上面代码中nextIndex变量是AtomicInteger，这样通过与服务数量进行模运算，以及通过compareAndSet即CAS，返回了当前的索引值，然后根据索引就获取到了具体的服务，这时候可以说关于负载均衡的部分已经完成了。

---

获取到具体某个服务器信息后再进行一系列的包装，最终返回到LoadBalancerClientFilter的choose方法：

 ServiceInstance instance = this.choose(exchange);

这时候ServiceInstance的具体信息如下图所示：

图-5.png
最终LoadBalancerClientFilter的filter方法执行前后ServerWebExchange的属性信息对比如下图所示：
filter执行前.png
filter执行后.png
通过对比可以发现请求的gatewayRequestUrl已经变成具体的服务地址，另外属性中多了一个gatewayOrinalRequestUrl。这和我们在本小节开始讲解是一致的。

---

四、总结

今天关于Gateway的学习主要是整合了Nacos，并且通过一个服务的2个实例测试了Gateway的路由配置，以及学习了Gateway负载均衡的部分源码。因为在学习源码过程中我启动了几次服务，可能有时候服务的端口号没有对应上，比如前面服务的端口号可能是9010，后面就成了9020，这点希望小伙伴谅解下。最后这一块还有一点我没有提及到，那就是获取服务列表信息，我们使用Nacos作为服务的注册中心，肯定是从Nacos获取服务列表，但是我并没有去看到底是如何从Nacos获取的，比如本地是不是有服务缓存等等，这部分以后有机会再来学习。