這一次給大家分享微服務網關的相關知識，這個也是微服務架構中，相當重要的組件之一，來，下面聽我徐徐道來

1，API網關概覽

1.1，現有的交互模式存在什么問題？

目前，是客戶端會直接跟多個微服務直接交互，這種模式存在什么問題？

1，客戶端會請求多個不同的服務，需要維護不同的請求地址，增加開發難度

2，在某些場景下存在跨域請求的問題，也會降低訪問的效率

3，加大身份認證的難度，每個微服務都需要獨立認證

因此，我們需要一個微服務網關，介于客戶端與服務器之間的中間層，所有的外部請求都會先經過微服務網關處理，之后再交給相關的業務服務進行處理。

客戶端只需要與網關交互，只知道一個網關地址即可，這樣簡化了開發還有以下優點：

1，方便客戶端調用

2，方便做統一身份認證

3，減少了客戶端與各個微服務之間的交互次數

1.2，什么是微服務網關？

API網關是一個服務器，是系統對外的唯一入口。

API網關封裝了系統內部架構，為每個客戶端提供一個定制的API。

API網關方式的核心要點是，所有的客戶端和消費端都通過統一的網關接入微服務，在網關層處理所有的非業務功能。

API網關提供REST/HTTP的訪問API

1.3，網關的實現方案有哪些？

