Spring Tips: Hedging Client Requests with the Reactive WebClient and a service registry

preview_player
Показать описание
Hi Spring fans! In this installment of Spring Tips we look at how to use the reactive `WebFlux` client to make a number of concurrent requests to distinct service instances (discovered using a service registry like Netflix Eureka or Consul through the Spring Cloud `DiscoveryClient` abstraction) and meet SLAs by using the fastest request to return.

speaker: Josh Long
Рекомендации по теме
Комментарии
Автор

I learned this pattern from your Devoxx talk, and now watching this Spring Tips exactly one year later! And just bought your book Reactive Spring seconds ago!

zhaowentao
Автор

@Josh

I understand its just an example, but this implementation has various problems

1. It does not handle errors properly. If any of the upstream servers always fail fast due to any issue at its end, the overall client call will fail even if another service returns the response with slightly more latency
2. You shared a HashMap across multiple threads (most commons Scheduler implementation), which is completely unsafe
3. This does not work with all load balancer algorithms. Many people prefer latency based next server selection (and not round robin). If this high value algo is selected, this solution becomes completely useless as loadBalancer always returns the best server according to the past statistics (the same server again and again) & only single call to the past best server is always selected
4. If by the time between you retrieve service ids from discover client & the time you ask load balancer for next server, if the service registry info changes, say a bunch of servers leave due to network partition, your application does not behave the way you intend, i.e you might have less number of upstream servers than you intended (or) you may get no server returned if all he servers are invisible now

Overall, the next best server selection should be done inside the loadbalancer as he might have latency information. The concept is fine, but your implementation needs to be changed significantly to be anywhere near to be used in a production grade system due to the issues I mentioned above

arithmeticerror
Автор

make fulll fledged tutoriaal of webflux microservice commmunication with each other

darogajee
Автор

Who use Eureka, Zull when you have k8, istio and envoys

prashantjha