SpringCloud學習筆記四：Spring Cloud Zuul 路由

Spring Cloud Zuul 路由的作用

Eureka用于服務的注冊于發現，Feign支援服務的調用以及均衡負載，Hystrix處理服務的熔斷防止故障擴散，Spring Cloud Config服務叢集配置中心，似乎一個微服務架構已經完成了。

我們還是少考慮了一個問題，外部的應用如何來通路内部各種各樣的微服務呢？在微服務架構中，後端服務往往不直接開放給調用端，而是通過一個API網關根據請求的url，路由到相應的服務。當添加API網關後，在第三方調用端和服務提供方之間就建立了一面牆，這面牆直接與調用方通信進行權限控制，後将請求均衡分發給背景服務端。

Spring Cloud Zuul 路由的功能

這個元件其實功能很多，比如反向代理，負載均衡還有權限控制等功能。

zuul和feign的應用場景和差別

1、zuul作為整個應用的流量入口，接收所有的請求，如app、網頁等，并且将不同的請求轉發至不同的處理微服務子產品，其作用可視為nginx。

2、feign則是将目前微服務的部分服務接口暴露出來，并且主要用于各個微服務之間的服務調用。

兩者的應用層次以及原理均不相同。

3.zuul也含有hystrix和ribbon，基于http通訊的，可以直接代理服務就行。在它和服務間增加feign隻會增加通訊消耗，沒有特别的意義。feign在服務互相調用的時候用就行了，可以仿rpc通訊。

4.Feign主要作用戶端流控，Feign的負載均衡是基于Eureka實作的

Zuul主要作服務端流控，并且Zuul的負載均衡結合Eureka實作易用性較好，并且Zuul我一般用在對第三方提供通路接口。

摘取《拜托！面試請不要再問我Spring Cloud底層原理！》對SpringCloud核心元件做出的總結

• Eureka：各個服務啟動時，Eureka Client都會将服務注冊到Eureka Server，并且Eureka Client還可以反過來從Eureka Server拉取系統資料庫，進而知道其他服務在哪裡
• Ribbon：服務間發起請求時，基于Ribbon做負載均衡，從一個服務的多台機器中選擇一台
• Feign：基于Feign的動态代理機制，根據注解和選擇的機器，拼接請求URL位址，發起請求
• Hystrix：發起請求是通過Hystrix的線程池來走的，不同的服務走不同的線程池，實作了不同服務調用的隔離，避免了服務雪崩的問題
• Zuul：如果前端、移動端要調用後端系統，統一從Zuul網關進入，由Zuul網關轉發請求給對應的服務

以上就是我們通過一個電商業務場景，闡述了Spring Cloud微服務架構幾個核心元件的底層原理。

文字總結還不夠直覺？沒問題！我們将Spring Cloud的5個核心元件通過一張圖串聯起來，再來直覺的感受一下其底層的架構原理：

參考資料

《SpringCloud微服務實戰-Zuul-APIGateway（十）》

《Spring-Cloud系列第7篇：spring-cloud-zuul》

《spring cloud使用zuul實作反向代理和負載均衡》

《springcloud中zuul和feign的應用場景和差別》