martinlippert
commented
7 years ago Thank you very very much for the detailed explanation, this is an extremely interesting use case that we thought about in the past already, but never got around to fully implement this in STS or Ribbon yet.
I will follow up with you via email for additional discussions... :-)
We develop above 100 microservices - monthly increasing - in 7 teams and therefore its completely impossible to run integration tests (based on feature branches of single teams or developers ) locally/offline on a dev machine- it would exceed available machine ressources (mostly ram,). Therefore a developer/team would like to fallback to reuse the stable running microservices in the cloudfoundry shared via org>space with his/other teams. Here the developer will e.g. have access to the last integrated stable release train of all microservices. Running one of these microserviceslocally with commits a head on a feature branch, the developer would like to run integrations tests through the cloudfoundry deployed stable microservices, but as soon as the requests comes to usage of any of his locally running services - the discovery lookup shall find and route towards the mciroservice instance on his local machine only for his request. Of course integration test requests of other developers will never be routed to any dev machine else them their own.
The solution for such scenario could be like this:
Prerequisite for all microservices(locally and deployed on the cloudfoundry space all share together) is a (new artifact) "Spring Cloud devtools" dependency, because this one brings in the auto configuration for this dev features for the cloud in Spring Boot and Spring Cloud Netflix - optional.
The Spring Cloud devtools provide an following new behavior to spring components:
1.) In STS Boot Dashboard a developer can tie/register a local microservice to a cloudfoundry space where spring cloud services are being deployed and therefore its possible to register the local instance to the remote registry(eureka).
2.) The local instance is registered with special eureka metadata "localdevroute" (added on the fly by a Spring Cloud devtools 2.) enhanced DiscoveryClient marking the instance as devtools instance for the cloudfoundry the developers cloudfoundry user name (exactly reuse the one known to STS boot dashboard the the local ms i tied to).
3.) For any Spring Cloud STS project which has configured such Spring Cloud devtools integration a @SpringBootTest will add a pcf-user header param "localdevroute" to any test request (if not already attached) that has the value of the developers cloudfoundry username.
4.) Spring cloud Netflix DiscoveryClient (Ribbon) will extract the request header parama "localdevroute" and match it against microservice metadata attribute "localdevroute", and will filter down to these instances for the following load balancing decision only. If no match is found the complete instance list will be used as usual. There already is github project (we use for simlar things) that provide such feature tbased on PredicateRules in o Ribbon. see https://jmnarloch.wordpress.com/2015/11/25/spring-cloud-ribbon-dynamic-routing/