参考：http://www.ityouknow.com/springcloud

为什么需要API Gateway

摘录自：http://www.ityouknow.com/springcloud/2017/06/01/gateway-service-zuul.html

1、简化客户端调用复杂度

在微服务架构模式下后端服务的实例数一般是动态的，对于客户端而言很难发现动态改变的服务实例的访问地址信息。因此在基于微服务的项目中为了简化前端的调用逻辑，通常会引入API Gateway作为轻量级网关，同时API Gateway中也会实现相关的认证逻辑从而简化内部服务之间相互调用的复杂度。

2、数据裁剪以及聚合

通常而言不同的客户端对于显示时对于数据的需求是不一致的，比如手机端或者Web端又或者在低延迟的网络环境或者高延迟的网络环境。

因此为了优化客户端的使用体验，API Gateway可以对通用性的响应数据进行裁剪以适应不同客户端的使用需求。同时还可以将多个API调用逻辑进行聚合，从而减少客户端的请求数，优化客户端用户体验

3、多渠道支持

当然我们还可以针对不同的渠道和客户端提供不同的API Gateway,对于该模式的使用由另外一个大家熟知的方式叫Backend for front-end, 在Backend for front-end模式当中，我们可以针对不同的客户端分别创建其BFF，进一步了解BFF可以参考这篇文章：Pattern: Backends For Frontends

4、遗留系统的微服务化改造

对于系统而言进行微服务改造通常是由于原有的系统存在或多或少的问题，比如技术债务，代码质量，可维护性，可扩展性等等。API Gateway的模式同样适用于这一类遗留系统的改造，通过微服务化的改造逐步实现对原有系统中的问题的修复，从而提升对于原有业务响应力的提升。通过引入抽象层，逐步使用新的实现替换旧的实现

在Spring Cloud体系中， Spring Cloud Zuul就是提供负载均衡、反向代理、权限认证的一个API gateway。

简单使用

建立一个moduel，测试zuul的使用

添加依赖

首先，添加zuul的依赖包，spring-cloud-starter-zuul

    org.springframework.cloud
    spring-cloud-starter-zuul
    1.4.5.RELEASE

此外，还得需要hystrix和actuator的依赖

    org.springframework.cloud
    spring-cloud-starter-hystrix
    1.4.5.RELEASE


    org.springframework.cloud
    spring-cloud-starter-hystrix-dashboard
    1.4.5.RELEASE


    org.springframework.boot
    spring-boot-starter-actuator
    1.4.4.RELEASE

配置文件

添加如下配置，（也可以注册到注册中心去）

server:
  port: 6789
zuul:
  routes:
    abreaking:  #这个名可以任意指定
      path: /abreaking/**    #访问该路径
      url:  https://github.com/aBreaking    #就forward到该地址去

上述配置中，配置zuul的配置后，访问/abreaking/**路径时，包括该路径下的所有子路径，都会转发（forward）到指定的url去。注意转发（forward）与重定向（redirect）的区别哦，此处不再累述。

启动类注解

在启动类上添加注解：@EnableZuulProxy。表明能够启用zuul代理

@EnableZuulProxy
@SpringBootApplication
public class ZuulApplication {
public static void main(String[] args) {
    SpringApplication.run(ZuulApplication.class, args);
}

}

访问

此时，我们再浏览器中输入地址：http://localhost:6789/abreaking，效果如下：

访问子路径：http://localhost:6789/abreaking/spring-cloud-demo。同样跟在github上看到的一样一样的。

这就是一个最简单的使用方式把

路由

现在比如我们发布两个服务（同一个应用），对应者两个不同的地址。我们应该配置路径，去访问这个服务。

服务端

服务端正常的注册到注册中心即可。比如，我们配置这两个服务，应用名就为：demo-provider。两个Controller的方法分别如下：

第一个：

 @RequestMapping("say")
public String say(){
    return "hello, it`s provider01";
}

第二个：

@RequestMapping("say")
public String say(){
    return "hello, it`s provider02";
}

注册到注册中心后，能够通过浏览器正常访问这两个服务。

zuul端

依赖、注解同上，不需要修改，唯一修改的就是修改配置文件将zuul端注册到注册中心去。

server:
  port: 6789
      service-id: demo-provider    #应用名
eureka:
  client:
    service-url:
      defaultZone: http://localhost:9999/eureka/ #将服务注册到那个注册中心去

启动moduel后，

直接在通过：http://ip:port/应用名/RestController的RestMapping即可访问服务的方法。。这是zuul的默认配置。

访问地址：http://localhost:6789/demo-provider/say。效果如下：（此处的负载默认是轮询)

如果想自己指定url路径，类似于简单使用的配置，自己指定path，需要指定应用名

server:
  port: 6789
zuul:  
  routes:
    abreaking:  #这个名可以任意指定
      path: /abreaking/**
      service-id: demo-provider    #应用名
eureka:
  client:
    service-url:
      defaultZone: http://localhost:9999/eureka/ #将服务注册到那个注册中心去

此时，再访问:http://localhost:6789/abreaking/say，效果同上，一样一样的。