Deep dive into Microservices Architecture: Spring Cloud connected to an Identity Provider
Hello everyone! :)
My name is Gabriele and I come back after 6 months since the last publication (https://medium.com/@hyseneim/java-oca-ocp-my-personal-experience-aabd3b8a99ce) to talk about a topic that I’m studying in recent times, that is, drumroll…Microservices Architectures.
In the last few years, this term has been abused exponentially by customers without asking the existential question par excellence:
What is a microservice architecture and what advantages / disadvantages does it offer?
It’s easy to draw up a list of benefits like:
- Self-consistency and independence from each other;
- Precious beautiful X² and…
I could go on for hours without getting tired, I’m trained 🙂
All beautiful words that make fashion but what’s true behind all this clamor?
And above all, if we wanted to integrate an Identity Provider what could be a solution?
To explain it in detail I decided to build a very simple project that demonstrates the power of Spring Cloud and the (objective) beauty of an Authentication & Authorization Provider, all microservices contained in a dedicated Docker container that talk to each other and bootable via docker-compose easily.
First of all, the code of this project can be found here (first read the README!):
But…don’t you think it’s time to reveal the chosen architecture?
Open the project (clone it from GitHub) with your beautiful IDE and follow the “iconic explanation” step by step…or if you are a Pro, start all the components now!
The subject that forwards the request.
It can be a PC, a mobile device, a Smart TV, the limit is the imagination!
- Authorization & Authentication Provider (AAP):
It exposes the endpoints necessary to request an access token, a refresh token and revoke a token, managing various flows (including the “password” flow, using other microservices).
He’s always in contact with the Service Discovery / Registry, through which he records and discovers the positions of the other microservices.
- Database (MySQL):
The choice of the DB for this application is indifferent (obviously, modifying the Spring connector).
The only information stored is related to the AAP, namely:
User tables, roles, access / refresh tokens and client details.
- API Gateway:
Implemented through Zuul, it is in “close liaison” with the Service Discovery / Registry to obtain information on other microservices to be registered as routes available to the client.
Moreover, it acts as load balancer (through Ribbon), as well as filter and proxy (through Hystrix) of requests.
In addition, timeouts related to requests, read times or sockets of all / some microservices are configurable through convenient Hystrix parameters.
- Config Server:
It contains the configurations of all the microservices in play that can come from different sources.
Outside the Docker container, it typically uses the filesystem or Git as sources of truth.
Inside the container, however, uses the classpath of it JAR, with the foresight to change the references of the other microservices with their logical name (specified through docker-compose.yml).
Obviously, the latter method is not recommended when you have a “cluster” of Config Servers.
PS: In the latter case, the blue-green pattern might help you when replacing configurations.
- Service Discovery / Registry Server:
Widely mentioned above, it allows the discovery and registration of microservices.
Feign is particularly useful, a tool through which you can also request other microservices using the register containing all the recordings.
- Microservice 1:
Sample microservice containing only a Hello World endpoint protected by all non-administrator users, retrieving user and role by submitting a request to the AAP (through Feign).
This architecture can be a concrete basis for your personal or business project.
I am available through Linkedin for any clarifications / additions or information on this or other projects: