I recently have learnt and practicing Microservice using Spring technology. I am currently writing a small program that has Eureka Server, Configuration Server, Gateway and Account service. I have all of my services register its instance to Eureka and have my Gateway gets its configuration from Configuration Server. After that, I got some question, should I my Account Service fetch its configuration directly from Configuration Server, or from Gateway because it can be done in both way. I think, if I decide to fetch it through Gateway, it might be better because Gateway is a load balancer, so in case if there are multiple Configuration Servers out there, I don't need to worry if any of them failed or down as Gateway can handle this for me. But, doing so, isn't I put too much weight on Gateway because it need to handle this and another requests. Furthermore, I am not sure and I can't find any information about if there is a way to load balancing Gateway or is it makes sense to do so?
Please advice and explain. Thank you.
Only user's requests from UI need to be passed via Gateway. Services should be able to fetch their configuration during startup disregarding whether gateway is online or doesn't exist at all.
Also I'd advise you to avoid registering config service in Discovery (Eureka). I suppose there is no need for your users to send requests to config service.
Along with spring cloud config and gateway documentation I'd recommend you to get familiar with these 2 books:
https://www.manning.com/books/enterprise-java-microservices
https://www.manning.com/books/spring-microservices-in-action
Related
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.
What I know so far is that:
Api gateway: Is fixed entry point that manage north/south communications.
Service Mesh: Is a side-car proxy that manage inter-service communication east/west.
service registry: Is a database of services, their instances and their locations.
All sound clear, but when I try to put all things together, I am confused:
Most of the service mesh/api gateway vendors say that they provide
access control mechanisms and other similar mechanisms, are these mechanisms an overlapping
functionalities between both concepts, or they have different scope
and goals?
Assume all Api gateway, Service Mesh and Service registry are deployed together:
Does the api gateway forward the request directly to the service, or
it communicate with service proxy?
Do I have to register a service twice, one in the gateway and one in
the service registry? or how to integrate the service registy with api gateway?
Finally Until now it seems for me the all concepts purely serve different purposes so they all necessary, but they overloaded with other functionalities. Is it possible to integrate them in meaningful way? or is there a reference architecture that I can follow?
Because no one posted an answer and based on my continuous reading, I was able to grasp a basic idea of how all components should work together, I will not answer directly to question, rather I will try to make things more clear:
API Gateway or Service Mesh are nothing just proxies, but with that said they are proxies of different types.
API Gateway is a front-proxy or edge-proxy, through it you communicate with the world. so in your architecture you may have an API Gateway running with or without Service Mesh beeing deployed.
To register your services in your Gateway you have two options(maybe more):
Static registration: using configuration file or using the Admin API of the API Gateway you are using, this is similar of how KONG work.
Dynamic registration: usually this is done by integrating your Front-proxy (API Gateway) with some other Service Registry/Discovery tool. you can accomplish that for example using Envoy and consul.io.
Using only Front-proxy (without service mesh) It is hard to do health monitoring, Logging and let all service know if it’s pointless to try to contact a down service(Circuit breaker).
Now, if you need to isolate your services from the topology of the network, or you need to provide a set of functionality around each of your services such as, mentoring, Logging, retries, circuit breaker..etc, then you can accomplish that by deploying a process (beside each service) that proxies all the out and in requests to your service. This process what we call a sidecar proxy. All the sidecars proxies usually run the same code, but they are configured differently.
Finally: The combination of the edge-proxy (API Gateway ) and the sidecar proxies forms what we call a Service Mesh. And obviously all proxies can utilize the same service registry/discovery mechanism.
I implemented a Spring backend which is responsible to store different data (users, lectures, ...). This backend is secured with a JWT and everything is working fine. For my studies I want to enhance the backend and now I want to use a microservice architecture instead of a monolith. For this purpose I have the requirements to use Docker and Kubernetes. I always read articles which write that I need a Authorization Server and a Ressource Server when I want to use the JWT in a microservice architecture. Is that correct? And do I need a Gateway (e.g. Zuul) for my purpose? Can someone help me to structure the project and give advice for the technology stack. At the end the whole project will run in one single server.
I implemented a molotithical backend, secured with JWT.
Kubernetes officially supports authentication to API server within JSON Web Tokens(JWT) through OpenID Connect tool using OAuth 2.0 protocol for user request identification. However, this only represents a part of Authorization model, which determines how authenticated user can be granted with appropriate security policies or roles to manage Kubernetes cluster resources.
In order to build or migrate application to Kubernetes, you might consider to expose application outside the cluster, for that purpose Ingress proxies requests to exact service by matching request path. Actually, Ingress is a logical resource element which describes a set of rules for traffic management via Ingress Controller. Therefore, Ingress controller can play a role of API Gateway by delivering L7 network facilities like: load balancing, SSL termination and HTTP/HTTPS traffic routing for nested application services.
As you mentioned Zuul gateway can be one of the option for the edge proxying service in front of Kubernetes cluster, however I would recommend to look for some more Kubernetes oriented solutions. Istio is a good example, as it brings a wide set of network router functions with a quite simple integration into Kubernetes cluster via its core Service mesh design. Istio provides end user authentication via JWT within declared authentication policy.
Alternativelly, you can get through Nginx plus features with announced JWT authentication as well.
i have created two java spring-boot micro services they are
1) producer
2) consumer
and i have used spring eureka server for service registration and discovery . it worked fine . then what is the use of Netflix Zuul.
Let's suppose you have 20 services to which user can interact to, and of course we are not going to expose each and every services publicly because that will be madness (because all services will have different ports and context), so the best approach will be to use an API gateway which will act as single entry point access to our application (developed in micro service pattern) and that is where Zuul comes into picture. Zuul act as a reverse proxy to all your micro-services running behind it and is capable of following
Authentication
Dynamic Routing
Service Migration
Load Shedding
Security
Static Response handling
Active/Active traffic management
You can go through documentation here
If you have enough experience in the domain, you could look at zuul as an API gateway like Apigee. It is very feature rich and touches up on a lot of different concerns like routing, monitoring and most importantly, security. And eureka as a service discovery platform that allows you to load balance (in Linux terms the nginx or haproxy) and fail over between your service instances.
Typically the backend services that perform the server side business operations (i.e. core) are not exposed publicly due to many reasons. They are shielded by some Gateway layer that also serves as reverse-proxy. Netflix Zuul serves as this gateway layer which easily gives you the capabilities as mentioned by #Apollo and here
I am new to spring cloud and going through some examples and material available online to make myself comfortable. However, while reading about ZUUL, some sites configured the routes in ZUUL's application.yml and some other sites mentioned that the requests will be forwarded to the respective microservice and no need to explicitly configure the routes. I was bit confused. For ex, in the below scenario what is the approach, to configure routes or to let zuul route automatically?
Let's say i have few micro services running and all of them along with ZUUL are registered to Eureka.
I have a front end which is running on a different port on the same server and needs to interact with the above micro services.
I also have few other applications (Running entirely on different servers) which need to interact with the above micro services for fetching the data.
TIA..
Did you use Zuul (which know microservices address through Eureka) to forward request between your micro-services ? if it's the case, you are using Server-Side Load Balancing pattern.
If you use a discovery service (Eureka in your case), i think the best approach it's to use Client-Side load balancing pattern for all inter-services requests (inside your system). (you can use Ribbon or RestTemplate for that).
You can use Zuul as a unified front door to your system, which allows a browser, mobile app or other user interface to consume services from multiple hosts without managing cross-origin resource sharing (CORS) and authentication for each one.
For example : a client (mobile app) request for all picture comments. The client dont need to know the Comments-service address. Only proxy address needed and Zuul will forward the request to the right service. You can do this in application.yml/.properties by
zuul.routes.comments.path=/comments/**
zuul.routes.comments.service-id=comments
The request will be GET www.myproxy.mycompany.com/comments. Dont forget the service name in your application.yml/.properties is very important (spring.application.name). It's the service-id in Zuul routes (which the same identifier in Eureka).
For some reason, your system need to request external services (as you mentionned in the 3th note). In this case, your external services are not a discovery client, Zuul can't look for the service-id from Eureka. you use routes as
zuul.routes.currencyprovider.path=/currencies/**
zuul.routes.currencyprovider.url=https://currencies.net/
with this route, all /currencies/** requests from your services THROUGH Zuul will be done.
with this approach you have one door for all your system. This is API Gateway pattern.
Sometimes your system need to aggregate multiple results from different services to response to client request. You can do this in Proxy (Zuul in your case).