微服務springcloud—微服務閘道器、Zuul簡介和Zuul微服務
使用zuul構建微服務閘道器
為什麼要使用微服務閘道器
雖然微服務架構已經初具雛形，但還有一些問題————不同的微服務
一般會有不同的網路地址，而外部客戶端（例如手機APP）可能還需
呼叫多個微服務接口才能完成一個業務需求。例如一個電影購票的
手機APP，可能會呼叫多個微服務介面，才能完成一次購票的業務流程。
如果讓客戶端位元組與各個微服務通訊，會有以下的問題：
客戶端會多次請求不同的微服務，增加客戶端的複雜性。
存在跨域請求，在一定場景下處理相對複雜。
認證複雜，每個服務都需要獨立認證。
難以重構，隨著專案的迭代，可能需要重新劃分微服務，例如：可能
將多個服務合併成一個或者一個服務拆分成多個。如果客戶端直接與微服務通訊，那麼重構將很難實施。
某些微服務可能使用了防火牆/瀏覽器不友好的協議，直接訪問會有一定的難度。
以上問題可以藉助微服務閘道器解決。微服務閘道器是介於客戶端和伺服器端之間的中間層，
所有的外部請求都會事先經過微服務閘道器。
客戶端只和閘道器互動，而無需直接呼叫特定微服務的介面。這樣，開發就可以得到簡化。
不僅如此，使用微服務閘道器還有以下優點
易於監控。可在微服務閘道器收集監控資料並將其推送到外部系統進行分析。
易於認證。可在微服務閘道器上進行認證，然後再將請求傳送到後端的微服務，
而無須在每個微服務中進行認證。
減少了客戶端與各個微服務之間的互動次數。
Zuul簡介
Zuul是Netfilx開源的微服務閘道器，他可以和Eureka、Ribbon、Hystrix等元件配合使用。
Zuul的核心是一系列的過濾器，這些過濾器有以下功能
身份認證與安全：識別每個資源的驗證要求，並拒絕那些與要求不符的請求。
審查與監控：在邊緣位置追蹤有意義的資料和統計結果，從而帶來精確的生產檢視。
動態路由：動態地將請求路由到不同的後端叢集。
壓力測試：逐漸增加指向叢集的流量，以瞭解效能。
負載分配：為每一種負載型別分配對應的容量，並棄用超出限定值的請求。
靜態響應處理：在邊緣位置直接建立部分響應，從而避免其轉發到內部叢集。
多區域彈性：跨越AWS Region進行請求路由，旨在實現ELB使用的多樣化，以及
讓系統的邊緣更貼近系統的使用者。
Spring Cloud對Zuul進行整合與增強。目前，Zuul使用的預設HTTP客戶端是Apache
HTTP Client，也可以使用RestClient或者okhttp3.0.okHttpClient。如果想要
RestClient，可以設定ribbon.restclient.enable=true，想要使用okhttp3.0kHttpClient，
可以設定ribbon.okhttp.enable=true。
編寫Zuul微服務閘道器
1.建立一個Maven工程，ArtifactId是microservice-gateway-zuul，併為他新增以下依賴。
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-zuul</artifactId>
<version>2.0.2.RELEASE</version>
</dependency>
2.在啟動類上添加註解@EnableZuulProxy，宣告一個Zuul代理。該代理使用Ribbon來定位註冊到Eureka Server中的微服務，同時該代理還整合了Hystrix，從而實現了容錯，所有經過Zuul的請求都會在Hystrix命令中執行。
@SpringBootApplication
@EnableZuulProxy
public class ZuulApplication {
public static void main(String[] args) {
SpringApplication.run(ZuulApplication.class, args);
}
}
3.編寫application.yml
server:
port: 8040
spring:
application:
name: zuul
eureka:
client:
service-url:
defaultZone: http://localhost:8761/eureka/
#開啟斷路器功能
feign:
hystrix:
enabled: true
management:
endpoints:
web:
exposure:
include: hystrix.stream
這樣一個簡單的微服務閘道器就完成了，有配置可知，此時是添加了Zuul的依賴，並將Zuul註冊到Eureka Server上。
測試：路由規則
1.啟動專案microservice-discovery-eureka。
2.啟動專案microservice-provider-user。
3.啟動專案microservice-consumer-movie-ribbon。
4.啟動專案microservice-gateway-zuul。
5.訪問http://localhos:8040/movie/user/1,請求會被轉發到localost://localhost:8010/user/1（電影微服務）。
6.訪問http://localhos:8040/users/1,請求會被轉發到localost://localhost:8000//1（使用者微服務）。
說，ing預設情況下，Zuul會代理所有註冊到Eureka Server的微服務，並且Zuul的路由規則如下：
http://ZUUL_HOST:ZUUL_PORT/微服務在Eureka上的serviceId/**會被轉發到serviceId對應的微服務。
測試：負載均衡
1.啟動專案microservice-discovery-eureka。
2.啟動多個microservice-provider-user。
3.啟動專案microservice-gateway-zuul。此時，Eureka Server首頁如圖
4.多次訪問http://localhost:8040/users/1,會發現兩個微服務節點都會列印如下日誌。
說明Zuul可以使用Ribbon達到負載均衡的效果。
測試：Hystrix容錯與監控
1.啟動專案microservice-discovery-eureka。
2.啟動專案microservice-provider-user。
3.啟動專案microservice-consumer-movie-ribbon。
4.啟動專案microservice-gateway-zuul。
5.啟動專案microservice-hystrix-dashboard。
6.訪問http://localhost:8040/movie/user/1。
7.Hystrix Dashboard中輸入http://localhost:8040/hystrix.stream，隨意指定一個Title並點選Monitor Stream按鈕後。
說明Zuul已經整合了Hystrix。
本文大部分內容轉載自周立的《Spring Cloud與Docker微服務架構實戰》