閘道器

　　通過服務閘道器統一向外系統提供REST API的過程中，除了具備服務路由、均衡負載功能之外，它還具備了許可權控制等功能。Spring Cloud Netflix中的Zuul就擔任了這樣的一個角色，為微服務架構提供了前門保護的作用，同時將許可權控制這些較重的非業務邏輯內容遷移到服務路由層面，使得服務叢集主體能夠具備更高的可複用性和可測試性。

　　下面我們通過例項例子來使用一下Zuul來作為服務的路有功能。

準備

　　在使用Zuul之前，我們先構建一個服務註冊中心、以及兩個簡單的服務，比如：我構建了一個service-A，一個service-B。然後啟動eureka-server和這兩個服務。通過訪問eureka-server，我們可以看到service-A和service-B已經註冊到了服務中心。

建立閘道器專案

　　首先建立一個簡單的spring-boot專案zuul-getway

　　pom檔案如下：

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>1.3.5.RELEASE</version>
    <relativePath/> <!-- lookup parent from repository -->
</parent>

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-test</artifactId>
    <scope>test</scope>
    </dependency>

    <dependency>
        <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-eureka-server</artifactId>
    </dependency>
    <!-- 閘道器依賴 -->
    <dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-zuul</artifactId>
</dependency>
</dependencies>

<dependencyManagement>
    <dependencies>
        <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-dependencies</artifactId>
        <version>Brixton.RELEASE</version>
        <type>pom</type>
        <scope>import
 
</scope>
    </dependency>
    </dependencies>
</dependencyManagement>

　　應用主類使用@EnableZuulProxy註解開啟Zuul

@EnableZuulProxy
@SpringCloudApplication
public class Application {

    public static void main(String[] args) {
        new SpringApplicationBuilder(Application.class
 
).web(true).run(args);
    }
    @Bean
    public AccessFilter accessFilter() {
        return new AccessFilter();
    }

}

　　這裡用了@SpringCloudApplication註解，之前沒有提過，通過原始碼我們看到，它整合了@SpringBootApplication、@EnableDiscoveryClient、@EnableCircuitBreaker，主要目的還是簡化配置。

application.properties 配置檔案

spring.application.name=api-gateway
server.port=5555

服務路由

　　通過服務路由的功能，我們在對外提供服務的時候，只需要通過暴露Zuul中配置的呼叫地址就可以讓呼叫方統一的來訪問我們的服務，而不需要了解具體提供服務的主機資訊了。

　　在Zuul中提供了兩種對映方式：

• 通過url直接對映，我們可以如下配置：

