上周简单的学习了一下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服务列表页查看注入成功的服务，如下图所示：
根据上图可以看出我们的
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接口，多次调用就会发现响应结果不太一样，如下图：
其实多次调用就会发现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。具体信息，见下图：
根据上图可以看出，其包含了
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的具体信息如下图所示：
最终
LoadBalancerClientFilter的filter方法执行前后ServerWebExchange的属性信息对比如下图所示：
通过对比可以发现请求的
gatewayRequestUrl已经变成具体的服务地址，另外属性中多了一个gatewayOrinalRequestUrl。这和我们在本小节开始讲解是一致的。
四、总结
今天关于Gateway的学习主要是整合了Nacos，并且通过一个服务的2个实例测试了Gateway的路由配置，以及学习了Gateway负载均衡的部分源码。因为在学习源码过程中我启动了几次服务，可能有时候服务的端口号没有对应上，比如前面服务的端口号可能是9010，后面就成了9020，这点希望小伙伴谅解下。最后这一块还有一点我没有提及到，那就是获取服务列表信息，我们使用Nacos作为服务的注册中心，肯定是从Nacos获取服务列表，但是我并没有去看到底是如何从Nacos获取的，比如本地是不是有服务缓存等等，这部分以后有机会再来学习。
