There is no doubt that API gateway should be the edge server to outside world.We are wondering that should we use API gateway in the communications between the microservices?
You can definitely use API gateway lets say for that matter (netflix -zuul) for inter-service calls, only thing of concern for you would be,
what happens when you start versioning your services, assuming you'll be using eureka as a naming server from which zuul gateway will fetch all registered services, but now in your case zuul will get two instances of your service (version previous and verison next) and ribbon will load balance the requests between the two, this point is already thoughtfully covered in
How to route in between microservices using Spring Cloud & Netflix OSS
Basically if you are familiar with BlueGreen Deployment model, implementing that would be a problem, surely there are proper workarounds for that as in defining/registering some metadata along with your previous and latest versions which would later be picked by ribbon client to route accordingly
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.
We are developing our application which probably is going to consist of about 20 Microservices. We are considering to use Pivotal Cloud Foundry to manage our Microservices and make it easier to have a platform for deployment and health check - amoung others.
About 12 Microservice will render HTML and now we want to know how we can compose all these services to one UI and present it to the client. Does Cloud Foundry a plugin or somehow solves the UI issues for Microservices? Does PCF generates Composite UI?
Does Cloud Foundry a plugin or somehow solves the UI issues for Microservices? Does PCF generates Composite UI?
No, the platform does not do this for you. It only handles routing requests to your apps.
About 12 Microservice will render HTML and now we want to know how we can compose all these services to one UI and present it to the client.
You might look into using a proxy app in front of your microservices. The proxy would just be responsible for presenting a unified front for your clients and combining all the backend services together.
Netflix Zuul/Spring Cloud Zuul or Spring Cloud Gateway might help with this, if you're using Java. I've also see people use Nginx as a reverse proxy to do similar things.
At the end of the day, you're going to need to figure out what works for your particular microservices & clients side apps though. I don't think anyone can give you a definitive answer to your question, at least not without a lot more information.
I am trying to build a simple application with microservices architecture.
Below are the details about 3 microservices I have created.
1] Customer.
database: mongodb
server : embeded tomcat server.
port : 8081
2] vendor.
database: mongodb
server : embeded tomcat server.
port : 8082
3] product.
database: mongodb
server : embeded tomcat server.
port : 8083
All the 3 micros runs on an embeded tomcat server.
Now I want to create a common gateway for all these micros [API gateway].
which help me to route my request based on the request I get for example:-
for example if I get a request of http://hostname:port_of_gateway/customer.
on reading this I need to route the request tom my customer micro and fetch its response and send it back to client.
Which of the spring tool I can use to achieve this?
Because your requirements are quite simple you can implement such a gateway by yourself. Here's an example.
But if you really want to use some Spring solution you can try to use Spring Cloud Netflix which is a part of Spring Cloud umbrella project. It includes router and filter features which in turn based on Netflix Zuul gateway service.
Note that this is not a complete standalone application but a library. Therefore you still should create another microservice that would act as API gateway in your application. To make it a gateway you should just add #EnableZuulProxy annotation to the same class that has #SrpingBootApplication annotation. You can find a very good example here.
Please also note that you should somehow inform the gateway about your microservices' addresses for redirection. It can be done in two general ways:
By statically defining the addresses in gateway microservice's configuration;
By applying service discovery pattern in conjunction with e.g. Netflix Eureka service registry.
The 1st approach is easy and straightforward but is not very well for large number of microservices and/or when microservices' locations can change dynamically (e.g. due to auto-scaling).
The 2nd approach requires additional component - service registry - and needs modification of other microservices (to let them register themselves in the registry). This is quite more complicated approach but is the only possible in case of complex architecture. Simple yet expressive example can be found in the same article.
UPDATE (January'19)
As of December 2018 the Spring Cloud team announced that almost all Netflix components in Spring Cloud (except Eureka) entered maintenance mode. It means that for the next year they won't receive any feature updates (only bugs and security fixes).
There are replacements for all the affected components, including Netflix Zuul aforementioned above. So please consider using Spring Cloud Gateway instead of it in new projects.
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