Context Propagation And Favorite Zone

Jump to bottom

enadim edited this page Nov 14, 2017 · 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.

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.

What are you waiting to use this awesome feature ❗