摘要：但是如果將負(fù)載均衡器置于所有服務(wù)前便不是一個(gè)好主意，會(huì)造成瓶頸。服務(wù)超時(shí)使用的和庫來進(jìn)行請(qǐng)求。支持以下四種過濾器前置過濾器在將請(qǐng)求發(fā)送到目的地之前被調(diào)用。通常用于記錄從目標(biāo)服務(wù)返回的響應(yīng)處理錯(cuò)誤或?qū)徍嗣舾行畔ⅰ?/p>

springcloud 總集：https://www.tapme.top/blog/detail/2019-02-28-11-33

本篇中 Zuul 版本為 1.x，目前最新的是 2.x，二者在過濾器的使用上有較大區(qū)別

超長警告

項(xiàng)目代碼見文章結(jié)尾

??微服務(wù)架構(gòu)將一個(gè)應(yīng)用拆分為很多個(gè)微小應(yīng)用，這樣會(huì)導(dǎo)致之前不是問題的問題出現(xiàn)，比如：

安全問題如何實(shí)現(xiàn)？

日志記錄如何實(shí)現(xiàn)？

用戶跟蹤如何實(shí)現(xiàn)？

上面的問題在傳統(tǒng)的單機(jī)應(yīng)用很容易解決，只需要當(dāng)作一個(gè)功能實(shí)現(xiàn)即可。但是在微服務(wù)中就行不通了，讓每個(gè)服務(wù)都實(shí)現(xiàn)一份上述功能，那是相當(dāng)不現(xiàn)實(shí)的，費(fèi)時(shí)，費(fèi)力還容易出問題。

??為了解決這個(gè)問題，需要將這些橫切關(guān)注點(diǎn)（分布式系統(tǒng)級(jí)別的橫切關(guān)注點(diǎn)和 spring 中的基本一個(gè)意思）抽象成一個(gè)獨(dú)立的且作為應(yīng)用程序中所有微服務(wù)調(diào)用的過濾器和路由器的服務(wù)。這樣的服務(wù)被稱為——服務(wù)網(wǎng)管(service gateway)，服務(wù)客戶端不再直接調(diào)用服務(wù)。取而代之的是，服務(wù)網(wǎng)關(guān)作為單個(gè)策略執(zhí)行點(diǎn)（Policy Enforcement Point,PEP) , 所有調(diào)用都通過服務(wù)網(wǎng)管進(jìn)行路由，然后送到目的地。

??之前的幾節(jié)中我們是通過 http 請(qǐng)求直接調(diào)用各個(gè)服務(wù)，通常在實(shí)際系統(tǒng)中不會(huì)直接調(diào)用。而是通過服務(wù)網(wǎng)關(guān)來進(jìn)行服務(wù)調(diào)用。服務(wù)網(wǎng)關(guān)充當(dāng)了服務(wù)客戶端和被調(diào)用服務(wù)間的中介。服務(wù)客戶端僅與服務(wù)網(wǎng)關(guān)管理的單個(gè) url 進(jìn)行對(duì)話。下圖說了服務(wù)網(wǎng)關(guān)在一個(gè)系統(tǒng)中的作用：

服務(wù)網(wǎng)關(guān)位于服務(wù)客戶端和相應(yīng)的服務(wù)實(shí)例之間。所有的服務(wù)調(diào)用（內(nèi)部和外部）都應(yīng)流經(jīng)服務(wù)網(wǎng)關(guān)。

??由于服務(wù)網(wǎng)關(guān)代理了所有的服務(wù)調(diào)用，因此它還能充當(dāng)服務(wù)調(diào)用的中央策略執(zhí)行點(diǎn)（PEP），通俗的說就能能夠在此實(shí)現(xiàn)橫切關(guān)注點(diǎn)，不用在各個(gè)微服務(wù)中實(shí)現(xiàn)。主要有以下幾個(gè)：

