Skip to content

Context Propagation And Favorite Zone

Nadim Benabdenbi edited this page May 22, 2018 · 3 revisions

Let's check how developers can test new features or bug fixes and how fault-tolerance can be achieved in the optimal way.

  • Suppose that all micro-services has been configured with the @EnableRibbonFavoriteZone & @EnableContextPropagation
  • Suppose that zone1 & zone2 are not in the same data center
  • Two developers will register their micro-services under eureka specifying respectively their zone as developer1 & developer2.
  • For testing the developers will initiate a request setting the favorite zone to their own one.

Illustration

Explanation:

  • Use case 1: Usual usage of the platform without knowing its topology
  • Use case 2: Usage of external services that are near the zone1
  • Use case 3: Usage of external services that are near the zone2
  • Use case 4: Usage of external services that are near the zone3 (however this zone is down)
  • Use case 5: Developer 1 testing service1 & service3 which are running in his desktop
  • Use case 6: Fault-tolerance
  • Use case 7: Developer 2 testing service3 which is running in his desktop

We can combine multiple zuul behind an F5 hardware with no break of the desired outcome.

Clone this wiki locally