Here is a microservice architecture deployment diagram. All Services are docker containers which are registered to Consul Server via Registrator. Client (External – Mobile, UI) makes a call to Bouncer which is our API Proxy. Bouncer has all permissions configured on API URLs. It makes a call to Auth Server which authenticates the request and if successful it passes the Service URL to HAProxy. HAProxy then has rules configured which redirect the URL to exact service.
Service always follow a naming convention so when service is registered in consul then consul-template refreshes the HAProxy configuration in the background.
Bouncer – API Proxy gateway…all calls come to bouncer to make sure that only authenticated requests are passed to actual services
Auth Server – Single point of authentication and authorization. All applications create permissions and save in Auth Server
External ELB – All public APIs talk to External ELB which in turn are passed to HA Proxy cluster
Internal ELB – All internal APIs are routed through Internal ELBs. There will be URLs which will only be exposed to Internal Services
HA Proxy (Cluster) – The Load balancer cum service router
Consul Server (Cluster) – Centralized Service Registry
Registrator – SideCar application running with each service which updates Consul Cluster about service health
Consul Template – Background application which updates HAProxy whenever there is a change in service configurations
ECS Cluster – AWS ECS where all docker containers are registered. Takes care of dynamically launching new docker containers based on parameters. Autoscaling is handled automatically
There you have major parts in deployment..Please share your comments..Happy Coding !!
A friend posted this question on my FB account
Question 1.
I am depicting from diagram that all microservice API will proxy through API gateway. Is it true for internal cluster communication also? If yes, then wouldn’t it be too much load on gateway server for too many micro-services in infrastructure? Or will it be as lightweight as load balancer? Can I assume this gateway as a simple reverse proxy server which is just passing through the request/response then why not use Apache or Nginx?
Answer : 1st….internal cluster communication may or may not happen through Bouncer..depending on what your security requirements are.if you want all API calls to be authenticated then yes it will go through Bouncer…Point to note is.Bouncer is very lightweight Node.JS application so it will have extremely high throughput and because its behind HA Proxy you can always add new nodes…
API Proxy is a reverse proxy but with some logic…Most of the time when you want to expose an API which interacts with multiple microservices you will have to aggregate data..that logic will reside in API Proxy..Its a common pattern in large scale architecture
Question 2.
As per your description, Auth server is also responsible for authorisation here? Then how are you making sure of isolation of microservice, if it’s authorisation logic is shared to auth server the how are you making sure of data integrity which is a security measure which protects against the disclosure of information to parties other than the intended recipient.
Answer:
Auth Server is like “Google auth server”…All resource permissions reside in AuthServer..Authorization server has permissions for each application…These permissions can either be added via API by app or by an Admin UI…so each app can have different permissions…A single user will be given different permissions for different apps so isolation is guaranteed. e.g. I May have “user-create” permission in UserService but I may not have “account-create” permission in AccountService
Who creates permissions, who gives them to users.. and when depends on your design.
A geek's blog 
I would personally hold auth logic to the responsibility of the service itself. Logic now resides in more than one isolated area of the network and this is prone for failure imho. So in that aspect, chain bouncer from each individual microservice. Of course bouncer itself would be part of the cluster in its entirety, and connection would be established through (in this case) haproxy. What you now miss is also similarity in architecture for your auth, e.g. a missing registrator on bouncer. Only the microservice should know if it’s privately or publicly available, with or without auth. I can think of no actual use case in which a user could change this behaviour on the fly without having a serious change on the microservice.
LikeLike
– Registrator from bouncer has been deliberately hidden to make the diagram clutter free and only to show most important parts…Bouncer at the end of the day is also a service and it will scale and register just like other services. So it is kind of obvious
– There are some circumstances when service can decide whether it’s hidden or not but there are lot of other scenarios when it’s not possible e.g. When you have to expose an API that actually aggregates data from other services but still put some permissions on these APIs. So API Proxy gateway like Bouncer always helps…In-fact there are tools now that are especially designed for API governance. so these tools are like replacement for Bouncer.
LikeLike