I'm trying to create a microservices architecture based on consul for discovery and fabio for load balancer.
Basically what I want to do is use consul to discovery some backend and frontend services and a database service.
I already have my services running and health checked so fabio can sees them but I'm trying to interact with them.
The main idea is use the consul DNS to establish a connection between front back and database and then expose the Fabio to balance the instances of each microservice.
In which case I have no idea on how to use consul's DNS to connect my back and database through Fabio so I can Balance my own microservices connection.
Related
I am using "Spring Cloud Gateway" in my microservices application
Ex:
spring.cloud.gateway.routes[0].id=mydemoservice
spring.cloud.gateway.routes[0].uri=http://localhost:8100/
spring.cloud.gateway.routes[0].predicates[0]=Path=/mydemoservice/**
In this case if the request is coming from client like : http://localhost:8100/mydemoservice/api/getdetails
in this case "Spring Cloud Gateway" will route the request to respective service.
But why is Eureka Server required here ? I am not really understanding Eureka Server use here can some please explain.
Best I could find is this medium article which depicts the problems and solutions Eureka provides.
https://medium.com/javarevisited/how-to-use-spring-cloud-gateway-to-dynamically-discover-microservices-194c0c3869c6
This comes to shine when you deploy services with horizontal auto scalability (such as kubernetes). At certain moments, based on the equation you configure (recourse usage, client connections, etc.) the orchestration can and will scale your services (e.g. mydemoservice). It can scale your service instance up to:
the configured max number of instances
until the service usage limit is reached
either way, all of them will have different IP addresses.
Eureka is a discovery/registry service which provides to your gateway information of which cluster/load balancer (IP address) will it pass the request based on Round Robins and such algorithms. The gateway needs to configure all of the services but it will use aliases provided by the Eureka server depicted as such:
https://github.com/rubykv/code-examples/blob/master/gateway/src/main/resources/application.yml
In this example, we see the gateways are configured for services: subject, student, and eureka.
Eureka has a dashboard:
https://miro.medium.com/max/1400/1*KgT1_hnuXvX6xldyiJJuaQ.png
and will display all eureka clients. To display a service as a eureka client one must implement:
https://github.com/rubykv/code-examples/blob/master/student/pom.xml (netflix eureka and open feign)
annotate application with #EnableFeignClients https://github.com/rubykv/code-examples/blob/master/student/src/main/java/com/example/demo/StudentApplication.java
There are lots of tutorials and articles on medium, I hope this helps for your further investigation.
What are the benefits to use "spring service discovery kubernetes" instead of using directly the Service DNS coming from Kubernetes?
I mean, If I deploy in kubernetes 2 services (service-a and service-b), and service-b exposes a Rest API.
service-a can easily connect to service-b using the url "http://service-b/...".
Question #1. In order to let service-a be able to connect to service-b using the service DNS, service-b has to be deployed before service-a?
Question #2. What are the pros/cons using the spring discovery?
Question #1:
No, the order in which you deploy the services is not important to use the kubernetes DNS services to resolve the ips, the only thing here is that if you deploy serviceA after serviceB, you will have in serviceA as an environment variable the ip of serviceB but not the inverse.
Question #2:
The spring service discovery is an alternative to the native kubernetes service discovery and it is used by other spring cloud projects like spring-cloud-eureka to perform the service discovery. The only pros I see in this approach is that you can custom the load balancing algorithm tath you can use to spread the load among the different instances
I am new to Micro services architecture.. I want know if it is required to deploy all Spring boot micro services in the same local network ..? As Eureka Discovery service uses Private/Internal IP Address for Registration , i am unable to call a services from another service deployed in different local network...
Please let me know how micro services deployed across multiple Sub nets should communicate each other in this case
or is there a way to tell eureka to use only public IP Address..?
Not sure if this would help, but by default, your eureka client will try to connect to the default localhost:8761 where the eureka discovery server should exist.
In case you have a different location for your discovery-service you can use the following in the application.properties file in your client services.
eureka.client.service-url.defaultZone=http://{address}-{port}/eureka
I am currenly learning microservices. I have two services Service A and Service B. Service A registered with Eureka server. Service B is calling Service B via Eureka server to get the response. My question is
why Service B has to register with Eureka service in order to call Service A?
Service B can get the Service A url and portno through service discovery from Eureka server. What is the significance of Service B to register with Eureka server?
Typically in Microservices architecture, we have a lot of small applications running independently together, and ofcourse they will all have their own URLs and ports.
In that scenario, it would be very cumbersome to maintain all these microservices to run in synchronization, and more importantly, with monitoring. This problem will increase manifold when we start implementing load balancers.
To solve this issue, we need a tool that will monitor and maintain the registry of all the microservices in the ecosystem.
That's why Eureka server acts as directory and service discovery system to make sure they is no direct binding between services and it make sure to have health check for those services.
So I have a very small micro service architecture built using Eureka service discovery. The problem I am facing right now is that I only want my service endpoints to accept request from my api gateway, as it is right now you can just make a request straight to the service and hit that service endpoint. Is this a problem Kubernetes would solve? Or Is there a more practical way of doing this?
You should be using network policies to control the traffic between the services.
In kubernetes the services you want to expose internally use service type ClusterIP. This is default anyway which means services are accessible within cluster only. your api gateway is exposed as load balancer service type which then takes traffic from external world and talks to services internally. Depending on your cloud provider you can use firewall in front of load balancer since you can compromise security by simply exposing load balancer. e.g. azure kubernetes you could use application gateway. You can also replace the api gateway with ingress controller. it's very powerful reverse proxy controller which you can expose directly to traffic and that would talk to your services internally.
You really need to understand concepts so i would recommend following links
https://kubernetes.io/docs/concepts/services-networking/service/
https://blog.getambassador.io/kubernetes-ingress-nodeport-load-balancers-and-ingress-controllers-6e29f1c44f2d