I've read some articles online and saw one tutorial regarding microservices. I'm confused with one thing that the tutorial said. Lets say we have simple architecture with eureka as disovery server and feign client. The tutorial said that this architecture uses server side load balancing and uses client side load balancing at the same time. First it get's services addresses and saves them in cache and then using that does client side load balancing. But I think its wrong. For me using feign client uses only client side load balancing. Server side is off the chart. There is no saving in cache, but the feign client is using eureka rather than cache memory. I could use server side load balancing with zuul, but then I wouldn't be using client load balancing am I right?
Second question is. Spring boot api gateway is also has built in load balancer and it also is using client side load balancing right?
I think the tutorial made some assumptions that weren't correct and now I'm left confused.
Related
For microservices architecture not in the cloud :
What is the difference between the load balancer of Kubernetes and the load balancer of spring cloud?
what are the advantages of implementing Eureka and spring boot load balancer when using Kubernetes for deployment rather than using Kubernetes load balancer and kubernetes service discovery?
Quite a complex question but here are my thoughts on the matter:
Before actually answering the questions, I must say that my experience setting up Kubernetes load balancer outside of public clouds is a hassle so I wouldn't recommend the approach but, assuming that it is not an issue for you, the main difference is how things are set ut. I would say that the biggest advantage of having it in Kubernetes is that you may also have service mesh solution like Istio that gives you other advantages that just load balancing. Furthermore, it would be easier to do canary (or other special type of) deployments with infrastructure load balancing than with Spring.
The only real advantage I see is if you have different teams with responsibility of the infrastructure, deployment and coding. Say if the Kubernetes team is responsible for creating services, deployments, etc and is overloaded, you might get code out faster if your dev team has capacity and competence but, again, there would be no point using Kubernetes then. Or in case you cannot actually create the LoadBalancer service in Kubernetes (as mentioned - not always straightforward in non cloud env)
On a side note, if you are on the way to deploying Kubernetes internally and want to get it to work, have a look at Metallb
I am following a course about microservice architecture using spring, covering netflix's eureka.
The clientui serves webpages and calls the 3 microservices when needed.
The config-server serves configuration for the 3 microservices from a git repo.
Of course the 3 microservices are registered as eureka clients.
My questions are :
should the config server and also be registered as an eureka client, or is there no benefit in doing so?
what about the clientui (which is the web entry point) ? can it be registered as an eureka client in order to benefit from load balancing system and if yes, how then should the app be accessed by clients?
About your first question :- Yes you can register config server as eureka client. Benefit of this will be that in terms of service management it will give you a single point of visibility of all the services. Also later if you try to expand your app in terms of distributed architecture and say you implement an api gateway like zuul, it will be easy for you to setup a fallback config server say if one config server goes down requests can be routed to other config server and so on.
About your second question :- Honestly speaking , I didn't understand it very well in first place. I have never seen any ui service registering to eureka so I am not very sure about this. Still if you have more doubts about it , you can let me know like is it a angular ui or is it a http based client or what.
Which kind of load balancing (client side or server side) is implemented when we use lb as a prefix for a url/service? How is it different from zuul? Afaik, zuul is used for server side load balancing.
We are currently setting up a Micro-service Architecture using spring boot and netflix components, for Deployment we are planning to go with aws kubernetes(EKS) setup. We are in a in a dilemma to choose whether to use netflix's Eureka & ribbon services on Kubernetes for service discovery or to use Kubernetes own service discovery Mechanism. The advantages I see in using k8s service discovery is that horizontal scaling becomes easy. Any thoughts on this will be really good for us to take it in the right direction.
Thanks.
If you don't have a strong case for client side load balancing I would not use Eureka and ribbon. I am getting the load balancing and service discovery from my platform (k8s) for free. If not for client side load balancing, there is no value that eureka and ribbon brings other than beefing up your resume :). On the other hand, it brings another stack that you need to maintain in the long term.
This is a kind of related question
Can Eureka be used by outside world to discover my service? Below is the flow:
Public client( developed in any technology and not using Eureka) --> Eureka server (hosted on my organization server, exposed to outside world) --> My Eureka aware services.
I am trying to understand how Netfilx Eureka works from overall architecture point of view.
Basically Load Balancer and discovery service are two completely different things.
Discovery service = a registry of currently available services
Load Balancer = a routing of requests based on various rules
So, Eureka, as a discovery service, cannot be used a Load Balancer by itself.
However Eureka, being an application by itself, exposes an HTTP REST API
So if you want to build a load balancer by yourself based on the information provided by eureka, you can call rest APIs like this.
For example, Ribbon, being a client side load balancer, calls these APIs internally.
Having said that, its not unclear why to use the tool for the purpose for which is not intended to be...