I understand that sharing code between microserices in an anti-pattern, but what about sharing DTOs between the API Gateway and the services it communicates with?
Is it better to copy all of the DTOs from all of the services into the gateway?
Or is it better to have a common module that can be reused by the gateway and each service?
Related
I am confused with Zuul role in Microservice architecture.
zuul acts as a proxy and loadbalancer for internal communication between the services where in lets say no authentication is required.
zuul acts as a Api gateway which can take care of Authentication and access control functionalities for the requests coming from UI or some other external clients.
So the same zuul instance can take care of both the objectives. How it is handled in best scenario possible.
i am novice in architecture side of microservices. please excuse me if it is a silly question.
Thanks in advance.
I have implemented microservices architecture in Spring Boot. All services are accessible from the front-end. There are 2 types of API in few Microservices -
Public - (Directly Accessible from the front-end)
Internal - (for inter-service communication)
I have implemented JWT based authentication. But I want to know how to implement auth for internal APIs?
In internal API we will not get the JWT token. Auth is needed because someone can mock a private API.
For Authentication, we are using an auth service. All other services call the Auth service before every API call to authenticate the request.
Auth is needed because someone can mock a private API
While this may be true, an attacker would need to be inside your network already.
However, assuming you still need secure intra-service communication, you could look at service discovery to mediate this communication. Service registry platforms such as Eureka or Consul, will allow you to set up service discovery.
Eureka is commonly used in sprint boot applications, and is fairly lightweight, but weighted toward AWS hosting.
In addition to other benefits, such as configuration management, failure detection, and load balancing, these platforms will also enable you to secure your intra-service communication.
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 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 have read few details of use of api gateway in microservices architecture. I have read that it basically helps with security , transformation , throttling etc. Is orchestration also one of it responsibilities? When I read about microservices , I saw that it should have dumb pipes and smart endpoints and services must be choreographed and not orchestrated. So my assumption is that orchestration is not a responsibility of api gateway.
Probably no orchestation but there is a pattern called API Gateway
Using an API Gateway
Usually a much better approach is to use what is known as an API
Gateway. An API Gateway is a server that is the single entry point
into the system. It is similar to the Facade pattern from
object-oriented design. The API Gateway encapsulates the internal
system architecture and provides an API that is tailored to each
client. It might have other responsibilities such as authentication,
monitoring, load balancing, caching, request shaping and management,
and static response handling. pattern call API Gateway
https://www.nginx.com/blog/building-microservices-using-an-api-gateway/
http://microservices.io/patterns/apigateway.html?utm_source=building-microservices-using-an-api-gateway&utm_medium=blog
https://www.nginx.com/blog/microservices-reference-architecture-nginx-proxy-model/