網關的概念 服務A、B都是暴露出來，供外部直接調用的， 有時候需要對請求進行過濾、校驗，比如檢驗用戶是否已登陸，可以寫在暴露出來的每個服務中，但要在多個服務中寫相同的代碼，太繁瑣，可以提出來，放在網關中。 如果A、B進行集群，需要負載均衡來確定使用A|B的哪個節點來處理，可以使用網關來進行路由轉發（ ...
網關的概念
服務A、B都是暴露出來，供外部直接調用的，
- 有時候需要對請求進行過濾、校驗，比如檢驗用戶是否已登陸，可以寫在暴露出來的每個服務中，但要在多個服務中寫相同的代碼，太繁瑣，可以提出來，放在網關中。
- 如果A、B進行集群，需要負載均衡來確定使用A|B的哪個節點來處理，可以使用網關來進行路由轉發（負載均衡）。
網關相當於服務前面的一道關卡，即服務入口，可以統一進行請求的過濾、校驗，可以實現路由。
Ribbon實現服務內部的負載均衡（C、D），網關實現暴露出來的服務的負載均衡（A、B）。
外部不直接訪問服務A、B，而是訪問網關，通過網關來訪問A、B。
如果A、B不集群，網關每次都轉發到A|B固定的節點（因為這個服務只有這一個節點），一成不變、是靜態的，叫做靜態路由。
如果A、B集群，這次可能轉發到A|B的某個節點，下次可能轉發到A|B的另一個節點，轉發的節點不是固定的，是會變化的、動態的，叫做動態路由。
如果網關進行了集群，還需Nginx進行負載均衡，來確定使用哪個網關節點。
Zuul是實現網關的一種技術、一個框架，也是Netflix家的，被SpringCloud集成了。
使用Zuul進行路由轉發
（1）新建子模塊api-gateway
（2）pom.xml
<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-zuul</artifactId> </dependency>
網關要作為Eureka客戶端，因為要從Eureka伺服器獲取服務節點列表，使用Eureka客戶端內置的Ribbon進行負載均衡。
所以Eureka客戶端的配置都要有。
（3）引導類
@SpringBootApplication @EnableEurekaClient @EnableZuulProxy //也可以使用@EnableZuulServer public class GatewayApplication { public static void main(String[] args) { SpringApplication.run(GatewayApplication.class, args); } }
預設使用的是Ribbon的輪詢，如果要使用其它策略，修改方式和Ribbon的完全相同。
（4）application.properties
### gateway config###
#使用的埠
server.port=11001
#提供的服務，服務名稱
spring.application.name=api-gateway
#2個配置為一組，可配置多組
#開頭是固定的zuul.routes，結尾也是固定的path、service-id,中間部分相當於這組配置的id，可隨意取
#映射地址
zuul.routes.user-service.path=/user-server/**
#要映射的服務
zuul.routes.user-service.service-id=user-server
#註冊到Eureka伺服器
eureka.client.serviceUrl.defaultZone=http://127.0.0.1:9001/eureka/
#本機地址，上線時要改為機器實際的ip
eureka.client.ipAddress=127.0.0.1
#實例名，以ip:port的形式註冊到server上
eureka.instance.instance-id=${eureka.client.ipAddress}:${server.port}
#註冊節點時IP優先，預設為false——註冊主機名
eureka.instance.prefer-ip-address=true
#多久發送一次心跳，預設30s，調試時可設置短些
#eureka.instance.lease-renewal-interval-in-seconds=30
請求地址：http://ip:port/user-server/user/order/{user_id}
使用網關（Zuul）的ip:port，後面跟該服務名映射的path（不是服務名，只不過上面我設置的path和服務名相同）
會自動根據path找到對應的服務名（service_id），負載均衡確定要使用該服務的哪個節點。不同的服務（暴露出來的那些服務）映射到不同的path。
可以添加首碼：
zuul.prefix=/api
請求地址：請求地址：http://ip:port/api/user-server/user/order/{user_id} 加在映射地址前面的
ajax的url、<a>鏈接的href、<form>的action寫上面的請求地址。
以後調用消費者（暴露出來的服務）時，不直接調用，而是使用上面的url，通過網關來調用，
網關相當於一個介面（API），提供網關的地址、服務的path供外部調用，所以網關（gateway）又叫做API gateway。
此處網關並未集群，所以直接使用網關的ip:port，請求發給網關；
如果網關要集群，需要使用Nginx做網關的負載均衡，請求發給Nginx。
使用Zuul對請求進行過濾
新建一個包filter，包下新建一個類MyFilter：
@Component //放到spring容器中即可，會自動使用此攔截器 public class MyFilter extends ZuulFilter { //需要繼承ZuulFilter
//指定過濾時機 //String類型，"pre"——路由轉發之前，"routing"——路由轉發之時，"post"——路由轉發之後，"error"——發生錯誤時 @Override public String filterType() { return "pre"; }
//設置此攔截器的執行順序 // 因為可能有多個攔截器，設置一個int型的值，數值越小，優先順序越高、越先執行 @Override public int filterOrder() { return 0; } //是否要進行過濾，即是否要使用此過濾器，這個需要改一下，因為預設為false @Override public boolean shouldFilter() { return true; } //核心方法，進行過濾 @Override public Object run() { RequestContext currentContext = RequestContext.getCurrentContext(); HttpServletRequest request = currentContext.getRequest(); //獲取傳遞的參數、驗證許可權 String token = request.getParameter("token"); //token要和資料庫查到的進行比較，此處隨便寫一個代替 if (token==null || !token.equals("123456")) { //直接就返迴響應了，請求終止，不再轉發給服務 currentContext.setSendZuulResponse(false); currentContext.setResponseStatusCode(400); //把提示信息顯示到頁面 try { currentContext.getResponse().getWriter().write("token is invalid"); } catch (IOException e) { e.printStackTrace(); } } return null; }
}
說明
網關的請求過濾會過濾所有對暴露出來的服務的請求，所以一般寫通用的過濾，比如登錄狀態檢驗，如果不是通用的，要寫在服務中。
如果暴露出來的服務沒有集群，可以不使用網關，直接請求服務節點即可。
文件上傳使用SpringMVC的文件上傳，但網關預設對上傳文件的大小、請求的大小有限制，需要我們在網關的application.properties中配置一下：
#上傳文件的最大尺寸，預設1MB
spring.servlet.multipart.max-file-size=2000MB
#請求的最大尺寸，預設10MB
spring.servlet.multipart.max-request-size=2500MB
在引導類上可以使用@EnableZuulProxy、@EnableZuulServer，這2個註解基本差不多，微小的區別是：
實現過濾器時要繼承ZuulFilter類，要指定過濾時機，這個類有很多子類，這些子類已經指定了時機，我們可以直接繼承來用，這樣就不用指定過濾時機了，使用@EnableZuulServer，少部分子類用不了，影響不大。
不建議使用大量的過濾器，因為會加大時間開銷，拉低性能。
