I'm a consul neophyte. There exists certain job servers in which consul is not configured. And these job servers has to inform consul server that it is about to fail and then fail. Is there a class that I can use using rickfast's consul client?
Currently there's a simple listener on the consul server. This listener uses ConsulCache.Listener :- https://github.com/rickfast/consul-client/blob/master/src/main/java/com/orbitz/consul/cache/ConsulCache.java
Haven't figured out a way yet. Any suggestions will be most welcome.
Related
I'm working with spring cloud consul as a config server and service discovery tool in test environment. according to the consul documentation, consul server need to be at least 3 to 5 recommended servers, and consul will automatically choose a leader server with internal election. The problem is in consul cluster, which server I need to choose to connect in my spring boot service? if leader server changed, what will happen to my service? what is the best practice of using consul server in a real production environment?
I need to mention that, I already studied consul website documentation, but what I need is a real example for architecture and best practice for production environment. note that my services have high TPS due to USSD transactions in a telecom company. Thanks in advance.
I have tried to connecting to consul server and I'm using it in a test environment as config and service discovery tool. I have nearly 100 service to use consul as their config and discovery server within an internal network with 100 VMs and containers.
I expect a architecture for production environment to use consul in real production environment with pros and cons.
I've started building a microservice application with the netflix stack, and have been successful in registering clients with the eureka discovery server.
I want to have two instances of each client service,
and i'm wondering what happens if one instance of a client goes down. Does loadbalancing handle such situations ? If yes, then isn't eureka also acting as a failover system ?
I'm learning Consul.Got confused by relation between Spring Cloud Consul and Consul Client.
I found that, in Spring boot applications, we can use #EnableDiscoveryClient to contact to a Consul Agent. But if I want to election a leader of my own service, can Spring Cloud Consul provides these interfaces？Or I need to relay on consul-client?
The election of the leader in the consul cluster is make of internal algorithm of consul based in RAFT that is an algoritm of consensum, for more information you can see:
https://www.consul.io/docs/internals/consensus.html
The clients of consul is a wrapper of API REST expoused by Consul, normaly you must have you consul servers behind of the load balancer and this url is that you configure in your clients for example in spring boot.
spring.cloud.consul.host = url_load_balancer
spring.cloud.consul.port = port_load_balancer
In conclusion the client can't manage the leader election of a consul cluster, but the closest approach that i find is:
https://www.consul.io/docs/guides/leader-election.html
i hope that it help you
In my project we have a requirement to run two instances of spring cloud config server so if one instance goes down, other will take care the config server responsibilities.
Currently, you would need to put config server behind a load balancer. It is stateless, so that wouldn't hurt. There is an open issue to configure multiple config server url's in the client, so it could do failover there.
If you are running multiple instances of the config server, you can have them all register themselves in Eureka, and maybe do a lookup to the config server with it's application name via Eureka in all the other microservices. This way, Zuul (and Ribbon) will take care of the load balancing.
Edit:
I guess spencergibb is right. It's best to use a load balancer, for eg: ELB, if you're going to deploy on AWS.
Consider multiple spring-cloud-config-uris for high availability
We've three Spring Boot applications:
Eureka Service
Config Server
Simple Web Service making use of Eureka and Config Server
I've set up the services so that we use a Eureka First Discovery, i.e. the simple web application finds out about the config server from the eureka service.
When started separately (either locally or by starting them as individual docker images) everything is ok, i.e. start config server after discovery service is running, and the Simple web service is started once the config server is running.
When docker-compose is used to start the services, they obviously start at the same time and essentially race to get up and running. This isn't an issue as we've added failFast: true and retry values to the simple web service and also have the docker container restarting so that the simple web service will eventually restart at a time when the discovery service and config server are both running but this doesn't feel optimal.
The unexpected behaviour we noticed was the following:
The simple web service reattempts a number of times to connect to the discovery service. This is sensible and expected
At the same time the simple web service attempts to contact the config server. Because it cannot contact the discovery service, it retries to connect to a config server on localhost, e.g. logs show retries going to http://localhost:8888. This wasn't expected.
The simple web service will eventually successfully connect to the discovery service but the logs show it stills tries to establish communication to the config server by going to http://localhost:8888. Again, this wasn't ideal.
Three questions/observations:
Is it a sensible strategy for the config client to fall back to trying localhost:8888 when it has been configured to use discovery to find the config server?
When the eureka connections is established, should the retry mechanism not now switch to trying the config server endpoint as indicated by Eureka? Essentially putting in higher/longer retry intervals and periods for the config server connection is pointless in this case as it's never going to connect to it if it's looking at localhost so we're better just failing fast.
Are there any properties that can override this behaviour?
I've created a sample github repo that demonstrates this behaviour:
https://github.com/KramKroc/eurekafirstdiscovery/tree/master