靜態(tài)路由——服務(wù)網(wǎng)關(guān)將所有的服務(wù)調(diào)用放置在單個(gè) URL 和 API 路由后，每個(gè)服務(wù)對(duì)應(yīng)一個(gè)固定的服務(wù)端點(diǎn)，方便開發(fā)人員的服務(wù)調(diào)用。

動(dòng)態(tài)路由——服務(wù)網(wǎng)關(guān)可以檢測(cè)傳入的請(qǐng)求，根據(jù)請(qǐng)求數(shù)據(jù)和請(qǐng)求者執(zhí)行職能路由。比如將一部分的調(diào)用路由到特定的服務(wù)實(shí)例上，比如測(cè)試版本。

驗(yàn)證和授權(quán)——所有服務(wù)調(diào)用都經(jīng)過服務(wù)網(wǎng)關(guān)，顯然可以在此進(jìn)行權(quán)限驗(yàn)證，確保系統(tǒng)安全。

日志記錄——當(dāng)服務(wù)調(diào)用經(jīng)過服務(wù)網(wǎng)關(guān)時(shí)，可以使用服務(wù)網(wǎng)關(guān)來收集數(shù)據(jù)和日志信息（比如服務(wù)調(diào)用次數(shù)，服務(wù)響應(yīng)時(shí)間等）。還能確保在用戶請(qǐng)求上提供關(guān)鍵信息以確保日志統(tǒng)計(jì)（比如給每個(gè)用戶請(qǐng)求加一個(gè) url 參數(shù)，每個(gè)服務(wù)中可通過該參數(shù)將關(guān)鍵信息對(duì)應(yīng)到某個(gè)用戶請(qǐng)求）。

看到這兒可能會(huì)有這樣的疑問：所有調(diào)用都通過服務(wù)網(wǎng)關(guān)，難道服務(wù)網(wǎng)關(guān)不是單點(diǎn)故障和潛在瓶頸嗎？

1. 在多帶帶的服務(wù)器前，負(fù)載均衡器是很有用的。將負(fù)載均衡器放到多個(gè)服務(wù)網(wǎng)關(guān)前面是比較好的設(shè)計(jì)，確保服務(wù)網(wǎng)關(guān)可以實(shí)現(xiàn)伸縮。但是如果將負(fù)載均衡器置于所有服務(wù)前便不是一個(gè)好主意，會(huì)造成瓶頸。

2. 服務(wù)網(wǎng)關(guān)的代碼應(yīng)該是無狀態(tài)的。有狀態(tài)的應(yīng)用實(shí)現(xiàn)伸縮性較為麻煩

3. 服務(wù)網(wǎng)關(guān)的代碼應(yīng)該輕量的。服務(wù)網(wǎng)關(guān)是服務(wù)調(diào)用的“阻塞點(diǎn)”,不易在服務(wù)網(wǎng)關(guān)處耽誤較長的時(shí)間,比如進(jìn)行同步數(shù)據(jù)庫操作

??使用 Netflix Zuul 來構(gòu)建服務(wù)網(wǎng)關(guān)，配合之前的代碼，讓服務(wù)網(wǎng)關(guān)來管理服務(wù)調(diào)用。

在生產(chǎn)環(huán)境中不建議使用 zuul，該組件性能較弱，且已經(jīng)停止更新

??詳細(xì)過程不贅述，和之前一樣（注意 spring cloud 版本要和之前一致），主要 pom 依賴如下：

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


    org.springframework.cloud
    spring-cloud-starter-eureka

??首先在啟動(dòng)加入注解開啟 zuul 并注冊(cè)到 eureka 中

??然后編寫配置文件：

spring:
  application:
    name: zuulservice
#服務(wù)發(fā)現(xiàn)配置
eureka:
  instance:
    prefer-ip-address: true
  client:
    register-with-eureka: true
    fetch-registry: true
    service-url:
      defaultZone: http://localhost:8761/eureka/
server:
  port: 5555

