Skip to content
Zuul ratio based routing to a legacy and modern app
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
gradle/wrapper
legacy-app
modern-app
sample-eureka
zuul-load
zuul-routing-gateway
.gitignore
Components.graffle
README.adoc
build.gradle
gradlew
gradlew.bat
settings.gradle

README.adoc

Sample Application Demonstrating Ratio based Routing to a legacy and a modern app

This app demonstrates using Zuul to route to a "legacy" and a "pcf" based app based on user specified ratios.

Additionally it understands sessions - if say the user is routed to the legacy app and the app is session based then further requests from the user will be pinned to the legacy app.

Starting it up Locally

In three terminal windows:

Terminal 1:

cd zuulgateway
../gradlew bootRun

Terminal 2:

cd legacyapp
../gradlew bootRun

Terminal 3:

cd pcfapp
../gradlew bootRun

Testing the routing behavior

Access an endpoint - http://localhost:8080/routes/message, the request will be routed to either "pcfapp" or "legacyapp" based on this property:

routing:
  ratio:
    old-percent: 50

Access another session based endpoint in an "Incognito" window - http://localhost:8080/routes/withsession, the behavior now will be once the user is directed to one of the versions of the app, subsequent requests should stick to the same app.

Deploying to CloudFoundry using SCS Tile

All the libraries relevant to getting it to work with SCS tile is already present with the app, just bind to Eureka, specify the name of the "pcfapp" via properties in zuulgateway, for eg:

pcf:
  ribbon:
    DeploymentContextBasedVipAddresses: myeurekaappname

Challenges with Sticky session

  • If Zuul and the target app are hosted on PCF then the call will go via gorouter twice. If there is JSESSIONID being set, then the gorouter tends to add the VCAP_ID twice

  • We add a custom token to route to "legacy" or "pcf" app - however we don’t have a good mechanism to expire this currently. Short term we plan to just add the same expiry as the JSESSIONID cookie, but we will never know if the session has been invalidated manually.

You can’t perform that action at this time.