一提閘道器的時候，可能大家第一個想到的就是我們網路中的閘道器，其實在微服務體系中閘道器的作用是什麼的明顯的，閘道器負責統一接收所有請求，然後根據不同的規則進行轉發到不同的服務。使用閘道器能夠統一的管理請求日誌、進行許可權控制、過濾等，這樣就能避免在每個單體應用中做重複的工作。如果在沒有閘道器之前的時候，可以看到架構是這樣的的：

雖然有點小簡單（ps有些功能沒有畫進去）。這樣的話就會發現我們去每一個服務沒有一個統一的入口，比如消費者去訪問服務1的時候，他要直接去訪問服務1，訪問2的時候直接去2，這樣看是沒有問題，可是當我們需要進行許可權控制的時候怎麼辦呢？這樣我們就必須在每個服務區做相同的許可權控制，這樣是不是有問題啊，如果我們需要在進入具體的服務之前進行一些操作，這時候怎麼辦？還有一個很大的問題就是，現在我們的微服務架構都是結合容器的，而容器可能暴露出的介面是一個，因為容器內部是可以互相訪問的，那麼我們又應該怎麼辦？帶著這些問題去思考的同時，我們sping也為我們提供了這些解決方案，那麼就是進今天主要講的閘道器。

而spring cloud的閘道器是叫zuul，有了閘道器之後我們的結構就變成這樣了。

所有的請求先到閘道器，然後閘道器進行相應的路由分發，在介紹這個閘道器的同時，我們就主要就基於他現在比較重要的兩方面來講：反向代理和負載均衡
在我們傳統的模式下，可能使用上面兩種方式是基於nginx的，但是很巧，我們的zuul閘道器也有這個功能，他的負載均衡是基於之前講過的ribbiton的，而他的反向代理是基於我們的註冊中心，之前也提過。下面就開始進入正題吧。

反向代理：這個原理就不用我說吧，我們就直接說在zuul中是如何實現的把
首先我們還是先將zuul的基本給搭建出來：
引入這幾個依賴

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-zuul</artifactId>
</dependency>
<dependency>  
        <groupId>org.springframework.cloud</groupId>  
        <artifactId>spring-cloud-starter-consul-discovery</artifactId
 
>  
    </dependency>
    <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-actuator</artifactId>
        </dependency> 

上面的依賴一個是啟用zuul閘道器的依賴，一個是將我們網關注冊到consul上面，這樣的目的是便於查詢註冊上面的其他的服務，便於負載均衡，最後一個依賴是監控服務，是暴露一些資訊，讓我們的服務能註冊到consul上面去。
這個完成後只要在我們的主函式裡面新增如下註解就可以了

@SpringBootApplication
@EnableDiscoveryClient
@EnableZuulProxy

這樣就表示我們啟動了閘道器。
這時候我們需要去properties裡面去配置一些檔案。如果要做到反向代理的時候，我們需要在啟動一個服務 ，這個服務的目的就是讓我們通過走閘道器的ip和埠能訪問他其他服務。
首先我們要配置一些基本的資訊，比如註冊到consul的配置，這些就不說了，我們直接說如何配置反向代理的，其實在zuul中是通過路由將我們訪問路徑進行匹配然後路由到其他的服務中。
如下配置所示，我們可以將配置放到我們的閘道器的配置中

zuul.routes.serviceA.path=/serviceA/**
zuul.routes.serviceA.url=http://localhost:8080/

這兩個配置的含義就是如果我們本地啟動閘道器的埠號是80，而我們服務A的埠是8080的時候，我們訪問localhost/serviceA/hello的時候，我們閘道器發現serviceA能匹配到我們配置中的配置，就會轉到localhost:8080/hello中去，這樣就達到反向代理的過程。記住path和url一定要成雙出現。還有一種方式就是通過註冊中心的名字來進行路由

zuul.routes.serviceA.path=/user-service/**
zuul.routes.serviceA.serviceId=serviceA

這樣也能達到反向代理的過程，因為我們註冊到consul上面的服務名有對應的ip和埠，所以通過服務名就能找到對應的ip+埠。
我們通過配置並啟動閘道器和另一個服務，然後訪問能看到如下效果

這樣就完成了反向代理的過程。

而負載均衡：在閘道器中其實已經幫我們整進去了rabbion負載均衡的依賴，他的負載均衡是依賴於外部的註冊中心，因為我們可以將不同的伺服器相同的服務名註冊到同一個consul上面，然後通過閘道器路由的訪問在進入到相應的服務，而rabbtion的講解我們之前也已經講過了，這邊就不說了，他開始也是使用預設的輪詢方式來弄的，當然我們也可以修改這種方式。至於過程可以參考一下之前的那篇部落格。
閘道器的更細一步可以去網上查閱一下資料，因為我這邊說的可能不夠詳細。之後我在好好整理，為大家講解一下閘道器的攔截器以及異常怎麼處理的