為什么要使用微服務網關
不同的微服務一般會經過不同的網絡地址，而外部客戶端可能需要調用多個服務的接口才能完成一個業務需求。
如果讓客戶端直接與各個微服務通信，會有以下的問題：
- 客戶端會多次請求不同的微服務，增加了客戶端的復雜性。
- 存在跨域請求，在一定場景下處理相對復雜。
- 認證復雜，每個服務都需要獨立認證。
- 難以重構，隨着項目的迭代，可能需要重新划分微服務。例如，可能將多個服務整個成一個或者將一個服務拆分成多個。如果客戶端直接與微服務通信，那么重構將會很難實施。
- 某些微服務可能使用了防火牆/瀏覽器不友好協議，直接訪問會有一定的困難。
以上問題可借助微服務網管解決。微服務網關是介於客戶端和服務器之間的中間層，所有外部請求都會先經過微服務網關。
如圖，微服務網關封裝了應用程序的內部結構，客戶端只需跟網關交互，而無需直接調用特定微服務的接口。這樣，開發就可以簡化。不僅如此，使用微服務網關還有以下優點：
- 易於監控。可在微服務網關收集監控數據並將其推送到外部系統進行分析。
- 易於認證。可在微服務網關上進行認證，然后再將請求轉發到后端的微服務，而無需再每個微服務中進行認證。
- 減少了客戶端與各個微服務之間的交互次數。
Zuul簡介
Zuul是Netflix開源的微服務網關，核心是一系列的過濾器，這些過濾器可以完成以下功能。
身份認證與安全：識別每個資源的驗證需求，並拒絕那些與要求不符的請求。
審查與監控：在邊緣位置追蹤有意義的數據和統計結果，從而帶來精確的生產視圖。
動態路由：動態地請求路由到不同的后端集群。
壓力測試：逐漸增加執行集群的流量，以了解性能。
負載分配：為每一種負載類型分配對應容量，並棄用超出限定值的請求。
靜態響應處理：在邊緣位置直接建立部分響應，從而避免其轉發到內部集群。
多區域彈性：跨越AWS Region進行請求路由，旨在實現ELB（Elastic Load Balancing）使用多樣化，以及讓系統的邊緣更貼近系統的使用者。
編寫Zuul微服務網關
1.pom.xml添加maven依賴
<dependency>
<groupId>org.springframewor.cloud</groupId>
<artifactId>spring-cloud-starter-zuul</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-eureka</artifactId>
</dependency>
2.在啟動類上添加注解@EnableZuulProxy，聲明一個Zuul代理。該代理使用Ribbon來定位注冊在Eureka Server中的微服務；同時，該代理還整合了Hystrix，從而實現了容錯，所有經過Zuul的請求都會再Hystrix命令中執行。
3.編寫配置文件application.yml
這樣，一個簡單的微服務網關就編寫完成了。從配置可知，此時僅是添加了Zuul的依賴，並將注冊到Eureka Server上。
路由配置詳解
上邊已經編寫了一個簡單的Zuul網關，並讓該網關代理了所有注冊Eureka Server的微服務。但在現實中可能讓Zuul代理部分微服務，又或者需要對URL進行更加精確的控制。
Zuul的路由配置非常靈活、簡單
1.自定義指定微服務的訪問路徑。
配置zuul.routes。指定微服務serviceId = 指定路徑即可。例如：
zuul: routes: microservice-provider-user:/user/**
這樣設置，microservice-provider-user微服務就會被映射到/user/**路徑。
2.忽略指定微服務。
忽略服務非常簡單，可以使用zuul.ignore-services配置要忽略的服務，多個用逗號分隔
zuul:
ignored-services:microservice-provider-user,microservice-consumer-movie
這樣就可讓Zuul忽略microservice-provider-user和microservice-consumer-movie微服務，只代理其他微服務。
3.忽略所有微服務，只路由指定微服務