在業界，一般有兩種微服務的實踐方法：基于dubbo的微服務架構、基于Spring Cloud的微服務架構。從概念上來講，Dubbo和Spring Cloud并不能放在一起對比，因為Dubbo僅僅是一個RPC框架，實現Java程序的遠程調用，實施服務化的中間件則需要自己開發；而Spring Cloud則是實施微服務的一系列套件，包括：服務注冊與發現、斷路器、服務狀態監控、配置管理、智能路由、一次性令牌、全局鎖、分布式會話管理、集群狀態管理等。

在國內基于Dubbo實施服務化，剛開始是基于ZooKeeper進行服務注冊與發現，現在已經轉成使用Etcd。我這次學習Spring Cloud，則是想成體系得學習下微服務架構的實現，也許能夠對基于Dubbo實施微服務架構有所借鑒。

目前，在Spring cloud 中服務之間通過restful方式調用有兩種方式?
- restTemplate+Ribbon?
- feign
Ribbon
Ribbon 是一個基于 HTTP 和 TCP 客戶端的負載均衡器

它可以在客戶端配置 ribbonServerList（服務端列表），然后輪詢請求以實現均衡負載

它在聯合 Eureka 使用時

ribbonServerList 會被 DiscoveryEnabledNIWSServerList 重寫，擴展成從 Eureka 注冊中心獲取服務端列表

同時它也會用 NIWSDiscoveryPing 來取代 IPing，它將職責委托給 Eureka 來確定服務端是否已經啟動

Feign
Spring Cloud Netflix 的微服務都是以 HTTP 接口的形式暴露的，所以可以用 Apache 的 HttpClient 或 Spring 的 RestTemplate 去調用

而 Feign 是一個使用起來更加方便的 HTTP 客戶端，它用起來就好像調用本地方法一樣，完全感覺不到是調用的遠程方法

總結起來就是：發布到注冊中心的服務方接口，是 HTTP 的，也可以不用 Ribbon 或者 Feign，直接瀏覽器一樣能夠訪問

只不過 Ribbon 或者 Feign 調用起來要方便一些，最重要的是：它倆都支持軟負載均衡

注意：spring-cloud-starter-feign 里面已經包含了 spring-cloud-starter-ribbon（Feign 中也使用了 Ribbon）

從實踐上看，采用feign的方式更優雅（feign內部也使用了ribbon做負載均衡）。

如何理解客戶端Ribbon?
zuul也有負載均衡的功能，它是針對外部請求做負載，那客戶端ribbon的負載均衡又是怎么一回事？

客戶端ribbon的負載均衡，解決的是服務發起方（在Eureka注冊的服務）對被調用的服務的負載，比如我們查詢商品服務要調用顯示庫存和商品明細服務，通過商品服務的接口將兩個服務組合，可以減少外部應用的請求，比如手機App發起一次請求即可，可以節省網絡帶寬，也更省電。

ribbon是對服務之間調用做負載，是服務之間的負載均衡，zuul是可以對外部請求做負載均衡。?

————————————————
版權聲明：本文為CSDN博主「q_0718」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/q_0718/article/details/80269864

總結

以上是生活随笔為你收集整理的SpringCloud系列之服务消费Ribbon和Feign区别的全部內容，希望文章能夠幫你解決所遇到的問題。

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