SpringBoot3.1.5對應新版本SpringCloud開發(2)-Eureka的負載均衡
Eureka的負載均衡
負載均衡原理
- 負載均衡流程

老版本流程介紹
當order-servic發起的請求進入Ribbon后會被LoadBalancerInterceptor負載均衡攔截器攔截,攔截器獲取到請求中的服務名稱,交給RibbonLoadBanlancerCient,然后RibbonLoadBanlancerCient會將服務名稱當作服務id交給DynamicServerListLoadBanlancer,此時DynamicServerListLoadBanlancer就回去通過eureka-server獲取到對應的服務列表,eureka-server會返回真實的服務地址給DynamicServerListLoadBanlancer,然后DynamicServerListLoadBanlancer會通過IRule的實現接口來基于規則選擇一種方式獲取到返回的真實地址列表中的一個服務返回給RibbonLoadBanlancerCient,然后RibbonLoadBanlancerCient就會通過獲取到的真實ip和端口取替換掉原來的服務名稱,去發起這個請求獲取到對應的數據返回給order-servic
新版本流程介紹
新版本eureka對于netflix包只保留eureka本身,其它組件全部移除,并給出了推薦的替代品。
| Netflix | 推薦替代品 | 說明 |
|---|---|---|
| Hystrix | Resilience4j | Hystrix自己也推薦你使用它代替自己 |
| Hystrix Dashboard / Turbine | Micrometer + Monitoring System | 說白了,監控這件事交給更專業的組件去做 |
| Ribbon | Spring Cloud Loadbalancer | 忍不住了,Spring終究親自出手 |
| Zuul 1 | Spring Cloud Gateway | 忍不住了,Spring終究親自出手 |
| Archaius 1 | Spring Boot外部化配置 + Spring Cloud配置 | 比Netflix實現的更好、更強大 |
其中,Ribbon被Spring Cloud Loadbalancer替代了,所以新版本的流程將不再通過IRule來選擇地址了。
當order-servic發起的請求進入Loadbalancer后會被LoadBalancerInterceptor負載均衡攔截器攔截,攔截器獲取到請求中的服務名稱,交給LoadBalancerClient,LoadBalancerClient就去通過eureka-server獲取到對應的服務列表,并且通過ReactiveLoadBalancer來選擇一個并且返回對應的真實地址,然后LoadBalancerClient就會通過獲取到的真實ip和端口取替換掉原來的服務名稱,去發起這個請求獲取到對應的數據返回給order-servic。
需要注意的是,默認ReactiveLoadBalancer只有默認兩個實現類,也就意味著它默認只能通過兩種方案來選擇,一種是隨機選擇,一種是輪詢選擇。要做更多的選擇需要我們自己編寫對應的代碼。

浙公網安備 33010602011771號