這樣便以默認(rèn)配置啟動(dòng)了 zuul 服務(wù)網(wǎng)關(guān)。

??Zuul 核心就是一個(gè)反向代理。在微服務(wù)架構(gòu)下，Zuul 從客戶端接受微服務(wù)調(diào)用并將其轉(zhuǎn)發(fā)給下游服務(wù)。要和下游服務(wù)進(jìn)行溝通，Zuul 必須知道如何將進(jìn)來的調(diào)用映射到下游路由中。Zuul 有一以下幾種路由機(jī)制：

通過服務(wù)發(fā)現(xiàn)自動(dòng)映射路由

通過服務(wù)發(fā)現(xiàn)手動(dòng)映射路由

使用靜態(tài) URL 手動(dòng)映射

默認(rèn)情況下，Zuul 根據(jù)服務(wù) ID 來進(jìn)行自動(dòng)路由。先將組織服務(wù)中的延時(shí)去掉

啟動(dòng)之前的所有服務(wù)實(shí)例，然后通過 postman 訪問localhost:5555/organizationservice/organization/12,得到結(jié)果如下：

說明服務(wù)網(wǎng)關(guān)自動(dòng)路由成功。

??如果要查看 Zuul 服務(wù)器管理的路由，可以通過訪問 Zuul 服務(wù)器上的/routes，返回結(jié)果如下：

{
  "/confsvr/**": "confsvr",
  "/licensingservice/**": "licensingservice",
  "/organizationservice/**": "organizationservice"
}

左邊的路由由基于 Eureka 的服務(wù) ID 自動(dòng)創(chuàng)建的，右邊為路由所有映射的 Eureka 服務(wù) ID。

??如果覺得自動(dòng)路由不好用，我們還可以更細(xì)粒度地明確定義路由映射。例如想要縮短組織服務(wù)名稱來簡(jiǎn)化路由，可在application.yml配置中定義路由映射,在配置文件中加入如下配置：

