SpringCloud(7)---閘道器概念、Zuul專案搭建

專案程式碼GitHub地址：https://github.com/yudiandemingzi/spring-cloud-study

一、閘道器概念

1、什麼是路由閘道器

閘道器是系統的唯一對外的入口，介於客戶端和伺服器端之間的中間層，處理非業務功能 提供路由請求、鑑權、監控、快取、限流等功能。它將"1對N"問題轉換成了"1對1”問題。

通過服務路由的功能，可以在對外提供服務時，只暴露 閘道器中配置的呼叫地址，而呼叫方就不需要了解後端具體的微服務主機。

2、為什麼要使用微服務閘道器

不同的微服務一般會有不同的網路地址，而客戶端可能需要呼叫多個服務接口才能完成一個業務需求，若讓客戶端直接與各個微服務通訊，會有以下問題：

（1）客戶端會多次請求不同微服務，增加了客戶端複雜性

（2）存在跨域請求，處理相對複雜

（3）認證複雜，每個服務都需要獨立認證

（4）難以重構，多個服務可能將會合併成一個或拆分成多個

3、閘道器的優點

微服務閘道器介於服務端與客戶端的中間層，所有外部服務請求都會先經過微服務閘道器客戶只能跟微服務閘道器進行互動，無需呼叫特定微服務介面，使得開發得到簡化

總的理解閘道器優點

服務閘道器 =路由轉發 + 過濾器

（1）路由轉發：接收一切外界請求，轉發到後端的微服務上去。

（2）過濾器：在服務閘道器中可以完成一系列的橫切功能，例如許可權校驗、限流以及監控等，這些都可以通過過濾器完成（其實路由轉發也是通過過濾器實現的）。

4、服務閘道器技術選型

引入服務閘道器後的微服務架構如上，總體包含三部分：服務閘道器、open-service和service。

（1）總體流程

服務閘道器、open-service和service啟動時註冊到註冊中心上去；

使用者請求時直接請求閘道器，閘道器做智慧路由轉發（包括服務發現，負載均衡）到open-service，這其中包含許可權校驗、監控、限流等操作

open-service聚合內部service響應，返回給閘道器，閘道器再返回給使用者

（2）引入閘道器的注意點

增加了閘道器，多了一層轉發（原本使用者請求直接訪問open-service即可），效能會下降一些（但是下降不大，通常，閘道器機器效能會很好，而且閘道器與open-service的訪問通常

是內網訪問，速度很快）；

（3）服務閘道器基本功能

智慧路由：接收外部一切請求，並轉發到後端的對外服務open-service上去；

注意：我們只轉發外部請求，服務之間的請求不走閘道器，這就表示全鏈路追蹤、內部服務API監控、內部服務之間呼叫的容錯、智慧路由不能在閘道器完成；

當然，也可以將所有的服務呼叫都走閘道器，那麼幾乎所有的功能都可以整合到閘道器中，但是這樣的話，閘道器的壓力會很大，不堪重負。

許可權校驗：可在微服務閘道器上進行認證，然後在將請求轉發給微服務，無須每個微服務都進行認證，不校驗服務內部的請求。服務內部的請求有必要校驗嗎？

API監控：只監控經過閘道器的請求，以及閘道器本身的一些效能指標（例如，gc等）；

限流：與監控配合，進行限流操作；

API日誌統一收集：類似於一個aspect切面，記錄介面的進入和出去時的相關日誌。

二、Zuul專案搭建

使用到的元件包括：Eureka、Feign、Zuul，包括以下四個專案：

（1）Eureka-server： 7001 註冊中心

（2）product-server ：8001 商品微服務

（3）order-server ： 9001 訂單微服務

（4）zuul-gateway ： 6001 Zuul閘道器

註冊中心、商品微服務、order在之前部落格都已搭建，這裡就不重複寫。這裡只寫zuul-gateway微服務。

1、pom.xml

        <!--客戶端jar包，這個在訂單微服務，商品微服務都要新增-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
        </dependency>

        <!--zuuljar包-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-zuul</artifactId>
        </dependency>

2、application.yml

server:
  port: 6001

#服務的名稱
spring:
  application:
    name: zuul-gateway

#指定註冊中心地址
eureka:
  client:
    serviceUrl:
      defaultZone: http://localhost:7001/eureka/

#自定義路由對映
zuul:
  routes:
    order-service: /apigateway/order/**
    product-service: /apigateway/product/**
  #統一入口為上面的配置，其他入口忽略
  ignored-patterns: /*-service/**
  #忽略整個服務，對外提供介面
  ignored-services: order-service

3、SpringBoot啟動類

@SpringBootApplication
//加上網關注解
@EnableZuulProxy
public class ZuulServerApplication {
    public static void main(String[] args) {
        SpringApplication.run(ZuulServerApplication.class, args);
    }
}

4、測試

（1）直接訂單服務調商品服務

(2)通過Zuul閘道器實現訂單介面調商品服務

5、注意些細節

（1）url不能重複，否則會覆蓋

    order-service:    /apigateway/order/**
    product-service:  /apigateway/product/**

（2）通過zuul後，request中的cookie值獲取不到，那是因為閘道器給過濾掉了。

    @RequestMapping("list")
    public void list(@RequestParam("user_id")int userId, @RequestParam("product_id") int productId, HttpServletRequest request){
        String token = request.getHeader("token");
        String cookie = request.getHeader("cookie");
       //會發現token值能夠獲取，cookie無法獲取，原因是因為閘道器會過濾掉敏感詞
        System.out.println("token="+token);
        System.out.println("cookie="+cookie);
    }

想要不過濾掉cookie值那麼在配置裡配置

zuul:
  #處理http請求頭為空的問題
  sensitive-headers:

6、問題

自己遇到兩個問題記錄下，後期再來思考解決。

1、現在通過訂單服務地址可以直接訪問訂單微服務，如何配置成訂單微服務不能直接服務，只能通過閘道器訪問。

思考，是不是以後訂單微服務配置到內網就不會有這個問題了。

2、當我的訂單服務調商品服務異常時，直接訪問訂單微服務熔斷降級能夠完成，通過閘道器竟然直接報異常了。

我在商品微服務相關介面新增：

//睡眠兩秒，微服務預設一秒就超時，所以會到降級方法
TimeUnit.SECONDS.sleep(2);

直接調訂單服務，降級資訊返回正常。如果通過閘道器訪問。

返回的是異常，這不是很蛋疼嗎，總是有解決辦法讓降級資訊返回來的，以後解決來再來寫。

參考

Spring Cloud：服務閘道器 Zuul

我只是偶爾安靜下來，對過去的種種思忖一番。那些曾經的舊時光裡即便有過天真愚鈍，也不值得譴責。畢竟，往後的日子，還很長。不斷鼓勵自己，

天一亮，又是嶄新的起點，又是未知的征程（上校9）

以上內容為雨點的名字原創