Zuul Net?ix開源，功能豐富，使用JAVA開發，易于二次開發；需要運行在web容器中，如Tomcat。 問題：缺乏管控，無法動態配置；依賴組件較多；處理Http請求依賴的是Web容器，性能不如 Nginx； ? Spring Cloud Gateway SpringCloud提供的網關服務 ? Nginx 如果只是需要一個基礎的具備轉發功能的網關，那么使用Ngnix是一個不錯的選擇。 ? 比如：路由，過濾處理（nginx+lua） location /api-index { proxy_pass http://127.0.0.1:8081/; } location /api-product { proxy_pass http://127.0.0.1:8082/; }

2，Zuul

2.1，什么是Zuul

zuul是Net?ix開源的微服務網關，它可以和Eureka、Ribbon、Hystrix等組件配合使用，Zuul組件的核心是一系列的過濾器，這些過濾器可以完成以下功能：

動態路由：動態將請求路由到不同后端集群

負載分配：為每一種負載類型分配對應容量，并棄用超出限定值的請求

身份認證和安全: 識別每一個資源的驗證要求，并拒絕那些不符的請求。

Spring Cloud對Zuul進行 了整合和增強，讓我們可以輕松上手。

2.2，Zuul網關的構成

1，客戶端發送一個請求，經過網關，將這個請求轉到合適的服務， 這個過程，叫做路由（路由規則，起到映射的作用）

2，核心是一系列過濾器 前置（pre），后置（post），路由（Route），錯誤（Error）

2.3，搭建Zuul網關服務工程

1，創建網關工程

api-zuul-server

2，引入依賴

<dependency>

3，啟動類添加注解

@EnableZuulProxy

2.4，網關核心功能-路由

1，配置

server:port: 8888 eureka:client:service-url:defaultZone: http://localhost:9090/eureka/ spring:application:name: api-zuul-server

2，檢驗效果

【1】，默認提供的路由規則，可以幫助我們路由到后臺的服務，如下：

訪問規則：網關地址:端口/微服務服務名稱/微服務請求地址

訪問案例：http://localhost:8888/product-service/product/list

默認zuul就已經提供了好了路由規則，無需任何配置，就可以實現路由

路由，本質就是映射

【2】，自定義路由規則

#自定義路由規則，默認的規則依然生效 zuul:routes:api-index:path: /index/**serviceId: index-serviceapi-product:path: /product/**serviceId: product-service

注意：原先的路由規則依然有效

新配置的路由規則也生效

【3】，需求 ：不想讓默認的服務對外暴露接口

zuul:routes:api-index:path: /index/**serviceId: index-serviceapi-product:path: /product/**serviceId: product-service#統一入口為上面的配置，其他入口忽略ignored-patterns: /*-service/**#處理http請求頭為空的問題sensitive-headers:#默認zuul會屏蔽cookie，cookie不會傳到下游服務，這里設置為空則取消默認的黑名單，表示會傳遞到下游服務，比如product-service

2.5，網關核心功能-過濾

1，ZuulFilter簡介

Zuul中的過濾器跟我們之前使用的 javax.servlet.Filter 不一樣，javax.servlet.Filter是通過配置 urlPatterns 來攔截對應的請求。而 Zuul 中的過濾器是分為不同的類型，每種類型都有對應的使用場景。

1，PRE：這種過濾器在請求被路由之前調用。我們可利用這種過濾器實現身份驗證、記錄訪問日志等等。

2，ROUTING：這種過濾器將請求路由到微服務。這種過濾器用于構建發送給微服務的請求，并使用 Apache HttpClient或Net?lx Ribbon請求微服務。 注意，此處的過濾器類型應該寫為route

3， POST：這種過濾器在路由到微服務以后執行，可以對響應的信息做處理。

4，ERROR：在其他階段發生錯誤時執行該過濾器

過濾器的應用場景：

請求鑒權：一般放在pre類型，如果發現沒有訪問權限，直接就攔截了 異常處理：一般會在error類型和post類型過濾器中結合來處理。 服務調用時長統計：pre和post結合使用。

2，ZuulFilter接口說明

/*** @author huangguizhao*/ public class MyZuulFilter extends ZuulFilter{@Overridepublic String filterType() {return null;} ?@Overridepublic int filterOrder() {return 0;} ?@Overridepublic boolean shouldFilter() {return false;} ?@Overridepublic Object run() throws ZuulException {//具體的過濾處理邏輯return null;} }

方法說明：

filterType返回一個字符串代表過濾器的類型，在zuul中定義了四種不同生命周期的過濾器類型pre：路由之前routing：路由之時post： 路由之后error：發生錯誤調用 filterOrder通過返回的int值來定義過濾器的執行順序，數字越小優先級越高。 shouldFilter返回一個 Boolean 值，判斷該過濾器是否需要執行。返回true執行，返回false 不執行。 run過濾器的具體邏輯，比如判斷當前用戶是否有合法權限，沒有，則不放行我們假設以請求中的token為例http://localhost:8888/product/product/list?token=666

3，自定義ZuulFilter

@Component public class MyZuulFilter extends ZuulFilter{@Overridepublic String filterType() {return "pre";}@Overridepublic int filterOrder() {return 0;}@Overridepublic boolean shouldFilter() {return true;}@Overridepublic Object run() throws ZuulException {//請求上下文RequestContext ctx = RequestContext.getCurrentContext();HttpServletRequest request = ctx.getRequest();System.out.println("--->攔截請求：" + request.getRequestURI());String token = request.getParameter("token");if(token == null){//此處讓請求不再往下分發ctx.setSendZuulResponse(false);try {//給客戶端響應信息ctx.getResponse().getWriter().print("Token is null!");} catch (IOException e) {e.printStackTrace();}}return null;} }

4，RequestContext說明

RequestContext：用于在過濾器之間傳遞消息，它的數據保存在每個請求的ThreadLocal中；它用于存儲請求路由到哪里、錯誤、HttpServletRequest、HttpServletResponse都存儲在 RequestContext中。

所有的zuulFilter都可以共享到此塊數據。

2.6，搭建高可用的zuul集群架構

配置多個實例，保證下面的配置是一致的即可

spring:application:name: api-zuul-server

SpringCloud讓我們非常方便對組件進行水平擴展！

2.7，zuul網關存在的問題

【問題一】

Zuul1x版本本質上就是一個同步Servlet，采用多線程阻塞模型進行請求轉發。簡單講，每來 一個請求，Servlet容器要為該請求分配一個線程專門負責處理這個請求，直到響應返回客戶端，這個線程才會被釋放返回容器線程池。如果后臺服務調用比較耗時，那么這個線程就會被阻塞，阻塞期間線程資源被占用，不能干其它事情。我們知道Servlet容器線程池的大小是有 限制的，當前端請求量大，而后臺慢服務比較多時，很容易耗盡容器線程池內的線程，造成容器無法接受新的請求。

【問題二】

且不支持websocket這種長連接的方式。

【解決方案】

2018 年 5 月，Zuul 2.x（基于 Netty，也是非阻塞的，支持長連接）發布，但 Spring Cloud 暫時還沒有整合計劃。所以，我們可以看到，整合的zuul版本還是1X版本。

下期，我們分享SpringCloudGateway，另一款微服務網關的實現，如果對您有幫助，就點個贊吧

總結

以上是生活随笔為你收集整理的天翼网关 ddns设置_19，微服务网关之Zuul的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。