zuul:
  routes:
    organizationservice: /org/**

??上面的配置將org開頭的路徑映射到組織服務(wù)上了。重啟服務(wù)器，訪問localhost:5555/org/organization/12,仍然能夠獲取到數(shù)據(jù)。

??現(xiàn)在訪問/routes端點(diǎn)可以看到如下結(jié)果：

{
  "/org/**": "organizationservice",
  "/confsvr/**": "confsvr",
  "/licensingservice/**": "licensingservice",
  "/organizationservice/**": "organizationservice"
}

可以看到不光有自定義的組織路由，自動(dòng)映射的組織路由也存在，如果想要排除自動(dòng)映射的路由可配置ignored-services屬性，用法如下：

zuul:
  routes:
    organizationservice: /org/**
  # 使用","分隔，“*”表示全部忽略
  ignored-services: "organizationservice"

??服務(wù)網(wǎng)關(guān)有一種常見模式是通過使用/api之類的標(biāo)記來為所有服務(wù)調(diào)用添加前綴，可通過配置prefix屬性來支持。用法如下：

zuul:
  routes:
    organizationservice: /org/**
  # 使用","分隔，“*”表示全部忽略
  ignored-services: "organizationservice"
  prefix: /api

配置后再次訪問/routes端點(diǎn)可以看到路徑前都加上了/api

??如果系統(tǒng)系統(tǒng)中還存在一些不受 Eureka 管理的服務(wù)，可以建立 Zuul 直接路由到一個(gè)靜態(tài)定義的 URL。假設(shè)許可證服務(wù)是其他語言編寫的 web 項(xiàng)目，并且希望通過 Zuul 來代理，可這樣配置：

zuul:
  routes:
    #用于內(nèi)部識(shí)別關(guān)鍵字
    licensestatic:
      path: /licensestatic/**
      url: http://localhost:8091

配置完成后重啟 zuul 訪問/routes端點(diǎn)如下所示,靜態(tài)路由已經(jīng)加入：

{
  "/api/licensestatic/**": "http://localhost:8091",
  "/api/org/**": "organizationservice",
  "/api/confsvr/**": "confsvr",
  "/api/licensingservice/**": "licensingservice",
  "/api/zuulservice/**": "zuulservice"
}

??licensestatic 端點(diǎn)不再使用 Eureka，直接將請(qǐng)求路由到localhost:8091。但是這里存在一個(gè)問題，如果許可證服務(wù)有多個(gè)實(shí)例，該如何用到負(fù)載均衡？這里只能配置一條路徑指向請(qǐng)求。這里又有一個(gè)配置項(xiàng)來禁用 Ribbon 與 Eureka 集成，然后列出許可證服務(wù)的所有實(shí)例，配置如下：

#zuul配置
zuul:
  routes:
    #用于內(nèi)部識(shí)別關(guān)鍵字
    licensestatic:
      path: /licensestatic/**
      serviceId: licensestatic
    organizationservice: /org/**
  # 使用","分隔，“*”表示全部忽略
  ignored-services: "organizationservice"
  prefix: /api

ribbon:
  eureka:
    #禁用Eureka支持
    enabled: false

licensestatic:
  ribbon:
    #licensestatic服務(wù)將會(huì)路由到下列地址
    listOfServers: http://localhost:10011,http://localhost:10012

配置完畢后，訪問/routes端點(diǎn)發(fā)現(xiàn)licensestatic/**映射到了 licensestatic 服務(wù)上，相當(dāng)于 Zuul 模擬了一個(gè)服務(wù)出來。但是 Eureka 上是沒有這個(gè)服務(wù)的，所以需要禁用掉 Ribbon 的 Eureka 支持，不然是無法訪問成功的（Ribbon 向 Eureka 查詢?cè)摲?wù)不存在，報(bào)錯(cuò))?，F(xiàn)在 x=連續(xù)訪問localhost:5555//api/licensestatic/licensing/12,可以發(fā)現(xiàn)正常響應(yīng)和 404 交替出現(xiàn)（10011 上能否訪問成功，10012 報(bào)錯(cuò) 404），說明配置的多個(gè)地址生效了。

問題又來了

??_禁用 eureka 支持會(huì)導(dǎo)致所有服務(wù)的地址都需要手動(dòng)指定，ribbon 不會(huì)再從 eureka 中獲取服務(wù)實(shí)例信息。所以沒辦法混合使用_

??目前有兩種辦法來規(guī)避這個(gè)問題：

對(duì)于不能用 Eureka 管理的應(yīng)用，可以建立一個(gè)多帶帶的 Zuul 服務(wù)器來處理這些路由。

建立一個(gè) Spring Cloud Sidecar 實(shí)例。Spring Cloud Sidecar 允許開發(fā)使用 Eureka 實(shí)例注冊(cè)非 JVM 服務(wù)，然后再通過 Zuul 代理，相當(dāng)于曲線救國。

??zuul 還有一個(gè)動(dòng)態(tài)加載路由的功能，也就是在不重啟 zuul 服務(wù)的情況下刷新路由。

??直接修改application.yml將 prefix 從/api改為/apis。注意這里修改后要讓修改生效需編譯一次 application.yml 讓修改替換到 target 文件中（idea 如此，eclipse 應(yīng)該類似),或者直接到編譯文件夾下修改 application.yml

??然后訪問/refresh路徑，可以看到如下返回值：

響應(yīng)表明更新 prefix。然后訪問/routes路徑會(huì)發(fā)現(xiàn)前綴變成了apis

??這個(gè)功能與 spring cloud config 配合，用起來就是爽。

??Zuul 使用 Netflix 的 Hystrix 和 Ribbon 庫來進(jìn)行 http 請(qǐng)求。so 也是有超時(shí)機(jī)制存在的。配置方法和前面的一篇類似。但是只能通過配置文件來進(jìn)行，無法通過注解（這是 Zuul 管理的沒有地方給你寫注解）。通過配置hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds屬性來實(shí)現(xiàn)。如果要為特定的服務(wù)配置只需將 default 替換為服務(wù)名就行了。

注意還要只有有另一個(gè)超時(shí)機(jī)制。雖然覆蓋了 hystrix 的超時(shí)，但是 Ribbon 也會(huì)超時(shí)任何超過 5s 的調(diào)用。so 如果超時(shí)時(shí)間大于 5s 還要配置 Ribbon 的超時(shí),配置方式如下：

#對(duì)所有服務(wù)生效
ribbon.readTimeout: 7000
#對(duì)組織服務(wù)生效
licensingservice.ribbon.readTimeout: 7000

??這才是服務(wù)網(wǎng)關(guān)真正重要的東西。有了過濾器才能實(shí)現(xiàn)自定義的通用處理邏輯?？稍诖诉M(jìn)行通用的安全驗(yàn)證、日志、服務(wù)跟蹤等操作。和 springboot 中的過濾器概念類似，這里就不做說明了。

??Zuul 支持以下四種過濾器：

前置過濾器——在將請(qǐng)求發(fā)送到目的地之前被調(diào)用。通常進(jìn)行請(qǐng)求格式檢查、身份驗(yàn)證等操作。

后置過濾器——在目標(biāo)服務(wù)被調(diào)用被將響應(yīng)發(fā)回調(diào)用者后被調(diào)用。通常用于記錄從目標(biāo)服務(wù)返回的響應(yīng)、處理錯(cuò)誤或?qū)徍嗣舾行畔ⅰ?/p>

路由過濾器——在目標(biāo)服務(wù)被調(diào)用之前攔截調(diào)用。通常用來做動(dòng)態(tài)路由。

錯(cuò)誤過濾器——在產(chǎn)生錯(cuò)誤是調(diào)用，用于對(duì)錯(cuò)誤進(jìn)行統(tǒng)一處理。

下圖展示了在處理客戶端請(qǐng)求時(shí)，各種過濾器時(shí)如何工作的：

下面說說如何來使用這些過濾器：

??這里我們來實(shí)現(xiàn)一個(gè)過濾器-IdFilter，對(duì)每個(gè)請(qǐng)求檢查請(qǐng)求頭中是否有一個(gè)關(guān)聯(lián) id，無 id 生成一個(gè) id 加入到 header 中。代碼如下：

@Component
public class IdFilter extends ZuulFilter {

    private static final Logger LOGGER = LoggerFactory.getLogger(IdFilter.class);

    /**
     * 返回過濾器類型 ；pre:前置過濾器。post：后置過濾器。routing:路由過濾器。error：錯(cuò)誤過濾器
     */
    @Override
    public String filterType() {
        return "pre";
    }

    /**
     * 過濾器執(zhí)行順序
     */
    @Override
    public int filterOrder() {
        return 1;
    }

    /**
     * 是否啟動(dòng)此過濾器
     */
    @Override
    public boolean shouldFilter() {
        return true;
    }

    @Override
    public Object run() {
        RequestContext ctx = RequestContext.getCurrentContext();
        String id = ctx.getRequest().getHeader("id");
        //如果request找不到，再到zuul的方法中找id.request不允許直接修改response中的header，
        // 所以為了讓后續(xù)的過濾器能夠獲取到id才有下面的語法
        if(id==null){
            id = ctx.getZuulRequestHeaders().get("id");
        }
        if (id == null) {
            id = UUID.randomUUID().toString();
            LOGGER.info("{} 無id，生成id:{}",ctx.getRequest().getRequestURI(), id);
            ctx.addZuulRequestHeader("id", id);
        } else {
            LOGGER.info("{}存在id：{}", ctx.getRequest().getRequestURI(), id);
        }
        return null;
    }
}

