Setup: 2 eureka servers replicate. and 1 eureka client set the default zone in application.yml as localhost:8761, localhost:8762.
Question:
1.Will eureka client send heartbeat to both 8761 and 8762?
Thanks,
Young
No, it will not send the heart beat to both 8761 and 8762. How it works is- We provide the list of Eureka servers. All the clients will pick first server from the list (in your case 8761) and start sending the heartbeat. All the clients will switch to other server only in case first Eureka server dies.
Second server will always get a copy of registry from first server.
Related
I have two Eureka servers with peer awareness enabled. Multiple clients connect to these two and the config file looks like this:
eureka:
client:
service-url:
defaultZone: https://server1/eureka/,https://server2/eureka/
Everything works just fine until one of the Eureka servers go down. If it's server2 then the clients start to throw exceptions, but nothing breaks. I can even restart the clients and they will boot up just fine. However, if the server1 goes down I can no longer restart clients as they seem to prefer the first Eureka server in the list and if it's down the client just won't start at all throwing org.springframework.web.client.ResourceAccessException: I/O error on GET request for ... exception.
Is there any way to make the clients at least try to use the second server (or third, fourth, etc) upon startup if the first one is down?
rsocket seems to be a cool idea. I have this question and I could not find a better answer.
Lets consider this initial set up. client sends multiple requests to the server-1 sequentially.
client --> server-1
server-1 is doing some compute intensive tasks. So auto-scaler created another instance of server which is server-2 after some time. Now the setup became like this.
client --> server-1
server-2
As per my understanding client-->server-1 connection is established and kept alive. We use this connection for all the client-server communication. How to make use of another server - server-2 to share some of the client requests like this.
client --> server-1
|-----> server-2
Otherwise it will be a sequential processing.
I use spring boot with rsocket.
There are two options for this:
use low-level load balancer on client side from rsocket-load-balancer
deploy RSocket broker between client and server, some options are Netifi Broker or Alibaba RSocket Broker
I'm testing a consul server cluster. I am using the go client for this.
How do I enter multiple servers for the client to connect to?
Optimally it would be something like:
client, err := api.NewClient(api.DefaultConfig())
client.remotes = host_array
Is this a wrong-headed approach to using consul and the expected way for a user is to start a client node and then read the locally replicated state?
The Consul API client defaults to 127.0.0.1:8500 because there is an expectation that it will connect to a local Consul Agent running in client mode. The Consul Agent should be your "proxy" to the Consul Servers and maintain the connections with active servers so you don't have to.
https://www.consul.io/docs/internals/architecture.html
https://github.com/hashicorp/consul/issues/3689
An alternate approach could be to utilize a load balancer for a cluster of Consul Servers. Strategies for that are documented here... https://www.hashicorp.com/blog/load-balancing-strategies-for-consul
I've set up a Node-Red instance on IBM Cloud with a Socket.IO server using node-red-contrib-socketio.
I was able to subscribe to events on port 3000 on my local host fine but I'm having difficulty doing the same with the Node-Red instance on IBM Cloud.
According to my client console I seem to be able to connect but get no response using the following URL: ws://MYAPP.eu-gb.mybluemix.net/red:3000/socket.io/?EIO=3&transport=websocket Is this correct or should I be using something else like ws://MYAPP.eu-gb.mybluemix.net:3000/socket.io/?EIO=3&transport=websocket ?
Is any further configuration required in IBM Cloud to enable the connection?
If I need to authenticate within the URL I pass to the server is there a particular way that string should be structured?
Many thanks,
This will not work on Bluemix.
The Bluemix router only forwards external traffic on ports 80 and 443 (http/https) to apps.
But the app may not be actually listening on those ports (The port to listen on is passed in to the application on start up in a environment variable).
You can not just pick an arbitrary ports and listen on.
I have an eureka-server, eureka-client-1, eureka-client-2 and zuul-proxy deployed.
The eureka-client-* are changing from {status:"UP"} to {status:"DOWN"}.
How can I lower the delay so that zuul-proxy always points to one of the eureka-client-* that is {status:"UP"}?
There are several options to reduce the delay.
The values in below are just for example.
Eureka Server Response Cache
eureka server property
eureka.server.response-cache-update-interval-ms: 5000 (default 30000)
Eureka server has response cache for the performance, so it doesn't return actual values that it knows during above milliseconds. You can reduce this delay with above property.
Zuul Ribbon Cache
zuul property
ribbon.ServerListRefreshInterval: 5000 (default 30000)
As you know, zuul is using Ribbon for load-balancing and Ribbon has cache for server list. The default value is 30 seconds. You can adjust this value with above property to reduce ribbon cache time.
Eureka Client Cache
eureka client property (In your case, it's zuul property)
eureka.client.registryFetchIntervalSeconds : 30
Zuul is another eureka client and it is using eureka client to retrieve available server list for a specific service. The default interval for this is 30 seconds and you can adjust this value with the above property.
Lease Expiration Duration
eureka instance properties (In your case, for your eureka-client-1, eureka-client-2)
eureka.instance.lease-expiration-duration-in-seconds: 60 (default 90)
If Eureka server didn't receive heartbeat during above seconds, eureka server removes that instance from available server list. Each your client sends a heartbeat in every 30 seconds (that value is also configurable, but don't change this property because eureka server has some codes based on the assumption of this 30 seconds). So 90 seconds means that eureka instance will be removed from the list if it fails to send (or server fails to receive) heartbeats at three consecutive times. You can reduce this duration, but you may have some risks of that. This property must exist on your eureka client side.
There is a great article about this information here : http://blog.abhijitsarkar.org/technical/netflix-eureka/