參考：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可以參考這篇文章：

4、遺留系統的微服務化改造

對於系統而言進行微服務改造通常是由於原有的系統存在或多或少的問題，比如技術債務，程式碼質量，可維護性，可擴充套件性等等。API Gateway的模式同樣適用於這一類遺留系統的改造，通過微服務化的改造逐步實現對原有系統中的問題的修復，從而提升對於原有業務響應力的提升。通過引入抽象層，逐步使用新的實現替換舊的實現。

在Spring Cloud體系中， Spring Cloud Zuul就是提供負載均衡、反向代理、許可權認證的一個API gateway。

簡單使用

建立一個moduel，測試zuul的使用

新增依賴

首先，新增zuul的依賴包，spring-cloud-starter-zuul

        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-zuul</artifactId>
            <version>1.4.5.RELEASE</version>
        </dependency>

此外，還得需要hystrix和actuator的依賴

        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-hystrix</artifactId>
            <version>1.4.5.RELEASE</version>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-hystrix-dashboard</artifactId>
            <version>1.4.5.RELEASE</version>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-actuator</artifactId>
            <version>1.4.4.RELEASE</version>
        </dependency>

配置檔案

新增如下配置，（也可以註冊到註冊中心去）

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，效果同上，一樣一樣的。