要在 Zuul 中實(shí)現(xiàn)過濾器，必須拓展 ZuulFilter 類（2.x 版本中不是這樣的），然后覆蓋上述 4 個(gè)方法。

??要給請(qǐng)求頭加入一個(gè) header 需要在ctx.addZuulRequestHreader("","")(上面代碼中的 RequestContext 是 zuul 重寫的，在其中加入了一些方法)方法中操作，zuul 會(huì)在發(fā)出請(qǐng)求是把 header 加到請(qǐng)求頭中。（因?yàn)?Zuul 本質(zhì)是一個(gè)代理，它截取請(qǐng)求，然后自己再發(fā)送這個(gè)請(qǐng)求，所有不能也沒有必要在原來的 request 上加 header。

??重啟項(xiàng)目 Zuul，訪問localhost:5555/apis/licensestatic/licensing/12，可以看到控制臺(tái)有如下打?。?/p>

說明前置過濾器生效。

??現(xiàn)在從 zuul 服務(wù)網(wǎng)關(guān)發(fā)往許可證服務(wù)的 http 請(qǐng)求已經(jīng)攜帶了 id。

??后置過濾器通常用于進(jìn)行敏感信息過濾和響應(yīng)記錄。這里我們實(shí)現(xiàn)一個(gè)后置過濾器，將許可證服務(wù)請(qǐng)求的響應(yīng)內(nèi)容打印到控制臺(tái)上同時(shí)把idheader 插入到服務(wù)客戶端請(qǐng)求的 response 中。