zuul.routes.api-a-url.path=/api-a-url/**
zuul.routes.api-a-url.url=http://localhost:2222/

　　該配置，定義了，所有到Zuul的中規則為：/api-a-url/**的訪問都對映到http://localhost:2222/上，也就是說當我們訪問http://localhost:4444/api-a-url/add?a=1&b=2的時候，Zuul會將該請求路由到：http://localhost:2222/add?a=1&b=2上。

　　其中，配置屬性zuul.routes.api-a-url.path中的api-a-url部分為路由的名字，可以任意定義，但是一組對映關係的path和url要相同，下面講serviceId時候也是如此。

　　通過url對映的方式對於Zuul來說，並不是特別友好，Zuul需要知道我們所有為服務的地址，才能完成所有的對映配置。而實際上，我們在實現微服務架構時，服務名與服務例項地址的關係在eureka server中已經存在了，所以只需要將Zuul註冊到eureka server上去發現其他服務，我們就可以實現對serviceId的對映。例如，我們可以如下配置：完整application.properties 配置檔案

spring.application.name=api-gateway
#啟動埠
server.port=4444
#服務中心地址
eureka.client.serviceUrl.defaultZone=http://localhost:1111/eureka/
zuul.routes.api-a.path=/api-a/**
zuul.routes.api-a.serviceId=service-A

zuul.routes.api-b.path=/api-b/**
zuul.routes.api-b.serviceId=service-B

　　針對我們在準備工作中實現的兩個微服務service-A和service-B，定義了兩個路由api-a和api-b來分別對映。另外為了讓Zuul能發現service-A和service-B，也加入了eureka的配置。

　　接下來，我們將eureka-server、service-A、service-B以及這裡用Zuul實現的服務閘道器啟動起來，在eureka-server的控制頁面中，我們可以看到分別註冊了service-A、service-B以及api-gateway

　　嘗試通過服務閘道器來訪問service-A和service-B，根據配置的對映關係，分別訪問下面的url

• http://localhost:4444/api-a/add?a=1&b=2：通過serviceId對映訪問service-A中的add服務
• http://localhost:4444/api-b/add?a=1&b=2：通過serviceId對映訪問service-B中的add服務
• http://localhost:4444/api-a-url/add?a=1&b=2：通過url對映訪問service-A中的add服務(本示例並沒有使用url對映，可以在配置檔案裡面去掉serviceId對映配置，新增上url對映)

 　　推薦使用serviceId的對映方式，除了對Zuul維護上更加友好之外，serviceId對映方式還支援了斷路器，對於服務故障的情況下，可以有效的防止故障蔓延到服務閘道器上而影響整個系統的對外服務

服務過濾

　　在完成了服務路由之後，我們對外開放服務還需要一些安全措施來保護客戶端只能訪問它應該訪問到的資源。所以我們需要利用Zuul的過濾器來實現我們對外服務的安全控制。

　　在服務閘道器中定義過濾器只需要繼承ZuulFilter抽象類實現其定義的四個抽象函式就可對請求進行攔截與過濾。

　　比如下面的例子，定義了一個Zuul過濾器，實現了在請求被路由之前檢查請求中是否有accessToken引數，若有就進行路由，若沒有就拒絕訪問，返回401 Unauthorized錯誤。

package com;

import javax.servlet.http.HttpServletRequest;

import com.netflix.zuul.ZuulFilter;
import com.netflix.zuul.context.RequestContext;

public class AccessFilter extends ZuulFilter{

    public Object run() {//過濾器的具體邏輯
        // TODO Auto-generated method stub
        RequestContext ctx = RequestContext.getCurrentContext();
        HttpServletRequest request = ctx.getRequest();
        Object accessToken = request.getParameter("accessToken");
        if(accessToken == null) {
            ctx.setSendZuulResponse(false);//不進行路由
            ctx.setResponseStatusCode(401);
            return null;
        }
        return null;
    }

    public boolean shouldFilter() {//返回一個boolean型別來判斷該過濾器是否要執行，所以通過此函式可實現過濾器的開關
        // TODO Auto-generated method stub
        return true;//true 總的是執行
    }

    @Override
    public int filterOrder() {//過濾的執行順序
        // TODO Auto-generated method stub
        return 0;
    }

    /* (non-Javadoc)
     * @see com.netflix.zuul.ZuulFilter#filterType()
     * 
    pre：可以在請求被路由之前呼叫
    routing：在路由請求時候被呼叫
    post：在routing和error過濾器之後被呼叫
    error：處理請求時發生錯誤時被呼叫

     */
    @Override
    public String filterType() {//過濾器的執行時間
        // TODO Auto-generated method stub
        return "pre";
    }

}

　　自定義過濾器的實現，需要繼承ZuulFilter，需要重寫實現下面四個方法：

• filterType：返回一個字串代表過濾器的型別，在zuul中定義了四種不同生命週期的過濾器型別，具體如下：
  • pre：可以在請求被路由之前呼叫
  • routing：在路由請求時候被呼叫
  • post：在routing和error過濾器之後被呼叫
  • error：處理請求時發生錯誤時被呼叫
• filterOrder：通過int值來定義過濾器的執行順序
• shouldFilter：返回一個boolean型別來判斷該過濾器是否要執行，所以通過此函式可實現過濾器的開關。在上例中，我們直接返回true，所以該過濾器總是生效。
• run：過濾器的具體邏輯。需要注意，這裡我們通過ctx.setSendZuulResponse(false)令zuul過濾該請求，不對其進行路由，然後通過ctx.setResponseStatusCode(401)設定了其返回的錯誤碼，當然我們也可以進一步優化我們的返回，比如，通過ctx.setResponseBody(body)對返回body內容進行編輯等。

　　http://localhost:4444/api-a/add?a=1&b=2      沒有進行路由

　　http://localhost:4444/api-a/add?a=1&b=2&accessToken     進行路由