@Component
public class ResponseFilter extends ZuulFilter {

    private static final Logger LOGGER = LoggerFactory.getLogger(ResponseFilter.class);

    /**
     * 返回過濾器類型 ；pre:前置過濾器。post：后置過濾器。routing:路由過濾器。error：錯(cuò)誤過濾器
     */
    @Override
    public String filterType() {
        return "post";
    }

    /**
     * 過濾器執(zhí)行順序
     */
    @Override
    public int filterOrder() {
        return 1;
    }

    /**
     * 是否啟動(dòng)此過濾器
     */
    @Override
    public boolean shouldFilter() {
        return true;
    }

    @Override
    public Object run(){
        RequestContext ctx = RequestContext.getCurrentContext();
        String id = ctx.getZuulRequestHeaders().get("id");
        ctx.getResponse().addHeader("id", id);
        try {
            BufferedReader reader = new BufferedReader(new InputStreamReader(ctx.getResponseDataStream()));
            String response = reader.readLine();
            LOGGER.info("響應(yīng)為：{}", response);
            //寫到輸出流中,本來可以由zuul框架來操作，但是我們已經(jīng)讀取了輸入流，zuul讀不到數(shù)據(jù)了，所以要手動(dòng)寫響應(yīng)到response
            ctx.getResponse().setHeader("Content-Type","application/json;charset=utf-8");
            ctx.getResponse().getWriter().write(response);
        } catch (Exception e) {
        }
        return null;
    }
}

經(jīng)過這樣一波操作，就能達(dá)到目的了。訪問：localhost:5555/apis/licensestatic/licensing/12?？刂婆_(tái)打印如下：

請(qǐng)求響應(yīng)如下：

??路由過濾器用起來有點(diǎn)復(fù)雜，這里不寫具體的實(shí)際代碼，只是寫一個(gè)思路。具體代碼可以參考spring 微服務(wù)

獲取當(dāng)前請(qǐng)求路徑

判斷是否需要進(jìn)行特殊路由

如需要進(jìn)行特殊路由，在此進(jìn)行 http 調(diào)用

將 http 調(diào)用的 response 寫入到當(dāng)前請(qǐng)求的 response 中

??終于寫完了，微服務(wù)的基礎(chǔ)學(xué)習(xí)又近了一步，加油！

本篇代碼存放于:github

本篇原創(chuàng)發(fā)布于：https://tapme.top/blog/detail/2019-01-03-19-19

掃碼關(guān)注微信公眾號(hào)：FleyX 學(xué)習(xí)筆記,獲取更多干貨